Blackbox scanning agents
The main researcher, the specialist team, how the agents coordinate, and how candidates are independently verified.
Blackbox begins without supplied authenticated target accounts. The research team works from the application's accessible pages, requests, scripts, APIs, and observed behavior within the Run's permitted boundaries.
The Main Researcher: One Agent
The main researcher starts the investigation and remains responsible for coordinating the assessment. It discovers the initial application surface, selects promising questions, loads relevant skills, executes tests, and records evidence. It also collects specialist results and tracks unfinished work in the shared research ledger.
- 1Discover the surfaceThe initial application surface.
- 2Select questionsChoose the most promising ones.
- 3Load skillsRelevant investigation guidance.
- 4Execute testsThrough the available tools.
- 5Record evidenceAnd track unfinished work in the shared ledger.
Coordination does not mean waiting for the other agents. After delegation, the main researcher continues its own investigation while specialists work on their assigned areas. It can submit supported vulnerability candidates for verification just as a specialist can.
Its starting context includes the permitted application addresses, testing mode, profile policy, available tools, and any declared account references. Each tool result provides new observations for the next decision. For example, a page containing a search form and a document-download link gives the researcher two concrete features to investigate. Their presence alone does not establish an injection flaw or an access-control failure.
The Specialist Team: Up to Three Agents
After initial reconnaissance establishes enough application surface, the runtime normally launches one automatic wave of three specialists. Each receives a different research area and claims work in the shared ledger. The default assignments are:
- 1Initial reconnaissanceEnough application surface is established.
- 2One automatic waveThree specialists are launched.
- 3Each gets a research areaDifferent from the other two.
- 4Claim work in the ledgerBefore testing a question.
| Specialist | Main responsibility | Example investigation |
|---|---|---|
Authorization and business logic (authz-logic) | Authentication boundaries, object and function permissions, privilege changes, and workflow rules. | Determine whether an observed public operation exposes data or permits an action that should require authentication. |
Server-side injection (injection-serverside) | SQL/NoSQL and template injection, command injection, SSRF, XXE, file/path handling, and deserialization. | Follow an input anomaly with a baseline, a controlled variation, and evidence of the resulting behavior. |
Client-side and API behavior (client-source) | XSS, CSRF, CORS, redirects, JavaScript-discovered routes, WebSocket behavior, and API authentication. | Connect an observed page or API request to a client-side or cross-origin security question. |
Authorization and business logic
The authorization and business-logic specialist examines who can perform an operation and under which conditions. It establishes normal behavior, identifies a relevant permission or workflow boundary, and compares controlled variations. In Blackbox, its conclusions must reflect the access actually available; it cannot assume access to two signed-in accounts that were never configured. Evidence must show the unexpected data access or completed action.
Server-side injection
The server-side injection specialist follows inputs that may influence server processing. It compares the normal response with a targeted variation, then uses an applicable verification tool or further controlled requests to investigate a signal. A parser error is a lead, not a confirmed vulnerability. The useful output is a reproducible relationship between the input and an observable result, with the relevant request and response references.
Client-side and API behavior
The client-side and API specialist connects visible application behavior with scripts, routes, and network operations. It can investigate how a value reaches the page, whether an API enforces the observed boundary, or how an origin-sensitive operation behaves. The required evidence follows the claim: text reflected in HTML is different from Browser execution, just as an observed API route is different from confirmed unauthorized access.
Areas of investigation, not a guarantee
These are investigation areas, not a promise that every listed vulnerability class exists or receives a complete test on every application. Relevant surface, available access, evidence, and the scan budget determine the work that can actually be completed.
The team stays bounded
Specialists have separate model sessions and working records while sharing the Run's research ledger and findings store. Their tool access does not allow them to create another generation of specialist agents. The research team remains bounded.
How the Agents Coordinate Their Work
The shared research ledger records investigation questions, called hypotheses, together with their ownership, progress, and evidence references. A specialist reads this ledger and claims an applicable question before testing it. This gives the main researcher a record of which work has already been assigned and which questions remain unresolved.
- 1The ledger records hypothesesWith ownership, progress, and evidence references.
- 2A specialist claims a questionBefore testing it.
- 3Tests and returns outcomesPartial or completed. A supported candidate can be reported immediately.
- 4The main researcher collects resultsAnd uses them to guide the remaining work.
The agents share structured results rather than one unrestricted conversation. A specialist receives observed surface and assigned work, loads relevant skills, performs tests, and returns partial or completed outcomes. The main researcher collects those results and uses them to guide the remaining work. A specialist can report a supported candidate immediately and then continue its other assigned questions.
Skills and tools are not agents
Skills provide investigation guidance; tools perform operations and return observations. Neither is another AI teammate. Saving an artifact, maintaining the ledger, or generating a report also does not add a separate reporting agent.
Independent Verification: Additional Sessions When Needed
A researcher or specialist submits a candidate with its supporting evidence. The runtime validates that submission before scheduling verification. An independent verifier then examines the claim in a fresh session, reproduces the relevant behavior, and uses a benign or negative control where required.
- 1Submit a candidateWith its supporting evidence.
- 2The runtime validates itBefore verification is scheduled.
- 3An independent verifierA fresh session reproduces the behavior, with a benign or negative control where required.
- 4Confirmed, rejected, or inconclusiveThe verifier's outcome.
- 5A verified FindingOnly a confirmed candidate that passes the reporting requirements.
The verifier can return confirmed, rejected, or inconclusive. Only a confirmed candidate that passes the reporting requirements becomes a verified Finding. A plausible explanation from a research agent is not enough. The saved finding's title, classification, severity, description, and impact follow the verifier's structured assessment; see What's new.
Confirmed
Confirmed means the verification requirements were met.
Rejected
Rejected means the tested claim was disproved by the verifier's evidence.
Inconclusive
Inconclusive means the available evidence or prerequisites did not settle the claim.
Rejected and inconclusive outcomes remain useful investigation records, but neither becomes a verified Finding merely because the original researcher considered the candidate promising.
Verification is asynchronous: research can continue while submitted evidence is being checked. Different candidates can have separate verifier sessions, and a retry can create another session. A rejected submission or failed prerequisite may never reach a verifier model call. Consequently, the verifier is a separate responsibility with a variable session count, not one permanent fifth agent assigned to every Run.
For example, a Blackbox assessment can progress through these counts:
- Main researcherStarts and coordinates the assessment
- Authorization and business logicauthz-logic
- Server-side injectioninjection-serverside
- Client-side and API behaviorclient-source
- Independent verifierAdded when a candidate is submitted
Initial reconnaissance. One main researcher.
| Situation | Agents involved |
|---|---|
| Initial reconnaissance | 1 main researcher. |
| Full automatic research wave | 4 research agents: one main researcher and three specialists. |
| Full team plus one active verification session | 5 agents at that point, if all four research agents are still active. |
| Several candidate submissions | The research team plus the verifier sessions actually started; the total varies. |
For an illustrative public document portal, the main researcher might map search and download features. The authorization specialist examines access boundaries, the injection specialist investigates search-input handling, and the client/API specialist examines script-discovered operations and page behavior. Each follows its assigned evidence. If one submits a supported candidate, an independent verifier checks that specific claim while the remaining research can continue. This is an example of responsibility allocation, not a prediction of findings on every portal.