Defence patterns.

Scope what the model can invoke to the task in front of it, not to the union of everything the product might ever need.

The default in most agent frameworks is one credential with broad scopes, because that is what makes the demo work. It also means a single successful injection inherits every permission you own. The fix is boring and effective: bind capability to the step.

• Per-task tokens. A run that summarises tickets gets read on tickets. Not write. Not on tickets belonging to other tenants.
• Per-step allow-lists. The tool set offered to the model changes as the plan progresses, rather than being constant for the session.
• No standing credentials in context. Keys live in the execution layer, never in a prompt, where they can be talked out.
• Separate read and write paths. The step that reads untrusted content should not be the step holding a write capability.

Whatever consumes the model's text — a browser, a shell, a SQL client, another agent — should handle it exactly as it would handle a string typed by a stranger.

This is the cheapest win in LLM security and the one most often skipped, because the output feels like it came from your own system. It did not. It came from a process that just read an attacker's document.

• Encode for the sink. HTML-escape before rendering, parameterise before querying, never interpolate into a shell.
• Constrain the render surface. If you render markdown, decide deliberately whether images, links and raw HTML are allowed. Each is an outbound channel.
• Allow-list, do not deny-list. Permitted tags and permitted link hosts, not a list of things you have thought to ban.
• Validate structure before use. Parse and schema-check any output you are about to act on, rather than trusting a shape it usually has.

Filter the index by the caller's identity before the search runs, and re-check ownership on what comes back. Never place in the context something the user is not allowed to read.

The common failure is an instruction like "only answer using documents belonging to this customer", written into the system prompt. That is a request, not a control. Vector search does not respect it, and the moment retrieval crosses a tenancy line the data is already in the context window where the model can be persuaded to repeat it.

• Pre-filter by identity at the store, using metadata the user cannot influence.
• Re-check after retrieval. Confirm every returned chunk belongs to the caller before assembly, so an indexing bug fails closed.
• Keep provenance on the chunk — source, owner, ingest date — so downstream layers can reason about trust.
• Separate stores for separate tenants where the data is sensitive enough that a filter bug is unacceptable.

An injection that cannot send anything out is a much smaller problem. Break the send leg and most data-theft chains stop being worth running.

Three ingredients turn an injection into an incident: the model can read something sensitive, it can be influenced by untrusted content, and it has a way to transmit. Simon Willison's name for that combination — the lethal trifecta — is the most useful triage question in the field, because you rarely need to remove all three.

• Allow-list outbound hosts for fetches, webhooks and any tool that takes a URL.
• Do not auto-load remote images from model output. A constructed image URL is a fully functional exfiltration channel that renders silently.
• Constrain link rendering to known hosts, and never let the model choose an arbitrary recipient for a message or a file.
• Watch the quiet channels — DNS lookups, analytics pings, error reporters, anything that takes a string and puts it on the wire.

Mark untrusted content so it is visibly distinct from your instructions, and tell the model in advance that anything inside the marks is data to be examined, never orders to be followed.

Microsoft's spotlighting work groups the practical variants: delimiting with unforgeable boundaries, datamarking by interleaving a token through untrusted text, and encoding the untrusted span so instructions inside it do not read as fluent commands.

• Use a boundary the attacker cannot guess — a random nonce per request, not a fixed string like ###.
• Strip the boundary token from untrusted content before insertion, or the fence can be closed early.
• Tag every untrusted source, not just the obvious ones. Tool results and prior assistant turns count.

Build prompts through a typed interface that knows the provenance of every field, rather than by string concatenation scattered through the codebase.

Most injection surface is created accidentally, by a template that interpolates a variable nobody traced back to its source. A single assembly layer makes provenance a property of the code, and lets you answer "what untrusted text reached the model in this request" from a log rather than from memory.

• One assembler. Every prompt is built in one place, with fields declared trusted or untrusted at the call site.
• Untrusted fields are fenced automatically by DP-05, so nobody has to remember.
• Use the model's own role separation where the API offers it, and do not put untrusted text in a system role because it was convenient.
• Log the assembled prompt shape — sources and lengths, not necessarily contents — so incidents are reconstructable.

Put a person in front of anything that cannot be undone, and give them enough context to actually judge it.

The pattern fails in a specific, predictable way: confirm too much and people click through everything, at which point you have added friction and removed nothing. The discipline is in choosing a short list and showing real detail.

• Reserve it for the irreversible — sending, paying, deleting, publishing, granting access. Reads and drafts do not qualify.
• Show the effect, not the intent. "Email this text to this address", with both rendered, beats "run the email tool?".
• Say where the instruction came from. If the step was triggered by retrieved content rather than the user's own words, that is the single most useful thing on the screen.
• Make the safe option the default, and never pre-select confirm.

Give every request a hard ceiling in tokens, tool calls, wall-clock time and money, enforced by the runtime rather than requested in the prompt.

Agent loops fail open by default: a plan that is not going well produces more steps, not fewer. The same ceilings that contain a runaway loop also contain an attacker who successfully told your agent to keep going.

• Step ceiling per run, with the run terminated rather than the model asked to stop.
• Token and cost budget per request, tracked across the whole loop including retries and sub-agents.
• Fan-out limit on delegation, so a sub-agent cannot spawn its own sub-agents indefinitely.
• Rate limits keyed to identity, not to IP, for anything authenticated.

Score incoming text — from users and from retrieval — for injection-shaped content, and route on the score rather than blocking on it.

Classifiers are genuinely useful and genuinely oversold. They catch the loud majority cheaply, which is worth real money at volume. They are also a fixed decision boundary that an attacker can probe indefinitely, and benchmark scores tend to fall under adaptive attack.

• Route, do not just block. High score to a review queue or a reduced-capability path; only the extreme tail gets a hard refusal.
• Normalise before scoring — strip invisible characters, decode obvious encodings, fold homoglyphs — or you are classifying a disguise.
• Score retrieved content too. Most teams only score the user's message, which is the half attackers stopped using.
• Log every decision, allows included. You cannot measure either of your two numbers from a log of blocks alone.
• Write a real refusal message with an appeal route. Your false positives are people.

Plant a unique marker string in the system prompt and alert whenever it appears in output. Scan responses for the other things that should never leave — keys, internal hostnames, other users' identifiers.

This does not prevent hidden context exposure (LLM08); it tells you it happened, which is the difference between finding out from your logs and finding out from a screenshot on social media.

• One canary per deployment, rotated, with an exact-match alert on egress.
• Scan for secret shapes — key prefixes, internal domains, ID formats — on the way out.
• Alert, do not silently drop. A canary firing is an incident signal, and suppressing the output loses it.
• Assume the prompt leaks anyway. A canary is instrumentation, never a reason to keep a secret in a prompt.

Split the work between two models. A privileged one plans and holds the tools but never sees untrusted content. A quarantined one reads the untrusted content but has no tools and cannot address the privileged model in natural language.

Untrusted text is processed only by the model that can do nothing, and the result crosses back as a constrained value — a classification, a number, a field in a schema — rather than as prose the privileged model will read as instructions.

Derive the plan from the trusted request only, express it as a program, and attach capabilities to every value so untrusted data can never change what executes — only what the values are.

This is the approach taken by CaMeL: extract control flow from the user's query, run it in an interpreter, and track provenance on data so a value that originated in untrusted content cannot reach a sink it lacks the capability for. It is the strongest published containment story, and the paper reports the honest capability cost alongside it.

• The plan comes from the trusted query. Retrieved content supplies values, never steps.
• Capabilities travel with data, so provenance survives transformation instead of being lost at the first summarisation.
• Sinks demand capabilities. Sending externally requires data cleared for that; nothing else reaches it.