Lesson 3 of 9 · 4 min read
Excessive Agency
In this lesson
TL;DR: Excessive agency means an agent can do more than its task needs through its available operations, credentials or freedom to act. Reduce each separately. Then test repeated and concurrent actions: a small per-call limit can still permit a large cumulative effect.
After this lesson, you should be able to separate functionality, permissions and autonomy; place a refund check in the enforcing service; and distinguish token expiry, single use, idempotency and cumulative limits. Agentic AI security introduces the proposal-to-execution boundary.
Before you read
Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.
1A meeting assistant needs to find free time but holds full mailbox, file-editing and calendar permissions. Which part of the design is excessive?
Three questions about authority
OWASP's Excessive Agency definition distinguishes functionality, permissions and autonomy. Its identifier is LLM03 in the 2026 edition, previously LLM06:2025, as confirmed by OWASP's 2026 reporting (checked November 2026).
| Dimension | Ask | A concrete correction |
|---|---|---|
| Functionality | Which operations does this task need? | Give an order-summary task a lookup operation instead of arbitrary SQL |
| Permissions | Which resources may this user and task act on? | Restrict lookup to the selected order and enforce access in the order service |
| Autonomy | Which consequences require an independent decision? | Keep refunds unavailable until the refund policy and any required approval are satisfied |
A narrow tool can still have broad database credentials. A narrow credential can still permit an inappropriate action on an allowed object. Approval can still be misleading. Inspect all three dimensions rather than treating one as a substitute for the others.
A tool request is not authorization
For a refund tool, derive the employee, tenant and task from authenticated application state. Check that the order belongs to the permitted customer and that the refund is eligible. Do not let the model choose its authority by supplying a customer ID or a claim that a manager approved it.
A user's permissions are the maximum the task may inherit, not the default it must receive. A support employee may work across many customers while the current task concerns one order. If a backend uses a service account internally, it must still enforce that delegated user and task scope before every operation.
Agent proposal
Order and amount
Refund tool
Validate request shape
Authorization
User, task and order
Policy and state
Balance, caps, approval
Commit once
Record operation identity
Functionality
Expose a refund operation rather than arbitrary payment commands. Typed arguments still need semantic validation.
OAuth can express some limits; services must enforce them
RFC 9700, section 2.3 recommends restricting access tokens to the necessary resources and actions, with audience validation at the resource server. RFC 9396 defines rich authorization requests for more detailed authorization data. These mechanisms require support and enforcement in the deployment; naming a field in a token does not implement its policy.
| Limit | Representation or check | What it does not imply |
|---|---|---|
| Operation | Scope or application policy | Permission for every object supporting that operation |
| Object and amount | Supported authorization details plus service checks | Automatic support for arbitrary custom restrictions |
| Receiving service | Audience validated by that service | Authorization for every action in that service |
| Time | Expiry checked at use | Only one use before expiry |
| One approved action | Bound operation ID with atomic consumption | A short token lifetime is sufficient |
For token replacement, also inspect whether earlier credentials remain usable. The trifecta lesson explains why exchanging a token is not revocation.
Worked example: a refund budget that survives retries
Use these hypothetical product rules: each refund is at most $200; refunds for one customer total at most $300 in a defined day; and an order cannot be refunded beyond its remaining paid balance. Assume enough eligible balance across that customer's orders to reach the daily cap.
Before revealing the diagram's second step, decide which rule blocks twenty distinct $50 refunds. Then decide what happens if all twenty arrive together.
Only a $200 per-call cap
Twenty separate requests
Every request is below $200
$1,000 total can pass
Outcome, unsafe: No cumulative bound
Assumes enough eligible order balance and no other limits.
Also a $300 daily total
Same twenty requests
Reserve budget atomically
After $300, reject more
Outcome, safe: Daily exposure bounded
Retries reuse an operation ID; new operations still consume budget.
Distinct requests
Idempotency does not merge twenty genuinely different operations. The shared cumulative limit must constrain their total.
The per-call rule allows each $50 request. The daily rule allows at most six, provided every call uses the same authoritative counter and reservations are atomic. Order-level balances may reject a request earlier. Specify the day boundary and the customer identity; creating another session must not reset either.
For a retry of the same refund, use a stable operation ID assigned by trusted application logic. Bind it to the customer, order, amount and approved action. The service returns the existing result for a matching retry and rejects changed parameters under that ID. Carry a stable idempotency key into the payment provider integration where supported, and retain records for the permitted retry window.
A timeout is an unknown result, not proof that payment failed. Keep the reservation until the system reconciles the outcome. If the provider does not support safe retry semantics, use status lookup or manual reconciliation instead of blindly submitting again. Local duplicate detection alone cannot undo two accepted downstream payments.
These controls limit exposure; they do not make every allowed refund correct. Six mistaken $50 refunds still reach $300. Add aggregate limits across customers and time periods according to the product's risk tolerance, and do not assume a refund can be reversed.
Practice the failure cases
What if · interview follow-ups
Hold your answer as the constraints change
A support assistant has a hypothetical $200 per-refund cap and a $300 per-customer daily budget. It can request refunds for orders selected by an authenticated employee.
Start here
What if several calls arrive at the same time?
Can two calls both read the same remaining balance?
Yes, if the service checks and updates separately. Validate ownership and eligibility, then atomically reserve from both the order balance and the customer budget. Only a successful reservation may dispatch payment. Reconcile the reservation with the external outcome rather than releasing it on an ambiguous timeout.
Carry it forwardA cumulative limit requires atomic state changes across concurrent callers.
Weak answerAdding a daily-cap query without controlling the update race.
Constraint changes
What if a request times out after the payment provider accepted it?
Does timeout mean nothing happened?
No. Keep the same operation ID and query or reconcile the provider result. If retrying is supported, reuse the stable provider idempotency key. Reject changed parameters under the same operation. A newly generated key could turn an uncertain outcome into a second payment.
Carry it forwardUncertain delivery needs reconciliation, not a new operation identity.
Weak answerGenerating a fresh key on every retry.
Constraint changes
What if the agent submits another refund with a different reason?
Does idempotency bound distinct actions?
No. A new reason can become a separate operation. Cumulative order and customer limits must still hold, and the service must decide whether another refund is eligible. Do not let arbitrary model text define the identity of an approved business action.
Carry it forwardDuplicate suppression and authorization solve different problems.
Weak answerUsing order plus free-text reason as the only safeguard.
Constraint changes
What if the agent decides that a higher limit is needed?
Who can change the policy that constrains this task?
Deny the request or use a separate authorized review workflow. A reviewer must see the specific order, amount and existing exposure. Any approved exception must be explicit, recorded and checked at execution. The agent cannot edit the cap or approve its own exception.
Carry it forwardAuthority expansion requires an independent decision within organizational policy.
Weak answerLetting the model raise its limit to finish the task.
Now defend it
How would you describe the remaining financial risk?
State the maximum permitted amount for each customer and time window under the assumptions tested, plus aggregate limits across customers. Explain that incorrect refunds within those limits can still occur and refunds may not be reversible. Name the owner who accepts that residual exposure.
What to test before relying on the bound
In an isolated system with synthetic orders, verify cross-customer rejection, exhausted order balance, parallel requests at the daily limit, repeated operation IDs, changed parameters and a simulated timeout after acceptance. Check that delegated agents and background workers share the limits. Keep caller identity, operation ID, decision and outcome in access-controlled audit records.
The question is whether the service enforces its rule even when the model supplies an unwanted request. Prompt guidance and detection can reduce mistakes; they do not replace those checks. Continue with tool-permission design to apply the distinction to a larger agent.
Check yourself
Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.
1Does a five-minute access token allow only one refund?
2Why are idempotency and cumulative limits both needed?
3The model supplies a valid order ID for another customer. What must the backend use to reject it?