Prove you own the asset, or no scan.
"No proof, no gate."
Pentes.io requires cryptographic proof of asset ownership before any scan runs. Users prove control through a DNS TXT record or an HTTPS path challenge — the same patterns ACME uses for TLS certificate issuance. The proof is stored on the asset row as an ownership_token, and the scan-launch path refuses to enqueue a job until that row exists and is current.
The creature in the sketch aligns a hash-etched key into the gate slot, and nothing happens until the token matches. That's the whole model: no verified ownership token, no open gate, no scan.
Your security reviewer can point at a single database column and say: this is what gates the operation. There is no configuration flag, no override, no admin bypass that skips it.
What this means in practice
- Every scan job carries the verification id that authorized it — visible in the audit log.
- Pointing the product at a domain you don't control returns a clean refusal, not an attempt.
The worker re-verifies ownership at the moment of scan.
"Stamped once outside, stamped again inside."
The scan worker re-reads the ownership_token from the database immediately before any scanner process starts. If the token has been rotated, the asset row deleted, or the asset disabled between enqueue and execution, the job aborts and writes a SCAN_REFUSED audit event. Stale state in the BullMQ queue cannot sneak a scan through.
The creature in the sketch has a first stamp in its notebook from the gate. The moment it steps into the worker box, it presses a second stamp. Both must be there. One is not enough.
Race conditions and concurrent asset rewrites are accounted for at the execution layer, not just at enqueue time. The second check is not optional and has no bypass path.
What this means in practice
- Aborted jobs leave an audit row with the exact reason — token rotated, asset disabled, ownership revoked.
- No code path runs a scanner before the second ownership token check passes.
Non-destructive probing, enforced at the image layer.
"Dust the jar; never swing the hammer."
All Pentes.io scan templates are architecturally non-destructive. Nuclei runs with -exclude-tags intrusive,exploit,dos,fuzzing. OWASP ZAP runs in baseline (passive) mode only. testssl.sh inspects TLS posture without active renegotiation. The ephemeral worker container has no exploit modules installed — the constraint is enforced at the image layer, not by a runtime flag that could be changed.
The creature in the sketch dusts the jar with a feather duster. The sledgehammer sits in the corner with an X through it. Observation only — the jar stays intact and nothing inside it changes.
Safe to run against production. No proof-of-concept payloads are delivered to your asset. When the job ends, the worker container is destroyed — nothing persists on your infrastructure.
What this means in practice
- Intrusive scanner templates are removed from the worker image, not just disabled at runtime.
- Each scan container is destroyed when the job ends — no persistent agent on your infrastructure.
The triage LLM reads SARIF — never your systems.
"The AI lives in a sealed box."
The triage LLM (Anthropic Claude, claude-haiku-4-5) sees a SARIF document plus minimal asset context — no credentials, no session tokens, no system access. It has no shell, no network reach to any scan target, and no tool-use channel. Output is parsed as strict JSON at the service boundary; malformed responses are rejected, not surfaced as findings.
In the sketch, SARIF goes into a slot on one side and a JSON report comes out the other. The box has no wires leading anywhere else — no connection back to your systems, no way out except through the output slot.
The AI cannot invent findings that aren't in the SARIF input, and it cannot attempt anything against your asset regardless of what it is prompted with. The constraint is architectural, not a policy.
What this means in practice
- Every triage claim links back to the raw SARIF result it was grounded in.
- Malformed model output is rejected at the parse boundary, not surfaced as a finding.
One tenant per org, enforced at two database layers.
"One key, one drawer, one tenant."
Every Pentes.io repository method takes orgId as a mandatory first argument, and PostgreSQL row-level security enforces the same scope at the database layer. Even a buggy service cannot read another org's findings, assets, or reports — the constraint is held independently by application code and by the database. The audit log records which org each query ran under.
The creature in the sketch inserts its key into the org B drawer and the drawer opens. Every other keyhole in the cabinet physically rejects the same key. The pile of extra keys on the floor is irrelevant — none of them fit.
A SOC 2 reviewer can be shown the RLS policy and the per-query audit log. The isolation is not a promise in code comments — it exists at two independent layers.
What this means in practice
- Cross-tenant reads are impossible at the database layer, not only at the application layer.
- Every scan job, finding, and report is stamped with the org id that authorized it.
Attributed egress — every scan from a static IP with a PTR record.
"When the scanner steps out, it wears a name tag."
Production scanner traffic leaves through a Hetzner dedicated server with a static IP and a PTR record pointing at scanner.pentes.io, plus a matching forward A record. No CGNAT, no shared cloud IP range, no residential connection. Any network operator receiving the traffic can resolve the PTR record and reach the product domain immediately.
The creature in the sketch steps through a doorway labeled scanner.pentes.io and hangs a name tag around its neck. The identity is visible the moment it crosses the threshold — not hidden, not borrowed from a residential ISP.
If a target's WAF logs or abuse desk flags the traffic, the PTR record answers the question before a human needs to. The authorization evidence lives in the audit log if escalation requires it.
What this means in practice
- Abuse complaints can be matched against the audit log to confirm authorization for any specific scan.
- Scanner IPs are documented in the operator runbook and never overlap with the application plane.