LLM prompt injection defense: protect the action boundary

Map untrusted content to available authority

List user messages, retrieved documents, web content, emails, and tool responses that can influence the model. Then list the data and operations the application can access. The important security question is whether content from one trust level can cause access or actions at another.

OWASP’s prompt-injection guidance describes how both direct and indirect inputs can influence model behavior. For a product review, connect that concept to a concrete workflow: a support assistant reading customer documents should not gain authority to expose another account’s data or perform unrelated administrative changes.

References: [1] OWASP, [2] OWASP

Enforce tools and permissions outside the model

Give an agent only the functions and downstream permissions needed for its task. Prefer narrow operations over general-purpose administrative interfaces. The server handling a tool call should verify the caller, resource, and action using trusted context, even when the model has produced plausible arguments.

OWASP’s excessive-agency category distinguishes unnecessary functionality, permissions, and autonomy. Those are useful review dimensions: remove tools the feature no longer uses, narrow the credentials of retained tools, and define when a proposed action needs a human decision.

References: [3] OWASP, [4] OWASP

Review retrieval and output boundaries

Apply access controls before sensitive retrieved content enters the model context. A prompt that asks the model not to reveal a forbidden document is weaker than preventing the application from retrieving that document for the current user. Include tenant boundaries and connected knowledge sources.

Treat model output according to its destination. Text rendered in a browser, a database operation, and a tool argument need the appropriate validation or safe handling at that boundary. Do not grant output authority simply because it was generated by your own application’s model provider.

References: [5] OWASP, [6] OWASP, [4] OWASP

Verify the workflow with controlled adversarial content

Use synthetic documents and authorized test accounts to assess whether untrusted instructions can alter data access or trigger out-of-scope actions. Record the model configuration, tools, permissions, expected policy, and observed outcome. Avoid equating one successful refusal with comprehensive resistance.

Repeat relevant tests after changing tools, retrieval sources, permissions, or model configuration. Preserve evidence about proposed and executed actions without logging unnecessary sensitive context. The goal is a product that limits consequences through enforceable boundaries even when content or model behavior is unexpected.

References: [1] OWASP, [7] OWASP, [8] NIST

Your next steps

1. Map content sources to the tools and data available in each AI workflow.
2. Remove unnecessary functions and narrow downstream identities.
3. Define approvals and enforce data access before retrieval.
4. Book a scoped review using synthetic content and controlled accounts.