Understanding Excessive Agency Vulnerabilities in AI
Sweet team
|
October 26, 2026
A language model produces text. It becomes a security problem when that text reaches a system holding more authority than the task requires. Excessive agency is that condition. This guide traces the path from untrusted input to irreversible action, along with the design and runtime controls that narrow it.
Key takeaways about Excessive Agency
- Excessive Agency arises when an AI system has more tools, permissions, or independent decision-making authority than its assigned task requires, turning manipulated output into consequential action.
- In LLM systems, indirect prompt injection can influence plans and tool choices; the resulting harm depends on the connected capabilities, inherited identity, accessible data, and ability to proceed unchecked.
- PHP2Shell and EchoLeak illustrate how untrusted content combined with connected execution or outbound access can create command-execution or data-exposure paths, even without a user click.
- Reducing risk requires narrowly scoped identities and tool registries, approval gates for irreversible operations, adversarial testing, and runtime telemetry that can block, contain, and investigate unexpected agent behavior.
Run AI on a secured infrastructure.
See Sweet secure your cloud-native applications and AI agents in one platform, in a 30-minute walkthrough.
What is excessive agency?
Excessive agency describes an AI system that can act, access, or delegate beyond what its intended job demands. The problem isn't the wrong output itself. It's that a wrong, manipulated, or ambiguous output had a usable path to consequential action.
OWASP lists Excessive Agency as LLM06 in its 2025 Top 10 for LLM Applications and attributes the condition to three contributing factors: excessive functionality, excessive permissions, and excessive autonomy. An agent with a database connector it never uses, write access it never needs, or the freedom to execute without confirmation satisfies at least one of them.
The practical test is simple. If an attacker could dictate the model's next output word for word, what could the surrounding system be made to do? Anything in that answer beyond the task's requirements is excessive agency, and it was built by the architecture around the model rather than by the model itself.
Understanding excessive agency in AI and LLM systems
That architecture is where delegated authority becomes difficult to govern. Traditional automation executes a fixed sequence a developer wrote. An LLM-driven workflow selects, at runtime, which step comes next, based on language it was handed moments earlier.
Why LLM excessive agency creates security risks
Current LLMs have no reliable boundary between instructions and data; both arrive as tokens in the same context window. A support agent that reads a customer ticket treats the ticket's contents as context, and context influences behavior. When an attacker plants instructions inside a document, a ticket body, or a calendar invite, that is indirect prompt injection, OWASP's LLM01, and it is a common trigger for excessive agency outcomes.
Keep the trigger and the condition separate. Injection determines whether an agent can be influenced; agency determines whether that influence reaches anything that matters. The same malicious ticket is a nuisance against a read-only summarizer and an incident against an agent holding refund, deletion, or email-send permissions.
Autonomy, permissions, and tool access
Three independent dials set how far influence can travel, and teams often turn all three up at once because it makes demos work.
- Functionality: Every connected tool the agent may select, including the ones inherited from a framework and never used in production.
- Permissions: The effective rights of the identity the agent borrows, frequently a service account scoped for convenience rather than for the task.
- Autonomy: How far the agent may proceed before a human confirms anything, particularly for irreversible operations.
Turn any one dial down and the blast radius shrinks. Understanding why requires following what happens between the injected sentence and the executed call.
How excessive agency works under the hood
That sequence is more mechanical than it sounds. Excessive agency is an action path with discrete links, and every link is a place where authority can be narrowed or left wide open.
The role of agent goals and action loops
Consider a representative case: an operations agent is asked to resolve a customer ticket, and the ticket contains a hidden instruction to export account records to an external address.
- Untrusted input: The agent ingests ticket text, attachments, and retrieved documents as ordinary context.
- Goal interpretation: The orchestrator reconciles the user's task with the injected instruction, producing a plan neither the developer nor the user approved.
- Tool selection: The agent picks from every registered tool, not just the ones the ticket workflow requires.
- Identity assumption: The tool call executes under the agent's inherited token or service account.
- Data access: The query returns whatever that identity can reach, which may span more than one tenant or record set.
- Execution: A write, send, or delete operation completes without confirmation.
- Feedback loop: The result re-enters context, and the loop runs again with the attacker's objective now embedded in the agent's working state.
Risk accumulates across those links. No single step looks like an exploit, which is part of why the chain survives review.
How excessive permissions expand the attack surface
Step four tends to do the most damage. Agents often hold no narrowly scoped credential of their own; they borrow a service account provisioned once, broadly, during development and rarely revisited. Effective permissions then exceed documented permissions, and identity security for those non-human accounts becomes a deciding factor in how far an injected instruction travels.
The same holds at the tool boundary. An agent's API calls can be indistinguishable from legitimate automation unless the endpoint enforces scope and rate limits, so API security for tool-facing endpoints determines whether a request for one customer's record can quietly return a full table. Two public cases show what happens when those links stay wide.
Excessive agency examples in the real world
Both cases below are useful because they are publicly documented, not because either was formally classified as an excessive agency incident. Read them as illustrations of a shared structure: untrusted content, a connected capability, and an identity with reach.
PHP2Shell: excessive agency through vulnerable tooling
PHP2Shell has been described publicly as a chain in which model-influenced content reaches a tool capable of interpreting or executing code, converting generated output into command execution on the host. Details reported for this technique vary by write-up, and it is cited here for the pattern rather than for any specific implementation. The underlying vulnerability lives in the tool, not the model.
The excessive agency lesson concerns registration, not exploitation. An agent that can select a code-execution capability for a task that never requires one has functionality it should not have been granted. Remove the tool from the registry and the output stays inert text, which is one of the lower-effort controls available.
EchoLeak and unauthorized data exposure
EchoLeak, reported by researchers at Aim Security and tracked as CVE-2025-32711, was a zero-click attack against Microsoft 365 Copilot. Researchers demonstrated that a crafted email could carry instructions Copilot processed without user interaction, creating a path for sensitive context the assistant could reach to leave the tenant. Microsoft rated the issue critical, remediated it server-side with no customer action required, and stated it had no evidence of real-world exploitation.
What makes EchoLeak instructive is the absence of a click. The assistant's legitimate data access, combined with an outbound path, was sufficient; no destructive tool was required. Every pathway from influence to access is worth examining, and that is what least agency formalizes.
Excessive agency and least agency: key differences
Least privilege and least agency are related but not interchangeable. Least privilege constrains what an identity is permitted to do. Least agency extends that principle to delegated decision-making: which tools the system may select, which workflows it may initiate, how far it may proceed without approval, and what context is allowed to influence those choices.
That distinction matters because an agent can hold well-scoped permissions and still have too much agency if it can choose among twelve tools when the task needs two, or chain a read operation into a delete without a checkpoint.
Moving a workflow one row up the table is often a smaller engineering effort than hardening the row it currently sits in, though that trade-off depends on how much functionality the downgrade removes.
Applying the principle of least agency
Applied to the ticket agent, least agency means a defined intended use, a tool registry containing only the connectors that workflow needs, a dedicated identity scoped to one tenant, and an approval gate on anything outbound or destructive. NIST's AI Risk Management Framework (AI 100-1) expresses a compatible idea in its GOVERN and MANAGE functions: document the system's context of use and maintain human oversight proportional to potential consequence.
Designing to that principle requires layered controls, because no single constraint covers decision, identity, data, and execution at once.
Mitigating excessive agency risks
Those controls fall into two categories that are easy to conflate. The first constrains capability, meaning what the agent is structurally able to do. The second observes and enforces behavior, meaning whether what it actually does stays inside the boundary. Capability constraints come first, because they hold even when the model is fully manipulated.
Limit permissions and scope for every agent
Scoping work is unglamorous, and it is where capability reduction is most directly measurable.
- Dedicated identity: Give each agent its own credential rather than a shared service account, so effective permissions can be audited against one workflow.
- Tool allowlist: Register only the tools the task requires, and remove framework defaults that were never exercised.
- Data partitioning: Bind queries to a single tenant, record set, or time window at the data layer, not in the prompt.
- Reversibility bias: Prefer draft, queue, and soft-delete operations over direct destructive calls wherever the workflow allows.
- Action auditability: Record every tool call with the identity, parameters, and originating context so a boundary violation can be reconstructed.
Scoping decides what is possible. Deciding what proceeds without a human is a separate judgment.
Use human approval for high-impact actions
Approval gates are a high-value control for irreversible actions: external sends, bulk exports, permission changes, deletions, payments. They are also the control teams most often skip, because they slow automation down.
Apply them by consequence rather than uniformly. Requiring sign-off on every low-risk lookup encourages reflexive approval, which erodes the control while keeping its cost. Gate the small set of operations that cannot be undone, and let the rest run.
Test agents against prompt injection and tool abuse
Scoping and approvals remain assumptions until something tries to break them. Adversarial testing should target the action path rather than the model's language: plant instructions in documents and tickets the agent ingests, then verify which tools it selects, which identity it uses, and where the call is refused.
Testing demonstrates that the boundary held under the conditions tested, which is narrower than proving it holds generally. Production changes tools, prompts, permissions, and data sources continuously, and that is where the remaining gap lives.
Dealing with excessive agency risks at runtime
Runtime controls do not replace least-agency design; they check whether the design still describes reality. Tool registries grow, service accounts accumulate rights, retrieval sources are added, and model versions change how instructions are interpreted. Preconfigured approvals cannot account for any of that on their own.
Monitor agent actions and tool calls
The more durable signal is behavioral rather than textual. Establish a baseline for each agent (the tools it invokes, the identities it uses, the data scopes it touches, the destinations it reaches) and compare live activity against it. Behavioral drift detection is the term vendors generally use for making that deviation legible; the underlying requirement is a baseline plus comparable telemetry.
Useful deviations are specific enough to act on: an agent invoking an administrative API it has never called, reading outside its assigned tenant, opening a connection to a new external destination, or escalating from a read to a delete inside one task loop.
Set runtime guardrails and policy enforcement
Observation alone changes nothing. Enforcement means the unapproved destructive call is blocked, the out-of-scope query is refused, and the unrecognized outbound destination is denied while the agent is executing, evaluated against declared intended use rather than a static signature list.
Enforcement needs restraint. Broad policies disrupt legitimate automation, so scope them per agent, roll them out in stages, and assign clear ownership for exceptions. Approaches differ in where they sit: some operate inside the agent framework, others at the identity, network, or workload layer, and each sees a different slice of the action path. Sweet Security is one example of a Cloud & AI Runtime approach built around validating live agent behavior against intended authority.
Contain and respond to unsafe agent behavior
When a boundary is crossed, containment is an identity problem as much as a workload problem, and the order of operations matters.
- Credential revocation: Revoke or rotate the token the agent was executing under before anything else.
- Tool suspension: Suspend the tool binding so the same capability cannot be selected again mid-incident.
- Session isolation: Isolate the session, then determine whether the action loop ran once or repeatedly.
Detection and response work then reconstructs the path from ingested content through tool selection to executed call, which is only possible if that chain was logged in the first place.
An LLM becomes dangerous when untrusted text reaches a system with more authority, tools, data access, and execution freedom than the task requires. The action path, PHP2Shell and EchoLeak, the least-agency distinction, scoping, approval gates, drift detection, and enforcement all serve one question: can this agent's current behavior be justified by the job it was given?
As agents take on more consequential work, that question moves from design review into production operations. For more on how runtime validation applies across cloud and AI workloads, see the Sweet Security runtime guide.
Excessive agency FAQs
What are the three main causes of excessive agency in AI systems?
The three main causes are excessive functionality, excessive permissions, and excessive autonomy. An agent becomes overly capable when it has unnecessary tools, access rights beyond its task, or authority to act without confirmation.
How can indirect prompt injection lead an LLM agent to take unauthorized actions?
Indirect prompt injection places malicious instructions in content an agent ingests, such as tickets, documents, or emails. If the agent treats that content as guidance and has relevant tools and permissions, it may select actions the user and developer never intended.
What permissions and tools should an AI agent have for a customer-support workflow?
A customer-support agent should have only task-specific, tenant-scoped read access and the minimal tools needed to retrieve information or create drafts. External sends, refunds, exports, deletions, and permission changes should be excluded or require approval.
Why is a dedicated identity safer than a shared service account for an AI agent?
A dedicated identity limits an agent's effective permissions to one defined workflow and makes its actions easier to audit. Shared service accounts often accumulate broad access, allowing a manipulated agent to reach systems or data it does not need.
Which AI agent actions should require human approval before they run?
Human approval should be required for irreversible or high-impact actions, including external sends, bulk exports, permission changes, deletions, and payments. Low-risk, scoped retrieval can usually proceed automatically without weakening the control.
How do PHP2Shell and EchoLeak demonstrate the risks of excessive agency?
PHP2Shell illustrates the risk of giving an agent access to a code-execution tool it does not need, turning influenced output into host-level command execution. EchoLeak shows how untrusted content, legitimate data access, and an outbound path can expose sensitive information without a user click.
What runtime signals can reveal that an AI agent is operating outside its intended scope?
Warning signals include invoking an unfamiliar administrative tool, accessing data outside its assigned tenant, connecting to a new external destination, or escalating from read activity to a destructive action in one task loop. Comparing live tool calls, identities, data scopes, and destinations with an agent-specific baseline makes these deviations detectable.
