Reading does not imply sending
The account may read a fictional dossier and prepare a local note, but may not send it. Expected: reading and drafting work; the control rejects sending. The note’s quality does not change that boundary.
In-depth practical guides
Validate an AI agent’s actions before granting permissions
Separate proposal, authorization and execution, then check target objects, confirmations and the effects of a retry.
Updated :
Transparent panels and documents in a control workspace. Illustrative scene.
Does a correct answer authorize the next action?
A well-written note does not establish permission to send it. OWASP treats excessive agency as a distinct risk. This proposed method starts with a concrete contract between a person, an operation and an object; the examples use only a simulated service and fictional data.
Describe the effect and its scope
State who may do what, to which dossier, for which recipient and until when. Distinguish reading, drafting and sending. Each step can require a different permission; document access does not grant redistribution rights.
Separate the three states
Trace a proposal, an authorization and an execution. Model-generated wording, a checkbox inside a document or an old conversation cannot replace the control governing the specific action.
Check the parameters actually executed
Have the application check the actor, object, operation and final parameters. Test an allowed object and an out-of-scope object. Observe an effective refusal by the simulated service, not just the agent’s explanation.
Bind confirmation to the exact proposal
Show recipient, content, revision and consequence before confirmation. Under this test contract, changing any of them invalidates the previous approval. Recheck permissions at execution time even if the proposal has already been approved.
Examine retries and revocations
Simulate a lost response after an effect was recorded, followed by an identical retry. Verify the intended duplicate-handling behaviour instead of assuming that an identifier or HTTP method is enough. Also test permission removed between approval and execution.
Situations and decisions
Typical situations for preparing a check. They do not describe completed assignments or actual observations.
Recipient changed after confirmation
The approved proposal named one test recipient; the final call names another. Expected under this procedure: no effect, and a new proposal for review. Do not reuse approval bound to different parameters.
Effect recorded, response lost
The test double records an operation, then simulates a timeout before replying. A retry must not be treated as a first attempt without checking operation state. Observe the number of effects recorded by the double.
Permission revoked between stages
Modification rights are removed after human approval but before simulated execution. Expected: the execution-time check rejects the action. A previous confirmation does not restore revoked permission.
Worked exercise
A repeated operation is not a new authorization
Fictional example: the values and documents teach the method and do not describe a real organisation.
Starting information
Fictional exercise. The simulated service binds each identifier to fixed parameters and rejects changes. OP-17 with content v1 and recipient A is authorized and recorded; its response is lost. A second OP-17 call uses exactly v1 and A. A third reuses OP-17 with recipient B. What should be observed?
Your checks
- Count recorded effects rather than calls alone.
- Check whether the second request has exactly the same parameters.
- Treat a changed recipient separately from an identical retry.
Read the answer
Answer and decision
Under the stated contract, exactly one effect is recorded. The second call returns the first operation’s state without processing it again. The third is rejected as a parameter conflict; reusing OP-17 does not authorize it. A new target requires a new proposal and the prescribed control.
If the case changes
If the double cannot recover state after the timeout, the outcome remains unresolved. Infer neither no effect nor success; arrange reconciliation or human verification before a risky retry.
Record to retain
Record initial approval, each attempt’s parameters, the duplicate-handling contract and effect count. This demonstration identifier proves nothing about a real API.
Documentation reference : OWASP — LLM06:2025 Excessive Agency · Consulted on
Record to retain
- Test identity and role, allowed objects and prohibited operations.
- Exact proposal: content, recipient, revision and validity period.
- Authorization decision, checked parameters and state at execution time.
- Operation identifier, attempts, responses and number of recorded effects.
Official references
Related protocols
Checks before reaching a conclusion
- Does the control reject an out-of-scope object or recipient?
- Does a content or revision change invalidate the old confirmation?
- Is revoked permission taken into account before the effect?
- After a timeout, can you distinguish no effect, a confirmed effect and an unresolved state?
Frequently asked questions
Is human confirmation sufficient?
It approves a proposal in a particular context. The final action must still match that proposal and current permissions must remain valid.
Does a timeout mean nothing happened?
No. It describes what the client did not receive within the deadline. The service may have recorded the operation; check its state before deciding to retry.
Does the same identifier guarantee one effect?
Only if the service implements and tests an appropriate duplicate-handling contract. The exercise states that contract explicitly; do not assume a real API provides it.