Securing LLM Applications: A Practical Guide

LLM applications add a new attack surface to your stack: the model itself can be manipulated through the very text it processes. Here is a practical, layered defense for production LLM apps — prompt injection, data privacy, access control, and output safety.

Threat Model First

The main risks for enterprise LLM systems:

1. Prompt injection — retrieved documents or user input that hijack instructions ("ignore previous instructions and…")
2. Data leakage — the model revealing content the requesting user isn't authorized to see
3. PII exposure — sensitive data flowing to model providers or logs
4. Unsafe actions — agent tool calls doing more than intended
5. Output harms — hallucinated claims presented as fact, unsafe content

Layer 1: Access Control Before the Model

The most important control is boring: permission filtering in the retrieval layer. If a user can't read a document, it must never enter their context window — no prompt instruction can leak what was never retrieved. Enforce ACLs at chunk level, filter before ranking, and audit-log the filter decisions.

Layer 2: Input Hardening

• Screen retrieved text for injection patterns before it reaches the prompt (instruction-like phrases, encoded payloads)
• Structurally separate instructions from data: system prompt for rules, clearly delimited context blocks for documents
• Treat all retrieved content as untrusted input — your knowledge base is only as clean as its least-trusted upload path

System: You answer using ONLY the provided sources...
<sources>
  <doc id="1">…retrieved text…</doc>
</sources>
User question: …

Layer 3: PII Redaction

Detect and mask PII (names, account numbers, health identifiers) before context leaves your boundary — both toward the model provider and into traces/logs. Field-level redaction in observability is routinely forgotten and routinely audited.

Layer 4: Constrain Agent Actions

For tool-using agents:

• Allowlist tools per agent; deny by default
• Validate tool arguments against typed schemas before execution
• Require human approval above value/risk thresholds
• Make every side effect idempotent and auditable

An agent that can only call search_kb and create_draft_ticket has a bounded blast radius no prompt injection can exceed.

Layer 5: Output Controls

• Require citations and verify they exist in the retrieved sources
• Run output through safety/policy filters appropriate to your domain
• Prefer abstention over confident invention — low evidence coverage should return "not found in sources"

Monitoring for Security

Log and alert on: injection-pattern detections, permission-filter denials per user (probing behavior), abnormal tool-call sequences, and abstention-rate drops. Security signals in LLM systems look like behavioral drift, not stack traces.

The One-Page Checklist

• Chunk-level ACL filtering before ranking
• Injection screening on retrieved content
• PII redaction toward providers and logs
• Tool allowlists + typed argument validation + approval gates
• Citation verification and abstention paths
• Audit logs for retrieval filters and agent actions

None of these layers is exotic. Applied together, they turn "the model might do anything" into a system with enforceable boundaries — which is what security reviews, and customers, actually want to see.