How Do You Secure an AI Agent That Acts on Its Own?

By Kehinde Ogunlowo · August 14, 2026

Quick answer: Securing an autonomous agent means constraining what it can do rather than what it can be told, because every control that lives inside the conversation can be argued with. The durable controls are agent identity, least-privilege credentials, per-tool authorisation, blast-radius limits, external approval gates for irreversible actions, and an immutable session ledger. Guardrails and system prompts are useful mitigations and are not boundaries.

Last updated: August 2026 | Author: Kehinde Ogunlowo, Principal AI Platform Architect

Why is agent security a different problem?

Application security has always assumed that the code decides what happens and the input decides only what data it happens to. An agent inverts that. The input decides what happens, because the plan is generated at runtime from text that includes untrusted content.

This is the reason existing controls transfer so unevenly. Input validation still works. Output encoding still works. Network segmentation still works. What stops working is any control whose enforcement point is a statement of intent, because the agent's behaviour is produced by a component that treats intent statements and adversarial text as the same kind of thing.

OWASP's Agentic Security Initiative has been publishing on this since its first threat-model-based reference guide in February 2025 (Agentic AI threats and mitigations), and its most recent state-of-the-field publication, State of Agentic AI Security and Governance 2.01, was released on 1 June 2026 and covers the frameworks, governance models and global regulatory standards shaping agentic adoption (OWASP GenAI Security Project). Prompt injection has remained at the top of the project's risk list for LLM applications throughout (OWASP Top 10 for LLM Applications), and the reason it stays there is structural rather than a matter of insufficient effort: there is no reliable way to separate instructions from data inside a single context window.

Which controls are boundaries and which are mitigations?

This distinction is the whole of practical agent security, and getting it wrong is how deployments end up with a long control list and no actual containment.

A boundary is enforced by a system the agent is a client of. A mitigation operates on the same channel the attacker can influence. Both are worth having. Only one of them can be relied upon in a design review.

The test for any proposed control is one question: if the agent becomes convinced that the forbidden action is authorised and necessary, does the control still stop it? If the answer depends on the agent's cooperation, it is a mitigation. Write it down as one, budget for it as one, and do not let it appear in a risk register as the reason a high-severity risk was closed.

What does agent identity actually require?

An agent needs to be a first-class principal, with its own credential, distinguishable from every other agent and from the human on whose behalf it is acting.

Three properties matter. The credential must be short-lived, so a leak has a bounded window. It must be scoped to the agent's specific function rather than inherited from a broad service account, because a shared account gives every agent the union of everyone's permissions. And it must carry the initiating user's context through to the tool call, so downstream systems can enforce that a user's agent cannot read what the user could not read.

That third property is the one most implementations miss, and it produces a specific and serious failure: the confused deputy. An agent holding broad credentials, asked by a low-privileged user to retrieve something, will happily retrieve it, because the permission check happened against the agent's identity rather than the user's. The user has just escalated privilege by asking politely. The pattern for avoiding it, including credential exchange and delegation, is set out in workload identity for AI agents.

How should tools be authorised?

Treat every tool as an independent API that authorises each call on its own merits, not as a capability granted to the agent at configuration time.

The distinction sounds pedantic and is not. "The agent has access to the ticketing tool" is a statement about connectivity. "This principal may transition this specific ticket to this specific state" is a statement about authorisation, and only the second one survives an agent being convinced to do something unusual. Concretely, that means the tool validates the calling principal, checks the operation against a policy, checks the target object against that principal's scope, and rejects parameters outside the expected range, all server-side, on every call.

Parameter validation deserves particular attention because it is where blast radius actually lives. A refund tool authorised for a support agent is reasonable; the same tool with no ceiling on the amount and no restriction to orders belonging to the requesting customer is a very different exposure with the same permission label. The useful discipline is to enumerate, for each tool, the worst single call an adversary could make with the parameters currently allowed, and then constrain the parameters until that answer is survivable.

What has to be recorded?

The session ledger is a boundary control because it determines whether an incident can be investigated at all, and it has to be designed rather than accumulated.

A sufficient record covers the initiating user and the agent identity, every model call with its inputs and outputs, every retrieval and what was retrieved, every tool invocation with full parameters and result, every guardrail trip, and every human approval with what the approver was shown. It has to be append-only, in storage the agent has no write path to, with retention set against your investigation window rather than your logging budget.

Two properties separate a ledger from a pile of logs. The first is attribution: any state change must be traceable back through the chain of delegation to the human request that caused it. The second is reconstruction: an investigator must be able to replay a session end to end and understand why the agent did what it did. Most teams believe they have this until the first time somebody asks them to demonstrate it. The design is covered in detail in audit trails for AI agents, and it is also the practical substance of what regulators mean by logging requirements.

What changes in multi-agent systems?

Multi-agent architectures multiply every problem above and add three that do not exist in single-agent deployments.

Delegation dissolves attribution unless it is explicitly propagated. When a supervisor agent hands work to sub-agents that call further tools, the causal link from the human request to the final action passes through several hops, and each hop is an opportunity to lose the initiating context. If the link breaks, the ledger records that something happened without recording who caused it.

Permission accumulation happens by composition. Each sub-agent may hold a defensible permission set, and the system as a whole holds the union. A system able to read customer records and able to send external email has an exfiltration path that neither component has alone, and nobody approved that path because nobody looked at the union.

Trust between agents is usually assumed and rarely verified. An orchestrator that accepts a sub-agent's output as fact has extended its trust boundary to include everything that sub-agent read, which in a retrieval-heavy system means the open web. Inter-agent messages need the same untrusted-input treatment as any other external content.

We work through these patterns in our multi-agent systems practice, and the governing structure that has to sit above them is described in our AI governance service.

A practical sequence for an existing deployment

1. Inventory agents and credentials. Every running agent, every credential it holds, every tool it can reach. Include shadow deployments and vendor features that became agentic in an update.
2. Reduce to least privilege in IAM. Per agent, per tool, per object scope. This is the highest-value step and the least interesting one.
3. Move authorisation into the tools. Server-side checks on principal, operation, object and parameters, on every call.
4. Set blast-radius limits. Volume ceilings per session and per hour, value ceilings on financial operations, and record-count ceilings on bulk reads.
5. Gate the irreversible. Anything externally binding, financially material or non-recoverable keeps a human approval step permanently, and the approval is logged with what the approver saw.
6. Complete the ledger. Append-only, agent-unwritable, attribution preserved across delegation hops.
7. Red team multi-turn. With decomposition, false authorisation context, and injection through retrieved documents. Score on systems reached, not refusals produced.
8. Drill the stop. Pause intake, freeze writes, revoke credentials, with a measured time-to-stop.

Steps 1 and 2 typically remove more exposure than steps 3 through 8 combined, which is inconvenient for anyone hoping the answer is a product. Our fixed-fee Agent Assurance Assessment runs steps 1 and 2 and produces the prioritised plan for the rest in three weeks, and the architectural context sits on our AI agents overview.

Frequently asked questions

What makes an agent harder to secure than a chatbot?

An agent takes actions, and actions have consequences that survive the session. A chatbot's worst output is text a person can ignore; an agent's worst output is a state change in a system of record, made under credentials the agent holds. The security question shifts from what did the model say to what was the model able to do, and that is an authorisation question rather than a content question. It also means the attack surface includes every tool the agent can reach and every document it might retrieve, because retrieved content can carry instructions.

Are guardrails useless, then?

Not useless, but they are mitigations rather than boundaries and should be budgeted accordingly. Guardrails reduce the rate of undesirable behaviour and catch obvious cases cheaply, which is worth having. What they cannot do is provide an assurance that an action is impossible, because they operate on the same channel the attacker influences. The failure mode to avoid is a risk register in which a high-severity risk is marked closed on the strength of a guardrail. Mark it mitigated, keep the boundary control as the reason it cannot occur, and the register stays honest.

How should we handle tools that the agent calls?

Treat every tool as an API with its own authorisation, not as a capability the agent has been granted. The tool should independently verify who is asking and whether that principal may perform this operation on this object, exactly as it would for a human user. An agent that can call a tool is not the same as an agent that is authorised to call it with those parameters. Add explicit parameter constraints, amount ceilings, object scoping, result-set limits, and derive them by asking what the worst permitted single call would do.

What breaks first in multi-agent systems?

Attribution, and it breaks quietly. When a supervisor agent delegates to sub-agents that call further tools, the chain from an initiating human request to a specific state change gets long, and most implementations lose the link somewhere in the middle. The failure only becomes visible during an investigation, which is the worst possible time to discover it. The fix is to propagate the initiating principal through every delegation hop and to record it at every tool call, which is a design decision that is cheap upfront and expensive to retrofit.

Where do we start if we already have agents in production?

Start with an inventory of agents and the credentials each one holds, then reduce those credentials to least privilege. This is unglamorous and it removes more risk than any other single activity, because credential scope is the one control that no prompt, document or persuasive context can alter. Expect the inventory to surface agents nobody registered, and expect several of them to hold broader access than anyone would approve if asked directly. Once scope is correct, move authorisation into the tools and complete the session ledger.

Where to go from here

Agent security is not a new discipline so much as an old one applied at a point most teams have not yet moved it to. The question is not whether the model behaves; it is whether the surrounding architecture makes misbehaviour survivable. That means identity, scope, tool-side authorisation, ceilings, gates and a ledger, and it means being honest in the risk register about which of your controls are boundaries.

If you cannot currently state what each agent in your estate can reach, how much it can do per hour, or whether a session could be reconstructed after an incident, the fixed-fee Agent Assurance Assessment produces those answers in three weeks. For programme-level structure across a portfolio, see our enterprise overview, or book a call to work through it against your own deployment.