Prompt Injection Defense Checklist

Prompt injection is the defining security problem of LLM applications: anything the model reads can try to become an instruction. It cannot be fully solved at the model layer, so defense is layered, and the layers that matter most are the ones that hold when the model has already been manipulated. This checklist covers them. It is the operational form of the injection sections of the AI agent security architecture whitepaper and complements what is prompt injection and the LLM security checklist.

Who should use this checklist?

Security reviewers and engineering owners of any LLM application or agent that reads content from users, documents, emails, web pages, tools, or other agents.

Have you mapped every content channel?

1. Every source of text the model reads is inventoried: user input, retrieved documents, emails, chat history, web content, tool results, memory, other agents' outputs.
2. Each channel is classified as trusted (system configuration) or untrusted (everything else).
3. The inventory is maintained as channels are added.

Is structural separation in place?

1. System instructions are delivered through the mechanism the model treats as privileged, not concatenated with data.
2. Untrusted content is delimited and labeled as data in the prompt.
3. Instruction-like patterns in retrieved content are neutralized or flagged where feasible.
4. The model is instructed to treat content as data, understood as a weak layer, not a control.

Reference: context engineering explained.

Is detection in place?

1. Input screening for known injection patterns runs on user input where feasible.
2. Retrieved and tool-returned content is screened before it enters context.
3. Classifier or heuristic detection is tuned on your own adversarial suite.
4. Detections are logged and alerted, not silently dropped.

Is capability bounded? (Most important)

Check	Evidence
Tools are least privilege with read and write separated	Tool registry and scopes
No tool can send data to arbitrary destinations; egress is allowlisted	Network and tool policy
User-facing actions use delegated, user-scoped authorization	Access design
Code, file, and network execution is sandboxed	Sandbox configuration
Agents hold no credentials beyond their specification	Permission audit
Memory writes are policy-controlled and not triggered by arbitrary content	Memory design

Reference: how to build tool use for llm agents and ai access control.

Are outputs and actions validated outside the model?

1. Tool arguments are validated against schemas and policy (targets, values, rates).
2. Outputs are checked for sensitive data and prohibited content before leaving the system.
3. Consequence classification routes irreversible, costly, external, or regulated actions to approval.
4. Validation failures have deterministic behavior: block, escalate, degrade.
5. Content rendered downstream is encoded to prevent injection into browsers or systems.

Reference: llm output validation and ai agent guardrails.

Are gates real?

1. Approval gates on consequential actions are enforced in code.
2. Approvers see the proposed action, evidence, and trajectory, including retrieved content.
3. Queues are staffed, and gate metrics detect ceremonial review.

Reference: how to build a human review queue.

Is anomalous behavior detected?

1. Trajectory logging captures retrieved content, tool calls, and decisions.
2. Baselines for normal tool sequences, data volumes, and destinations exist.
3. Alerts fire on unusual tool chains, first-seen destinations, data spikes, and repeated validation failures.
4. Security telemetry flows to the security operations center.

Reference: the AI observability whitepaper.

Are multi-agent and memory surfaces protected?

1. Handoffs between agents are validated against schemas and policy, so manipulated output cannot steer downstream agents.
2. Memory writes are validated, restricted by source, and monitored.
3. Sub-agents reading untrusted content do not hold consequential tools.

Reference: how to build a multi-agent system and how to build long-term memory for ai agents.

Is the adversarial suite comprehensive and continuous?

1. Payloads cover direct injection in user input.
2. Payloads cover indirect injection through every retrieved and tool-returned channel.
3. Objectives tested: instruction override, data exfiltration, unauthorized actions, policy violations, memory poisoning.
4. Success rates are measured with thresholds; the suite runs in CI on every change.
5. Red-team findings are added to the suite.
6. Provider model updates trigger a full suite run.

Reference: ai red teaming guide and how to build an agent evaluation harness.

Is incident response ready for injection events?

1. Containment actions (autonomy drop, credential revocation, tool block) are pre-authorized.
2. The audit trail can reconstruct which content influenced which action.
3. Poisoned content can be identified and removed from indexes.

Reference: ai incident response checklist.

How should gaps be prioritized?

Capability bounding and validation first, because they hold under full manipulation. Then the adversarial suite in CI, because it tells you where you stand. Then separation, detection, gates, and monitoring. Treat any channel without adversarial coverage as untested.

How FISTA Solutions defends against injection

FISTA Solutions builds every LLM application and agent with layered injection defense as standard: channel inventory, structural separation, screening, least-privilege sandboxed tools, validation and consequence gates outside the model, trajectory monitoring, protected handoffs and memory, and an adversarial suite in CI. The AI enablement practice delivers the gateway, tool, and validation platform, AI agents are built on it, and forward deployed engineers work with your security team on testing. The record behind the approach is 150+ projects with 99.9% uptime.

To assess injection defenses on an existing system, message FISTA on WhatsApp, or read what is jailbreaking in ai for the related attack class.