Securing LLM applications is now its own discipline

As AI features moved from demos to production, a specific class of security problem came with them. It is well enough understood now that there is an OWASP top ten for it, and treating it as an afterthought is how teams end up with an incident.

Prompt injection is the core problem

Any text the model reads can contain instructions, and the model cannot reliably tell your instructions from an attacker's. A malicious web page, a poisoned document in your knowledge base, a crafted support message: all of them can try to redirect the model. There is no prompt phrasing that fully solves this. It has to be handled at the system level.

The dangerous combination

Injection becomes serious when the model can also act: call tools, read private data, send messages. An attacker who can inject instructions and reach a tool that exfiltrates data has a real exploit. This is a confused-deputy problem, the model acts with its own privileges on behalf of an untrusted input.

Defences that actually help

• Least privilege for the model: it gets only the tools and data a given task needs, nothing more
• Human approval for irreversible or sensitive actions, always
• Treat model output as untrusted input to the next system, validate and sandbox it
• Input and output filtering for known attack patterns and for data that should never leave
• Separate trust levels for content, do not let retrieved documents carry the same authority as system instructions
• Log every tool call with the context that triggered it, so an incident is investigable

Where this sits in delivery

AI security is not a review at the end. The threat model belongs in the design phase, alongside the tool and permission decisions, and the guardrails belong in the evaluation suite so a regression shows up before it ships. It is the same shift-left approach that works for the rest of security, applied to a new surface.