What "AI Security" Misses When You Reduce It to Prompt Injection
Written by the Rafter Team
Open any "AI security" landing page in 2026 and the same bullet list appears: prompt injection, jailbreaks, model hallucination, training-data poisoning, alignment failure. Each of those is a real attack class. None of them was the root cause of the AI-adjacent incidents that put real money on the line last quarter. The actual root causes were boring, were old, and were the kind of bugs that have been in the OWASP Top 10 for fifteen years — applied to a new surface.
This post argues that the prompt-injection-first frame is now actively harmful to defender budgets, because it sends security investment toward a small and well-funded subproblem while leaving the larger problem under-resourced.
If your AI-security program's threat model starts and ends with prompt injection, you are auditing for the most visible attack class while shipping the bug classes that actually caused 80% of the AI-related incidents in 2026 so far. The frame needs to broaden, fast.
What the past quarter's incidents actually were
Pull the AI-related incident postmortems Rafter has covered this quarter into a list and bucket by root cause. The buckets are not what the prompt-injection frame predicts.
Tool over-privilege and confused deputy. The largest bucket. An AI agent has more authority than it needs, an untrusted input reaches the agent, the agent acts with its full authority. Examples: Codex branch injection, tier-permission paths as a bug class. Root cause: authorization design. Not prompt injection.
Supply-chain compromise. The second-largest bucket. AI tooling — frameworks, SDKs, MCP servers, agent runtimes — is shipped through package ecosystems that have all the same supply-chain problems every other package ecosystem has. Examples: Mercor LiteLLM, Trivy TeamPCP, PyTorch Lightning impersonation, Canisterworm / ClawHavoc cluster. Root cause: dependency surface. Not prompt injection.
Trust-channel and impersonation. The third bucket. Attackers deliver payloads through channels users have been trained to trust. Examples: Robinhood, Canvas, trust-signal forgery economy. Root cause: channel-vs-content authorization. Not prompt injection.
Classical AppSec bugs in AI framework code. The most embarrassing bucket. Frameworks shipping by major vendors with eval() on attacker input, filter injection, insecure-by-default cross-user data sharing, arbitrary file write. Root cause: 2005-era CWE classes. Not prompt injection.
Prompt injection. A real bucket, smaller than the four above. The CamoLeak and sandworm-mode worm cases are the high-profile examples. Real bugs. Solving them does not eliminate any of the four buckets above.
The pattern: prompt injection is the visible top of an iceberg whose mass is in older, less-glamorous bug classes that the AI-security industry's frame underweights.
Why the frame got narrow
Three forces compressed the public "AI security" conversation into prompt-injection-and-jailbreaks.
The research community led with what was novel. Prompt injection is a genuinely new class of bug — one that did not exist before LLMs. The academic security research industry pursued it because it was research-publishable. The industry conversation absorbed the research framing. That was reasonable in 2023. It is no longer the only frame, because the practitioner picture has filled in.
Vendor product marketing followed. "Prompt injection defense" is a product category with funded startups and known buyers. "AI supply chain hygiene" or "agent tool over-privilege detection" are not yet that — they look like generic AppSec, which is harder to sell as "AI security." The vendor narrative narrowed the public frame.
Practitioner attention deficit. Security teams have limited budget cycles and limited mindshare for new threat models. "AI security" got allocated one bucket, and the bucket was sized for one problem. The bucket got filled with prompt injection because that is what the budget conversation was framed around.
None of these is irrational on its own. The aggregate is a frame that systematically under-resources the bug classes causing the incidents.
The reframe
The right framing is not "AI security is a special new thing." The right framing is "AI surfaces inherit every classical security problem plus a small number of genuinely new ones." The classical problems dominate the incident base. The new ones are real and need attention, but the budget allocation has to follow the incident base, not the press-release base.
A reframed program looks like:
- Authorization and tool design as the central frame. What can each agent and each tool actually do? Are tool privileges minimized? Are tier labels real boundaries or just hints?
- Supply chain as a first-class line item. Dependency hygiene for AI frameworks is identical to dependency hygiene for any other framework, except the rate of new code is faster and the audit-to-code ratio is worse. Treat it accordingly.
- Classical AppSec for AI framework code. Every AI agent framework is a web/distributed system underneath. SQL injection, eval-on-input, path traversal, insecure deserialization — all present, all shipping, all caught by the same tools that catch them in any other codebase.
- Trust-channel discipline. Agents extend the trust-signal surface. Threat-model the content, not the channel.
- Prompt injection as one CWE among many. Real, defended, but not the only line item.
The reframe is not "stop caring about prompt injection." It is "stop treating prompt injection as the entire problem."
The Rafter angle
Rafter's pitch has always been that AI-relevant security is AppSec applied to AI-shaped code. rafter run catches the classical bug classes in the AI framework layer. The OWASP Top 10 is the foundation; the AI-specific patterns sit on top of it, not in place of it. The reason the program is built that way is the same reason this post argues for the reframe: the incidents that hit budget reality are the classical-bug-classes-on-new-surfaces incidents, not the novel ones.
The companies that survive 2026's AI-incident curve will be the ones whose security program looks like a complete AppSec program with AI extensions, not the ones whose program looks like a prompt-injection defense with everything else delegated to "general AppSec, separate team, different budget."