How it works
A white-box pentest runs in two linked stages. First the agents read your source code and build a model of it, producing a set of candidate vulnerabilities with the code evidence that explains them. Then the agents probe your live application and confirm which candidates an attacker can actually reach and exploit.
Each stage is itself a multi-agent workflow, and each stage builds on the previous one. The whole run works without human intervention: you start it, the agents do the work, and you review the results when they are ready.
Stage one: static source analysis
The agents acquire your source and build a structural model of the codebase: entry points, frameworks, data flows, and trust boundaries. This model enables taint analysis, call graph traversal, and cross-file data flow tracking.
The analysis follows data flows from source to sink, noting where user input enters the system, where the system sanitizes it (or fails to), and where it reaches a sensitive operation. The agents map authentication checks, authorization boundaries, and configuration to understand where the application enforces security. For each candidate vulnerability, an agent traces the full path from source to sink, checks for sanitization or validation that would block exploitation, and records the code evidence: the vulnerable locations, the taint flow, and a proof-of-concept description.
This stage is what the static source analysis can see that a purely black-box run cannot: latent vulnerabilities and taint flows, unsafe deserialization in library code, weak cryptography, and logic that never surfaces through HTTP. The output is a set of candidates to validate, not confirmed findings.
Stage two: live validation
The agents now treat the running application as a black box. They crawl it, following links and submitting forms to record each endpoint and parameter, respecting your excluded paths and rate limits. They analyze the crawled surface to identify high-value targets: authenticated endpoints, admin interfaces, routes that accept user input, and flows that handle sensitive data.
For each candidate the source analysis raised, an agent crafts a payload, sends the request, and inspects the response. If the response suggests the candidate is exploitable, the agent refines the payload to confirm exploitation and capture proof, iterating until it either confirms the issue or rules it out. Candidates the runtime stage cannot confirm do not become findings.
Triage and report
A separate triage agent re-examines each confirmed finding's evidence from both stages, confirms or rejects it, deduplicates findings that share a root cause, and assigns a confidence score. This pass keeps the false-positive rate low and the backlog clean.
The final stage compiles the confirmed findings, evidence, and remediation guidance into a shareable report.
Why the two sources together
Each stage covers a weakness of the other.
- A source-only audit finds a latent issue but cannot prove an attacker can reach it, because the application never runs.
- A black-box test sees only what surfaces over HTTP, so it cannot reason about the code behind the request.
Reading the code gives the runtime stage a head start: it knows where to probe instead of exploring blind. Probing the live target gives the source findings proof of exploitability. The result is findings that say both where the bug lives in the code and exactly how to trigger it.
Before you start
You need two kinds of input: the source to read, and a live target to validate against. See Prepare your target.