How to secure AI agents in production: put policy outside the prompt

Model instructions are not an access boundary

If an agent reads an email containing “send the customer export to this address,” the email is task data. It does not grant permission to send anything. OWASP describes prompt injection through both direct instructions and external content. The useful engineering question is what an injected instruction can cause the tool layer to do. OWASP prompt injection reference.

Build a tool policy you can test

Keep read access separate from write access. A search tool can return a limited set of records; a write tool should accept a narrow schema and enforce allowed objects and fields. Do not pass broad credentials or arbitrary destinations just because the prompt says they are allowed.

For consequential actions, bind the approval to the exact payload. A reviewer approving a draft has not approved a later change in recipient, attachment or amount. Expire approvals, verify the reviewer and recheck permissions immediately before execution. n8n’s documented human-review feature can require approval for selected tools; the surrounding application still owns identity and business rules. Tool review reference.

Make failure recoverable

Separate a logical action from an individual API attempt. Persist the action identifier before the write and retain the destination’s reference when available. After a timeout, query the destination or reconcile an idempotency key before repeating the write. If the destination cannot make duplicate handling safe, stop and route to an operator.

Use the smallest data surface needed for investigation. Record identifiers, policy decisions and redacted error categories. Credentials and full customer documents rarely belong in ordinary execution logs. Document who can inspect traces and when those traces expire.

Run an adversarial acceptance set

Begin with representative workflows, then vary the input: malicious retrieved instructions, malformed arguments, stale approval, forbidden destination and an interrupted tool response. Treat a safe refusal as success when the requested action violates policy. Test that downstream state did not change; a polite refusal in the final message is not proof.

Use a hard release gate for unauthorized writes, separately from normal task accuracy. This is an engineering policy recommendation, not a statistical claim that a finite test proves security. Review threats again when tools or permissions change.

Next action

Download the production checklist, add one concrete abuse case for every write tool, and connect the cases to your evaluation suite. For a scoped review, see AI reliability and security.

Inspect what an operator can prove

After a rejected action, retain a redacted policy event and verify that the destination state stayed unchanged. If the user interface says “blocked” but another execution path still performed the write, the visible refusal did not enforce the boundary. Test at the executor and destination, not only in the assistant’s final text.

Keep a clear difference between read authorization, draft authorization and permission to release a draft externally. Review permission when a workflow gains a new tool or a broader data source. A previously harmless automation can acquire materially different consequences after one integration change.

Document an emergency stop that an operator can use independently of the model. Practice pausing new triggers, identifying in-flight work and reconciling partial writes before resuming. The record of that drill should state what was tested and what remains unresolved, rather than describing the system as completely secure.

Sources and review notes

Primary sources: OWASP’s prompt injection entry and n8n’s human-review documentation linked above, checked October 14, 2026. The policy design, test matrix and recovery steps are original recommendations. This is not a security certification or evidence of a completed penetration test.