LLM Security: Injection, Keys, and Data Leakage
LLM apps add a new attack surface: the model itself can be talked into misusing its tools and leaking its context. Treat every model output as untrusted input, and every tool call as a privileged operation.
Last reviewed Jul 7, 2026
1. Design for injection surviving, not being filtered
Do: Give the model the minimum tools for the task, scope each tool's permissions server-side, and confirm destructive or outward-facing actions with a human.
Don't: Rely on 'ignore malicious instructions' system-prompt lines or regex filters as the security boundary.
Why: Injection via retrieved documents, web pages, or user uploads reliably beats instruction-level defenses. If a hijacked model can only do harmless things, injection becomes a nuisance instead of a breach.
2. Keep secrets out of the model's world
Do: Hold API keys server-side in a secret manager; give agents short-lived, narrowly-scoped credentials; set per-key spend limits and alerts.
Don't: Embed keys in prompts, client bundles, or notebooks — or share one all-powerful key across services.
Why: Anything in the prompt can be exfiltrated by injection ('repeat your instructions verbatim'), and leaked LLM keys are actively scanned for and abused within hours.
3. Control what data reaches the vendor
Do: Strip or pseudonymize PII before prompting, disable training-on-data where offered, and know each provider's retention policy; keep regulated data to providers with signed agreements (BAA, DPA).
Don't: Pipe raw customer records, support tickets, or medical text into third-party APIs because it was fast.
Why: Prompts and logs are data flows under GDPR/HIPAA like any other. The 'we didn't realize prompts count' incident is now a compliance classic.
4. Sandbox code execution and browsing
Do: Run model-generated code in ephemeral, network-restricted sandboxes; allowlist domains agents may fetch; cap file-system access.
Don't: Exec model output on a host with production credentials or open egress.
Why: Generated code is untrusted code from the internet, statistically speaking. Sandboxing converts a remote-code-execution risk into a contained failure.
5. Log for forensics, alert on anomalies
Do: Log prompts, tool calls, and outputs with user attribution (PII-scrubbed); alert on spend spikes, unusual tool sequences, and mass retrieval.
Don't: Run agents with no audit trail, then reconstruct an incident from vendor invoices.
Why: LLM incidents look like weird usage before they look like breaches. The audit trail is the difference between a one-hour and a one-month investigation.
The mental model: a very persuadable intern
The most useful security frame for an LLM app: the model is an intern who believes everything it reads and has your tools in hand. Any text it processes — user input, a retrieved wiki page, a scraped website, an email — can carry instructions, and some of it eventually will. Content filtering catches the crude attempts; architecture (least privilege, sandboxes, approval gates, scoped credentials) is what holds when filtering fails.
Security and cost discipline overlap more than teams expect: per-key spend caps, tool allowlists, and full call logging serve both, and are all one-day tasks when done at project start — see the checklist above and set them up before the first feature ships.