How to Prevent Prompt Injection in AI Agents

An agent becomes vulnerable to prompt injection when text from a page, file, ticket, or tool response can change what the agent is allowed to do. This guide builds a control path for agents that can retrieve data and take real actions. The outcome is a release test that proves hostile content did not alter a protected target.

Start with the action inventory

List actions by consequence, not by tool name. Sending an email, exporting a record, changing access, and creating a purchase order need separate rows even when one API performs them. For every row, record the initiating identity, candidate recipients, allowed arguments, approval rule, and state change. A MCP protocol architecture becomes relevant when the same action is exposed through client-server tool discovery.

Use a harmless target for the first test: a sandbox mailbox, disposable record, or test tenant. The control is not proved when the model says it ignored an instruction. It is proved when the prohibited action cannot reach that target.

Keep external content out of the authority layer

Retrieved material should carry provenance and be supplied as data, never merged into policy text. A support ticket may tell the agent what happened to a customer; it must not be able to grant itself a new recipient, tool, or privilege. Keep system policy, user authorization, and tool schemas in separately owned fields.

Run a document containing a direct override such as an instruction to disclose a canary or call a blocked URL. The expected behavior is ordinary processing of the document's business content while the instruction has no effect on the action plan. If the test changes the selected tool or recipient, remove that source from the authority path before changing the wording of a prompt.

Put deterministic checks in front of side effects

Use the model to propose work, then evaluate the proposed action with rules that do not rely on the model's interpretation. Validate the caller, tenant, tool, destination, arguments, amount or record scope, and any approval token before execution. A model may summarize a request for an export; a policy component should decide whether this caller may export these records to that destination.

The agent credential leak controls guidance belongs here when the proposed action uses an OAuth token, service account, or connector secret. Test with a disposable identity. If a prompt trace contains the token, revoke it and repair the trace pipeline before reusing the test.

Test the result, not the refusal

Build a small corpus that changes the attack channel rather than repeating the same sentence: a direct request, a retrieved HTML page, a PDF-like text extract, a tool response, and a multi-turn follow-up. For each one, assert the selected tool, normalized arguments, policy result, and target state. Add an allowed baseline so a broad deny rule does not masquerade as security.

The critical failure is an apparently denied interaction that still queues a job, writes an audit record to the wrong tenant, or sends a downstream request. Treat any post-denial side effect as an execution-boundary defect. Restore the last approved tool policy, rerun the failed case, and only then reopen the action.

Keep one traceable release record

Retain the poisoned fixture, its provenance, the agent and policy revision, proposed tool arguments, final decision, and the sandbox target's final state. That compact record gives the next reviewer a way to reproduce an escape without storing production content. The OWASP Prompt Injection guidance and NIST AI 600-1 provide useful test and risk language; the deployment evidence must come from your own path.

When the release changes a skill, plugin, MCP server, or agent, attach a Deep Scan finding to that exact component and version. Use it to justify the admission decision or select a regression fixture, not as proof that recipients, records, and effects are authorized.

Record components outside that review scope as unassessed. AgentGuard documentation defines the component types to check; the normalized action and unchanged target remain the release evidence for the application path.