What is an AI agent's attack surface?

Attacks get in through the inner layers. The damage happens in the outer ones.

While you’re reading this, countless agents go about their day, working through open issues on GitHub or Jira. Each of them signs in with a credential to access materials, some scoped specifically for their agent and others tied to the owner or a service role. 

This common setup clearly illustrates how extensive each agent’s attack surface is. All we need to do is deconstruct the mundane activity flow into layers built around the Large Language Model (LLM), which is the heart of agentic AI. 

Imagine a nesting doll, with the LLM as its smallest part. Everything the agent does, from reading issues and authenticating with a token to opening repositories, can be drawn on the larger nesting dolls that wrap around the smallest one. Each adds capabilities but also the surface area that needs protection. 

We define the attack surface as every touchpoint between the program and the outside. For a web app, it’s what the app exposes: ports, endpoints, forms. To this, agents add ingested content, since anything an agent reads can become an instruction, and anything the agent reaches is a place where that instruction can land. 

An agent's attack surface is everything that can steer it, plus everything it can act on.

Hostile input usually gets in through the inner layers. The damage occurs in the outer ones, where the agent holds credentials and interacts with real systems. Those outer layers are also the ones that identity and security teams control.

Layer 1: The model

The foundation model is here, along with any fine-tuning and the data it was trained on.

We don’t often talk about model poisoning as something that can happen, but research shows that it’s absolutely possible. A poisoned training set could cause a model to write weak authentication code for a specific library, and no one would notice.

Unless you train your own models, securing this layer is your provider's responsibility. There’s also not much you can do about it.

Layer 2: Instructions

This is where you find the system prompt, developer instructions, and the user's request. In other words, the agent learns its job here. It’s the most obvious and visible attack surface. If someone can write your agent’s instructions directly, they can literally tell it what to do. 

It's also where credentials end up when nobody's looking. An API key pasted into a system prompt during testing works for as long as the key does, and the developer who pasted it may have left long ago.

Layer 3: Context and memory

Everything the agent ingests while working is tied to this layer. From files, tickets, and emails, to websites, tool output, conversation history, and memory. 

The model itself can’t reliably separate data from instructions. A line in a retrieved document, if it enters the context, carries the same weight as the task you gave it.

For each source, the question is who can write to it.

Layer 4: The harness and its tools

The harness runs the agent's loop. Claude Code, Codex, and OpenClaw are harnesses. They decide which tools are available and are also the layer that actually executes them.

Tools are where the surface gets wide and unpredictable:

• MCP servers and plugins. Each one adds tools, and each tool's description goes straight into the model's context. Whoever controls a server's updates controls what the model reads about it.
• The machine the agent runs on. Local MCP servers take credentials from the environment, often from a plaintext config file on a developer's laptop. Anything else running on that machine can reach them.
• The harness itself. Last year, malicious Nx npm packages went looking for AI coding CLIs and ran them while skipping permission checks. They aimed to discover secrets in the file system. In that case, the malware was calling the agent directly.

Layer 5: Identity

Every action an agent takes is carried out under an identity. That's a given, as the agent needs to authenticate for access to resources, but there often isn't an identity purpose-built for the agent. It might ride a user's session, hold an OAuth grant, use a static API key, or assume a cloud role. 

The identity sets how much harm a steered agent can do. An attacker who gets instructions into the agent's context can do whatever its identity allows. 

At the identity layer lives the bulk of the agent’s reach. Stealing a valid credential can give an agent full access, unless that identity is right-sized. And not only are credentials themselves the target, but every hop in the agentic loop can also give the agent the ability to act with more and more permissions through new identities that come with tools like MCP servers. 

Layer 6: Orchestration and reach

The outermost layer of our nesting doll is what’s happening around the agent. So, not strictly a part of it, but integral to understanding its attack surface. Here we’ll find the pipelines that trigger this agent, its agentic peers, and systems its identity opens. These are both part of the attack surface and the blast radius for when an attack succeeds.

Pipelines decide when the agent runs and what input it’s handed. Trigger the pipeline to feed the agent. An agent that runs on every new PR will take your input if you submit one. The damage part is the reverse scenario: an agent can use pipelines, such as a CI job, to operate with that job’s permissions. 

Agentic peers are agents that give or receive work from our nesting doll. Both the attack surface and the blast radius are obvious here: if our agent accepts communication from another agent, poisoning that agent can compromise ours.

Systems are the repositories, databases, SaaS apps, and cloud accounts that the identity reaches. This is primarily a damage target unless the agent reads from them, which is common. In that case, it’s also the attack surface.

These pieces combine into unique paths:

• Escalation pairs. An agent that can create a Lambda function and holds iam:PassRole, can grant that function any role it's allowed to pass, then act as that role. Neither permission looks dangerous on its own.
• The lethal trifecta. That's Simon Willison's term for an agent with access to private data, exposure to untrusted content, and the ability to send data out. An agent with all three has a path to getting data out, however narrow each grant may look.

How the surface grows

An agent's attack surface grows from the moment it’s launched. While it can theoretically shrink, that rarely happens. Here are just a few examples of what is bound to happen quickly: 

• Sub-agents. Sub-agents your agent spawns often start with its credentials.
• Grants outlive projects. Refresh tokens will mint access until someone revokes them. Not only that, but OAuth grants made in a SaaS app often don't appear in the IdP at all.
• Owners leave. Offboarding disables the SSO account but often not the tokens issued to agents. They can go on working. 
• Memory carries over. Whatever reached a saved state in one run will shape the next.
• Tools get added. A new MCP server rarely triggers an access review.

All these turn agent ownership itself into a part of the attack surface.

The layers at a glance

Note: OWASP mappings include the Top 10 for LLM Applications and the Top 10 for Agentic Applications