The AI Security Conversation and the AI Governance Conversation Stopped Reading Each Other

The AI security conversation and the AI governance conversation have split into two markets that no longer read each other. The split is landing on the wrong budget line: governance teams are buying policy artifacts while the attack surface in their own telemetry is tool invocation and model evasion.

What most people think

The strongest version of the consensus goes like this. AI security is a specialist sub-discipline. It has its own techniques, its own tooling, its own practitioners. Governance sits one level up. It sets policy, maps obligations, runs the risk register, and treats security findings as an input, the way it treats legal review or internal audit. On this view the two functions are complementary and the division of labour is clean.

The consensus also holds that the governance agenda is set by the regulatory calendar. You look at what is due, you work backwards, you build the programme. That is a reasonable way to run any compliance function, and it is how most governance teams were trained.

What the data shows

Our live incident database, which tracks reported AI failures from public news, holds 1500 stories over the last 180 days. Story volume is flat: 468 in the last 45 days against 474 in the 45 before. But the mix moved. Governance stories rose from 184 to 220. Security stories fell from 46 to 37. Compliance stories fell from 80 to 45. Privacy rose from 74 to 98.

So the governance side is growing while the security side shrinks, in the same window, on the same feed.

Now look at what the security side is actually writing about. Our sister platform ThreatClaw published 40 articles in 60 days. Twenty-three were in ai-security. The recurring tags were Prompt Injection (11) and Data Poisoning (8). The titles are practical: what a real AI security check looks like, how attackers swap your AI for a lookalike, why guardrails fail when attackers own the path.

Then compare that to what the news window never mentions. MITRE ATLAS catalogues attack techniques with documented real-world case studies. Six of them get zero mentions across 180 days of incident coverage: LLM Prompt Crafting (AML.T0065) with 22 documented real cases, Evade AI Model (AML.T0015) with 18, AI-Enabled Product or Service (AML.T0047) with 16, AI Agent Tool Invocation (AML.T0053) with 15, User Harm (AML.T0048.003) with 12, and Financial Harm (AML.T0048.000) with 11.

Fifteen documented real cases of tool invocation. Zero mentions in the news window. Eighteen documented real cases of model evasion. Zero mentions.

The MIT AI Risk Repository tells the same story from a different angle. Overreliance and unsafe use: zero stories. Environmental harm: zero. Lack of capability or robustness: zero. Meanwhile privacy leakage drew 198 stories and multi-agent risks drew 118. Coverage clusters where the vocabulary is familiar, not where the risk is documented.

Why this happens

The mechanism is vocabulary, not ignorance.

Trade press coverage of AI security is written by practitioner outlets for practitioners. They describe techniques. They name the method, the tool, the sequence of steps. A piece on prompt injection explains how a retrieved document can carry instructions the user never typed.

Governance coverage is written by policy outlets for policy readers. They describe obligations. They name the regulation, the deadline, the reporting duty. A piece on the EU AI Act explains what Article 73 requires when a serious incident occurs.

When the same underlying event gets described in two vocabularies, neither side's risk register picks it up. The security team logs a technique. The governance team logs an obligation. Nobody writes the row that connects them, because the connecting sentence does not exist in either publication.

The consequence is a funding rule. The control that gets budget is the one with a regulatory citation attached, not the one with an exploit attached. A control can be justified to a board by pointing at a date. It is much harder to justify by pointing at a technique that no one in the governance literature has named.

There is a second effect. The regulatory calendar is legible and finite. You can finish a deadline. You cannot finish an attack surface. Teams gravitate to the work that closes.

This is where the two conversations should meet. Governance decides what an AI agent is allowed to do. Something has to show what it actually did. Argus, at argus.threatclaw.ai, records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including attacks hidden inside retrieved documents and tool results rather than in what the user typed. That is the evidence layer a risk register needs and rarely gets.

The best argument against this

The honest objection is that this is a measurement artifact. Governance stories rose because the EU AI Act high-risk obligations land in December 2027 and Article 73 serious-incident reporting lands on the same date. Colorado's original AI law was repealed and replaced by a narrower one starting January 2027. California's automated decision-making rules phase in from January 2027. Of course coverage rises. That is the calendar working as designed, and it is not evidence of a split.

It is a fair point, and it explains part of the movement. But it does not explain the silence. A regulatory calendar explains why governance volume goes up. It does not explain why a technique with 15 documented real cases gets zero mentions in 180 days of incident reporting. Deadlines generate coverage of deadlines. They do not suppress coverage of exploits. If anything, a serious-incident reporting duty should increase demand for the security vocabulary, because you cannot file a serious-incident report without describing a mechanism.

The second half of the objection is that governance teams are not supposed to do security. True. But they are supposed to scope risk. A risk register with no row for tool invocation is not delegating security. It is declining to describe the system.

What I think happens next

By September 2027, at least one EU AI Act Article 73 serious-incident report, or an equivalent public enforcement disclosure, will describe an AI system compromise whose mechanism is an ATLAS-catalogued technique, whether tool invocation, model evasion, or prompt crafting, rather than a content failure. And the governance trade press will cover it using security vocabulary it has not previously used.

What would prove me wrong: if by September 2027 every publicly disclosed AI incident in our feed and in EU AI Act enforcement notices is still described in content, bias, or privacy terms with no ATLAS technique named, the claim is wrong and the split was never real.

What to do about it

• Add the six underreported ATLAS techniques as explicit rows in your AI risk register. Each gets an owner and a control, whether or not a regulation names it. Prompt crafting, model evasion, tool invocation, product or service abuse, user harm, financial harm.
• Set a standing monthly read-across between the security team's technique list and the governance risk register. Name one person on each side. The meeting exists to translate, not to report.
• Require that any agent granted tool invocation be assessed against AML.T0053 before deployment, not after. Fifteen documented real cases is enough to justify the gate.
• Stop sizing controls against the deadline alone. A control is only as good as the threat it is sized against, and ThreatClaw at www.threatclaw.ai tracks that threat side with live feeds and detection rules you can deploy.
• Read the security trade press your own security team reads. If a technique appears there twice and nowhere in your register, that is a gap, not a specialism.

For a security-side view of where this lands, ThreatClaw's piece on why AI audits miss the server room entirely is worth twenty minutes: https://www.threatclaw.ai/blog/why-your-ai-audit-misses-the-server-room-entirely

The risk is concrete. A governance team whose risk register has no row for tool invocation or model evasion will be asked, after an incident, why those techniques were out of scope when the security team had documented cases for them. That is not a compliance question. It is a question about whether the register described the system at all.

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:

• The AI Management Certificate That Changes Your Security Job on ThreatClaw
• Why Your AI Audit Misses the Server Room Entirely on ThreatClaw