The attacks get reported when they can be told as a story

Security teams are sizing their AI defences against the attacks they can retell in a meeting, not the ones with the most documented cases.

What most people think

The consensus view inside most governance and security functions is that the known attack surface is broadly covered. Prompt injection is on the risk register. The team has read the write-ups. There is a control, a policy line, and a slide. The assumption underneath is that the industry has catalogued the main ways AI systems get attacked, and that what shows up in the trade press roughly tracks what is actually happening.

That assumption is reasonable. It is also the thing that makes the gap invisible. If your threat picture is built from what you read, and what you read is built from what can be explained in 400 words, then your threat picture is a picture of narratable attacks. That is a different set from the set of attacks with real cases behind them.

What the data shows

Start with our own live incident database, which tracks reported AI failures from public news. In the last 180 days it holds 1500 stories. The last 45 days produced 476, against 491 in the 45 days before. Volume is flat. Severity is flat too: 49 critical and 415 major in the last 45 days, against 52 critical and 425 major in the prior window. Coverage is also thin and concentrated. The top five outlets account for 7 percent of the last 45 days.

Now compare that to the catalogued risk classes. Over 180 days, the news gave 212 stories to privacy leakage and inference, 120 to multi-agent risks, 97 to AI system security vulnerabilities and attacks, 94 to fraud and targeted manipulation, and 40 to governance failure. The same window gave zero stories to overreliance and unsafe use, zero to environmental harm, zero to lack of capability or robustness, and one to competitive dynamics.

That is the pattern at the level of risk classes. The sharper version is at the level of specific attack techniques. MITRE ATLAS, the public knowledge base of adversary tactics against AI systems, lists documented real-world case studies against named techniques. LLM Prompt Crafting (AML.T0065) has 22. Evade AI Model (AML.T0015) has 18. AI-Enabled Product or Service (AML.T0047) has 16. AI Agent Tool Invocation (AML.T0053) has 15. Indirect prompting (AML.T0051.001) has 13. User Harm (AML.T0048.003) has 12.

Our sister platform ThreatClaw, which tracks the threat side, has published 40 articles in 60 days. Prompt Injection appears as a tag 14 times. AI Agent Tool Invocation appears zero times. Fifteen documented real cases, no coverage in the window we can see.

This is not a claim that nobody anywhere has written about it. It is a claim about the shape of attention. The technique with 15 real cases sits outside the conversation. The technique with a memorable name sits inside it.

Why this happens

Prompt injection is easy to narrate. You can show a user typing a sentence and the model doing something it should not. The demonstration takes thirty seconds. The harm is visible in the same frame as the cause. A journalist can explain it to an editor in one line, and a board member can repeat it to a colleague.

AI agent tool invocation does not compress like that. The technique is about an agent being induced to call a tool it has access to, in a way the operator did not intend. To explain why that matters you have to describe what tools the agent holds, what permissions those tools carry, what the blast radius is, and why the model's decision to call one is not the same as a user's instruction to call one. That is a paragraph of setup before the harm lands. Most coverage never gets past the setup.

The mechanism is not laziness. It is a selection effect that runs through three layers at once. Reporters pick stories they can tell. Editors pick stories readers will finish. Security vendors pick stories that make a demo land. Each layer is behaving rationally, and the compounding effect is that a technique with 15 documented cases can be functionally invisible while a technique with a catchier name becomes the mental model for the whole category.

Then the governance layer inherits it. Risk registers are built from what the team has heard of. Budgets follow risk registers. Controls follow budgets. By the time the gap reaches the resource plan, it has been laundered through three rounds of reasonable individual decisions.

The regulatory calendar is not going to close this gap for you. The EU AI Act's high-risk obligations apply from December 2027, with serious-incident reporting under Article 73 on the same date, and its rule on labelling AI-generated content applies from August 2026. Colorado's original AI law was repealed and replaced by a narrower one that starts in January 2027. California's privacy agency has automated decision-making rules phasing in from January 2027, with opt-out and pre-use notice in April 2027 and risk assessments for existing processing due at the end of that year. Canada has no comprehensive federal AI law right now, though OSFI's Guideline E-23 on model risk management takes effect in May 2027 for federally regulated financial institutions. Every one of these asks you to describe your risks and your controls. None of them tells you which attack techniques to size against. That judgement is yours, and it is exactly where the narrative bias does its damage.

The best argument against this

The strongest objection is that news coverage is the wrong denominator, and I should not be surprised when it fails to track a technical taxonomy. Reporters are not writing a risk register. They are writing about harm to people, and harm is the thing that matters. On that reading, the 212 privacy stories and the 94 fraud stories are not a distortion. They are the correct signal, because those are the harms that actually reach individuals. A technique with 15 case studies in a vendor-maintained knowledge base is not automatically a bigger threat than a harm class with 212 news stories. Frequency of documentation is not frequency of occurrence, and ATLAS case counts reflect what researchers chose to publish as much as what attackers chose to do.

That objection is partly right and I want to take it seriously. News does track harm, and harm is the point. But it does not follow that news tracks the causes of harm, and the two get conflated constantly. A privacy leak is an outcome. AI agent tool invocation is a mechanism that can produce that outcome. If you fund against the outcome and not the mechanism, you are buying detectors for the last incident rather than controls for the next one. The 15 ATLAS cases are not a claim about prevalence. They are a claim that the mechanism is real, documented, and absent from the conversation your team is having. The objection correctly says news is not a taxonomy. It does not rescue the risk register that was built as if it were.

What I think happens next

The first major incident involving AI agent tool invocation will be reported, and framed, as a prompt injection attack. I expect this by September 2027.

The reason is structural rather than cynical. When the incident lands, the first people to describe it will reach for the nearest available label, and the nearest available label will be the one with 14 mentions in the threat press and a demo everyone has seen. The mechanism will be there in the technical details. The framing will be wrong. And the remediation budget will go to the wrong control.

What would prove me wrong: if by September 2027, incidents involving AI agent tool invocation are correctly reported and kept distinct from prompt injection in the coverage, the incident write-ups, and the vendor response. If that happens, the selection effect I am describing is weaker than I think, and the field has better transmission from technical taxonomy to public narrative than the current data suggests.

What to do about it

• Map attack techniques to business impact, not narrative appeal. Take the ATLAS techniques your systems are exposed to and write down, for each one, what an attacker actually gets. Do this before you rank them. Ranking first is how narrative wins.
• Check your own register against the technique list. If AI agent tool invocation is not on it, that is a finding, not an oversight. Ask who decided it was out of scope and on what evidence.
• Train detection on the unreported techniques. Your security team can name prompt injection. Ask them to describe how they would detect an agent calling a tool it should not, and watch what happens to the room. That silence is your training plan.
• Separate what your agents are allowed to do from what they actually did. Governance sets the permission. You still need a record of the actual tool calls, the arguments passed, and the results returned, because that record is the only place this technique shows up. Argus at argus.threatclaw.ai records every trace an AI application produces, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed.
• Size your controls against the threat, not the headline. A control is only as good as the threat it is sized against, and ThreatClaw at www.threatclaw.ai tracks the exploitation side of these systems so the sizing is based on what is being tried rather than what is being written about. If you want a starting point on evidence and records, their piece at https://www.threatclaw.ai/blog/your-ais-receipts-will-save-you-in-a-crisis covers why the trace matters when something goes wrong.

The gap is not a failure of anyone's diligence. It is what happens when a field learns its threats from coverage. The fix is unglamorous: read the taxonomy, not just the news, and make the register follow the evidence rather than the story.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.

Related reading:

• Your AI's Receipts Will Save You in a Crisis on ThreatClaw
• How to Stress-Test Your AI Before Hackers Do on ThreatClaw