The Agentic Attack Surface Lives Between Models and Tools.
The model gets evaluated. The tools get reviewed. The seam connecting them — where a model's output becomes a tool's instruction — usually gets neither.
Two review processes tend to exist around an agentic system, and both are reasonable on their own terms. The model gets evaluated — red-teamed for harmful outputs, tested against known jailbreaks, benchmarked for accuracy. The tools get reviewed — the API endpoints, the database access, the file operations, checked the way any piece of software touching production would be checked.
What sits between them usually gets neither. The seam — the point where a model's output stops being text and becomes a tool call's input — is where most of the incidents we see actually originate. Not in the model. Not in the tool. In the handoff.
Why the seam is different from either side
A model evaluation asks whether the model says harmful things. A tool review asks whether the tool is secure against a malicious caller. Neither asks the question that matters once the two are wired together: what happens when the model's output — shaped by whatever untrusted content it just read — becomes the literal instruction the tool executes next.
That untrusted content doesn't have to come from the user typing into a chat box. It can arrive from a web page the agent was asked to summarize, a document it was asked to process, an email it was asked to triage, or the output of another tool earlier in the same chain. Once instructions can ride in on data, the model's job of separating "things to describe" from "things to do" gets adversarial in a way most pipelines were never designed to survive.
Each side assumes the other already checked
The reason the seam goes unexamined is not that teams are careless. It's that the responsibility for checking it belongs to no one by default. The tool trusts that whatever arrives from the model was already sanitized, because the model is "the smart part" of the system and surely wouldn't pass along something dangerous. The model, for its part, has no concept of trust boundaries at all — it was handed text and asked to act, and it did. The validation everyone assumes is happening upstream is, on inspection, happening in neither place.
This is why the seam is a responsibility gap as much as a technical one. A model eval and a tool pentest can both come back clean, each certifying the half it owns, and the system as a whole can still be wide open — because the thing that's broken is the untested assumption that output from a trusted-looking component is safe to execute. Nobody wrote that assumption down. It just sits in the space between two review processes that were never asked to meet.
The vulnerability isn't in the model or in the tool. It's in the assumption that whatever the model outputs is safe to execute.
Where this actually breaks in practice
These are not exotic failure modes; they are the ordinary ways the seam gives way once a system is wired together and left to run on its own. Each one is the same underlying gap wearing different clothes — untrusted content treated as a trusted command, or one component's output treated as another's vetted input — and each tends to pass every review aimed at a single component in isolation. The pattern below is worth reading as a map of where the handoff, rather than either endpoint, is what actually fails:
- Prompt injection via retrieved content — a summarized page or document contains text instructing the agent to take an unrelated action, and the agent complies because it has no reliable way to distinguish content from command.
- Tool output treated as trusted input — the result of one tool call feeds directly into the next tool call's parameters, with no validation that the pipeline was actually designed for that data to flow through.
- Chained agent behaviors — a low-risk action in isolation (read a file, query a record, fetch a page) becomes high-risk once an agent can string several together autonomously, because no single step trips the review that would have caught the sequence.
- Over-permissioned tool access — the agent holds credentials scoped for its broadest possible task, not the specific one in front of it, so a manipulated output has more to work with than the task ever required.
- Missing output validation before execution — the tool trusts that anything arriving from the model was already sanitized upstream, and the model trusts that anything it's asked to act on was already vetted — and the actual check happens in neither place.
Why autonomy raises the stakes
In a system with a human approving each action, the seam is still a weakness, but a slow one — a person sits between the model's suggestion and the tool's execution, and has at least the chance to notice that something is off. Autonomy removes that checkpoint by design. The whole point of an agent is that it decides and acts without waiting, so the manipulated output doesn't pause for inspection; it becomes a tool call at machine speed, and then the result of that call becomes the input to the next decision.
That is what turns a collection of individually harmless capabilities into a genuine attack surface. Reading a page is safe. Querying a record is safe. Writing a file is safe. An agent that can do all three in sequence, steered by content it read along the way, is doing something no single step's review ever evaluated — and the faster and more autonomous the loop, the less opportunity anything has to catch it before the effect lands.
Testing the seam, not just the endpoints
Closing this gap means testing the system as a system — not the model in isolation, not the tools in isolation, but the full path data takes from an untrusted source through the model's reasoning and into an executed action. That's a different exercise from a standard model eval or a standard penetration test, and it's the one most agentic deployments haven't had run against them yet.
It's also exactly the discipline behind 6QURE's AI Red Teaming & Evaluation work: we test how it actually behaves under adversarial pressure — prompt and tool manipulation, data exfiltration paths, chained agent behaviors — at the level of the full system, not just the model in isolation. The model and the tools will each have been checked already. The seam between them is where we start.
Facing something like this in your own environment?