There’s a tempting analogy doing the rounds: “prompt injection is just the new SQL injection — we’ll parameterize it away and move on.” It’s comforting. It’s also wrong, and believing it leads teams to under-invest in the controls that actually matter.

Why the analogy breaks

SQL injection is solvable because databases can cleanly separate instructions (the query) from data (the parameters). Bind your parameters and the attack surface largely closes.

Large language models have no such separation. As the UK’s NCSC has pointed out, an LLM consumes instructions and untrusted content in the same channel — natural language — and it is genuinely bad at telling them apart. When your agent reads a web page, a document, or an email, any text in that content can attempt to hijack its behaviour. That’s indirect prompt injection, and there is no bind() that makes it go away.

This is why OWASP’s Top 10 for LLM Applications keeps prompt injection and “excessive agency” at the top, and why the NIST Generative AI Profile treats it as a first-class risk rather than an implementation bug.

What the research actually shows

The honest summary of the current evidence is: mitigations are layered and probabilistic, not absolute.

  • Microsoft’s Lessons from Red Teaming 100 Generative AI Products concluded that LLMs amplify existing security risks and that AI security work is never “done.”
  • Microsoft Research’s work on spotlighting reduced attack success from over 50% to under 2% in their experiments — a huge improvement, but not zero.
  • Google DeepMind’s work on defending Gemini against indirect prompt injection frames it as continuous adaptive evaluation — a moving target, not a fixed patch.
  • Agent-focused benchmarks routinely report high peak attack-success rates against tool-using agents with current defences.

The throughline: anyone selling you a single “prompt-injection classifier” as the answer is selling you a false sense of security.

The approach that works: defence in depth

Because no single control is reliable, you layer them and you assume breach. This is the same instinct that has worked in security for decades, applied to AI. In practice:

1. Minimize privilege and agency. The blast radius of a successful injection equals what the agent is allowed to do. Give agents the narrowest possible permissions, the fewest tools, and read-only access wherever you can. An agent that can’t exfiltrate or transact is a far smaller problem when it’s tricked.

2. Constrain tools and connectors. Treat every connector and action as a data-egress decision. Default new connectors to non-business until reviewed, separate dev/test/prod environments, and be deliberate about which agents can call the web, execute code, or reach private data sources.

3. Layer runtime defences. Use what the platform gives you — prompt shields, spotlighting, plan-drift detection, and tool-invocation monitoring. Microsoft’s Zero Trust guidance on indirect prompt injection frames these as a stack, and Copilot Studio now includes built-in protections against several injection classes. None is sufficient alone; together they raise the cost meaningfully.

4. Instrument everything. You cannot defend what you cannot see. Log prompts, responses, tool calls, and accessed resources, and make them searchable. The goal is detection and investigation, not just prevention.

5. Review the traffic itself. Reasoning over prompt and response traffic with a second model catches semantic attacks that pattern-matching misses — with real caveats about it being injectable, probabilistic, and privacy-sensitive. I weigh that trade-off in Using an LLM to Watch Your LLM.

6. Validate with safe red-teaming. Test, don’t assume. Seed a benign artefact containing an obvious “ignore previous instructions” payload and a canary string, point your agent at it, and verify it refuses, blocks the tool call, or at least alerts. Do it with synthetic data and proper authorization — then do it again next quarter, because the threat moves.

The mindset

The lesson from the 2026 Copilot-related disclosures — SearchLeak, Reprompt, the Copilot Studio injection research — isn’t “AI platforms are unsafe.” It’s that runtime protections don’t remove the need for least privilege, connector governance, monitoring, and red-team validation in your own tenant. Vendors will patch specific exploits. Your job is to build a system that fails safely when the next, unpatched one arrives.

Prompt injection won’t be “solved” the way SQL injection was. But it can absolutely be managed — by people who treat AI like the powerful, partially-trusted system it is, and engineer accordingly.

Frontier vendors are making real progress on the model side — OpenAI reports indirect-injection attack success dropping from 27% to 8.5% in GPT-6 Astra — but a residual success rate against an adversary operating at machine speed is a reason to keep your own controls, not to retire them.

This is the heart of the agentic-AI governance work I run with security teams. If you’re deploying agents or Copilot and want to pressure-test your defences, let’s talk — or start with the secure Copilot launch playbook.