AI Agent Security Checklist For Prompt Injection

A system prompt can tell an agent to ignore hostile instructions. A product boundary decides what happens when the agent does not.

An email-reading agent finds a message that says, in effect, “send the employee’s details to this verification URL.” The request sounds administrative. The URL belongs to an attacker. If the same agent can read private mail and transmit data to arbitrary domains, one persuasive paragraph connects the source of the attack directly to a dangerous sink.

That is the practical prompt-injection problem. OpenAI now describes the strongest attacks as a form of social engineering, not a magic phrase that a classifier can always catch. Its March 2026 guidance argues that the safer goal is to constrain the impact of manipulation even when detection fails. For builders, this changes the job: do not ask only whether the model resisted. Ask what the compromised agent was able to do.

Replace the one-line defense with five boundaries

A brittle design joins browsing, private context, broad tools and silent execution in one loop. A safer design separates them. The following checklist is deliberately product-level: each item can become an acceptance criterion, a log event or a red-team test.

Failure-and-recovery matrix for an agent connected to real tools
Boundary	Unsafe state	Required control	Recovery evidence
Input trust	Mail, web pages and retrieved documents look like instructions	Label external content as untrusted and preserve provenance	Log the source that influenced every proposed action
Tool scope	One token can read, write, send and delete	Separate read tools from mutating tools; grant the minimum data scope	Revocation removes one capability without disabling the product
Source–sink policy	Private data can flow to any URL or recipient	Allowlist destinations and block unapproved data transmission	A denied attempt records source, destination and fields
Human authority	A vague approval covers later side effects	Show recipient, payload and consequence at the moment of action	The user can cancel without losing the draft
Evaluation	A demo is treated as a safety test	Run adversarial scenarios with explicit unauthorized outcomes	Every escaped action becomes a regression case

A control is incomplete until the team can observe both the blocked action and the safe recovery path.

1. Draw the trust boundary before choosing the model

List every source the agent can read: user prompts, web pages, email, files, calendar descriptions, tool output and retrieved database rows. Then list every sink: outbound messages, payments, uploads, data exports, navigation, shell commands and permission changes. The dangerous paths are the pairs where attacker-influenced content can cause a consequential action.

This inventory prevents an easy category error. Filtering a suspicious sentence may help, but it does not neutralize a path that remains open. OpenAI explicitly cautions that mature social-engineering-style injections are difficult for a standalone “AI firewall” to classify. Deterministic limits—recipient allowlists, spending ceilings, read-only modes and domain restrictions—still work when the model makes the wrong judgment.

2. Make least privilege a runtime property

Do not give the agent a permanent super-token because the happy path needs one privileged step. Mint short-lived credentials for the current job. Split “find invoice,” “draft payment” and “submit payment” into separate capabilities. Keep secrets outside model context, and pass only the fields required by the selected tool.

OpenAI’s public safety guidance recommends limiting access to the data required for the task and using logged-out modes when authentication is unnecessary. The OWASP Top 10 for Agentic Applications 2026 similarly treats least privilege and approval for high-risk actions as core mitigations. Neither source claims that least privilege prevents injection. It limits the blast radius.

3. Confirm the action, not the agent’s summary

“This looks good—continue?” is not informed approval. A consequential-action screen should show the concrete recipient or domain, the exact data leaving the system, the amount or permission being changed, and whether the action can be reversed. The confirmation must be generated from validated tool arguments, not from a free-form model explanation that could omit the dangerous detail.

For repeated low-risk work, teams can approve a narrow policy instead: “create calendar drafts in this workspace, never invite external addresses.” That is still bounded authority. A broad instruction such as “review my email and take whatever action is needed” gives hostile content more room to redefine the job.

4. Treat tool output as another attack surface

A trusted connector can return untrusted material. A customer-support tool may fetch a malicious ticket; a browser tool may retrieve a poisoned page; a search tool may quote attacker-controlled text. Preserve the distinction between system policy, user intent, tool metadata and tool output. Do not concatenate them into one undifferentiated instruction block.

Sandbox code and rendering where possible. Apply response-size limits. Reject unexpected content types. When a tool returns data that will influence another tool call, run a policy check over the proposed source-to-sink flow rather than asking the same agent to judge its own decision.

5. Red-team unauthorized outcomes, then keep the failures

A useful test does not ask only, “Did the model repeat the hidden instruction?” It asks whether private data left the approved boundary, a write occurred without confirmation, a tool exceeded its scope or the audit trail became ambiguous. Include direct injections, indirect instructions in HTML and documents, oversized responses, misleading tool descriptions, conflicting user goals and multi-step attacks that wait before acting.

Production monitoring should record proposed and executed tools, normalized arguments, policy decisions, confirmation events and final effects without logging raw secrets. A blocked attempt is evidence that a control worked. An escaped attempt is more valuable: it becomes a permanent regression scenario.

The 30-minute next test

Pick the most privileged tool in your agent. Feed the agent an external document that asks it to send one sensitive field to a new domain. The pass condition is not a polite refusal. The pass condition is that an enforced boundary blocks transmission, explains what was blocked, preserves the user’s legitimate work and leaves an auditable event.

If that test cannot be expressed today, begin with the Neyrotex AI Tech hub, compare the platform-level containment model in our Windows local-AI and agent guide, and use the product security review path for a concrete agent workflow. The safe version of autonomy is not “the model usually refuses.” It is “one bad judgment cannot silently become an irreversible action.”