An agent can interpret a request, consult information and ask connected tools to act. Each transition introduces a permission question. Which identity is acting? What data may cross that boundary? Which consequences require a person's decision? A useful security review answers those questions in the surrounding application and tool controls, so permissions do not depend solely on the model interpreting instructions correctly.
Map actions to their source of authority.
Inventory the tools available to the agent and classify their effects: reading information, changing internal state, sending external communications or making an irreversible commitment. Record the credential or delegated identity each tool uses, its resource scope and the component responsible for checking permission. A single tool can expose actions with very different consequences.
Define the review environment and approved fixtures before exercising a workflow. Include the user roles, connected services and data classes in scope. If a tool cannot be reviewed safely, document that limitation instead of inferring its behavior from its description.
Keep retrieved content outside the permission decision.
Documents, messages and tool results can supply information without granting authority. Trace how the application distinguishes those sources from the user's request and from application policy. Review whether content from a less trusted source can influence a proposed destination, selected account or action, and identify the independent checks that constrain the result.
The boundary should remain understandable without relying on a model's explanation of its own behavior. Tool adapters can validate allowed operations and resource access against the authenticated context. Retrieval controls should restrict which information reaches the agent in the first place.
Make approval specific enough to mean something.
Where approval is required, show the consequential details before execution: the action, account, destination, relevant data and expected effect. Check how the system binds that decision to the operation it subsequently performs. An approval for one recipient or resource should not silently apply to a changed request.
Review the interval between approval and execution. A changed permission, expired session or revised action may require a fresh decision. Establish which routine actions can proceed within a defined delegation and which need a new human checkpoint. Broad, repetitive prompts can obscure the decisions that matter.
Review interruption as part of the workflow.
Agents and connected tools can time out, retry or resume after a partial result. Trace how the application records an attempted action and determines whether it already completed. For changes with external effects, recovery needs a clear state model and a way to prevent unintended repetition. A tool error alone does not prove that no change occurred.
Keep evidence focused on decisions and outcomes: requested action, acting identity, authorization result, approval where required and observed tool effect. Minimize retained content, redact secrets and define who can inspect the record. Logging every prompt is not automatically useful evidence.
Retest the control, not just the response.
After remediation, verify that the surrounding control enforces the intended permission and that an allowed workflow still completes. Include relevant changes to identity, resource scope and approval state, using the agreed fixtures. Confirm the actual tool outcome rather than judging success from the agent's final message.
Report which tools, identities and workflow stages were reviewed, alongside unavailable integrations and unresolved assumptions. Model behavior can vary, so distinguish a sampled observation from a deterministic application check. The conclusion should explain the boundary supported by the evidence and the conditions under which it was evaluated.
A methodology note by BreachQuill Labs. This article describes a review approach; it is not a client case study or a disclosed finding.