The production reality of
AI agent security.

Attack surfaces, failure modes, and the gaps existing security tooling cannot cover

Most organisations deploying AI agents in production have never once asked: what can this agent actually do, and what could someone make it do?

That is not carelessness. It is a gap in available mental models. The security industry has spent decades building frameworks for applications, APIs, and infrastructure. None of those frameworks were designed for systems that reason, plan, and take actions based on natural language.

An AI agent is not an application. It is a reasoning system with access to tools, memory, network endpoints, and potentially other agents. The attack surface is not a fixed set of endpoints you can enumerate. It shifts with every conversation, every tool call, every retrieved document.

What follows documents the security problems that show up consistently in production agent deployments. Not edge cases. Not theoretical vulnerabilities. Problems in systems already running, serving real users, touching real data.

The Agent Attack Surface Is Not Where You Think It Is

Security practitioners are used to defending fixed, enumerable attack surfaces. Agents don't have one.

A traditional web application has a defined set of inputs. HTTP endpoints, form fields, query parameters. You enumerate them, fuzz them, scan them. The surface is bounded.

An AI agent accepts natural language. Any sequence of tokens is a valid input, and the agent's response depends on its system prompt, context window, retrieved memory, available tools, and the model weights underlying everything. That combination produces emergent behaviour that no single component can fully predict.

The attack surface is not the API endpoint. It is the entire execution chain: input, reasoning, memory and retrieval, tools, output. Every layer independently exploitable.

Every layer a potential entry point for a compromise that propagates through the rest.

The attacks worth worrying about are not single-layer. They chain. An injection at the input layer manipulates tool selection. The tool gets called with a crafted parameter. The response retrieves data that quietly exits through the output layer. No single hop looks alarming in isolation.

Prompt Injection Is a Structural Problem, Not a Filter Problem

When security teams first encounter prompt injection, the instinct is to build a filter. That instinct is wrong.

Prompt injection is not a problem you can solve by blocking specific strings or patterns. It is a structural property of how language models process context. A language model has no reliable, enforced boundary between instructions and data. When you retrieve a document and insert it into context, the model processes those tokens. If they contain instructions, the model will generally try to follow them.

Four distinct variants that practitioners need to treat separately, because they have different detection profiles and blast radii:

• Direct injection: an adversarial user crafts a prompt that overrides the system prompt or redirects the agent's behaviour
• Indirect injection: adversarial content is embedded in a document, webpage, or database record that the agent retrieves and processes
• Persistent injection: adversarial instructions written into the agent's memory store get re-retrieved in future sessions, possibly by completely different users
• Cross-agent injection: in multi-agent systems, a compromised agent sends adversarial instructions to another agent downstream

Indirect and persistent injection are consistently underappreciated. A user who cannot communicate with an agent directly can still influence its behaviour by controlling content the agent will retrieve. A document with a subtle embedded instruction can redirect an agent with significant tool access, and no amount of input filtering catches it, because the injection never came through the input.

The meaningful defence is structural. Constrain what the agent can do in response to any instruction, regardless of source. An agent that cannot exfiltrate data cannot be injected into exfiltrating it, even if an injection succeeds.

Tool Access Is Where Intent Becomes Consequence

An agent that reasons dangerously is annoying. An agent that acts dangerously is a liability.

The qualitative shift that makes AI agents a different security problem from chatbots is tool use. A chatbot that produces harmful text is a content moderation problem. An agent calling APIs, querying databases, sending emails, executing code converts language model behaviour into real-world consequences.

Four failure modes show up repeatedly in production:

Unauthorised invocation: The agent calls a tool it should not have access to. Usually this happens because tool permissions are not scoped to the task, or the agent has access to a registry with tools far beyond its operational mandate.

Dangerous parameter construction: The agent calls a legitimate tool with parameters that produce dangerous outcomes. A query tool with an unrestricted scope. A file operation on a sensitive path. The tool is working correctly; the parameters are not. These are nearly impossible to catch without parameter-level enforcement.

Tool chaining abuse: A sequence of legitimate tool calls that individually look fine but together produce an outcome no single call would permit. Retrieving records one at a time to stay below bulk export thresholds. Using a lookup to identify a target and an action tool to affect it.

Tool response injection: The response from a tool contains adversarial content that influences the model's subsequent behaviour. A web fetch returning a page with embedded instructions. A database field designed to redirect the agent's next decision.

In practice, tool permissions get assigned by convenience. The agent needs to look up customer records, so it gets access to the whole database. It needs to send one type of notification, so it gets access to the full email API. Nobody scopes permissions to the specific operations actually required.

RBAC Was Designed for Humans. Agents Break the Model.

Role-based access control assumes a human on one end and a resource on the other. An agent acting autonomously, across tools, across sessions, on behalf of a user it may never have directly served, fits none of those assumptions.

Traditional RBAC works because the identity of the principal is fixed, verifiable, and consistent. A user logs in, a role is assigned, and the role governs access. The system knows who is asking.

Agents dissolve that model in several ways at once.

Agent identity conflation: Most agent deployments run under the credentials of the invoking user or a shared service account. The agent inherits the full permission set of that identity, not a scoped subset appropriate to the task. If the user can read the entire customer database, so can the agent, across every session, for every query, at machine speed.

Tool-level permission inheritance: Access to a tool typically comes at the tool's broadest permission level. A search tool that a human would use to look up one record at a time can be called by an agent in a loop with unrestricted parameters, effectively granting bulk access no human was ever given explicitly.

Data scope at retrieval, not at use: RBAC traditionally enforces access at the point of retrieval. In agent systems, data retrieved in one operation gets loaded into context and may be referenced, quoted, or forwarded in subsequent operations involving different tools, different outputs, or different downstream recipients. Enforcement at retrieval does not govern what happens to the data afterward.

Cross-agent privilege escalation: In multi-agent systems, a compromised sub-agent with elevated access can take actions the orchestrator would never have authorised. The permission model of a multi-agent system is determined by the weakest boundary in the graph, not the intersection of components' permissions.

The practical consequence is that access control in agent systems tends to be governed by whatever the underlying infrastructure permits, which is almost always broader than what the specific agent task requires. The agent inherits permissions designed for human operators, then executes at volumes and patterns no human operation would ever resemble.

Data Exfiltration Does Not Look Like Data Exfiltration

The most effective data exfiltration from an agent system often triggers none of the signals that traditional DLP was designed to catch.

Traditional DLP looks for known patterns. Bulk file transfers. Large outbound payloads. Access to sensitive directories. Those patterns made sense when data movement required explicit file operations or network transfers that left a volumetric footprint.

In an agent system, data can leave through channels that look nothing like a transfer:

• Aggregation over time: the agent retrieves individual records within normal limits across many sessions, assembling a complete dataset that no single session reveals
• Semantic summarisation: sensitive content gets summarised into a form that conveys the information without triggering volume-based alerts
• Indirect channels: data is incorporated into output the agent sends to a third-party service, a notification system, or an external API
• Memory persistence: sensitive data from one session is stored in the agent's memory and retrieved in later sessions, potentially by different users or agents entirely
• Cross-session bleed: memory not properly isolated between users lets one user's data surface in another context

Aggregation is the hardest to catch at the application layer. Individual queries look normal. The pattern only emerges over time, across sessions, often across different users of the same agent. Detecting it requires session-level analysis across time, not per-request review.

Runtime Behaviour Drifts. Static Policies Don't Track It.

An agent that behaves acceptably at deployment can develop genuinely unsafe behaviour patterns over time. Static guardrails have no mechanism to notice.

The common deployment assumption: test before launch, verify correct behaviour, ship it. Security posture is set at deployment time and reviewed periodically.

Three things break this in production. First, agent behaviour is context-dependent. The same agent, same system prompt, same tools, will behave differently depending on what is in its context window. A security assessment testing a fixed set of scenarios does not cover the range a production agent will encounter.

Second, sessions can be steered. An adversarial user who cannot compromise an agent in a single message can often get there incrementally over a conversation. Individual messages look innocuous. The cumulative trajectory does not. This kind of drift is invisible to any system that only inspects individual requests.

Third, the operational environment changes. New tools get added. New data sources get connected. System prompts get updated. Each change opens behaviour paths that did not exist at the time of the original security review.

Multi-Agent Systems Multiply Complexity Non-Linearly

A single agent is a security problem. A network of agents communicating with each other is a different order of problem entirely.

As agent systems mature, single-agent architectures give way to multi-agent ones: orchestrators directing specialist sub-agents, pipelines where the output of one agent becomes the input to the next, networks collaborating on complex tasks.

Trust propagation: When Agent A receives an instruction from Agent B, how does Agent A know Agent B has not been compromised? In most implementations, agent-to-agent communication is not authenticated. An agent treats orchestrator instructions the same way it treats instructions from a trusted source, because there is no mechanism to verify the orchestrator is behaving correctly.

Blast radius expansion: A compromised orchestrator can direct all its sub-agents. A compromised sub-agent can inject content that shapes the orchestrator's future decisions. Blast radius scales with the connectivity of the agent graph.

Audit trail fragmentation: Reconstructing why a particular action was taken may require correlating logs across multiple agents. This is only possible if every agent logs in a way that can be correlated, which is rarely designed for upfront.

Supply chain exposure: Adversarial content embedded in a tool output used by one agent can propagate through a pipeline, influencing downstream agents in ways that are hard to trace to the original source.

Multi-agent systems inherit all the security properties of their components. The weakest link determines the security posture of the whole.

Existing Security Tooling Has a Structural Coverage Gap

The problem is not that security teams are not trying. The tools available to them were not designed for this threat model.

AI agent security presents problems that existing tooling handles poorly across the board:

• Static analysis cannot find vulnerabilities in agent behaviour. Agent behaviour is emergent, depending on context that only exists at runtime
• Web application firewalls inspect HTTP requests against known bad patterns. An adversarial prompt in natural language does not match those patterns
• Traditional DLP monitors for data movement patterns. It cannot detect semantic exfiltration through conversational output
• SIEM and log aggregation tell you what happened after the fact. They cannot stop an unsafe tool call before it executes
• Network monitoring can flag unusual outbound connections. It cannot tell you whether a specific API call was within the agent's intended operational scope
• Penetration testing assesses a fixed configuration. It cannot cover the range of behaviours an agent may exhibit across the space of possible conversational contexts

This is not a criticism of those tools. They were built for different problems. The gap is structural, not a matter of configuration or tuning.

What is needed is a security layer that operates natively at the agent execution chain. One that monitors at the tool call and output level, enforces policy based on semantic intent rather than syntactic patterns, and does it inline, before actions execute.

A note on scope

This piece focuses on production agent security. LLM training data security, model weight theft, inference infrastructure attacks, and classical adversarial ML are real problems with a different set of controls, and not covered here.

The problems described here — prompt injection, tool misuse, RBAC breakdown, semantic exfiltration, session drift, multi-agent trust — these show up when you give a capable language model tools, connect it to real systems, and expose it to real users. They are production problems, not research ones.

Future posts will go deeper on individual topics: the full taxonomy of prompt injection techniques, tool security architecture, RBAC design for agentic systems, memory and RAG security, and the practical challenge of building monitoring for systems with non-deterministic behaviour.