Securing AI agents: containing excessive agency

What makes agentic AI a different security problem?

A chatbot produces text a human then decides to act on. An agent acts directly — it plans, calls tools and changes state in real systems. The security boundary therefore moves from “what might it say?” to “what can it do?”, and the answer is determined entirely by the tools and credentials you handed it.

The useful mental model is not “clever chatbot”. It is a privileged service account that can be socially engineered. That comparison does real work, because it tells you which existing discipline applies: everything your organisation already knows about over-permissioned service accounts, standing credentials and unaudited automation transfers directly.

It also tells you where the novelty is. A conventional service account does exactly what its code says. An agent decides, in natural language, at runtime, based partly on content an attacker may control. You are combining the permissions of automation with the manipulability of a person.

What is excessive agency?

Excessive agency is granting an agent more capability, permission or autonomy than its task requires. It appears in the OWASP Top 10 for LLM Applications, and it is the condition that turns a successful prompt injection from an embarrassment into an incident.

It shows up in three distinguishable forms, and they need different fixes:

The failure mode is rarely a rogue model pursuing its own ends. It is a confused one, acting in good faith, with permissions far wider than the job needed — which is precisely how over-privileged automation has always failed.

How do you secure an AI agent?

Apply the controls you would apply to any privileged automation, then add containment for the fact that this one can be argued with: least privilege per tool, short-lived scoped credentials, human approval on consequential actions, egress allow-lists, identity propagation into retrieval, and tool-call logging as security telemetry.

1. Least privilege per tool, not per agent

Grant capability at the operation level. An agent that needs to read tickets should not hold a credential that can also close, reassign or delete them because the API client was convenient.

2. Short-lived, scoped credentials

Standing API keys embedded in an agent are the highest-severity design error in most agentic deployments and the cheapest to fix before launch. Issue tokens per task, scoped to the resources that task touches, expiring in minutes.

3. Human approval on consequential actions

Draw the line at anything that moves money, changes access or entitlements, deletes data, or communicates with a customer or the public. Everything else can run unattended. Being explicit about that boundary is what makes autonomy safe rather than frightening.

4. Egress allow-lists

Exfiltration and command-and-control both need a destination. An agent that can only reach a named set of hosts is dramatically harder to abuse, and this control keeps working after the model has already been manipulated.

5. Identity propagation into retrieval

If the agent queries data on behalf of a person, it must query as that person. An agent using a broad service account to fetch context will cheerfully surface documents the requester was never entitled to see, and no amount of prompt instruction prevents it.

6. Log tool calls, not just conversations

The security-relevant record is which tool was invoked, with what arguments, under which credential, on whose behalf, and what came back. Conversation transcripts alone will not let you reconstruct an incident.

7. Treat every connected server as a third-party integration

Protocols such as MCP make capability trivial to add, which is exactly why each connected server deserves the scrutiny of a supplier rather than of a browser plug-in. Ask who wrote it, what it can reach, and what it does with what it sees.

Design patterns that reduce blast radius

Separate agents by trust level, keep the agent that reads untrusted content away from the tools that matter, make consequential actions two-step, and prefer proposing over doing. These are architecture decisions, and they are far more durable than any prompt-level defence.

• Split by trust. One agent ingests untrusted content and holds almost no tools; a second, which never sees raw untrusted text, holds the capability. The handoff between them is structured data, not free text.
• Propose, then execute. Have the agent produce a structured action for a separate, deterministic component to validate and run. The validator, not the model, enforces policy.
• Constrain the action space. A fixed set of permitted operations with typed parameters beats an open-ended tool that accepts arbitrary strings.
• Budget and rate-limit every agent — on tokens, on tool calls, on spend. Runaway loops are more common than attacks and cost real money.
• Make it killable. Know how to revoke an agent’s credentials and stop it mid-task, and test that path before you need it.

An agent with a broad tool belt, standing credentials and no human checkpoint is an insider threat that never sleeps and cannot be interviewed.

Robin Johns, Worldwide AI SME, Cato Networks

Questions to ask before an agent goes live

A short pre-launch checklist catches most of what goes wrong. If the team cannot answer these six questions crisply, the agent is not ready regardless of how well it demos.

1. What is the worst single action this agent can take? If the answer is unbounded, the tool scope is wrong.
2. Whose permissions does it act with — the user’s, or a service account’s?
3. What untrusted content reaches it, and does it hold any consequential tool while handling that content?
4. Where can it send data? Name the allow-list.
5. What is logged, and could you reconstruct a bad day from it?
6. How do you stop it right now, and who has that button?

Frequently asked questions