Prompt Injection: The Unsolved Vulnerability at the Heart of Every LLM Application

Every engineer knows SQL injection: untrusted input gets interpreted as a command. We solved it decades ago with parameterized queries — a hard boundary between code and data.

Prompt injection is the same idea applied to LLMs, with one brutal difference: there is no parameterized query for natural language. To a model, everything is tokens. The system prompt, the user's question, and the contents of a PDF it was asked to summarize all arrive through the same channel — and the model has no reliable way to know which parts are instructions and which are data. That's not a bug in any particular model. It's a structural property of the architecture, and it's why OpenAI, Anthropic, and every security vendor still classify prompt injection as an unsolved frontier problem.

Direct vs. Indirect Injection

Direct injection is the classic "ignore previous instructions" trick typed straight into a chatbot. Annoying, but contained — the attacker mostly compromises their own session.

Indirect injection is where the real risk lives. The malicious instructions arrive through content the model processes on someone else's behalf: a web page an agent browses, a document in your RAG pipeline, an email, a GitHub issue, a calendar invite. The victim never types anything malicious — they just ask their assistant to "summarize this ticket," and the ticket contains hidden instructions the model dutifully follows.

Between 2024 and 2026 this moved from research demos to production incidents: documented attacks against Slack AI, Microsoft 365 Copilot, Cursor, and GitHub's MCP integrations all followed this pattern. By 2026, OWASP's exploit reporting shows organized tooling — dozens of distinct payload families and delivery techniques in active use — rather than isolated experiments.

The Lethal Trifecta

Simon Willison coined the cleanest way to reason about this risk. An AI system becomes dangerously exploitable when it combines three things:

1. Access to private data — your documents, database, codebase, inbox
2. Exposure to untrusted content — anything an attacker can influence: web pages, emails, tickets, package READMEs
3. The ability to communicate externally — sending requests, emails, commits, or tool calls that leave the perimeter

Any two are survivable. All three together mean an attacker who controls a single piece of content your agent reads can potentially exfiltrate everything the agent can see. Nearly every major incident of the past two years maps onto this exact combination.

This is also why the agentic era made things worse. A 2023 chatbot that falls for an injection says something embarrassing. A 2026 agent with database access, a shell, and an email tool does something irreversible. The stakes moved from words to actions — which is why in May 2026 the Five Eyes agencies (CISA, NSA, and their UK, Canadian, Australian, and New Zealand counterparts) issued joint guidance on agentic AI, naming prompt injection as a core manipulation vector and stating plainly that no single safeguard is sufficient.

Why You Can't Just Filter It

The instinctive fix — "detect and block malicious prompts" — doesn't hold. Injections can be paraphrased infinitely, encoded, split across documents, hidden in white-on-white text or image metadata. Even the strongest published detection approaches miss a meaningful fraction of optimization-based attacks, and an attacker only needs one success. Guardrail models help as a layer; they fail as a foundation.

The honest engineering position: assume injection will succeed, and design so that a successful injection can't do serious damage.

Defense in Depth That Actually Works

• Break the trifecta. The single highest-leverage move. If an agent reads untrusted content, cut its egress or its access to secrets. Design each agent to hold at most two of the three properties.
• Least-privilege tools. Scope every tool to the narrowest action set. Read-only where possible. No production credentials in agent reach.
• Treat model output as untrusted input. Never pipe it into a shell, SQL, or an API call without validation — injection turns the model into the attacker's proxy.
• Human confirmation for irreversible actions. Payments, deletions, emails to external addresses, production deploys.
• Sandbox and isolate. Code execution in egress-restricted containers; per-session isolation so one poisoned document can't contaminate other users.
• Log everything. Full prompt and tool-call telemetry in your SIEM. Injection attempts are an attack signal you should be alerting on, not discovering weeks later.

If you run models on your own infrastructure, these controls sit on top of the hardening baseline we covered in Security of Self-Hosted LLMs — injection is the behavior-layer threat that remains even when your network and supply chain are clean.

Conclusion

Prompt injection isn't a vulnerability you patch; it's a property you architect around. The teams getting this right in 2026 aren't the ones with the smartest filter — they're the ones who assumed compromise and made the blast radius small: minimal privileges, broken trifectas, validated outputs, and a human in the loop where it counts.

At NextVector, we apply the same security-first engineering to AI systems that we bring to payment and blockchain infrastructure. Building an LLM feature that touches real data? Get in touch.