LLM Security: Common Vulnerabilities and Best Practices

LLM applications fail in patterns. The model is new, but most of the failures are familiar security problems wearing a new interface. These are the ones that recur, and the practices that address them.

Insecure output handling

The completion is treated as trusted. It is rendered as HTML, interpolated into a query, passed to a shell or used to build a tool request. An attacker who can influence the output — through the prompt, retrieved content or a tool result — can inject into the downstream system.

Practice: treat model output exactly like user input. Encode for the target context, validate schemas, parameterize queries and never execute model text.

Excessive agency

The application gives the model tools with broad permissions and no checkpoints. The model can read any file, call any API, spend money or send email. A small prompt error becomes a large action.

Practice: least privilege per tool, narrow schemas, allowlisted destinations, per-session limits and human approval for destructive or financial actions.

Prompt injection and jailbreaks

Instructions hidden in data, or persuasion that removes the safety policy. Both are content-layer attacks that no single filter solves.

Practice: provenance labels, screening of user and retrieved content, constrained authority, output checks and evidence. Assume some payloads get through and make the consequence small.

Sensitive information disclosure

The model reveals system prompts, another tenant's data, credentials or internal identifiers. Causes include over-broad retrieval, secrets in prompts, verbose errors and memorized training data.

Practice: tenant-scoped retrieval, no secrets in prompts, output DLP, minimal error detail and redaction.

Retrieval and embedding weaknesses

Vector stores inherit whatever permissions the ingestion job had. If documents from multiple tenants share an index without filters, similarity search can return the wrong tenant's text. Embeddings can also leak information about their source.

Practice: partition by tenant, enforce permissions at query time, re-index on permission changes and keep sensitive documents out of shared indexes.

Supply chain and model integrity

Adapters, model files, inference containers, SDKs and plugins can be swapped or compromised. A model update can change behaviour without changing your code.

Practice: pin versions and hashes, verify provenance, scan artefacts, review model changes like code and keep a rollback path.

Unbounded consumption

Long prompts, recursive agents and abusive clients consume tokens and money. The application has no per-session ceiling.

Practice: input limits, token and cost budgets per session, loop detection, rate limits and alerts. Treat spend as a security control, not only a billing concern.

Overreliance and unsafe defaults

Users and downstream systems trust the output because it sounds confident. The model is used for decisions it should not make alone, without verification.

Practice: label generated content, require confirmation for consequential actions, keep a human in the loop and design for the model being wrong.

Weak observability

There is no record of what the model saw or why an action happened. Incident response becomes guesswork.

Practice: log input hashes, retrieval ids, controls, verdicts, policy versions and actions in a tamper-evident store. Retain the minimum necessary.

Best practices that cut across all of them

• —Put a screening gateway in front of model calls.
• —Make authorization decisions in code, never in the prompt.
• —Treat retrieved content and tool output as hostile.
• —Give agents the smallest authority that still works.
• —Validate and encode every output boundary.
• —Cap spend and steps per session.
• —Test with adversarial prompts on every release.
• —Keep evidence for every verdict.

LLM security is not a property of the model. It is a property of the system around the model.