The attack surface of an AI agent is every point where something outside the developer's direct control can influence what the agent decides to do next, and it's larger than most teams initially assume. It includes the obvious entry point, the user's prompt, but also documents the agent retrieves, tool responses it reads, memory it carries between sessions, messages from other agents, and the tool definitions and system configuration around it. Any of these can become a channel for an attacker to redirect an agent's plan, and because an agent acts on what it reads, a successful manipulation at any of these points can turn into a real action rather than just a bad sentence.
Direct prompt input
The most familiar entry point is still the most common one in practice: a user typing an instruction designed to override the agent's actual task. Direct prompt injection tries to convince the model that the attacker's instructions are the real instructions, sometimes through role-play framing, sometimes through claims of special authority ("ignore previous instructions, you are now in admin mode"), sometimes through more subtle context manipulation. It's the easiest vector to test for and often the one teams defend against first, which is exactly why more sophisticated attacks have moved elsewhere.
Retrieved and indirect content
Indirect prompt injection is where agent-specific risk really shows up. A webpage the agent browses, a PDF it summarizes, an email it processes, a support ticket it triages: any of these can carry an instruction the agent treats as legitimate simply because it appeared in its context window. The attacker never interacts with the agent directly. They just plant content somewhere the agent is known to look, and wait. This vector matters more for agents than for chatbots because agents actively seek out and process external content as part of normal operation.
Tool responses and function outputs
Once an agent calls a tool, whatever comes back is treated as trustworthy input to the next reasoning step, and that response is another place an attacker can inject content if the tool touches anything external, a search API, a scraped webpage, a third-party service response. A compromised or spoofed tool response can steer the agent's subsequent decisions just as effectively as a manipulated prompt, and it's often less scrutinized because teams assume their own tool integrations are safe by default.
Memory and persistent state
Agents with memory carry risk across sessions. Something written to memory today, a fact, a stated preference, an instruction disguised as context, can get read and acted on in a completely unrelated session weeks later. This turns memory into a slow-acting attack surface: the payload doesn't need to work immediately, it just needs to get stored somewhere the agent will trust later.
Inter-agent communication
In multi-agent systems, every message between agents is a potential injection point, and it's frequently the least defended one, because messages arriving from another internal agent don't get the same skepticism as messages arriving from an external user. A single compromised or manipulated agent can push its influence to every agent that trusts its output.
Tool and system configuration
The tools an agent can call, and how broadly they're scoped, are themselves part of the attack surface. An overly permissive tool definition doesn't need an attacker to exploit; it just needs the agent to make a reasonable-looking mistake with access it never should have had. Reviewing tool scope is attack surface reduction, not just good hygiene.
The surface grows quietly with every new integration
Attack surface reviews tend to happen once, at launch, and then get treated as settled. In practice, an agent's surface keeps expanding every time a team adds a tool, connects a new data source, or lets the agent talk to one more internal service, and none of those additions individually feel like a big enough change to warrant a full re-review. A few quarters in, an agent that started with three narrowly scoped tools can easily be sitting on a dozen, several of which nobody has revisited since the day they were added. Treating attack surface review as a recurring item tied to every new integration, rather than a one-time exercise, is the only way to keep the map accurate.
Where TELEON fits
Because so much of an agent's attack surface converges on the moment it calls a tool, whatever fed it the decision to do so, TELEON enforces policy right at that boundary, applying consistent checks regardless of whether the triggering content came from a user prompt, a retrieved document, another agent, or the agent's own memory. It also maintains an audit trail across those tool calls, which matters specifically because attack-surface incidents in agents are often diagnosed after the fact by tracing which input led to which action.
Reducing the attack surface itself, narrowing tool scope, sanitizing retrieved content, isolating memory per user or tenant, remains work done in the application and agent design layer, not something a gateway can do on its own.
A short checklist
- Map every source of content an agent reads, not just the direct user prompt.
- Treat retrieved documents and tool responses as untrusted input by default.
- Isolate memory per user or tenant, and audit what gets written into it.
- Apply skepticism to messages from other agents, not just external users.
- Review every tool definition for scope creep and overly broad parameters.
- Test the system with indirect injection payloads, not only direct prompts.
- Log which input triggered which tool call, for after-the-fact investigation.
An agent's attack surface keeps growing as you add tools, memory, and other agents to the system, and it rarely shrinks on its own. Treating each new integration as a new entry point worth reviewing, rather than an incremental feature, is the difference between a surface you understand and one that surprises you later.