Ask a developer to draw the attack surface of a normal web application and they will usually sketch something familiar: an entry point, an authentication layer, a database, maybe a queue. Ask the same developer to draw the attack surface of an AI feature bolted onto that application, and the diagram gets messier fast. There is a prompt template somewhere. There is a retrieval step pulling in documents nobody has re-read in months. There is a tool the model can call. There is a memory store quietly accumulating whatever the last hundred conversations said.
None of that shows up if you only think in terms of "the API and the database." That is the core problem with reasoning about AI risk using a traditional attack-surface mental model: the surface is real, but it is distributed across components that were never designed to be treated as untrusted input.
Start with where content enters the system
Every AI attack surface begins with the paths through which text reaches the model. The obvious one is the user's own message. The less obvious ones are just as important: a document pulled in by retrieval, a web page fetched by a browsing tool, an email summarized by an assistant, a file attached to a support ticket, the output of another agent in a multi-agent pipeline.
Each of these is a place where an attacker who never touches your infrastructure can still influence what the model does, simply by controlling content that eventually lands in the model's context. A support agent that summarizes incoming emails has an attack surface that includes every sender who can reach that inbox. A research assistant that fetches web pages has an attack surface that includes every page it might be asked to read. Mapping the attack surface starts with listing these entry points explicitly, because most teams can name their API endpoints but cannot immediately name every source of text their model reads.
The model itself is part of the surface
Once content reaches the model, the model becomes an attack surface in its own right. It can be pushed toward outputs the application did not intend through prompt injection, jailbreak phrasing, or simply through ambiguous instructions that a hostile input exploits. It can also leak information it was given earlier in the conversation, including system instructions, other users' context, or details from retrieved documents that should have stayed out of the response.
This is different from a traditional code vulnerability. There is usually no single line to patch. The model behaves the way models behave: it follows the most convincing instructions in its context, regardless of whether a human intended those instructions to be authoritative. Reducing this part of the surface means reducing what the model is exposed to and constraining what it is allowed to do with what it sees, not hoping it resists manipulation on its own.
Retrieval expands the surface quietly
Retrieval-augmented generation is often added to reduce hallucination, and it does. It also adds a second data path into the model that is easy to forget when someone asks "what can reach this model." Every document, database record, or search index connected to the retrieval layer is now something an attacker can potentially exploit, either by getting malicious content indexed, or by triggering retrieval of records the current user should never see.
Access control has to run before retrieval, not after generation. A common mistake is to retrieve broadly and depend on the model to "only use what's relevant," which is a request, not a permission boundary. If the retrieval layer can pull a record, the model can describe it, regardless of whether the requesting user was authorized to see it.
Memory turns a moment into a pattern
Memory adds a time dimension to the attack surface. Without memory, a successful prompt injection is scoped to one session. With memory, whatever the model wrote down can resurface in a later conversation, sometimes for a different user, sometimes days after the original interaction. This turns a transient content problem into a persistence problem: what gets stored, for how long, who can trigger writes to it, and who can read it back.
Teams that add memory to make an assistant feel more helpful often skip the question of what an attacker could plant in that memory and how far it could travel. That question deserves the same scrutiny as a database write path, because in effect, it is one.
Tools convert influence into action
Prompts and retrieval decide what the model believes. Tools decide what the model can do about it. This is where the attack surface stops being abstract. A model that can only draft text creates a bounded risk: a bad answer. A model that can call a tool to send an email, modify a record, or trigger a deployment creates an attack surface that includes every operation exposed through that tool, scoped only as tightly as the tool's own permission checks.
The attack surface here is not the tool's code in isolation. It is the combination of what the tool allows and what convinced the model to call it. A narrowly scoped tool with a wide-open model context is still risky if nothing checks whether the specific call being made is one the current user, or any user, should be allowed to trigger.
The people and processes around the system
The least discussed part of the AI attack surface is organizational. Who can change the system prompt in production. Who can add a new tool without review. Who can push a model or embedding update without re-running security evaluations. Who owns the decision to disable a misbehaving agent. These are not code paths, but they determine how quickly a technical weakness turns into an incident, and how long it takes to notice and contain one.
An attack surface map that stops at code and skips these operational questions will look complete and still miss the failure mode that actually happens: a well-intentioned configuration change that widens what the system will do, made by someone who didn't realize they were touching a security boundary.
Mapping it in practice
A workable exercise is to list every component that can put text into the model's context, every tool the model can call, every place output is consumed downstream, and every person who can change any of the above without a second reviewer. For each item, ask what the worst plausible outcome is if that component were fully compromised or fully manipulated by an attacker.
This produces a much longer list than "our API is authenticated," but it is the list that reflects how these systems actually fail. Prioritizing controls against this list, rather than against a generic checklist, is what turns attack-surface mapping into something a team can act on.
Where TELEON fits
TELEON is designed to sit at the runtime boundary between agents, models, and tools, which is exactly where much of this attack surface concentrates. Where it is deployed through the gateway or supported middleware, it can apply policy to tool calls and record audit events for model and tool activity, giving teams visibility into a part of the surface that is otherwise hard to observe after the fact.
It does not reduce the attack surface on its own. Access control on retrieval, scoping on tools, and change control on prompts and configuration are still the responsibility of the application and its owners. What TELEON adds is a consistent place to enforce and log decisions across that surface, rather than relying on each component to implement its own version of the same checks.
A short mapping checklist
- List every source of text that reaches the model, including retrieval,
tools, and other agents.
- List every tool the model can call and the real-world action each one
performs.
- Identify what memory stores, for how long, and who can read it back.
- Identify who can change prompts, tools, or model configuration without
review.
- For each item, write down the worst outcome if it were fully
compromised.
- Rank controls by that worst outcome, not by how easy the control is to
build.
The attack surface of an AI application is larger than its codebase because the system's behavior is shaped by more than its code. Treating prompts, retrieval, memory, tools, and the people who configure them as part of the same surface is what makes the rest of an AI security program point at the right problems.