TL;DR: Excessive agency arises when an LLM system can cause damaging effects through more functionality, permission or autonomous decision power than its task needs. Review those dimensions separately, then trace how they combine in the actual execution path. Narrow tools, scoped authority and appropriate decision gates help only when enforced for the real resources, recipients and cumulative effects.
How to approach it
Start with a supported task and the authority it requires. In the fictional Alder operations assistant, an engineer asks for a service-status summary. The assistant needs selected status data and runbooks; that task does not require changing production configuration or publishing an incident announcement.
A strong answer
The OWASP 2025 Excessive Agency entry describes three recurring roots: excessive functionality, permissions and autonomy. OWASP's September 2026 announcement places Excessive Agency at number three in the 2026 edition. Keep the edition attached to the identifier: LLM06:2025 and LLM03:2026 refer to different editions, not two independent findings.
Required task
Service status and selected runbooks
Functionality
Only applicable operations
Permission
Current resources and recipients
Autonomy
Valid grant and required decisions
Each dimension has its own boundary
Removing a write tool does not establish the remaining read scope. Narrowing a token does not decide whether the task may publish the returned data.
| Dimension | Excess in the status-summary task | Enforced correction |
|---|---|---|
| Functionality | A tool exposes status, configuration changes and publication when only status is needed | Expose the required operations or restrict the general tool's supported methods and targets |
| Permissions | A downstream credential or role reaches unrelated environments or records | Apply task and resource scope using trusted identity and current backend policy |
| Autonomy | The agent can commit a change or publish a message without the applicable decision | Require the grant or review defined for that actual effect |
Functionality is more than the number of tools. A narrow status tool can constrain service IDs, fields, result size and freshness. A general HTTP or SQL tool can also have meaningful enforcement, but its supported operations and parameter space need review. Replacing a free-form string with a typed string does not by itself restrict which resource the caller can reach.
Remove unused development capabilities when they are unnecessary, but investigate rare legitimate operations before deleting them. Recovery and maintenance workflows may be infrequent yet important. They can use a separate grant or isolated workflow instead of being available in every conversation. Usage frequency is evidence for this decision, not a universal necessity test.
Permissions must match the acting task. Establish workload identity and the user delegation or service-owned grant through trusted application state. Enforce tenant, object, environment and recipient constraints at the relevant service. The ability to read an internal runbook does not permit publishing its contents to every audience.
A broad service credential behind a narrowly implemented tool is a defense-in-depth concern; it does not prove that the model can exercise every credential permission through the current interface. Trace the effective path and the assumptions that constrain it. Narrow the credential where possible so a tool defect or newly exposed route does not silently expand the consequences.
Choose credential lifetime, renewal and revocation behavior for the workflow. A short lifetime limits exposure but does not authenticate model-supplied arguments or immediately stop already queued work. Long-running jobs need current authority and shared limits, not a permanent administrator token supplied for convenience.
Autonomy is a policy decision. Some consequential work can execute automatically under a valid bounded grant and independent checks. Other effects need an additional qualified decision or are prohibited. Assess affected parties, disclosure, cost, recovery and evidence quality; a read can leak data, and an editable comment can already have notified recipients. Reversibility alone is not a reliable classifier.
The model can propose a next step and explain it. The execution boundary checks whether that effect is permitted now. Required approvals should identify the actual target and terms and come from an authorized decision-maker. A valid existing grant should continue to cover its intended actions; asking again after every reasoning step adds friction without automatically strengthening the boundary.
Worked redesign. Alder's status-summary task receives a constrained service-status operation and access to selected runbooks. It can prepare an internal answer for the authorized engineer. Configuration changes and publication remain outside this task's grant. A separate incident-response task may legitimately receive those operations with appropriate scope, current policy and decision rules. The improvement is narrower effective authority for each task, not a promise that the system will never need powerful tools.
Prompts can communicate policy and help the model choose useful actions. Detection models can supply additional signals. Neither should be the sole mechanism that decides identity, object access, recipients or aggregate allowance. Check those at the effect boundary and test them independently of the model's willingness to comply.
What interviewers probe next
- “How does this relate to a confused deputy?” A privileged service can misuse its authority for a caller's request unless it checks the applicable task and resource permission. Distinguish that execution path from merely possessing a broad credential.
- “How do you evaluate the change?” Compare reachable effects and forbidden executions, along with legitimate task completion and unnecessary denials. Fewer tools alone is not a risk estimate.
- “Can budgets solve it?” Budgets can bound quantities and resource use. One unauthorized disclosure or destructive effect may still be unacceptable below every quota.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Alder’s operations assistant has a general service API, a broad credential and permission to act immediately. Its current task is only to summarize one service’s status.
Start here
Which three dimensions need review?
Distinguish supported operations, effective access and commitment decisions.
Functionality covers which operations and argument space are exposed; permissions cover the resources and effects the authenticated task can reach; autonomy covers which decisions can proceed without additional review. Compare all three with the status-summary task’s actual needs.
Carry it forwardEach dimension can be excessive independently.
Weak answerFixing one dimension and assuming the others are covered.
Constraint changes
Does a narrow status tool make the broad credential irrelevant?
Inspect both the current path and its failure assumptions.
No. The narrow implementation may prevent the current model interface from exercising broader rights, but the credential still increases consequences if a defect or new route exposes them. Describe that assumption and reduce the credential’s scope where possible rather than claiming either total safety or immediate unrestricted model access.
Carry it forwardEffective reach and latent credential authority both matter.
Weak answerEquating a broad credential with proven access through every tool call.
Constraint changes
Must the assistant ask again for each covered status read?
Use the applicable grant and current policy.
No. Reads within the valid task grant can proceed while enforcing source access, output audience and resource limits. Additional authority is needed when the effect or policy requires it, not merely because the model plans another step. A read can still need strict disclosure controls.
Carry it forwardUseful automation operates within enforced authority.
Weak answerUsing repeated confirmation as a substitute for scope.
Now defend it
What would the redesign demonstrate?
The selected status summary works, unrelated environment access and publication remain denied, and current identity and task policy govern each effect. Document rare workflows separately and compare outcome evidence alongside usability and resource use.
How it's scored
These are site-authored practice criteria, not a reported employer rubric.
Weak: Defines the problem only as too many tools or proposes a warning in the system prompt.
Hire: Separates functionality, permissions and autonomy and locates the enforcement for each.
Strong Hire: Traces effective authority, handles task-specific service or user grants, preserves useful automation and evaluates actual effects rather than counting tools or confirmations.
Common mistakes
- Assuming a narrow tool automatically narrows its credential or recipient policy.
- Treating every general-purpose interface as unbounded without inspecting its enforcement.
- Removing rare capabilities solely because ordinary usage logs seldom exercise them.
- Equating more confirmation prompts with less excessive agency.