When answers become actions
An agent that retrieves a record or calls a business tool participates in a permission system. Its output can look correct while the underlying action uses the wrong identity, reaches another customer’s data or exceeds the initiating user’s role. That makes the permission boundary a first-class evaluation question.
Three questions for enterprise leaders
First, whose authority is the agent using? Second, which customer or tenant should its data access be limited to? Third, which actions can it perform without an additional approval? Answer these in the application and tool layer, not only in an instruction to the model.
Start with customer-facing agents
A multi-tenant application gives the evaluation a concrete boundary: one customer’s agent should not retrieve another customer’s records. Pair that with role-specific restrictions, such as a read-only user who must not trigger a write. These scenarios turn a broad concern into an observable test.
Instructions and access controls play different roles
Model instructions express desired behavior. Application-side authorization determines what a tool request is permitted to do. Evaluate the complete path from initiating user to data or action, including identity propagation, tenant scoping, service credentials and approval checks.
Evidence that supports a decision
Useful evidence identifies the actor, intended tenant and permission scope, the action attempted, the observed result and a reproducible scenario. A transcript alone may miss the significance of a tool call. Connect the trace to the permission model and distinguish an attempted violation from successful unauthorized access.
Our proposed assurance loop
Fuzz is building around a focused loop: define the boundary, evaluate agent behavior, investigate reproducible evidence and verify the fix. Our initial emphasis is authorization and tenant isolation. Continuous regression testing and runtime enforcement are future directions rather than claims of current capability.
Before an evaluation begins
Agree on authorization, test environments, approved data, rate and action limits, stop conditions, retention and the people who will review findings. A meaningful evaluation should produce evidence that engineering and security teams can use, with clear limits on what was assessed.
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.