An AI assistant that can explain an invoice and an agent that can approve one operate under different levels of authority. The visible conversation may look similar, but the second system can change a business record. Security review therefore needs to examine the operations available behind the chat interface.
The relevant unit of review is the workflow. A broad instruction to help the finance team does not specify who may issue a refund, which account can receive it, or what evidence must exist before the payment system accepts it.
Excessive agency has several causes
OWASP describes excessive agency in terms of unnecessary functionality, excessive permissions, and excessive autonomy. These are separate design choices. A tool can expose too many operations, a credential can authorize too many resources, or an otherwise appropriate operation can execute without a required decision. OWASP's excessive agency guidance sets out these distinctions.
An illustrative collections assistant may need to retrieve an invoice, summarize correspondence, and draft a reminder. If its integration also exposes bank-detail changes, the available functionality exceeds that task. Removing the operation from the assistant's tool list reduces this particular exposure without preventing invoice review.
Translate policy into service-side checks
For each write operation, describe the actor, target record, permitted change, and required preconditions. A refund might require an eligible payment, a remaining refundable balance, and a reviewer with the appropriate role. The service processing the refund can evaluate these conditions independently of the model's explanation.
User context also matters. A shared administrative credential can make every assistant user appear equally privileged to the downstream system. Carrying the authenticated user's identity and tenant scope through the request allows the service to apply the same business restrictions used elsewhere in the application.
Make approvals specific to the action
An approval is more informative when it identifies the exact record and proposed change. For a refund, that means the payment, amount, currency, and destination. If the agent changes those details after approval, the original decision no longer describes the operation being executed.
In a test environment, approve one synthetic refund and then alter a material field before submission. The expected result is a fresh decision or rejection. Also try replaying the original approved request. The ledger and event history can establish whether one approval resulted in one permitted business change.
Document the authority that was exercised
The assessment record can connect the user request, proposed operation, approval, service authorization, and final state. Include denials and timeouts as well as successful actions. A stalled workflow that later resumes may otherwise execute under permissions or business conditions that have changed.
For the product owner, this creates a concrete release boundary. The agent can prepare the agreed work, request a defined decision, and execute within the same account rules as other clients. Any expansion into new operations becomes a visible change in scope that can be reviewed and tested.
Sources
OWASP: AI Agent Security. The invoice and refund scenarios are illustrative, not reports of a customer incident.
