Prompt injection isn't a jailbreak — it's a data problem

Recent industry surveys put the number of organizations reporting confirmed or suspected AI agent security incidents in the high 80s percent, and separate research puts year-over-year growth in prompt injection attacks in the hundreds of percent. Both numbers are jarring on their own. Together they point at the same root cause: most teams are still defending prompt injection like it's a model-alignment problem, when it behaves like an untrusted-input problem — the same category of bug the web industry spent two decades learning to handle with SQL injection and XSS.

The framing that keeps failing

The instinct is to treat prompt injection as something to fix with a better system prompt, a stricter refusal policy, or a smarter model. That framing puts the fix inside the model, where it's genuinely hard to guarantee — a large language model processes its system prompt, the user's message, and any retrieved document or API response as the same kind of token stream. It has no reliable, enforced boundary between "instructions from my operator" and "content I was asked to read." An attacker who can get text in front of the model — a document, a webpage, an email, an API response, a support ticket — can potentially get instructions in front of it too. Tightening the system prompt reduces the attack surface a little; it doesn't close it, because the vulnerability is architectural, not a wording problem.

What this looks like once an agent has real tool access

For a chatbot, a successful injection produces an embarrassing reply. For an agent wired into your systems — email, file storage, a database, a payments API — a successful injection produces an action taken with that agent's own credentials. Reported patterns from the past year include agents tricked into exfiltrating internal documents through an innocuous-looking summarization request, coding agents compromised through poisoned repository content that executes when the agent opens it, and supply-chain cases where a previously trustworthy package added data-exfiltration behavior after establishing a track record of clean releases. The common thread in nearly every case: the agent had more standing access than the specific task required, and nothing was watching what it actually did with that access at runtime.

Why "excessive agency" is the real vulnerability

OWASP's guidance for agentic applications names excessive agency — an agent holding broader tool access, data access, or autonomy than its current task needs — as one of the most consistently reported failure patterns across incident surveys. This reframes the defense entirely. If an agent can only call search_web and draft_email, a successful injection can, at worst, make it search and draft — annoying, not catastrophic. If that same agent can also call delete_records or send_email with no approval gate, the blast radius of the exact same injection is the whole system. Least-privilege access, scoped per tool and per task, is doing more real defensive work here than any prompt-level filtering.

A practical defense stack, not a single fix

Treat all retrieved content as untrusted input. Documents, web pages, API responses, and email bodies an agent processes are data, not instructions — the same discipline as never trusting user input in a web form.

Scope tool access to the task, not the agent's ceiling. Require explicit approval for irreversible or sensitive actions — sending mail, deleting data, executing payments — rather than granting standing access "in case it's needed."

Monitor the calls, not just the output. A jailbreak filter on the model's text response won't catch an agent that was manipulated into calling a tool it was technically allowed to call. Runtime detection needs visibility into which tools fired, with what parameters, and whether that pattern matches the agent's normal behavior.

Log everything for after-the-fact review. Detection isn't always real-time-perfect. A complete, tamper-evident audit trail of every tool call is what turns "we think something happened three weeks ago" into a fifteen-minute investigation.