Table of Contents

What Is the AI Agent Attack Surface?

4 min. read

Table of Contents

The AI agent attack surface is the collection of systems, identities, tools, data sources, memory stores and communication paths that could be exposed or misused when an AI agent performs tasks. It extends beyond the model's prompts and responses to include every resource the agent can access and every action it is authorized to take.

AI agents can plan multistep workflows, retrieve information, call APIs, use software tools and act on behalf of users or applications. These capabilities make agents useful, but they also create additional security considerations. A manipulated response in a conversational AI application may produce incorrect information. In an agentic system, a manipulated instruction could also cause the agent to access data, change a record or invoke another system, depending on its permissions and safeguards.

The size of an agent's attack surface depends on its design. An agent with limited data access, narrowly scoped permissions and human approval requirements has a smaller operational footprint than an autonomous agent connected to numerous enterprise systems.

Key Points

Expanded reach: An AI agent's attack surface includes the model as well as its tools, identities, data sources, memory and connected systems.
Action creates consequence: Because agents can take actions, a model error or manipulated instruction can affect applications and data outside the AI system.
Access determines exposure: The number of tools an agent can use and the permissions assigned to it directly influence potential impact.
State introduces persistence: Stored context and memory can preserve inaccurate or malicious information across steps or sessions.
Controls must follow execution: Effective security requires visibility and policy enforcement across the agent's complete workflow, not only its initial prompt and final response.

Why Do AI Agents Expand the Attack Surface?

Traditional generative AI applications often focus on receiving input and producing content. Some also use retrieval systems, conversation history, APIs or other application components. AI agents generally extend this model by selecting actions and interacting with external resources to accomplish a goal.

For example, an agent might read an email, retrieve a customer record, update a ticket and notify another system. Each connection adds a potential point of exposure. The agent's effective security boundary therefore includes the model and orchestration layer, the systems it can reach and the permissions used throughout the workflow.

An agent does not inherently create the same level of risk in every deployment. Exposure increases when agents have broad permissions, access untrusted content, retain persistent state, connect to numerous tools or operate without appropriate approval and monitoring controls.

What Makes Up the AI Agent Attack Surface?

Instructions, reasoning and planning

Agents interpret goals and determine the steps required to complete them. Attackers may attempt to manipulate this process through direct prompt injection, indirect prompt injection or malicious content retrieved from external sources.

If the agent cannot reliably distinguish trusted instructions from untrusted data, it may incorporate an attacker's directions into its plan. The consequences depend on what the agent is permitted to do.

Tools and external systems

Agents may connect to APIs, databases, SaaS applications, browsers, code execution environments and file systems. Every tool expands the set of resources the agent can reach.

Tool-related exposure can result from insecure integrations, excessive functionality, inadequate input validation or missing authorization checks. Security controls should validate both whether an agent is allowed to use a tool and whether a particular action is appropriate within the current task.

Model Context Protocol connections

The Model Context Protocol provides a standardized way for AI applications to connect with tools and data sources. MCP can simplify interoperability, but an insecure or ungoverned implementation can introduce risks such as unauthorized tool access, malicious servers, excessive permissions and token misuse.

MCP supports authorization capabilities for HTTP-based transports, but authorization is optional and does not replace enterprise access governance, tool-level policy or monitoring. Organizations should evaluate each MCP client, server and connected resource as part of the agent's overall trust boundary.

Identity and credentials

Agents require identities and credentials to access protected resources. Risk increases when an agent uses shared credentials, inherits a user's full access or relies on a broadly privileged service account.

A dedicated agent identity makes it easier to apply least privilege, attribute actions and revoke access without affecting other users or services. Permissions should be limited by task, resource and duration whenever possible.

Data and context sources

Agents may process content from email, documents, websites, databases, collaboration platforms and retrieval systems. Some of this information may be untrusted, inaccurate or intentionally manipulated.

External content can become an indirect instruction channel when an agent treats data as commands. Sensitive information may also be exposed if the agent retrieves more context than a task requires or sends protected data to an unauthorized destination.

Memory and stored state

Some agentic systems maintain short-term state during a workflow or long-term memory across sessions. Stored state helps an agent preserve context, but it can also retain sensitive, inaccurate or malicious information.

Memory poisoning occurs when an attacker causes manipulated information or instructions to be stored and reused. Memory systems therefore require access controls, data validation, retention rules and mechanisms for reviewing or removing unsafe content.

Inter-agent communication

In multi-agent systems, an orchestrator may assign work to specialized agents and combine their results. Messages passed between agents can create implicit trust relationships.

If one agent is compromised or produces manipulated output, other agents may act on that information. Systems should authenticate agent identities, validate delegated tasks and limit the data and permissions available to each participant.

Orchestration and runtime infrastructure

The orchestration layer coordinates model calls, tool selection, memory, policies and workflow execution. A weakness in this layer can affect multiple components at once.

Runtime infrastructure should enforce policy at the point of action, record decisions and support intervention when an agent attempts an unexpected or high-impact operation.

AI Agent Attack Surface vs. LLM Application Attack Surface

Both LLM applications and AI agents can face risks involving models, prompts, training data, retrieval sources and application infrastructure. The principal difference is that agents can independently select and execute actions within a defined level of autonomy.

Area	LLM application	AI agent
Primary function	Generates or transforms content	Pursues goals through multistep actions
External access	May use retrieval, APIs or application services	Commonly selects and invokes multiple tools
Identity	Often acts within an application session	May require its own identity or delegated credentials
State	May retain history or application-managed context	May use working state and persistent memory to guide actions
Operational impact	Often limited to content or application output	May modify data, trigger workflows or operate connected systems
Communication	Usually interacts with users or application components	May coordinate with other agents and orchestrators

The distinction is not absolute. An LLM application can have extensive integrations, while an agent can be narrowly constrained. Security teams should evaluate actual capabilities and access rather than relying only on the system's label.

Common Threats Across the AI Agent Attack Surface

The attack surface describes where exposure exists. Threats describe how an attacker may attempt to exploit that exposure.

Threat	Targeted area	Potential result	Example control
Direct prompt injection	Instructions and planning	The agent follows a malicious user instruction	Instruction hierarchy, input inspection and action controls
Indirect prompt injection	Retrieved data and tool output	Untrusted content influences the agent's behavior	Content isolation, data labeling and runtime detection
Tool misuse	Tools and APIs	The agent performs an unauthorized or unsafe operation	Tool allowlists, parameter validation and scoped permissions
Credential compromise	Identity and access	An attacker uses the agent's access to reach protected resources	Dedicated identities, short-lived credentials and least privilege
Memory poisoning	Stored state	Malicious context influences later tasks	Memory validation, access controls and retention policies
Agent impersonation	Inter-agent communication	A malicious actor submits instructions as a trusted agent	Mutual authentication and message integrity controls
Excessive agency	Orchestration and approvals	The agent completes a high-impact action without sufficient review	Risk-based approvals, transaction limits and human oversight
Data leakage	Context, memory or outputs	Sensitive information reaches an unauthorized user or system	Data classification, DLP and destination controls

How Can Organizations Reduce the AI Agent Attack Surface?

Discover AI agents and their connections

Maintain an inventory of sanctioned and unsanctioned agents, including their owners, models, tools, MCP servers, data sources and deployment environments. Discovery is necessary before access and security policies can be applied consistently.

Give each agent a dedicated identity

Use a distinct, attributable identity for each agent instead of shared accounts or unrestricted user credentials. Apply least-privilege access based on the agent's intended tasks.

Limit tools and permissions

Allow agents to access only the tools, functions and data required for an approved workflow. Separate read and write privileges, use short-lived credentials and require additional authorization for sensitive operations.

Treat retrieved content as untrusted

Separate system instructions from external data and inspect content received through documents, websites, email, retrieval systems and tool responses. Prevent untrusted content from silently changing the agent's goals or permissions.

Require approval for high-impact actions

Use human or policy-based approval before actions such as deleting data, changing access, executing code, transferring funds or communicating externally. Approval requirements should reflect the reversibility and potential impact of the action.

Test the complete agent workflow

AI red teaming should evaluate the model, prompts, memory, retrieval sources, tools, identities, orchestration and agent-to-agent communication. Testing only the model can miss vulnerabilities introduced by the surrounding system.

Monitor agent activity at runtime

Record prompts, tool calls, memory access, identity use, policy decisions and agent-to-agent messages with appropriate privacy protections. Monitoring should make it possible to reconstruct why an action occurred and which resources were affected.

Govern MCP and other integrations

Inventory MCP servers and other tool connections, authenticate access where applicable and validate the permissions granted to every integration. Block or isolate unapproved servers and review changes to their tools and capabilities.

How Are AI Agents Used in Cyberattacks?

The use of AI agents by attackers is related to, but distinct from, attacks against enterprise AI agents. Threat actors can use agents to automate activities such as reconnaissance, vulnerability research, target prioritization and elements of exploitation.

Unit 42 research into an autonomous AI-driven campaign documented a threat actor using an agentic system to scan for vulnerabilities, prioritize targets and adjust its activity when initial attempts failed. This illustrates how autonomy can increase the speed and scale of established attack techniques.

In separate controlled research, Unit 42 developed an autonomous, offensive multi-agent system to evaluate whether current models could coordinate stages of a cloud attack. Because this was a research demonstration rather than an observed customer incident, its findings should be understood as evidence of potential capability, not evidence that every attack is already autonomous.

These examples reinforce the need to protect both sides of the equation: organizations must secure their own agentic systems while preparing for threat actors to use automation against traditional infrastructure.

Frequently Asked Questions

There is no single risk that applies equally to every agent. Risk is generally highest when an agent can process untrusted content, use powerful tools and act with broad permissions without effective monitoring or approval controls.

No. The attack surface depends on the agent's connections, permissions, autonomy, stored state and deployment environment. A narrowly scoped agent with limited tools and strong controls may have substantially less exposure than an agent with broad enterprise access.

Prompt injection attempts to manipulate an agent's instructions or decision-making. Indirect prompt injection is especially relevant when an agent retrieves content from external sources and may interpret malicious data as an instruction.

Separate identities support least privilege, accountability and access revocation. They also help security teams distinguish an agent's activity from actions performed by a user or another application.

No. MCP is a protocol for connecting AI applications with tools and data. Security depends on how clients, servers, authorization and downstream resources are implemented and governed. Unmanaged or overly privileged MCP connections can increase risk.