Security for LLM applications — the OWASP Top 10 in practice
Building on an LLM introduces failure modes that do not exist elsewhere in your stack. The OWASP Top 10 for LLM applications is the useful reference; this is what matters most in practice when you are shipping something.
AI Tools Hub Editorial · published · updated
The risks that actually bite
Prompt injection
Any content the model reads can contain instructions. A support ticket, a web page, a document uploaded by a user — all of it is input. If your application takes action based on model output, assume an attacker can influence that output through content you did not write.
Controls: never let model output trigger a privileged action without a deterministic check; treat retrieved content as untrusted; keep system instructions and user content structurally separate; constrain output to a schema you validate.
Excessive agency
Giving a model tools it does not need. If it can read a database, it will eventually read the wrong row; if it can send an email, it will eventually send the wrong one. Scope tool access to the minimum and put a confirmation step in front of anything irreversible.
Sensitive information disclosure
Two directions: data leaving in prompts, and data leaking in responses. Redact before the API call rather than hoping the vendor does not retain it, and check what your retrieval layer is able to surface to a given user.
Insecure output handling
Model output rendered as HTML, executed as code or passed to a shell is the same class of problem as any other untrusted input. Escape, validate and sandbox exactly as you would with user input, because that is what it is.
The controls worth implementing first
- Output schema validation on every call that drives an action
- A deterministic permission check between model output and any privileged operation
- Input redaction for personal and confidential data before the API call
- Rate limiting per user, because generation is expensive and abuse is cheap
- Logging of prompts and responses, with retention that matches your privacy policy
- An evaluation suite that includes adversarial inputs, run on every model change
Model changes are a security event
Your prompts are calibrated against a specific model. When the vendor updates it, behaviour shifts, and controls tuned to the old behaviour may no longer hold. Pin versions where you can, and re-run the evaluation suite before adopting a new one.
Can prompt injection be solved?
Not completely with current architectures. It is mitigated by never trusting output for privileged actions, which is an architectural decision rather than a filter you can add later.
Do we need a separate LLM security review?
Not separate, but your existing review needs these categories added. The threat model is different enough that a standard application review misses most of it.
Related
More articles
Opinion
Why AI rollouts fail in Japanese companies — four structural reasons
For business
Enterprise AI rollout checklist — SOC 2, ISO 27001, DPAs and personal data
For business
Japanese-developed LLMs for business — ELYZA, Sakana AI, NTT tsuzumi and PLaMo
Comparison
AI coding tools compared — Cursor, Copilot, Claude Code, Windsurf and Codeium