8 Prompt Injection Defenses for Cloud LLM Applications
Prompt injection is a trust-boundary problem: an application can encounter instructions inside a document, email or tool result that should have been treated as data. Filtering those instructions is useful, but authorization must remain outside the model. The application’s permitted actions should be limited even when the model follows a hostile instruction.
This guide combines eight defensive layers with an original threat-model worksheet for a cloud document assistant. It is a design example, not a report that a particular deployment passed a penetration test.
Start with an asset and a permitted action
Imagine an assistant that reads invoice documents for one customer and drafts a summary. The user can approve sending that summary to an agreed destination. Reading invoices is different from granting the model authority to search every tenant, select an arbitrary recipient or send messages without approval.
| Boundary | Failure to consider | Control and evidence |
|---|---|---|
| User to retrieval service | A request selects another customer’s document | The server derives the tenant from the authenticated session and enforces access on each object |
| Document to model | Retrieved text pretends to be an administrator instruction | Label untrusted content and keep permissions independent of the generated answer |
| Model to tool | The model proposes an unauthorized recipient | The service validates recipient and operation against a server-side allowlist |
| Draft to external message | A mistaken draft is sent without review | Approval displays the exact recipient, contents and attachments before a separate commit action |
Write the allowed outcome first: “summarise documents that this user can read.” Add explicit exclusions: no cross-tenant access, no permission changes and no external send without approval. These are application invariants, not extra sentences the model is expected to remember.
Eight controls that work together
- Identify untrusted sources. Keep retrieved text and tool results distinguishable from developer instructions. The OWASP prompt-injection guidance explains direct and indirect injection and the need for layered mitigation.
- Authorize retrieval before generation. Resolve identity, tenant and document permissions in the retrieval service. Do not let a generated tenant identifier substitute for the authenticated one.
- Grant minimal tool permissions. A read-and-draft assistant does not need delete, bulk export or administrator credentials. Separate read, preparation and commit operations.
- Validate tool arguments on the server. Use schemas for shape, then check business rules and authorization. Valid JSON can still contain an unauthorized object or destination.
- Constrain outbound destinations. Keep network and storage access aligned with the task. A model-supplied URL should not automatically become an allowed destination.
- Treat output as untrusted. Validate it before rendering, running a query or feeding another system. Do not convert an answer into a shell command or executable instruction.
- Make approval specific. Bind approval to the exact proposed action. Changing a recipient, document or amount invalidates the earlier approval.
- Observe outcomes and rerun regression cases. Log permitted and denied operations with minimal data. Measure boundary violations and normal-task failures, not only whether a suspicious phrase was detected.
The OWASP prevention cheat sheet provides additional defensive patterns. Delimiters, screening and instructions are layers; they do not establish tenant authorization or prove that every injection will be blocked.
A safe regression worksheet
Use synthetic documents and an isolated environment. Include ordinary invoices, irrelevant text, a document that tries to change the task and a proposal to use a destination outside the allowed set. Record expected retrieval, expected tool calls and expected final action for each case.
| Case | Expected result | Evidence to retain |
|---|---|---|
| Allowed document, normal request | A useful draft from authorized data | Document IDs and review result |
| Document from another tenant | Denied before the model receives it | Authorization decision |
| Untrusted instruction in a document | No additional permission or unauthorized tool action | Tool decisions and final draft |
| Recipient changes after approval | Earlier approval is rejected | Action version and approval binding |
A model may still produce an incorrect draft. The containment objective is that this does not silently become a broader data read or an external send. Human review addresses the draft; deterministic controls enforce the permitted action.
What to document before release
Name the owner of retrieval authorization, tool validation, approval and log retention. Record residual risks and a rollback path. Do not store full invoices or secrets in a diagnostic log just to make testing easier.
Use this worksheet alongside our cloud-security baseline and shared-responsibility gap guide. A completed worksheet is a starting point for review, not a certificate that the application is secure.