Hook
Two frontier labs. Tens of thousands of security incidents under internal investigation. Not one public hash. Not one timestamp. Not one external attestation.
I have spent the better part of a decade taking protocols apart at the code level. In late 2017, at twenty-seven, I ran static analysis across twelve ICO presale contracts during the Ethereum boom. Four contained critical reentrancy vulnerabilities. I quantified the exposure at roughly fifteen million dollars and published a standardized risk report. My contract rejection rate that cycle was thirty-three percent. Institutional allocators paid attention not because I was loud, but because I had receipts. Every finding mapped to a line number. Every claim mapped to a test.
That standard governs everything I write. The code executes, not the promise.
So when a wire story surfaces that OpenAI and Anthropic are investigating "tens of thousands" of AI security incidents, my first question is not how bad it is. My first question is: compared to what, counted how, verified by whom. The number is the least useful part of the report. The absence of a definition, an attribution model, a severity distribution, and a verification path is the actual story. Without those four artifacts, "tens of thousands" is not a finding. It is a press release with a number attached.
Context
Set the record straight on what these two labs actually operate, because the mechanics matter more than the headline.
OpenAI publishes a Preparedness Framework. It defines tracked categories — cybersecurity, CBRN, persuasion, model autonomy — and assigns risk tiers to models before deployment. Anthropic publishes a Responsible Scaling Policy, or RSP, with AI Safety Levels and defined deployment gates. Both companies run input-side moderation classifiers, output-side guardrails, continuous red-teaming, and post-deployment monitoring. Both have built internal incident-handling functions that look, structurally, like a security operations center. Tiered queues. Triage rules. Escalation paths. On-call rotations.
That is the machinery. Now the gap. None of it produces an externally verifiable record.
When a bank discloses a data breach under GDPR or a US state notification law, the disclosure carries a legal signature. It is timestamped. It is filed with a regulator. It can be audited after the fact. When a CVE is published, it carries an identifier, an affected version range, a severity score, and a public record anyone can diff against. The entire cybersecurity industry runs on a shared, citable incident language. That language is the reason a threat analyst in Manila can act on a disclosure from a vendor in Tel Aviv without a phone call.
The AI industry does not have that language. It has narrative.
The terminology problem compounds everything. The English phrase "AI security incidents" collapses two different failure modes into one bucket. Security, in the adversarial sense, means jailbreaks, prompt injection, model-assisted cyberattacks, data extraction, model theft. Safety, in the alignment sense, means harmful outputs, deception, self-preservation behavior, refusal failures, sycophancy. These are different problems with different owners, different mitigations, different severity curves, and different regulatory homes. A media report that does not separate them is not reporting a number. It is reporting a mood.
That distinction is not academic. It determines whether a "tens of thousands" figure represents adversarial pressure on a defended system or a filtering layer firing on ordinary traffic. Those two readings differ by orders of magnitude in what they imply about risk. The wire story, as parsed, contains neither the definition nor the split. It gives a quantity and a verb. That is all.
Core
Build the technical case for why this matters, and why the blockchain toolkit is the right lens even though this is nominally an AI story.
Start with the counting problem.
"Tens of thousands" is a quantity without a denominator or a definition. In my DeFi work I learned to distrust any volume metric that arrives without a measurement methodology. Total value locked is the classic example. A protocol can inflate TVL by paying users to deposit. The incentives stop, the TVL evaporates, and the "growth" was never organic. Liquidity mining APY is not yield. It is a subsidy dressed as yield, and the moment you remove it you discover who the real users were. The reported number was real. The meaning was manufactured. The same discipline applies here: a quantity is only as meaningful as the definition underneath it.
Apply that to AI incidents. A counted "incident" could be any of the following:
A user jailbreak attempt blocked at the classifier layer. A flagged output that a moderator reviewed and cleared. A red-team finding from an internal adversarial exercise. A confirmed harmful output that reached a user. A model-assisted cyber operation detected downstream. A false positive from an overzealous filter. A prompt-injection attempt that failed. A data-extraction probe that partially succeeded before throttling.
The severity range across those eight categories spans from the guardrail working exactly as designed to active public harm. Summing them into one number and calling it "tens of thousands" is like adding up failed login attempts, blocked phishing emails, and confirmed account takeovers and calling the total a breach count. The number goes up. The meaning goes down. And it goes up fastest precisely where a system is doing its job — every blocked jailbreak is an incident under a generous definition and a success under a strict one. Counting methodology determines the size of the number more than actual risk does.
Now the auditability problem, which is where the blockchain lens earns its place.
Every meaningful on-chain system produces a verifiable trail. A transaction is signed, ordered, included in a block, and committed to a Merkle root. You can prove inclusion without revealing the transaction. You can prove a state transition occurred without exposing the state. That is the entire discipline: verifiable claims with minimal disclosure. Zero knowledge, infinite accountability.
AI incident reporting has the inverse property. It is high-disclosure and low-verifiability. The lab tells you a number. You cannot check the number. You cannot prove that any specific incident was classified, escalated, mitigated, or closed. There is no inclusion proof, no Merkle path, no root hash a third party can independently verify against a signed commitment.
This is not a hypothetical gap. It is the defining structural weakness of AI governance today, and it is being papered over with disclosure theater.
I ran this exact play in 2021, on a different target. I audited the ERC-721 implementations of ten trending NFT marketplaces and found a common flaw in royalty enforcement. The flaw was structural: marketplaces were trusted to honor royalties rather than required to verify them. You cannot bootstrap a shared standard by appealing to each participant's better nature. You get the standard you enforce. I drafted a formal specification for mandatory on-chain royalty checks. Two major platforms patched within forty-eight hours once the exposure — around five million dollars in lost creator revenue — was quantified and public. Quantification plus a specification plus a deadline produced a fix. A polite request would have produced a blog post.
Consider what a real AI incident audit trail would require. Five primitives:
First, a canonical event schema. Every incident gets a type, a severity band, a discovered-at timestamp, a resolved-at timestamp, and an outcome code. Enums only. No free text. Free text is where accountability goes to die, because free text cannot be aggregated, compared, or verified.
Second, a commitment mechanism. The lab hashes the incident record and publishes the hash. The record itself stays private. The hash proves the record existed at a point in time and has not been altered since. This is a timestamping problem, and it was solved roughly a decade ago. It is cheap.
Third, a Merkle aggregation. Individual incident hashes roll up into a per-period root. The lab publishes the root. A regulator, an auditor, or a journalist can later request a specific record and verify it against the published root. Selective disclosure. Verifiable existence. No full internal dump required.
Fourth, attribution and triage state. Was the incident adversarial, accidental, or a false positive? Was it mitigated, accepted, or escalated? These states must be recorded at the moment of decision, not reconstructed after a bad quarter. Retrospective attribution is where self-reported numbers get soft.
Fifth, an outcome linkage. For every incident marked high-severity, what actually changed? A model update, a policy patch, a classifier retrain, a customer notification, a rollback. Close the loop or the number is decoration.
I have built pieces of this before, in adjacent domains, so I know where the friction lives.
In 2020, I worked on gas optimization for Uniswap V2 forks. The naive version of the standardization protocol cost more than it saved, because every added check is an added opcode and every opcode burns gas. The winning version cut average transaction cost by eighteen percent for large-volume traders by moving verification off the hot path and committing to it periodically. The lesson: verification you cannot afford to run continuously has to be batched and committed. That is exactly the shape an AI incident registry should take. You do not notarize every event synchronously. You commit periodically and prove membership on demand. Anyone who designs this as a synchronous per-event proof has not priced the compute.
Now the cryptographic question. Can zero-knowledge proofs actually help here, or is that blockchain marketing applied to a problem it does not fit?
Honest answer: partially, and with real cost.
In 2025, I led a technical review of one of the first institutional-grade ZK-rollup solutions approved under the emerging regulatory frameworks. I verified the proof generation speed and found the circuit overhead was fifteen percent higher than advertised. That fifteen percent is not a rounding error at institutional scale. It shifted the deployment timeline and changed the cost model for every transaction required to carry a proof. I delivered the efficiency report to compliance officers and developers, and the project revised its schedule.
That experience calibrates my expectations. ZK proofs of AI behavior are theoretically attractive and operationally expensive. Proving that a specific model, at a specific weight version, with a specific prompt, produced a specific output within policy bounds requires committing to the weights, the inference process, and the output. The proving cost for large models is not close to production-viable for high-frequency serving. The circuit is the constraint. The circuit is always the constraint.
So the correct ambition is not "prove every inference." It is "prove the things that matter, batch the things that do not, and timestamp everything." A lab does not need to ZK-prove that a frontier model emitted token 4,000 of some completion. It needs to prove, on demand, that a particular incident record existed, that it was classified under a published schema, and that it was not edited after the fact. That is a hashing and commitment problem, not a heavy proving problem. It is cheap. It is boring. It is deployable today.
That distinction matters because the market keeps selling the heavy version.
There is a wave of projects claiming to decentralize AI, secure AI, or verify AI on-chain. Most of them are not doing any of those things. They are Ethereum projects or token wrappers rebranded for the AI cycle, exactly as a generation of Bitcoin-adjacent projects were Ethereum contracts rebranded for the Bitcoin cycle. The builders who understand what an attestation actually commits to do not recognize the loudest claims. This is the same pattern I have watched repeat since 2017: narrative arrives first, engineering arrives late, and the gap between them is where retail loses money. Nine years of protocol forensics have taught me one durable rule — Audit first, invest later.
The verifiable-AI thesis is real but narrow. It works for audit trails, attestation, and selective disclosure. It does not work yet for proving model behavior at scale, and it will not for a while. Anyone selling the second thing while delivering the first is selling a narrative, and narratives do not survive contact with an audit.
One more structural point, because it shapes where this goes. The instinct in crypto is to build a dedicated chain for everything. A dedicated data availability layer for incident data. A dedicated rollup for AI attestations. A dedicated L1 for model registries. That instinct is usually wrong. Most rollups today do not generate enough data to justify a dedicated DA layer; the throughput simply is not there, and the cost of running bespoke infrastructure exceeds the benefit for the overwhelming majority of workloads. The same logic applies here. Tens of thousands of incident records per year is a rounding error in data terms — kilobytes to low megabytes of structured metadata. It does not need a chain. It needs a schema, a commitment, and a boring verifier. The failure mode in this industry is over-engineering the substrate and under-engineering the standard.
Hardware attestation deserves a paragraph, because it is the shortcut everyone reaches for and it does not deliver what they expect. TEEs and confidential compute can attest that some code ran on some hardware in some environment. They cannot attest that the outputs were classified correctly, that the triage decisions were principled, or that the record was not amended in a subsequent write. Attestation of execution is not attestation of governance. Teams that ship a TEE-based "verifiable AI" claim and stop there have verified the wrong layer. Immutability is a feature, not a flaw — but only when it is applied to the record, not to the runtime.
Contrarian
Here is the counter-intuitive part, the part most coverage gets backward.
The problem is not that OpenAI and Anthropic have tens of thousands of security incidents. The problem is that we are being asked to treat the number as meaningful when the disclosure mechanism itself is unaudited.
Flip the assumption. Suppose the true count of confirmed, high-severity, harmful incidents is small. Say, low hundreds across both labs over the period in question, with the remainder being blocked jailbreak attempts, cleared false positives, and red-team findings. Under that reading, "tens of thousands" is not a scandal. It is evidence the detection layer is working: it is catching a large volume of low-severity noise and surfacing it for review. A functioning immune system generates a lot of immune activity. Nobody counts white blood cells and calls it a plague.
Now suppose the opposite. A meaningful fraction of those incidents are confirmed harmful outcomes, model-assisted cyber operations, or successful data-extraction attempts discovered after the fact rather than blocked in real time. Under that reading, "tens of thousands" is a genuine emergency, and the operative word is not the number. It is the verb. The reports say the labs are investigating incidents, not blocking them. Investigation is retrospective. Defense is prospective. A system that investigates tens of thousands of incidents and blocks most of them is healthy. A system that investigates tens of thousands and blocks few is bleeding, and the number is a symptom of exposure, not diligence.
We cannot tell which world we are in, because the disclosure does not distinguish them. That ambiguity is the actual finding. The number is not too high or too low. The number is unauditable, and an unauditable safety number is worse than no number at all, because it produces confident policy built on unknown data.
There is a second contrarian point, aimed at the governance crowd. The reflexive response to a scary number is to demand more regulation. But regulation built on an undefined metric will be wrong in one of two directions. If "tens of thousands" mostly means blocked attempts, the regulation will be disproportionate, and it will tax the labs running the strongest defenses the hardest — because strong defenses generate the most incident records. That is a perverse incentive: the better your classifier, the worse you look. If "tens of thousands" mostly means confirmed harm, the current regime of voluntary disclosure is obviously insufficient and the case for mandatory reporting with third-party verification is strong. Same number. Opposite policy conclusions. You cannot legislate responsibly on a metric you have not defined.
I watched this exact failure mode in 2022, during the LUNA and UST collapse. I executed an emergency migration for a DeFi yield protocol I advised. The cascade was not caused by a single villain. It was caused by leverage nobody could see in real time, because collateral composition was disclosed opaquely and lagged the market. I identified the peg-decoupling logic and the cascading liquidation flaw within hours and coordinated a patch deployment that saved roughly two million dollars in user funds. The lesson was never "leverage is bad." The lesson was that unverifiable, lagged, self-reported exposure is the structural precondition of every cascade. The disclosure regime is the vulnerability. Fix the disclosure, or the next cascade finds you first.
AI incident reporting has that same structural precondition right now. Exposure is self-reported, lagged, and unverifiable. The only open question is what triggers the cascade — and whether we will have built the audit trail before it starts or after.
Takeaway
Watch three things, in sequence. One: whether either lab publishes a real incident taxonomy with severity bands and outcome codes — a schema is the minimum viable form of accountability. Two: whether an independent party gains cryptographic access to verify the count against a signed commitment, because a number you cannot verify is a number you cannot govern. Three: whether the disclosure mechanism becomes a shared standard or stays a branding exercise, because the difference between those outcomes decides whether this industry builds accountability or builds a narrative.
The number will not save us. Only the receipt will. Audit first, invest later — and when a lab will not produce the receipt, assume the record does not exist.