Excessive Agency

Domain

AI, LLM & agents

ROOTVIEL support

Verified by ROOTVIEL — A deterministic, LLM-free verifier settles a specific property under stated assumptions — either a structural property over a graph, or an effect reproduced in execution. It does not by itself mean the whole system is secure, nor that an end-to-end exploit was run beyond what the evidence scope states.

Evidence scope

Structural property — Checked over a static authority/dataflow graph — the property holds in the code; no exploit was run.

Analysis family

FAM-GENAI-STATIC

CWE

CWE-272

OWASP

LLM06

Excessive agency is the condition of an LLM-driven system holding authority — tools, permissions, autonomy — in excess of what its declared purpose requires. It is not an attack in itself; it is the standing over-grant that determines how much damage any other failure can cause. The vulnerability is the gap between what the agent can do and what it needs to do.

OWASP decomposes it into excessive functionality (tools or capabilities the task does not need), excessive permissions (broader access than required for the capabilities it does use), and excessive autonomy (acting on consequential decisions without a confirmation step). All three share one logic: the blast radius of a model error or a successful injection is bounded by the authority the agent holds, so authority granted beyond need is pure downside risk.

Excessive agency is a property of agentic systems — anything where the model can call tools, hold credentials, retain memory across steps, or act without a human in the loop. It is the amplifier that makes prompt injection and jailbreak dangerous: on a read-only assistant an injection yields a bad answer, but on an over-privileged agent the same injection yields a bad action. The richer the tool set and the longer the autonomy horizon, the more a small over-grant matters.

• ▸Agents with tool access to send messages, write records, move money, or change configuration.
• ▸Systems holding broad, long-lived credentials shared across many capabilities.
• ▸Autonomous or multi-step agents that chain decisions without confirmation checkpoints.

The right way to reason about agency is as an authority graph: nodes are capabilities, tools, credentials and data stores; edges are the paths by which the agent can reach one from another. The reachable-capability set is everything the agent can ultimately cause, following those edges transitively. Least privilege means the reachable set equals the declared purpose; excessive agency is any reachable capability outside that purpose.

Three features of agents amplify a small over-grant into large risk. Tools convert a decision into an external effect, so one extra tool edge is one extra way to cause harm. Memory lets a payload planted in one step influence a later, higher-authority step, extending reach across time. Autonomy removes the human checkpoint that would otherwise catch a bad decision, so the reachable set executes without review. Together they mean a single unnecessary permission can chain — through memory and autonomous tool calls — into multi-step, attacker-chosen harm.

Authority graph

A model of capabilities, tools, credentials and data stores and the edges by which the agent reaches one from another.

Reachable-capability set

Everything the agent can transitively cause, following the edges of the authority graph.

Declared purpose

The set of capabilities the task actually requires — the baseline least privilege should match.

The defect is a violation of least privilege in a system whose decision-maker is non-deterministic. Developers grant broad tools and permissions for convenience — a single powerful credential, a tool kept “just in case”, autonomy to avoid confirmation friction — and the model’s probabilistic decisions then run against that broad authority. Because the agent’s behaviour cannot be fully predicted, every granted-but-unneeded capability is a path an error or an attacker can take. The root cause is standing authority in excess of declared purpose.

1. 1The agent is deployed with a set of tools, credentials and autonomy broader than its task requires.
2. 2An upstream failure occurs — a prompt injection, a jailbreak, a hallucinated plan, or simply a wrong decision.
3. 3The failure expresses itself as a tool call, because the agent has the tool available.
4. 4Memory and multi-step autonomy let the effect chain: a value captured early influences a later, higher-authority action with no human checkpoint to interrupt it.
5. 5The excess authority — a permission or tool the task never needed — is exactly the edge the failure travels, producing a consequential action outside the agent’s purpose.

A synthetic, illustrative agent given a broad toolset and a powerful shared credential, acting autonomously on whatever the model decides:

synthetic — do not use; illustrates the flaw
# UNSAFE: the agent holds far more authority than its task (summarise tickets) needs.
agent = Agent(
    tools=[read_tickets, send_email, delete_records, admin_api],  # only read_tickets is needed
    credential=ADMIN_TOKEN,                                       # full admin, shared across tools
    autonomy="act",                                               # no confirmation on any action
)
# a single injected instruction in a ticket can now reach delete_records / admin_api
agent.run(user_task="summarise today's tickets")

The fix is to make the reachable-capability set equal the declared purpose: grant only the tools the task needs, scope the credential to exactly those tools, and require confirmation for anything irreversible. The model’s authority now matches its job, so an upstream failure has nothing extra to travel on.

synthetic — least privilege aligned to declared purpose
# SAFER: reachable capabilities == declared purpose (summarise tickets).
agent = Agent(
    tools=[read_tickets],                      # nothing the task does not need
    credential=scoped_token("tickets:read"),   # least privilege, not admin
    autonomy="propose",                        # consequential actions require confirmation
)
# even if a ticket carries an injection, there is no send/delete/admin edge to reach.
agent.run(user_task="summarise today's tickets")
# any future capability is added deliberately, with its own scoped credential and checkpoint.

• ▸Integrity: an over-privileged agent can write, delete, or modify records far outside its task when any failure occurs.
• ▸Confidentiality: broad data access means an injection or error can exfiltrate data the task never needed.
• ▸Authorization: the agent acts as a confused deputy, applying its excess privileges to attacker- or error-driven decisions.
• ▸Amplification: tools, memory and autonomy chain a single unnecessary permission into multi-step, consequential harm.

Excessive agency is detected structurally, by comparing what the agent can reach against what its purpose requires. This is a static, graph-based analysis: build the authority graph from the agent’s tools, credentials and reachability edges, compute the reachable-capability set, and subtract the declared purpose; whatever remains is excess. It does not require running an attack — the over-grant exists whether or not anyone has exploited it yet. The quality of the finding depends entirely on how completely the authority graph was populated.

Support level

Verified — the execution engine computes the reachable set over the authority graph and subtracts the declared purpose.

Family

GenAI (static): a structural analysis of authority, not a live attack.

Declared invariant

“Reachable capabilities must not exceed the declared purpose” — least privilege expressed over the graph.

The execution engine computes the reachable-capability set over the authority graph and subtracts the declared purpose. A FAIL is the excess — the capabilities reachable but not needed — reported with the reaching path through the graph as evidence, so the finding is not “you have too much access” in the abstract but “this capability is reachable via this specific chain of edges”. The analysis is only as good as the graph: if the authority graph is sparse or unpopulated, the engine returns UNKNOWN rather than a clean verdict.

Make authority match purpose, and keep it that way as the system evolves.

• ▸Preventive: grant only the tools the task needs; scope credentials to exactly those tools (no shared admin tokens); require confirmation for irreversible or high-impact actions (limit autonomy).
• ▸Preventive (design): prefer narrow, purpose-specific tools over broad ones; give each capability its own least-privilege credential.
• ▸Detective: compute the reachable-capability set against declared purpose on every change to tools, credentials or autonomy; flag any new excess with its reaching path.
• ▸Corrective: when excess is found, revoke the unneeded capability or credential; when a shared credential is implicated, rotate and re-issue it scoped.

Verify by recomputing the reachable-capability set after the change and confirming it equals the declared purpose with no residual excess path. Confirm the authority graph is genuinely populated — otherwise the clean result is UNKNOWN, not a pass. Re-verify whenever a tool, credential, or autonomy setting changes, since least privilege degrades as systems accrete capabilities.

• ▸Granting a broad credential (admin) shared across every tool for convenience, instead of scoping per capability.
• ▸Keeping tools “just in case” — every unused tool is a reachable edge for a failure to travel.
• ▸Giving the agent autonomy over irreversible actions with no confirmation checkpoint.
• ▸Reading an empty or sparse authority graph as “least-privilege confirmed” rather than UNKNOWN.

Excessive agency is the amplifier for the entire injection family: direct and indirect prompt injection and jailbreak all become far more dangerous when the agent they hit holds excess authority. It is the structural reason a successful injection becomes a consequential action rather than a bad answer, and it is central to the lethal trifecta, where broad authority meets untrusted input and an egress path.