A Synthetic Pentest Finding: Evidence, Fix and Retest

Sources checked: 5 November 2026. FailSafe Research.

A finding is useful when an engineer can trace the observation to a control and verify the change. This worked example uses a fictional cross-workspace document lookup. It is a report-writing and review aid, not a customer incident or an executed assessment. Its limited scope makes it possible to explain the evidence chain without publishing credentials, sensitive data or an operational exploit.

What does the approved scope establish?

The fictional owner approves an isolated staging application, two synthetic workspaces and a read-only document retrieval workflow. Reader A belongs to Workspace A. Document B belongs only to Workspace B. The written policy says Reader A must not receive Document B, whether directly in a response or indirectly in an AI model's context.

Record the application build, policy version, permitted identities and test window. Agree an attempt budget, monitoring and a stop contact. Any real record, unexpected side effect or unapproved service ends the test until the owner reviews the scope. For an MCP-connected version of this scenario, use the safe tool-permission walkthrough.

Which observations belong in the finding?

First record a legitimate control: Reader A can retrieve synthetic Document A. Then record the approved boundary case involving Document B through the same supported workflow. In the deliberately defective example, Document B is returned. The finding describes the expected denial and the observed disclosure separately. It does not infer administrative access, a wider data breach or all-tenant impact from this single read.

Preserve sanitized trace references, caller role, object ownership, the server's permission decision and whether the content reached the model or user. A final answer that omits the document does not establish that earlier retrieval was blocked. Conversely, a proposed tool call is not proof that a server accepted it. Explain the actual stage at which the boundary failed.

How should an engineer evaluate the proposed fix?

The example proposes binding the object lookup to the authenticated caller's permitted workspace on the server. This follows the general principles in the OWASP authorization guidance. The engineer still needs to review the specific implementation and its legitimate uses. A prompt instruction or a tool's read-only label cannot grant or enforce object ownership.

When authorized source access is available, a testing workflow may produce a remediation pull request. Your team reviews the change and controls deployment. A proposed PR, merged commit and deployed fix are three different states; the finding should link to the relevant one rather than saying that an automatically generated change resolved the issue.

What does a bounded retest look like?

Illustrative retest after the reviewed fix is deployed

Case	Expected result	Illustrative outcome
Reader A retrieves Document A	Allowed	The legitimate read still works.
Reader A requests Document B	Denied before content retrieval	No restricted text reaches the model or user.
Approved search and preview variants	Same object policy	Record each result and leave unavailable variants unverified.

The resulting statement is specific: resolved for the tested path and configuration. Other roles, tools, deployments and data migrations remain outside that statement. Record failures and inconclusive cases alongside successful controls, using the original finding reference so the history remains traceable.

How does this relate to agent-security research?

FailSafe's NEAR AttackBench research explores how the model and runtime interact under adversarial pressure. This example applies that framing to an evidence package: record the runtime decision as well as the model's response. It introduces no new benchmark result and does not claim the benchmark tested this application.

Download the synthetic finding record and adapt its fields to an authorized engagement. Keep the filled report in the agreed secure channel. For a broader closure process, read the retest evidence checklist. Teams evaluating agentic penetration testing can use the record to compare the usefulness of proposed deliverables, and review the first-pentest offer only after confirming the target fits its available scope.