AI Agent Prompt Injection: Customer Messages Are Not Instructions
Start with the short answer ↓
An AI agent may read a customer's message without accepting it as authority. Separate incoming content from operating instructions, enforce permissions outside the model and test the boundary before connecting business actions.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
A request is useful information, not operating authority
A customer writes to change an appointment. The attachment also tells the assistant to skip review and send the full customer list elsewhere. The appointment request may be legitimate; the additional instruction must not acquire authority just because the agent can read it. This is an illustrative design exercise, not a claim about an incident or a delivered AgenticShip system.
OWASP describes indirect prompt injection as instructions arriving through external material such as files or websites. For a business owner, the practical question is which decisions an incoming message is allowed to influence. A request can supply a proposed date. It cannot grant itself permission to read another customer's records.
Keep the source and the permission separate
Use a small source record for each item: where it came from, the case it belongs to, when it arrived and whether it is customer-provided or approved business policy. Keep quoted email history and extracted attachment text in that incoming-content boundary. A familiar sender or a document found through search does not automatically make every sentence an approved instruction.
Anthropic's documentation recommends distinguishing third-party content from application instructions and identifying its provenance. The exact message format depends on the provider and implementation. Clear labels help, but they are not a substitute for access controls. Agree how the application represents trusted instructions and untrusted material before choosing prompt wording.
Write the action boundary before connecting tools
For a first appointment-intake workflow, our proposed boundary is deliberately narrow. The agent may prepare a summary and a suggested next step. The operational system decides which records the current case can access, and a person authorizes any booking change. The table is a scoping worksheet, not a universal security standard.
| Incoming content | Permitted preparation | Independent control |
|---|---|---|
| A requested appointment date | Extract the proposed date and flag missing details. | Check the case, customer identity and availability in the authorized system. |
| A claim that the manager approved a change | Show the claim with its source; do not mark it approved. | Verify a separate approval from the responsible person. |
| An instruction to send records to a new destination | Do not turn the destination into an authorized recipient. | Restrict recipients and exports in application code. |
| A request to ignore the usual process | Preserve the legitimate request and flag the conflicting instruction. | Keep the existing permissions and route the exception to its owner. |
Review a concrete action, not a reassuring summary
A reviewer should see the original request reference, the proposed action, the exact affected record and any conflicting instruction. An approval screen that displays only the agent's summary can hide the very change that needs review. A booking approval must not silently become approval to export records or contact a different recipient.
Keep authorization checks outside the model. Where the approved plan requires a reviewer, the execution path should verify that approval for the same case and action. Changing the record or destination should trigger another decision. A model's statement that permission exists is not the permission itself.
Test both refusal and useful work
Prepare a redacted test pack in an isolated environment with real sending and irreversible writes disabled. Pair each ordinary request with a version containing an unrelated instruction in the message, quoted history or attachment. Include the languages actually used by your customers. The expected result should name the legitimate information retained and the forbidden action that must not occur.
Do not count only how often the agent says no. Check that ordinary requests still reach an owner, that conflicting instructions do not become permissions and that unrelated records remain inaccessible at the system boundary. An all-refusal assistant can avoid useful work without establishing that the workflow is safe. Keep failed examples for the next release test.
Have an owner and a manual fallback
Decide who reviews suspected instruction conflicts, who can pause the integration and how staff continue handling the original requests. Keep only the evidence needed to investigate: case reference, workflow version, proposed action, blocked attempt and the responsible reviewer. Avoid copying entire private messages into unrestricted logs.
No prompt wording or filter guarantees protection against every injection. Treat this worksheet as one part of a reviewed implementation, with access restrictions, testing and an operating owner. Expand beyond preparation only after the actual workflow passes its agreed checks. Reassess the boundary when adding a tool, a new source of documents or a new type of outbound action.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.