What Is the AI Agent Attack Surface?

Expanded reach. An agent's surface includes the model and everything wired to it: tools, identities, data sources, memory and the systems behind each connection.

Action creates consequence. Because an agent can act, a manipulated instruction can change a record, spend money or move data outside the AI system entirely.

Access determines impact. The number of tools an agent can call and the permissions on its identity set the worst case, not the quality of the model.

State introduces persistence. Memory and stored context can carry a poisoned fact across steps and sessions, long after the page that planted it is gone.

Controls have to follow execution. Visibility over the prompt and the response is not visibility over the workflow, which is where the actions happen.

Why is the AI agent attack surface so important today?

The surface grew faster than the tooling that watches it. Agents moved from suggestions to actions inside ordinary business workflows, and the security stack was built for applications that do not decide what to do next.

The measurements say the exposed paths get used. In AgentDojo, prompt injections in its Slack suite succeeded 92% of the time against GPT-4o, and injections placed at the end of a tool response reached up to 70% average success (AgentDojo, arXiv:2406.13352). The largest public agent red-teaming competition recorded 1.8 million attacks and more than 60,000 successful policy violations against 22 frontier agents, and found that nearly all agents exhibit policy violations for most behaviours within 10 to 100 queries (Security Challenges in AI Agent Deployment, arXiv:2507.20526).

Tools are the widest part of the surface. Across 20 agents and 45 live MCP servers, MCPTox measured a 72.8% attack success rate against o1-mini, and no model refused more than 3% of the attacks (MCPTox, arXiv:2508.14925). A dynamic scan of 66 real-world agent tools found 75% were vulnerable to cross-tool hijacking (Les Dissonances, arXiv:2504.03111). The servers are ordinary software with ordinary bugs: 7.2% of 1,899 open-source MCP servers carried general vulnerabilities and 5.5% showed MCP-specific tool poisoning (MCP at First Glance, arXiv:2506.13538).

The incidents are concrete. EchoLeak, CVE-2025-32711, was a zero-click prompt-injection exfiltration in Microsoft 365 Copilot rated 9.3 CVSS (NVD). CVE-2025-6514 was an OS command injection in mcp-remote, a widely used MCP client, at 9.6 (NVD).

What makes up the AI agent attack surface?

The surface has eight parts. A review that names them finds the unowned ones quickly.

Instructions, reasoning and planning

The agent interprets a goal and decides the steps. Direct and indirect prompt injection both target this layer, because a plan built from untrusted content is an attacker's plan running with your permissions.

Tools and external systems

APIs, databases, SaaS applications, browsers, code execution and the filesystem. Every tool adds reach. The control has to check both whether the agent may use the tool and whether this particular call is appropriate in this task.

Model Context Protocol connections

MCP standardises how agents reach tools and data, which also standardises how those connections go wrong: unapproved servers, excessive scopes and token misuse. Authorization exists for HTTP transports and is optional, so it does not replace a decision at the point of the call.

Identity and credentials

Agents act as someone. A dedicated identity per agent makes least privilege, attribution and revocation possible at the same time. Shared service accounts and inherited user tokens make all three impossible.

Data and context sources

Email, documents, websites, databases and retrieval stores. Content that is untrusted, stale or manipulated becomes an instruction channel the moment the agent treats it as a command.

Memory and stored state

Working state inside a task and long-lived memory across sessions. Both can hold poisoned context, so both need access control, validation and a way to remove what turns out to be wrong.

Inter-agent communication

In a multi-agent system, one agent's output is another agent's instruction. Messages create implicit trust, so each participant needs an authenticated identity and a limit on what it can delegate.

Orchestration and runtime infrastructure

The layer that coordinates model calls, tools, memory and policy. A weakness here affects every component at once, which is why the decision point belongs here rather than in the model.

How is the AI agent attack surface different from an LLM application attack surface?

An LLM application takes text and returns text. Its surface is the prompt, the model, the retrieval corpus and the key that reaches the provider. Most of the risk is contained inside the application.

An agent is a system that acts. It plans across steps, selects tools at runtime, holds identities, reads untrusted content and writes to other systems. The risk is no longer confined to a response. It shows up in the actions, and in the state an action leaves behind.

Dimension	LLM application	AI agent
Primary input	A prompt from a user	Prompts, tool output, web pages, issues, email, memory
Reach	The model and its retrieval index	Tools, MCP servers, internal APIs, databases, shells
Identity	One service key for the app	Per-agent identities, inherited user tokens, delegated credentials
Persistence	Session context	Long-lived memory, vector stores, files, scheduled tasks
Blast radius	A wrong answer	A changed record, a payment, an exfiltration, a production change
Where control lands	Input filtering and output review	Capability policy at the point of action, plus detection
Owner	The application team	The business function that delegated the authority

The last row is the one that changes the operating model. An LLM application belongs to a product team. An agent's surface usually spans several teams, because the agent borrows their systems, their data and their credentials.

What are the main risks across the AI agent attack surface?

Agents expand operational risk in a small number of recurring ways. Each one needs a different control.

Tool and MCP server compromise

Every server an agent can call is code you did not write, running with access you granted. Tool descriptions are instructions the model reads, which makes a malicious description a working attack with no code execution. Tool poisoning, rug-pull updates and dependency compromise all reach the agent through this path.

The practical question is not whether a server is trustworthy in general. It is which tools that server exposes today, and whether anyone reviewed the description and the scopes.

Credential and identity exposure

Agents act as someone. That identity is often a developer token, a service account with a shared password, or an API key in an environment variable. Once an agent holds it, a hijack inherits everything the credential can reach.

A survey of 5,200 open-source MCP servers found 88% require credentials, 53% rely on long-lived static secrets and only 8.5% use OAuth, with 79% passing API keys through environment variables (State of MCP Server Security 2025, Astrix). That is a credential population that no rotation policy covers.

Context and memory poisoning

Retrieved content and stored memory are inputs the model treats as knowledge. A page, an issue comment or a tool response can place a fact that changes behaviour for weeks. Because memory outlives the session, the usual "the user would have noticed" assumption stops holding.

Retention is the practical control. If memory has no expiry and no way to review what was written, the only option left is deleting the whole store.

Egress and exfiltration

Almost every exfiltration needs an outbound connection. Agents frequently have more network reach than their task requires, because the machine they run on is a developer laptop with internet access. The combination of private data, untrusted content and outbound reach is the lethal trifecta, and each part is easy to find in a working deployment.

Log the destination, not just the request. An allowlist tells you what should happen; the record of where the bytes went tells you what did.

Host and supply chain reach

An agent running as a developer inherits the home directory, SSH keys, cloud credentials and browser sessions. The framework underneath is a supply chain too. An unpinned package update can change what the agent can do without a single permission change on the identity.

Run the agent as a separate account. Most of this risk disappears the moment the agent stops inheriting the developer's home directory.

Approval fatigue and trust

A control that asks a person to approve every tool call stops being a control within a day. Rubber-stamped approvals are how a blocked action becomes an incident with a signature on it.

Score reversibility. Reversible actions can be batched; irreversible ones deserve a decision every time.

How are AI agents used in cyberattacks?

Attacks against your agents and attacks that use agents are two different problems, and a programme has to hold both at once.

Threat actors increasingly use agents to automate reconnaissance, prioritise targets and iterate on attempts that fail. The change is not that machines can scan. It is that an attempt can be varied and repeated without an operator at the keyboard, which is the same persistence economics that decides how often injection succeeds. On the defensive side the numbers already show it: one injection attempt against Claude Opus 4.6 in GUI computer use succeeded 17.8% of the time, and 200 adaptive attempts reached 78.6% without safeguards (Claude Opus 4.6 System Card, February 2026). Automation is what makes the two hundredth attempt cheap.

The practical consequences are unglamorous. Patch cadence matters more when the scanning is continuous. Rate limiting and anomaly detection on authentication matter more when guessing is free. And an agent that can act on your infrastructure is worth hijacking precisely because it holds the access an attacker would otherwise have to earn.

Who is responsible for reducing the AI agent attack surface?

The deploying organisation, always. Model providers set capability, platform operators set defaults, but the organisation that grants the authority owns the consequence. That does not shift when the agent acts without a human in the loop.

Reducing the surface needs three named roles. An owner for each agent, who can say what it may reach and why. An owner for the inventory, who keeps it current. And an owner for the policy that enforces the boundary, who reviews exceptions.

In practice, the security team supplies the control and the business function supplies the authority decision. A control nobody asked for gets bypassed, and an authority nobody checked gets abused.

How to reduce the AI agent attack surface

Work from the parts you can bound deterministically before the parts that depend on model behaviour.

1. Inventory every agent, tool and credential source. Discovery has to run on the endpoints where agents actually work, in read-only mode, and it has to refresh. Include MCP servers, the tools each one exposes and the credential files in reach.

2. Give every agent a dedicated identity, then lease credentials to it. A distinct identity makes attribution and revocation possible, and a lease minted for one task and one destination limits what a hijacked agent can do. It also removes the copy of the secret in a dotfile.

3. Allowlist tools, pin versions and review descriptions. A sanctioned server list turns an unlimited supply chain into a finite one. Pin the version, review the tool descriptions, and re-review on update.

4. Bound egress to the destinations each agent needs. Most exfiltration is an outbound connection. Decide the allowlist per agent class, and treat an unlisted destination as a block rather than a log line.

5. Separate untrusted content from decisions. Where the architecture allows it, choose the tool set before reading untrusted input. On AgentDojo that single design choice cut a targeted attack success rate from 47.69% to 6.84% while keeping utility at 72.16% (AgentDojo results).

6. Reduce the host blast radius. Run agents as a dedicated low-privilege account with access to the repositories and hosts the task needs. Not the developer's whole home directory, not their personal token.

7. Run policy in monitor mode, then enforce. Record what a rule would have blocked, review the false positives with the people doing the work, then enforce on the rules you have proven. Enforcement that blocks real work gets switched off.

8. Test the whole workflow, then keep the inventory continuous. Red-team the agent, not only the model: memory, retrieval, tools, identities and agent-to-agent messages are all part of the surface. Review the inventory on a cadence, because a quarterly review of a daily-changing surface measures the past.

Where does the attack surface appear in the agent lifecycle?

The surface is created at design and widened by every stage after it.

Design

The scope decision sets the ceiling. Which systems the agent may reach, which data classes it may touch and how autonomous it is all land here. Breadth chosen for convenience at design becomes a permanent control problem.

Development

Tools get wired, credentials get pasted, and a config file gains a server that a colleague recommended. This is where an unpinned dependency or an unread tool description enters the estate.

Pre-deployment testing

Red-teaming the agent, not only the model, is the useful test here. Attempt injections through tool output, not just the prompt, and check whether the agent reaches a destination it was not meant to.

Deployment

Deployment is where permissions become real. Verify the identity actually holds the scopes you think it does, and confirm the logging destination is receiving events before the first production call.

Runtime

This is where execution control matters. Policy should decide on each tool call with the agent's identity, the destination and the task history in view, and it should be able to hold an action for approval rather than only deny it.

Continuous monitoring

Watch for widening, not only for failures. New servers, broader tokens and new integrations change the surface without a change ticket. Attribute every new tool to an owner within a day.

Decommissioning

Retire the credentials, revoke the server access and delete the memory. Orphaned agents keep their permissions and keep showing up in scans years later.

Example: reducing the surface of a coding agent in a fintech SDLC

A hypothetical worked example. The company, the events and the numbers below are illustrative, not a customer result or a measured outcome.

A payments company gave 40 engineers a coding agent with a personal access token, a shell and an MCP server for its internal API. A review found three problems: the token could read production configuration, the MCP server exposed 30 tools of which four were used, and the agent could reach any host on the network.

The team started with discovery. Beacon, running read-only, produced the inventory: 61 agents and CLIs, nine MCP servers, and 22 credential sources across the fleet. Four of the servers had no owner.

Next came credentials. The personal access token was replaced with a lease minted per task, scoped to one repository and one branch, expiring in 20 minutes. The production configuration read was denied by policy rather than by convention.

Then the tools. The internal MCP server was cut to six reviewed tools, pinned by version, with descriptions signed off by the API owner. The remaining 24 tools were retired rather than hidden, which removed the question of who had approved them.

Egress came next. The agent could reach the package registry, the repository host and the internal API. Everything else was blocked, including the metadata service.

The last change was the one engineers noticed. Policy ran in monitor mode for two weeks, and the false positives were fixed in the rules rather than in the workflow. Enforcement then applied to pushes after a web fetch, reads of secret files and calls to production hosts.

Eight weeks after the review, the fleet had 47 agents instead of 61, nine MCP servers instead of nine unmanaged ones with four orphans removed, and a policy record for every tool call. The engineers kept the same tool. The surface got smaller.

How standards and regulations influence the AI agent attack surface

The frameworks were written for systems that act, not only for models that answer. That makes them usable here without translation.

Framework	Primary focus	Relevance to the attack surface
NIST AI RMF	Risk identification and lifecycle management	MAP is the inventory, MEASURE is the surface metric, MANAGE is the response when a path is found open
ISO/IEC 42001	AI management system	Requires a register of AI systems with owners, scope and risk treatment, which is the inventory in management-system form
ISO/IEC 42005	AI system impact assessment	Structures the pre-deployment judgement about what an agent's reach could affect
ISO/IEC 23894	AI risk management alignment	Places agent risk inside enterprise risk registers and existing control models
EU AI Act	Binding obligations for high-risk systems	Article 15 requires robustness and cybersecurity, including resilience against attempts to exploit vulnerabilities
OWASP LLM Top 10	Application security risks for LLM systems	LLM06 Excessive Agency names the permission model the surface rests on
OWASP Agentic Top 10	Agent-specific risks	ASI01 goal hijack, ASI02 tool misuse, ASI03 identity and privilege abuse, ASI04 supply chain
OWASP MCP Top 10 (beta)	MCP-specific risks	MCP01 secrets, MCP03 tool poisoning, MCP07 authorization, MCP09 shadow servers
SOC 2	Controls over security and availability	CC6 logical access and CC7 monitoring are the two criteria a surface review produces evidence for

How Alyria handles it

Alyria (alyria.ai) starts from the endpoint, because that is where the surface is. A signed, user-space Beacon on each machine inventories the AI layer continuously: every agent and CLI, every MCP client and server, the tools each one exposes and the credentials in reach.

Above the inventory, Lyra evaluates capability-brokered, information-flow-aware policy against every MCP tool call and model request, locally, before the call leaves the machine. Umbra brokers credentials so the agent gets a short-lived lease instead of a standing secret. Spectra records each decision and trajectory as signed OpenTelemetry to Observatory or to your SIEM, which is how a reduced surface becomes a provable one.

Start with the free Agent Exposure Report for the read-only inventory, read how a request is governed for the enforcement path, and check the Lyra policy documentation for the rule model.