Prompt Injection Is a Containment Problem, Not a Prompting Problem

Prompt injection cannot be prompted away. The defence and the attack share a channel, so every mitigation written in the prompt is one the attacker can also address.

In a chatbot this is a content problem: the worst case is text you did not want. In an agentic system the model holds tools, so the same attack redirects actions — and the blast radius is whatever that agent was authorised to do.

From the standard

“Manipulating LLMs via crafted inputs can lead to unauthorized access, data breaches, and compromised decision-making.”

The channels people forget

Teams defend the obvious surface — the user's typed message — and leave three others open. Every one of them is content the agent processes, and content is where instructions hide.

Retrieved documents. A specification, a support ticket, or a supplier PDF ingested into a knowledge base carries whatever its author wrote. In a system where anyone can upload, that author is not necessarily an employee.

Data returned by a tool. A free-text field in a record — a customer note, a description column — reaches the model as content. Whoever can write that field can attempt an injection, and in a customer-facing system that includes people outside the organization.

Tool descriptions themselves. The most underestimated channel. Connectors advertise their tools with a name and a natural-language description, and that description goes into the model's context as authoritative guidance. A malicious or compromised connector can put instructions there.

Four attacks worth naming

Tool shadowing

A connected server registers a tool whose name or description impersonates a trusted one, so the agent selects it believing it is the legitimate tool. The mitigation is fail-closed name resolution: a collision denies the call rather than resolving it by registration order or preference. Failing closed is inconvenient and correct — the alternative is a silent substitution nobody observes.

Description injection

Instructions embedded in a tool's own description text, exploiting the fact that descriptions are usually treated as trusted configuration rather than as third-party input. Treat them as untrusted, the same as any retrieved content.

Structural query evasion

A restricted operation nested inside a subquery, defeating a validator that inspects generated queries as strings. String matching loses to nesting every time. Parse the query into a syntax tree and validate structurally, so a restricted operation is caught wherever it appears in the tree rather than only at the top level.

Egress through rendered output

The subtlest of the four. If the interface renders a link or loads an image from a URL the model produced, an attacker who controls that URL has an exfiltration channel — data leaves encoded in the request itself, with no tool call to audit. Validate every destination against an allowlist before rendering.

Containment, not prevention

Detection at ingress is worth having and is not sufficient. Scanning content for injection patterns raises the cost of an attack; it does not close the class, and treating it as the control is how organizations end up with a single point of failure they believe is a defence.

The layers that actually contain it are structural. Validate every proposed tool call before dispatch, against a policy the model cannot see or influence. Constrain the tool roster to the intersection of platform capability, tenant entitlement, and the acting user's role, so an injected instruction cannot reach for something outside that user's authority. Stop every write at a human gate. Deny egress by default from the execution sandbox.

With those in place, a successful injection produces an unauthorised read within the permissions that user already had, and an audit trace showing exactly what was attempted. That is a manageable incident rather than a breach.

Test it before an attacker does

Injection resistance is testable. Seed a document with instructions and confirm the agent does not follow them. Register a shadowing tool and confirm the call is denied rather than resolved. Nest a restricted operation in a subquery and confirm the validator catches it. Produce a URL pointing outside the allowlist and confirm it does not render.

Those belong in the automated suite, not in an annual assessment. Injection resistance is a property that regresses quietly whenever a connector is added or a prompt is edited, and a test that runs on every commit is the only thing that notices.