Skip to main content
SecureAI Guard

Agent security and excessive agency

An agent turns text generation into action. What excessive agency means, why shared service accounts are the core defect, and the controls that hold.

Published ·4 min read·SecureAI Guard
agent security
excessive agency
OWASP LLM Top 10

An agent is a model with tools and a loop: it can call functions, read the results, and decide what to do next until it judges the task complete. That loop is what makes agents useful, and it is also the entire security story, because it converts a system that produces text into a system that takes actions in your infrastructure.

The risk class is catalogued as LLM06:2025 Excessive Agency: harm that follows from an agent being able to do more than the task required.

Excessive agency has three distinct forms

Keeping them separate is useful, because they have different fixes.

  • Excessive functionality. The agent has tools it does not need. A support assistant given a general database client rather than three specific queries; a summariser given a file-write function because the library bundled one. Every unnecessary tool is an action an injected instruction can reach.
  • Excessive permissions. The tools it does need are wired to credentials that can do more than the task. The canonical case is a shared service account: the agent operates with the union of every permission that account has accumulated, on behalf of every user, and its actions are indistinguishable in the audit log from every other consumer of the same key.
  • Excessive autonomy. The agent performs consequential, irreversible actions without a human deciding. Sending, paying, deleting, publishing, granting access — each of these is a point at which "the model got it wrong" and "the model was manipulated" have identical, unrecoverable outcomes.

Why this is where prompt injection becomes expensive

A prompt injection against a chatbot produces bad text. The same injection against an agent produces an action, executed with the agent's privileges, attributed to the agent's identity.

The attack does not need to reach a user. In an agentic workflow the payload arrives in whatever the agent reads — a web page it browses, an email it triages, a ticket it summarises, an API response, a code comment — and it inherits every permission the agent holds at that moment. This is the reason agent security is mostly an identity and authorisation problem rather than a model problem, and why the mitigations that work are the boring ones.

The controls that hold

Give each agent its own identity. Not a shared service account. An agent instance acting for a specific user on a specific task should hold credentials minted for that user and that task, with a short lifetime. Two properties fall out of this for free: a compromised agent reaches only what one task needed, and the audit log can answer who did what.

Scope tools to the task, not to the capability. Prefer three narrow functions over one general one. getOrderStatus(orderId) is a tool; runQuery(sql) is a shell. Where a general tool is unavoidable, put the authorisation check in the tool implementation — server-side, against the acting user — and never in the tool's description.

Authorise in code, on every call. The model decides what to attempt. Your code decides what is permitted. If the only thing preventing an action is that the system prompt asked the model not to, the action is permitted.

Require confirmation for the irreversible and the outbound. This is the single most effective control, and it is fragile in a specific way: it works only while the prompts are rare enough to be read, and only if the prompt shows the real action and its real arguments. See human in the loop.

Bound the loop. Maximum iterations, maximum tool calls, maximum wall-clock time, maximum spend. Unbounded loops are a cost incident and an availability incident before they are a security one — see denial of wallet.

Log the decision, not just the outcome. For each step: the resolved context, the tool proposed, the arguments, the authorisation decision and the result. An agent trace that records only successful calls cannot answer the question an incident review will ask.

Multi-agent systems

Where one agent calls another, the properties above have to compose, and by default they do not. Two failures are worth naming:

  • Privilege accumulation. A supervisor agent that can invoke any sub-agent effectively holds the union of all their permissions. Delegation must narrow the scope, never widen it.
  • Trust laundering. Output from agent A arrives at agent B looking like system-generated content rather than the untrusted text it is. An injection that lands in A propagates as apparently-trusted input to B. Every hop is untrusted input; label it and treat it that way.

A checklist before an agent touches production

  1. Each agent has its own identity and short-lived, user-scoped credentials.
  2. Every tool is authorised server-side on every call, against the acting user.
  3. The tool set is the minimum the task needs, enumerated and reviewed.
  4. Irreversible and outbound actions require confirmation, showing real arguments.
  5. Iteration, time and spend budgets are set and enforced.
  6. Full traces are logged with retention and access controls appropriate to their contents.
  7. There is a way to stop a running agent, and someone has tested it.