AI Agent Attack Surface: How to Map Every Entry Point an Attacker Can Reach

TL;DR: An AI agent's attack surface is not just its chat interface — it includes every tool it can call, every data source it can read, every output channel it can write to, and the trust boundaries between all of them. This guide walks through how to map the complete attack surface of an AI agent, layer by layer. To do it automatically, ARTEMIS Recon maps your agent's tools, APIs, and trust boundaries in minutes, free.

The AI agent attack surface is not what you think#

When most teams think about AI security, they think about the chat interface. Can someone jailbreak the chatbot? Can they extract the system prompt? These are real vulnerabilities, but they are the smallest part of an AI agent's attack surface.

An AI agent is not a chatbot. A chatbot receives text and returns text. An AI agent receives text and takes actions: it calls APIs, queries databases, reads files, sends messages, browses the web, executes code. The attack surface of an AI agent is every action it can take and every data source it can access — not just its input field.

Consider a customer support AI agent with the following capabilities:

• Reads customer records from a database
• Sends emails through a transactional email service
• Creates refund requests in the billing system
• Reads internal knowledge base articles
• Searches the company's Slack workspace for internal context

This agent has five distinct attack surfaces beyond the chat input. Each tool is an entry point. Each tool parameter is a potential injection point. The combination of tools creates attack chains that no individual tool assessment would find.

Mapping this attack surface is the first step in any AI security assessment. Without the map, you are testing blindly — and the vulnerabilities you miss are the ones that matter most.

The five layers of AI agent attack surface#

Every AI agent's attack surface can be decomposed into five layers. Map each one to get a complete picture.

Layer 1: Input surface#

Everything that enters the agent as input from users or external systems.

Text input — the primary chat interface. This is where direct prompt injection happens. Map the exact input processing: does the input go directly to the model, or is it preprocessed (sanitized, classified, filtered)?

File uploads — if the agent accepts file uploads (PDFs, images, spreadsheets, code files), each file type is a separate injection surface. PDFs can contain hidden text layers. Images can contain steganographic instructions. Spreadsheets can have hidden sheets with injected prompts.

Structured data — forms, API request bodies, or structured input fields that feed into the agent's context. Each field is a potential injection point.

Voice and audio — if the agent processes voice input, the transcription pipeline is an attack surface. Adversarial audio can transcribe to injected instructions.

Images and video — multi-modal agents that process images can receive injected instructions through text embedded in images, adversarial pixel patterns, or manipulated screenshots.

For each input type, document:

• What preprocessing is applied before it reaches the model?
• Does the input go into the system prompt, user message, or a tool parameter?
• Is the input type visible to users in the agent's response?
• Can external systems provide this input type without user interaction?

Layer 2: Prompt surface#

The instructions and context that define the agent's behavior.

System prompt — the instructions that set the agent's role, constraints, tool usage rules, and persona. If the system prompt can be extracted, the attacker knows the rules and can target the gaps. If the system prompt can be overridden, the attacker controls the agent.

Conversation history — in multi-turn conversations, the full history is part of the context. Older turns can be leveraged for multi-turn escalation attacks. Long conversations push the system prompt further from the model's attention.

Retrieved context — for RAG (Retrieval-Augmented Generation) systems, the retrieved documents are part of the prompt context. If any retrieval source is attacker-influenceable, it is an indirect injection surface.

Few-shot examples — if the agent uses in-context examples to guide its behavior, those examples shape its responses. Manipulated examples can shift behavior without overriding instructions.

For each context source, document:

• Who can modify this content? (developer only, user, external system)
• Is the content treated as trusted (system-level) or untrusted (user-level)?
• How does the model prioritize this content relative to other context?
• What happens when this context is very large — does it push other instructions out of the attention window?

Layer 3: Tool surface#

Every tool the agent can call — and every parameter it can set.

This is the highest-impact layer for agentic systems. Traditional chatbot security focuses on input and output. Agent security lives and dies on the tool surface.

For each tool, enumerate:

Tool chains — beyond individual tools, map which combinations of tools create attack chains. A read_file tool and a send_http tool are individually harmless. Together, they enable data exfiltration. The mapping should identify every pair (and triple) of tools whose combination creates a capability that exceeds the individual tools' intended scope.

For details on testing tool-level security in MCP-based agents, see our MCP server security testing guide.

Layer 4: Data surface#

Everything the agent can read, write, or modify — directly or through tools.

Databases — what tables and columns can the agent query? Can it write? Can it delete? Are there row-level or column-level access controls, or does the agent's database connection have full access?

File systems — what directories can the agent read and write? Can it access configuration files, credential files, or other sensitive system files?

External APIs — what external services can the agent call? What data can it send to them? What data comes back?

Memory systems — does the agent persist information across sessions? Can a previous conversation's context be accessed in a new session? Can an attacker plant information in memory that influences future sessions?

Knowledge bases — what retrieval sources feed the agent? Can users add documents to the knowledge base? Can external content (web scrapes, email imports) enter the knowledge base?

For each data source, classify:

• Read-only — the agent can access it but cannot modify it
• Read-write — the agent can access and modify it
• External — the data source is outside the organization's control
• User-writable — users can influence the data source's contents

User-writable data sources that feed into the agent's context are indirect injection surfaces.

Layer 5: Output surface#

Where the agent's responses and actions go.

Display output — text responses shown to the user. The lowest-risk output channel because the user sees everything and can catch anomalies.

Email/messaging — if the agent sends emails or messages, its output reaches external recipients. An attacker who controls the output can use the agent for phishing or social engineering.

API calls — if the agent's output triggers API calls (creating records, updating configurations, processing payments), the output has direct system impact.

File writes — if the agent writes files (reports, logs, configuration), those files can be executed, read by other systems, or persist malicious content.

Other agents — in multi-agent systems, one agent's output is another agent's input. Compromising the upstream agent compromises the downstream agent's input.

For each output channel, document:

• Who receives the output? (user, external system, other agent)
• Is the output validated before delivery?
• Can the output trigger actions without human review?
• What is the worst-case impact if the output contains attacker-controlled content?

Trust boundary analysis#

After mapping all five layers, the critical step is identifying trust boundaries — where data crosses from trusted to untrusted or vice versa.

Trust boundary violations are the highest-severity findings in an AI agent attack surface assessment. They happen when:

1. Untrusted data is treated as trusted. User input or external data enters the agent's context as if it were system instructions. This is the mechanism behind all prompt injection attacks.

2. Low-privilege data reaches high-privilege tools. A user who should only have read access to their own records manipulates the agent into querying all records through a tool that has admin-level database access.

3. Internal data exits through external channels. The agent reads internal data (customer records, internal documents, system configuration) and outputs it through an external channel (email, API response, or tool parameter sent to an external service).

4. Cross-tenant data leakage. In multi-tenant AI systems, one tenant's data or context leaks into another tenant's session through shared memory, shared retrieval sources, or shared model context.

Draw the trust boundaries on your attack surface map. Every boundary crossing is a potential vulnerability.

Building the attack surface map#

Manual mapping#

For small agents (1-3 tools, single input modality), manual mapping is feasible:

1. Interrogate the agent. Ask it what tools it has, what it can do, and what data it can access. AI agents are often surprisingly honest about their capabilities.
2. Read the configuration. Check the system prompt, tool definitions, and integration configurations.
3. Probe the edges. Test each input type, each tool parameter, each output channel with boundary inputs.
4. Document the topology. Use the five-layer framework above to create a structured map.

Automated mapping#

For complex agents (multiple tool integrations, multiple input modalities, RAG pipelines), manual mapping misses things. You need an automated reconnaissance tool that can interact with the agent through its actual interfaces and systematically discover its capabilities.

ARTEMIS Recon does this. It runs an autonomous reconnaissance agent against your AI application — through the web interface or API — and maps the complete attack surface: tools, parameters, trust boundaries, retrieval sources, input modalities, and escalation paths. The output is a structured attack-surface map that feeds directly into penetration testing and red teaming.

What the map enables#

A completed attack surface map transforms AI security testing from guesswork to systematic assessment:

• Prioritize testing — focus on the highest-impact tool chains and trust boundary violations, not the obvious chatbot-level attacks
• Scope red team engagements — the map defines exactly what is in scope and what the expected blast radius is
• Track changes — re-map after every deployment to catch new tools, changed permissions, and new data sources
• Communicate risk — a visual attack surface map is the most effective way to explain AI security risk to non-technical stakeholders

Frequently asked questions#

What is an AI agent attack surface?

The attack surface of an AI agent is the complete set of entry points through which an attacker can influence the agent's behavior, extract data from it, or make it perform unintended actions. Unlike traditional software where the attack surface is defined by code endpoints and network exposure, an AI agent's attack surface includes its system prompt, tool integrations, retrieval sources, input modalities, memory systems, and the trust boundaries between them.

Why is AI agent attack surface different from traditional attack surface?

Traditional attack surfaces are defined by code: APIs, network ports, input fields, authentication flows. AI agent attack surfaces include all of that plus language-based entry points (the prompt layer) and capability-based entry points (tools, integrations, memory). An AI agent with access to 10 tools has 10 additional attack entry points that do not exist in traditional software. The attack surface also changes dynamically — a new conversation can expose different capabilities than the last one.

How do you map an AI agent's attack surface?

Start by enumerating five layers: (1) Input modalities — text, images, audio, files, structured data. (2) Prompt surface — system prompt, conversation history, retrieved context. (3) Tool surface — every tool the agent can call, its parameters, and its permissions. (4) Data surface — what data the agent can access through tools, retrieval, and memory. (5) Output surface — where the agent's responses go and what actions they trigger. For each layer, identify the trust boundaries: where does untrusted input enter, and what can it reach?

What tools can map AI agent attack surfaces automatically?

ARTEMIS Recon by Repello AI automates attack surface mapping for AI agents — it identifies tools, APIs, prompt surface, trust boundaries, and escalation paths. Open-source alternatives require manual assembly: use the AI's own responses to enumerate tools, test input handling across modalities, and probe trust boundaries through adversarial prompting. Automated mapping is faster and more comprehensive because the mapping agent can interact with the target agent through its actual interfaces.

What is the most commonly missed part of AI agent attack surfaces?

Tool responses. Most security assessments focus on user input (direct prompt injection) and sometimes retrieved content (indirect injection). Tool responses — the data that comes back when the agent calls a tool — are a critical injection surface that is often untested. If any tool returns attacker-controllable data, that data enters the agent's context and can influence its subsequent behavior, including which other tools it calls and with what parameters.

From map to action#

The attack surface map is not the goal — it is the starting point. Once you have the map:

1. Identify the highest-blast-radius paths. Which tool chains could lead to data exfiltration, unauthorized actions, or system compromise?
2. Test those paths. Use the AI penetration testing methodology to systematically attack the highest-risk paths.
3. Fix the trust boundary violations. Add input validation, parameter constraints, output filtering, and permission scoping at every trust boundary crossing.
4. Re-map after fixes. Confirm that remediations actually reduced the attack surface, and that new attack paths were not introduced.

ARTEMIS Recon automates step one. Point it at your AI agent, get the attack-surface map in minutes, and know exactly where to focus your testing. Runs inside your own Claude Code session. Three free runs. No sales call.

Map your AI agent's attack surface free →