Start with the expected boundary
A surprising output is not automatically an authorization failure. State what should have been allowed or denied, for which user and tenant. That expectation should come from the permission model rather than an assumption about how the agent ought to behave.
Show who acted and what happened
Include the initiating user, agent context, relevant tool, target record or action and observed result. Distinguish the model’s suggestion, an attempted tool call and a completed operation. They imply different failures and different fixes.
Make reproduction practical
Use a minimal scenario with approved test data. Capture the configuration and preconditions needed to reproduce the outcome. An engineering team should be able to inspect the path without relying on an unexplained screenshot or a broad risk score.
Minimize sensitive information
Use synthetic identifiers where possible. Redact tokens, credentials and unnecessary personal data. Decide what the trace needs to prove and keep the evidence within agreed access and retention limits.
Verify the underlying fix
Retest the original boundary failure after remediation. Check that the intended legitimate workflow still works. A refused response may be useful, but the underlying authorization check must also prevent unauthorized data access or action.
// Synthetic example. Not a live product result.
{
"actor": "support-agent",
"initiating_user": "user_014",
"expected_scope": "tenant_a",
"tool": "read_customer_record",
"observed_result": "tenant_b",
"finding": "AUTHORIZATION_MISMATCH"
}The returned record belongs to a different customer.
Further reading
Our perspective builds on the broader work of the agent-security community. These resources offer context for evaluating agent behavior and tool access.
This is an educational perspective, not a claim of product capability or a substitute for evaluating your own system. Fuzz is building in stealth.