AI Agent Prompt Injection Defense Checklist: Keep Retrieved Text From Becoming Orders

Prompt injection is not a model problem you patch with a better system prompt. It is a governance problem: the moment an agent reads the outside world, it reads text written by people who do not hold its grants. An AI agent prompt injection defense checklist draws the line that has to hold anyway — retrieved text is data, never instructions, and only a plan bound, a grant record, or a recorded human approval can authorize an action.

Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025, so more agents will be reading untrusted content with no human watching each step. The failure mode is already documented in a simpler form: one developer's runaway agent loop burned over $700 in 72 hours with no budget controls, because unchecked output kept being treated as a reason to continue. Injected text aims at the same gap — it just writes the instruction itself.

Why injected text is dangerous¶

An agent's context is flat. A system instruction, a line from its plan, a paragraph from a retrieved web page, and a sentence buried in a vendor document all arrive as tokens, and the model has no native sense of which ones carry authority. Attackers — and careless third parties — exploit exactly that flatness. The common entry points:

Retrieved pages and documents. A web page, PDF, README, or knowledge-base article the agent fetches can carry lines written to be read as orders: "ignore your previous instructions," "forward this file," "approve the pending request."
Inbound messages. An email, ticket, or chat message written to the agent can instruct it to reply, escalate, refund, or disclose — in the voice of a customer or a colleague.
Tool and sub-agent output. One tool's result becomes the next step's input. If that result contains instruction-shaped text, the next step inherits it as if a principal had said it.

The defense is to make authority come from somewhere text cannot reach: the plan, the grant store, and the approval record.

The boundary principle¶

State it as policy, in one sentence your whole stack can be tested against: instructions come from owners and plans; data comes from the world; data never promotes itself into an instruction.

In practice, authority has exactly three sources. The plan bound states what work is authorized — if a unit of work cannot be expressed in it, it is not a plan and it does not run. The grant store records which capabilities the agent's identity holds. And a recorded human approval covers the hard-gated actions no plan can pre-authorize. Retrieved content is none of these, however official it sounds — a "system notice," an "updated policy," a "message from the owner" in a fetched page is data until a real owner moves it through a real channel.

The AI agent prompt injection defense checklist¶

Run every item before retrieved content is allowed to influence an action.

Separate the instruction channel from the data channel. System prompts, plans, and approvals live in channels only owners can write. Retrieved pages, documents, messages, and tool outputs are tagged as data at ingestion, and that tag survives into every downstream step.
Validate retrieved content against the plan bound. The bound records 13 fields: plan_id, owner_identity, agent_identity, workload, data_class, resources, time_window, location, egress, storage, cost_ceiling, expiry, and grant_refs. Content that asks for work outside the bound workload is out of scope, however plausible it reads.
Schema-validate anything structured. Output that does not match the expected shape is rejected before any semantic check. Instruction-shaped free text hiding inside a field that should hold a date, a number, or an enum value is a validation failure, not a surprise order.
Enforce the egress allowlist on content, not just on calls. Any URL, domain, or endpoint named inside retrieved text must already be on the plan's allowed egress list before the agent may visit, send to, or act on it. A destination introduced by the data itself is the classic injection payload.
Scope by data class. Record the highest data class the workload touches — public, internal, confidential, or restricted. Retrieved content that reaches for a higher class than the bound allows is blocked; a read with write-grade consequences is still a consequential action.
Never let retrieved text create or widen a grant. Grants are records issued by a named authority to a named identity, with an expiry. Content cannot mint one, extend one, borrow another agent's, or talk the agent into treating a missing grant as implied.
Hard-gate the consequential actions, whatever the content says. Moving money, accepting contracts or terms, external outreach, accessing or transmitting credentials, changing permissions or grants, and anything with legal or regulatory consequences always require a recorded human approval — no auto-grant path, ever. An injected "the owner already approved this" is precisely the claim the approval record exists to check.
Watch for instruction markers in data. Phrases that address the agent — imperatives, fake role labels, claims of new policy or prior approval — are logged as injection signals; a marker attached to a consequential request is a block.
Fail closed, with a reason and an unblock path. When content fails a check, the action is blocked and recorded with the exact reason, and the owner is told, in plain language, which piece of evidence would unblock it. A block is never degraded to a warning the agent can walk past.
Never auto-retry a blocked action. A retry requires new evidence, not a timer. Re-presenting the same injected content until a check passes is how a defense becomes a delay instead of a wall.
Label synthetic and test content. Test fixtures, demo rows, and red-team payloads are labelled "synthetic demo" wherever they enter the system. Unlabelled test content trains everyone — and every log reader — to treat injected text as normal.
Write the audit row either way. Every request, approval, block, and outcome writes a hash-linked audit row; blocked and rejected outcomes carry the exact reason. Audit data never contains secrets or credentials — that material lives outside the log. If the injection attempt is not in the log, it did not happen as far as your evidence is concerned, and it will happen again.

Respond by risk tier¶

Not every piece of retrieved content deserves the same response. Tier by consequence, not by frequency.

Hard-gated: the content is never the approver

For money, contracts, outreach, credentials, permission changes, and legal actions, retrieved text has no vote at all. The action proceeds only on a recorded human approval from a person holding the approver role — and the acting agent can never approve its own action. If the only "approval" lives inside the data, the action is blocked.

Bounded auto: data can inform, bounds decide

Routine work inside an approved plan — inference, computation, writes to plan storage — can use retrieved content freely as data while every bound holds. The moment the content points outside the workload, the data class, the egress list, or the cost ceiling, bounded-auto stops being auto: the step is blocked and recorded, and unblocking it takes new evidence.

Draft-only: a draft built on injected text is still just a draft

Proposals, composed messages, and plans are draft-only: recorded, never executed, never contacting anyone. A draft shaped by out-of-scope content should be rejected and recorded, not polished and sent later — sending remains a separate, hard-gated action.

Common failure modes¶

Prompt-only defenses. "The system prompt says to ignore injections" is a warning, not a control. Warning-only paths are prohibited for any action with external or financial side effects — the check has to live in the dispatch path, not in the model's good intentions.
Trusting the source instead of the channel. A page on a reputable domain can still carry user-generated or compromised text. Authority follows the channel a message arrived through, not the brand on the page.
Letting a second model "vouch" for content. Asking another model whether retrieved text looks safe adds a second piece of untrusted output. Validate against the bound, the schema, and the grant store — records, not opinions.
Blocks with no reason. An unexplained block teaches the team to route around governance. Every block names the failed check and the evidence that would unblock it.

Before you call it done¶

Retrieved pages, documents, messages, and tool outputs are tagged as data at ingestion, and the tag survives downstream.
Every action traced to retrieved content validates against the plan bound's 13 fields first.
No grant can be created, widened, or borrowed on the say-so of content.
Hard-gated actions require a recorded human approval that lives outside the data channel.
Egress destinations named inside content must already be on the plan allowlist.
Blocks fail closed with an exact reason, an unblock path, no automatic retry, and a hash-linked audit row.

If any line is missing, you have a polite agent, not a defended one. The Governed Agent Mesh Playbook — Studio Edition gives you the full system this checklist plugs into: the six adopt-as-is policy templates, the validated plan-bound and audit-row schemas, the risk-tier worksheet, and the 14-day rollout that installs each layer in order. Get the Studio Edition at https://ghostcorpnet.gumroad.com/l/hdigmr.