The Agent Is the New Endpoint: MCP, Prompt Injection and the 2026 Wake-Up

For two years the security conversation about AI agents has been stuck on the model: can it be jailbroken, will it say something harmful, does it leak the system prompt. The incidents of 2026 have moved the question somewhere less glamorous and considerably more consequential. The model is rarely what breaks. What breaks is the scaffolding around it — the tool servers it can call, the credentials it carries, and the instructions it will accept from data it was only supposed to read.

Eleven Vulnerabilities in One Layer

At Black Hat USA in August 2026, researchers disclosed eleven vulnerabilities across the frameworks most production agents are built on: LangChain, LangGraph, CrewAI, AutoGen, Microsoft's Agent Framework and Google's ADK. The classes were familiar to anyone who has sat through a web application review — insecure deserialisation, server-side request forgery, path traversal — and that is precisely the lesson. Agent frameworks are web applications with a language model attached, and they inherited two decades of ordinary bugs along with a new class of their own.

The more instructive findings were the three exploitation techniques that required no malicious tool, no compromised server, and no vulnerability in the framework at all. They worked against correctly implemented agents, using only the inputs an agent is designed to consume.

Three Attacks That Need Nothing but Input

• Delayed-execution injection. Instead of instructing the agent to act now, the payload instructs it to act later — when a particular file appears, when the next meeting is scheduled, when a named colleague asks a question. The malicious instruction is stored as an ordinary task, and the harmful action happens in a later session where nothing in the context looks suspicious.
• Cross-agent propagation. Multi-agent systems treat one agent's output as another's input. A sub-agent that summarises an untrusted document can pass an instruction upward to the orchestrator, which holds broader permissions and sees the text as trusted internal output. The injection crosses a privilege boundary that everyone assumed was a trust boundary.
• Persistent memory poisoning. Agents with long-term memory write what they learn. An attacker who gets a false fact or an instruction into that store does not need to re-inject on the next conversation; the poison is retrieved as context, and the agent treats it as its own prior conclusion.

What unites the three is that none of them is a software defect. Each is the feature working as designed, pointed in the wrong direction. That is why patching the framework does not close them, and why the controls have to sit at the orchestration and permission layer.

The Confused Deputy With Standing Access

An agent is a confused deputy by construction: it acts on behalf of a user, with the user's authority, on instructions it cannot reliably distinguish from data. 2026 supplied the proof. Researchers at Capsule Security demonstrated PipeLeak against Salesforce's Agentforce and ShareLeak against Microsoft Copilot Studio, the latter tracked as CVE-2026-21520 — both reached through public-facing form submissions, the kind of field any visitor can fill in. No exploit chain, no endpoint compromise. A text field that a customer service agent would type into was enough to make an assistant act outside its intended scope.

The scale is no longer theoretical either. OWASP's first-quarter 2026 exploit roundup maps its cases, including GrafanaGhost and a Meta internal-agent leak, to the same two categories: tool misuse and prompt injection. Those are reported events in deployed systems, not demonstrations, and they are almost certainly an undercount in a category most organisations do not yet log in a way that would let them notice.

The MCP Inventory Problem

The Model Context Protocol became the default way to connect an agent to tools, data and other agents, and it solved a real problem. It also created a distribution channel that most organisations installed without reviewing. An MCP server is often added the way an npm package is added: a line of configuration, a URL, a token, and it works. The token is frequently the developer's own, with whatever scope their account happened to have.

That produces two attacks that are specific to the protocol. Tool-description poisoning exploits the fact that a tool's description is not documentation for humans — it is an instruction to the model. A server can embed directives in the description of a legitimate-looking tool, and the model will follow them. Rug pulls exploit the timing: a server behaves correctly through review, then changes its behaviour or its descriptions once it is in use, and every agent configured to trust it inherits the change automatically. Approving a server once is not a security decision that holds.

Controls That Bound the Blast Radius

The useful mental model is what has become known as the lethal trifecta: sensitive data, untrusted content, and an outbound channel, all available to the same agent. Any two are survivable. All three together mean a successful injection can read secrets and send them somewhere. Most useful architectural work consists of making sure no single agent holds all three.

• Inventory and allowlist MCP servers: Maintain a register with owner, purpose and approved version. Pin by version or hash, and re-review on change — a rug pull is only possible where silent updates are.
• Scope credentials to the agent, not the developer: Issue dedicated identities with least privilege, short lifetimes, and no inherited human scopes. An agent that can read one mailbox should not hold a token that can read every mailbox in the tenant.
• Gate irreversible actions: Sending external email, moving money, deleting records, changing permissions and writing to production should require explicit human approval, with the action and its arguments shown. Approval prompts that display only a summary are decorative.
• Constrain egress: Allowlist destinations for agent-initiated traffic. Exfiltration needs somewhere to go, and most agents have no business talking to an arbitrary host.
• Log every tool call with its arguments: The audit trail that matters is not the conversation transcript but the sequence of tool invocations, the credentials used, and the data touched. Without it, a delayed-execution attack is invisible after the fact.
• Treat retrieved content as hostile input: Documents, web pages, emails and tool output are user input. Delimit them, label their provenance, and never let instructions found inside them override the system's own policy.
• Keep a revocation path: One switch per agent, per credential, and per server. The response to a suspected compromise is to cut the agent off, not to negotiate with it.

What to Ask Before You Ship

Procurement questions do more work here than most controls documentation. Which systems can this agent write to, and who approved each one? What credentials does it hold, and whose are they? Can it reach the public internet, and to which destinations? Where does its memory live, who can write to it, and how is it cleared? What happens to a tool description after approval? If the answer to any of these is nobody knows, the agent is not ready for production — it is ready for a sandbox with synthetic data.

The uncomfortable conclusion of 2026 is that agent security is not a model problem and will not be solved by a better model. It is the oldest problem in the book: a privileged process consuming untrusted input, holding credentials it did not need, with no audit trail and no kill switch. We have made that mistake before, at scale, and we know how it ends. The agents are new. The discipline is not.