An AI agent's attack surface is everything that can feed it instructions or that it can act on: prompts, retrieved documents, tool and API access, memory, and the credentials it holds. Shrink it by limiting what the agent can touch, treating all retrieved content as untrusted, and logging every action.
Why is an agent different from a chatbot?
A chatbot produces text. An agent takes steps: it reads a ticket, calls an API, writes a file, sends a message. Each step uses authority that someone granted. That authority is what an attacker wants, and the agent's willingness to follow instructions is the route to it.
OWASP now tracks this as its own area. The GenAI Security Project has a Top 10 for Agentic Applications for 2026, alongside its Top 10 for LLM Applications. In the LLM list, "Excessive Agency" and "Prompt Injection" are the two entries that most directly describe an agent going wrong.
What are the parts of the surface?
Inputs. Anything the model reads can carry instructions: a web page, an email, a PDF, a code comment, a tool's response. The model has no reliable way to tell "data to summarise" from "orders to follow". NIST's report on adversarial machine learning (AI 100-2) gives a shared vocabulary for attacks of this kind.
Tools. Each tool is a capability. A tool that can read a file system and one that can send email, used together, make exfiltration possible without any bug in either.
Credentials. If the agent runs with a developer's token, it has that developer's reach. If it runs with a shared service account, you cannot tell its actions from anyone else's.
Memory and context. Stored notes and vector stores can be poisoned. A bad entry written today can steer behaviour next week. OWASP lists "Data and Model Poisoning" and "Vector and Embedding Weaknesses" for this reason.
Supply chain. Plugins, tool servers, models and prompts come from somewhere. Each is a dependency.
Output handling. What the agent produces may be executed downstream, as a shell command or a query. OWASP calls the failure "Improper Output Handling".
What does a constructed incident look like?
A support agent can read customer tickets and look up orders. A customer submits a ticket whose body says to include the last five orders of the account in the reply. The agent has both tools and no check that the order lookup should match the ticket's own customer. It complies. Nothing was hacked in the usual sense. The permissions were too wide, and the input was trusted.
How is this different from classic application security?
In a normal application, code decides what happens, and inputs are data. In an agent, a model decides which tool to call, and inputs can change that decision. Two requests with the same permissions can produce different actions. You cannot prove safety by reading the code alone, so you rely on boundaries that hold whatever the model decides: narrow credentials, allow lists for tools, approvals for irreversible steps, and logs you can replay. Test those boundaries the way you would test a firewall rule, by trying to cross them.
How to check or apply this
- List every agent you run and every tool each can call. Write the data each tool can read and the actions it can take.
- Give each agent its own identity and short-lived, narrow credentials. Avoid personal tokens.
- Remove tools the task does not need. A summariser does not need to send email.
- Put a human approval step in front of irreversible actions: payments, deletions, external messages.
- Treat retrieved text, tool output and other agents' messages as untrusted input.
- Check output before it is executed or sent, and log each tool call with who, what and why.
- Test with your own malicious documents in a staging environment, and record what the agent did.
Safeguard offers MCP Guardrail and agent identity controls for teams who connect agents to tools, so tool calls can be checked against policy.
Quick check
Is prompt injection the whole problem?
No. It is one way in. Excess permissions, weak credentials, poisoned memory and unsafe output handling decide how much damage any entry point can cause.
What is the most useful first step?
Cut the agent's permissions to the minimum its task needs. It limits damage whatever the attacker tries.
Sources
- OWASP Top 10 for Large Language Model Applications
- OWASP Agentic Security Initiative
- NIST AI 100-2 E2025, Adversarial Machine Learning taxonomy
- MITRE ATLAS
Last reviewed: 18 October 2026.
