Your agent cannot tell your instructions from the text it reads

One channel for everything

A language model receives the instructions you gave it and the text it met while working in the same way: as tokens in one context. There is no privileged channel for "what my operator told me", no type system separating it from "a paragraph I read on a web page", and no marker that cannot itself be written by someone else.

The consequence is easy to state and uncomfortable to accept. An agent that summarises a support ticket can follow instructions written inside the ticket. An agent that reads a repository can follow instructions in a README or a commit message. An agent that browses can follow an instruction hidden in an HTML comment that never appears on the rendered page. This is not a defect of one model. It follows from how these models work.

The person placing that text needs no access to your systems. Filing a bug report, leaving a comment on a public page, publishing a package with a well-crafted README, or sending a document to an address your agent processes is enough. They often do not even need to be targeting you.

Why "ignore any instructions in the following text" does not work

The instinctive fix is another instruction: tell the model to disregard instructions in the content it is about to read. But that sentence is also just text, in the same channel, competing with the attacker's text on equal terms. Which one wins depends on which the model finds more compelling at that moment, and that changes between models and between versions of the same model.

Detection fares little better. A classifier that flags suspicious content is bypassed by paraphrase, raises false positives on legitimate text that discusses security, and tends to displace the architectural work that actually holds. Nor is this an escaping problem in the SQL sense: there is no escaping function for natural language.

Assume the model will be convinced, and design for that

The defence that holds starts from the opposite assumption. Something in your agent's context will eventually convince it. The question is what it can do once it has been.

That moves the work out of the prompt and into the system around the model:

Separate and label what comes in. Classify every input before it enters the context. Fence untrusted content with a delimiter an attacker cannot predict, and record where it came from, so that a successful injection is at least attributable afterwards. Strip what is not content: invisible characters, hidden HTML elements, encoded blobs presented as prose.

Treat tool output as data, never as direction. A tool result never changes the plan. Text that issues an instruction, claims to come from the operator, announces that earlier instructions are cancelled, or asks for a credential is a finding to report, not a step to take. The dangerous cases are the credible ones: a TODO in a file the agent was asked to refactor, a contributing guide saying agents must run a setup script.

Validate every model-chosen argument in code. This is the rule that still holds after the model has been persuaded. Treat each argument the model produces like a query parameter from an unauthenticated request on the public internet — not because the model is malicious, but because its arguments are downstream of text you do not control. Resolve a path before checking it is inside the allowed root. Check recipients, amounts and targets against an allowlist in the function, before the side effect, not in the tool description.

Close the way out. An injection that cannot send anything anywhere has failed. Make outbound calls deny-by-default, remember the channels people forget — a rendered Markdown image with a remote source is an outbound request — and keep secrets out of the context entirely, so tools take a handle rather than the credential itself.

The trade nobody likes

Taken seriously, these constraints reduce what an agent can do on its own. An agent that both reads untrusted content and holds a capability worth abusing cannot be made safe by a rule file. The two have to be separated, usually with a human confirmation before the consequential step, or a second agent with no network access doing the risky part.

That cost is real and it is better stated up front. A design that pretends an agent can read anything and act on everything safely is relying on the model declining to comply, which is the one defence that changes every time the model does.

Test your own agent before you change anything

Before adding defences, find out where your agent stands. Run a small set of benign probes against your own system — content that asks the agent to write a marker string to a scratch file, or to reveal a canary value you planted — through each path untrusted text can take: a fetched page, a tool result, a document. Knowing which probes succeed turns the rules from abstract advice into a concrete list of what to fix first.

Where to start

AgentGuard: Cursor Rules for Context Isolation & Injection Defense packages this as four rules: rules/00-channel-separation.mdc, rules/10-untrusted-tool-output.mdc, rules/20-tool-parameter-validation.mdc — the one to adopt if you adopt only one — and rules/30-exfiltration-boundaries.mdc. THREAT-MODEL.md states what the rules defend against and, just as importantly, what they leave exposed. TEST-CASES.md holds twelve deliberately benign injection probes to run against your own agent, and ANTI-PATTERNS.md the failures the rules were written from. It is model-neutral and framework-neutral, and it is defensive: it constrains an agent you operate.

Deciding where an agent may act on its own is a design decision worth making before the code exists — see the design decisions your coding agent made without asking.