LLM security starts with trust boundaries

Large language models do not have a reliable notion of “instructions vs data.” Anything that lands in the context window can influence behavior — including content from users, tools, documents, and the open web.

A useful mental model

Think of the model as an untrusted interpreter sitting between your application and the outside world. Your job is not to “make the model obey.” Your job is to design trust boundaries so that even when the model is steered, damage is limited.

Practical starting points:

1. Separate privileges — tools and data access should be scoped per task, not granted as a blanket agent identity.
2. Prefer retrieval to authority — retrieved documents inform; they should not become system policy.
3. Validate outputs before side effects — never let free-form model text become SQL, shell, or privileged API calls without checks.
4. Log the full chain — prompts, tool calls, and downstream actions need auditability when something goes wrong.

What “secure enough” looks like

There is no single filter that defeats prompt injection. Defense is layered: least privilege, output validation, human approval for high-impact actions, and continuous red-teaming of your own product flows.

flowchart LR
  User[User / untrusted input] --> App[Application layer]
  App --> Model[LLM interpreter]
  Model --> Tools[Scoped tools]
  Tools --> Gate{High impact?}
  Gate -->|yes| Human[Human approval]
  Gate -->|no| Action[Validated action]
  Human --> Action

If you are shipping an AI feature into production, assume adversarial input from day one — not after the first incident.