Pentest: red-teaming

Pentest is inline’s autonomous red team. AI agents attack a repository’s own source code inside an isolated sandbox, prove exploitability with a non-destructive proof-of-concept, and surface only findings they could actually demonstrate. It’s the offensive complement to Sentinel’s defensive scanning: where Sentinel asks “are we exposed to a known CVE?”, Pentest asks “can I break this code myself?”

It’s an opt-in per-repo module. Every engagement runs against code the operator owns, in a sandbox, under enforced safety rules.

The discipline: prove, don’t guess. One proven Critical beats ten speculative Lows. Non-destructive proofs only. Precision over volume.

# The multi-agent pipeline

An engagement fans out across four phases:

1. Enumerate — a fast-model agent with read-only tools maps the attack surface: the stack, entry points, sinks, and auth model. This map is shared with every finder.
2. Find — one agent per enabled attack class, each focused exclusively on its class, tracing input from entry point to sink and returning candidate vulnerabilities.
3. Validate — candidates are ranked by severity then confidence, and the strongest go to a frontier-model agent with a screened command tool. It attempts a real, non-destructive PoC (it may install deps and start the app) and returns a verdict: validated or not, with the PoC, evidence, revised severity, and remediation.
4. Report — a deterministic step (no model) persists findings, computes surfaced vs. suppressed, and emails.

# Attack classes

Twelve, each mapped to a CWE, all on by default:

injection (89)      cmd-injection (78)   broken authz (285)
ssrf (918)          xss (79)             hardcoded secrets (798)
deserialization (502)  path-traversal (22)  ssti (1336)
xxe (611)           open-redirect (601)  auth weakness (287)

You can narrow the set per repo.

# Safety is enforced in code

The safety guarantee is not a prompt request — it’s a screened shell. The validation agent’s command tool passes every command through a denylist that blocks destructive or exfiltration operations before they run: recursive rm, disk wipes, shutdown/reboot, fork bombs, curl | sh, reverse shells, raw device writes, git push, firewall changes, and more. Blocked commands return an error the model adapts to — they never execute, and every command is logged to the run’s audit timeline. There’s no network egress tooling by design.

Additional guardrails: a per-run cost cap, validation count and time budgets, and safe mode locked on in v1.

# Findings

Severity runs critical / high / medium / low / info. A finding surfaces only if it was validated and meets the severity floor — everything else is stored with an honest suppress reason (unproven: … or below severity floor), never silently dropped. Candidates the budget never reached are stored unproven too. Findings dedup by a (category, file, sink) fingerprint, so re-runs update rather than duplicate.

# The case file

Every run produces a case file — used in the portal and on a public share page — that reads like a real pentest report:

• A run header with status, trigger, and summary; a meta grid (validated / candidates / suppressed / cost).
• Validated findings as cards: severity + CWE, the attack path (entry → data flow → sink), the proof-of-concept, evidence, and remediation.
• A collapsible agent decision timeline from the run’s log.
• A collapsible suppressed candidates list with the reason each wasn’t surfaced.

The public report lives at /p/<token> — read-only, noindex, no account needed.

# Running it

• Manual — “Run now” from Pentest → Settings. An engagement already in flight is returned rather than stacked.
• Scheduled — a sweep runs due configs (daily / weekly / monthly), atomically claiming each so two workers never double-enqueue.

# Configuration

Admin-only, per repo:

Status: Pentest is inline’s newest module. Config for routing validated findings into the auto-fix pipeline exists but that wiring is not yet active — findings are surfaced and shared today; automated remediation is on the roadmap.