AI agent security

An agent is a loop. It is given a goal, it decides what to do next, it calls a tool, it reads the result, and it repeats until it believes the goal is met. The tools are what make it an agent rather than a chat interface: reading and writing files, querying databases, calling internal APIs, sending mail, running code, opening pull requests.

Security-wise, that loop creates a new principal in your estate. It holds credentials, it takes actions, it makes decisions between steps that nobody reviews, and it is influenced by whatever text it reads along the way. It is closer to a contractor with system access than to a library.

Five things need securing, and most deployments we review have addressed one of them.

Identity: the agent authenticates as something. If that something is a shared service account with broad permissions, the agent is a broad permission. Credentials: what it holds, where they are stored, and whether they are scoped per user and per task or issued once and reused for everything. Reachable surface: the specific set of tools and data, which should be enumerable rather than “the internal API”. Integrity of what it consumes: its memory, its retrieved context, and the tools it loads, because all three are inputs an attacker can influence. And observability: a record of what it read, what it decided and what it executed, which is what makes an incident investigable.

The compromise route we use most often is the agent’s own credentials, and the reason is structural. Agents need broad access to be useful, so they get a service identity that can reach many systems. Then they act on behalf of many different users through that one identity. Anyone who can influence the agent, through any channel, gets the union of everything it can reach, and the audit trail records the service account rather than the person.

The second route is memory and context. An agent that stores what it learns will store what it was told, including instructions planted for a later session. Poisoning a persistent memory is more valuable than a single injection, because it survives the conversation and affects other users. The same applies to a retrieval corpus that anyone in the organisation can write to: a document is a delivery mechanism, and indirect prompt injection is the payload.

The third is the tool supply chain. Agents load tool definitions from servers, and a tool definition is text the model reads: its name, its description, its parameter documentation. A hostile or compromised tool server can put instructions there, and the model reads them before the user has typed anything. Where connectors are added by individual users from public directories, the organisation has a dependency it has never reviewed, and tool poisoning is the direct consequence. MCP has made connecting tools straightforward, which has made this considerably easier to get wrong.

The fourth is that nobody can reconstruct what happened. A chat transcript is not an audit log. It does not show which documents were retrieved, which tool calls were made, with which parameters, under which identity, or which of them succeeded. Without that, an incident investigation consists of asking the model what it did, which is not evidence.

The distinction decides which controls apply, and it is blurred by vendors who describe every feature as an agent.

The point is that adding one tool call moves a system from the left column to the right, and the controls in the right column are usually not added at the same time. That gap is where the findings are.

Giving the agent a shared service identity. It destroys accountability and grants every user the union of the agent’s permissions.

Granting tool access broadly because it is easier. “Read any file” and “call any internal endpoint” are the two grants that turn every injection into an incident.

Treating the model provider’s safety features as the control. They address content, not access. They have no view of your permissions model.

Letting users install connectors freely. Each one is code and text entering the loop from outside your review process.

Logging the conversation and nothing else. Investigating requires the retrieval, the tool calls, the parameters and the identity used.

Give the agent an identity per user and per task, with the user’s permissions and no more, and make the credentials short-lived. Where the platform supports acting on behalf of a user, use it. Where it does not, that limitation is a finding worth writing down rather than working around.

Enumerate the tools and make each one narrow. “Create a ticket in this project” is a tool. “Call this HTTP API” is a capability, and it is excessive agency waiting for an instruction. Put a human approval gate in front of anything irreversible, external or financial, and make the approval screen show the concrete action rather than a summary the model wrote.

Treat memory and retrieval corpora as trusted stores that need integrity: control who can write to them, review what gets stored automatically, and scope memory per user so one poisoned entry cannot reach everyone.

Review connectors before they are available, pin their versions, and re-review them when they change, because a tool description can change without the tool’s behaviour appearing to. This is ordinary supply chain discipline applied to a new kind of dependency.

Log the whole loop: prompts, retrieved documents, tool calls with parameters, identities, results and approvals. Then alert on the shapes that matter, which are an agent reading far more than a task requires, calling a tool it has never called for this user, or making outbound requests to a destination that is not in its expected set.

We test an agent as an insider with tools rather than as a chatbot. The questions are what identity it holds, what that identity reaches, what an attacker can put in front of it, and what it can send outward. Findings are written against the specific capability and the specific data reached, with the chain shown from the planted content to the action taken.

The evidence is the trace: where we planted the instruction, what the agent retrieved, which tool it called, with which parameters and under which identity. Where the client has no such trace available, that absence is itself a finding, because it means an incident would not be investigable.

Severity comes from reach and reversibility. An agent that can read one project’s tickets is a different risk from one that holds a service credential across the estate, and an agent that can act irreversibly without a human gate is treated as critical regardless of how well the prompts are written.

This is the second half of our work on systems that act on their own, alongside prompt injection, and it is the half that is usually missing from internal reviews.

How is AI agent security different from application security? The mechanics are familiar: identity, permissions, input handling, supply chain, logging. What is new is that the component deciding what to do next is influenced by text it reads, so the usual assumption that code paths are fixed does not hold.

What is the biggest risk with agents today? Over-permissioned identity. Agents are given broad credentials so they are useful, then anyone who can influence them inherits that breadth. Scoping the identity per user and per task addresses more real risk than any prompt engineering.

Do we need to worry about MCP servers? Yes, as dependencies. A tool server supplies text the model reads and code that runs in your context. Review them, pin versions, restrict which ones users may add, and treat a change to a tool description as a change to a dependency.

Can we log our way out of the problem? No, and you cannot investigate without logs either. Logging is what makes an incident reconstructable; the controls that reduce the incident are scoped identity, narrow tools and approval gates.