Greybox scanning agents

Greybox uses the same one-plus-three research structure. The difference is the authenticated application context available to the agents. Account setup affects which comparisons can be performed, rather than multiplying the research team.

The team and its coordination are described in Blackbox agents.

4 agents activeStage 1 of 3

• Main researcherStarts and coordinates the assessment
• Authorization and business logicauthz-logic
• Server-side injectioninjection-serverside
• Client-side and API behaviorclient-source

Account contextAccount A

One account. One main researcher plus up to three specialists. Authenticated behavior can be compared with relevant unauthenticated or negative controls.

Pause animation

Greybox Environment

In Greybox Environment, the runtime supplies the configured account access to supported request operations. The main researcher and specialists use the saved account references when investigating authenticated endpoints, API operations, permissions, and workflows.

The authorization specialist can compare an account's normal access with unauthenticated access or, when configured, a second account. The injection and client/API specialists investigate their respective areas using the appropriate authenticated context. All three continue to work from observed application behavior and recorded evidence.

For a document-ownership comparison, the relevant agent first establishes that Account A can access its own document and Account B can access its own. It can then compare equivalent operations across those ownership boundaries, with anonymous and negative controls where applicable. The runtime retains the account identity associated with each result. A response difference alone does not prove unauthorized access; the candidate needs evidence of the claimed data exposure or action before independent verification.

1. 1Account A reads its own documentEstablishes normal access.
2. 2Account B reads its ownThe same baseline for the other account.
3. 3Compare across ownershipWith anonymous and negative controls where applicable.
4. 4Evidence of the claimA response difference alone does not prove unauthorized access.
5. 5Independent verificationBefore it can become a verified Finding.

Greybox Browser

In Greybox Browser, agents explore the application through the declared account Browsers. The main researcher and specialists can inspect pages, navigate observed features, interact with relevant controls, and relate UI actions to captured requests and responses.

Specialist assignments remain authorization/business logic, server-side injection, and client/API behavior. The automatic wave assigns a primary exploration role to each specialist from the configured accounts. Operations must retain the correct account reference; a generic HTTP request does not automatically inherit a Browser's authenticated session.

The runtime coordinates Browser operations and preserves their evidence references. Several research agents therefore do not imply several agents clicking the same page at exactly the same moment. The verifier uses fresh verification context and the relevant account binding to assess a submitted Browser candidate.

For example, opening a document from an application's menu produces several distinct observations: the control selected, the navigation or UI change, and the requests associated with loading the document. A Browser investigation connects these records before drawing a conclusion. A page screenshot can show visible state, while captured request and response references support analysis of the underlying operation. An unavailable response body or changed element reference leaves an evidence or interaction gap to resolve; it does not itself establish a vulnerability or an account logout.

1. 1A control is selectedFor example, a menu item.
2. 2Navigation or UI changeWhat the page shows afterwards.
3. 3Requests are capturedThe requests that load the document.
4. 4The records are connectedBefore any conclusion is drawn.

Account Count and Agent Count Are Separate