Building Secure LLM Applications: Trust Boundaries in Practice

A secure LLM application needs more than a sentence telling the model to behave. The model receives text that may contain instructions, quotations, retrieved documents, and malicious input. The application must decide which sources carry authority and which are only information. That decision cannot safely depend on the model always interpreting the difference correctly.

Draw the trust boundary

Imagine an assistant that searches project documents. A retrieved page contains a paragraph requesting that the assistant reveal other documents. That paragraph is part of the material being examined, not a new instruction from the user. OWASP describes this class of indirect prompt injection and notes that retrieval does not eliminate the risk.

Separate trusted instructions from external content, but treat that separation as one mitigation rather than a complete defence. The more important architectural question is what the assistant could access or change if the model made a mistake. Restricting capabilities reduces the consequences of that mistake.

Enforce permission outside the prompt

A document search tool should apply the authenticated user's access rules before returning material. It should not retrieve everything and ask the model to conceal the restricted passages. The model never needs to see information that the user is not authorised to access.

Likewise, a tool that updates a record should validate the target and proposed operation in ordinary application code. Use narrowly scoped credentials, explicit schemas, and approval for consequential changes. A generated explanation of why an action is safe is not equivalent to an authorisation check.

Treat output as untrusted input

If generated text becomes HTML, a database query, or a tool argument, it crosses into another interpreter. Apply the protections appropriate to that destination. Schema validation can check structure, but a structurally valid request can still name the wrong customer or request an unauthorised action.

For a reporting assistant, presenting a draft for review may be a better first release than automatically emailing the report. That choice creates a recoverable boundary while the team learns where the system is unreliable. It is a product decision as much as a technical control.

Test what the system refuses

Exercise malicious documents, misleading tool results, inaccessible records, and ambiguous instructions. Check the final state as well as the response text. A refusal message is not reassuring if a write happened before the refusal.

OWASP's Top 10 is a risk taxonomy, not a certificate of compliance obtained by adding a filter. This article concentrates on trust boundaries and prompt injection; a complete assessment must also examine the application's other risks, dependencies, data handling, and operational limits.

Further reading: OWASP: Prompt injection.