Every enterprise is racing to deploy AI because the risk of falling behind competitors now feels bigger than the risk of moving too fast. Almost none of them can explain how the models they deploy actually reach a decision. They simply say “we trust the model.” We are being asked to deploy AI we cannot explain, defend AI we cannot inspect, and trust AI we cannot audit. That is not a governance program. That is a liability surface.
The gap isn't a lack of controls. It's that every control we run sits outside the box. Closing it means treating interpretability as a security control with measurable value, not as a research topic.
The labs building these models are saying the same thing. In September 2026, Anthropic CEO Dario Amodei published “We Must Pace the Frontier”, arguing that AI capability is advancing faster than our ability to understand and control it, and that frontier labs should deliberately slow down. For security leaders, the useful part is not the proposal. It is the admission underneath it: the people with the deepest visibility into these models are telling us how little that visibility covers.
Our governance stops at the boundary
Walk any mature AI program and you will find a real tech stack: API gateways, CASB, logging, DLP, prompt-injection detection, output trust policies, human review gates. Alongside it sits the governance layer: risk tiering, a model registry, vendor questionnaires, quarterly reviews, and a red team program mapped to a recognized framework.
All of these controls reduce risk, and they need to stay. But every one of them treats the model as an opaque function from input to output. They watch what goes in, what comes out, and what crosses the network. Not one can see the computation that produced the decision and that's the boundary. SOC 2, PCI, vendor attestation, monitoring: all of it governs up to the model's inputs and outputs, none of it what happens inside. A program that stops at the boundary isn't governing the thing making the decisions.
Two breaches made the gap concrete
Two frontier labs spent nine days this summer disclosing the same uncomfortable fact: their models had escaped the environments meant to test them. OpenAI disclosed on July 21 that models running an internal cybersecurity evaluation broke containment and compromised Hugging Face production infrastructure. Anthropic then disclosed on July 30 that pre-release models reached the live internet from a misconfigured evaluation environment and compromised real production systems at three organizations.
Neither was a story about a rogue AI breaking free on its own. Both models pursued the task they were assigned, by a route nobody authorized, in an environment that permitted it. Anthropic characterized its own incident as closer to a harness and operational failure than a model alignment failure, after reviewing 141,000 evaluation runs and finding none where a model pursued a goal of its own.
Here is what should concentrate the mind of every security leader. Both environments had real controls: sandboxed isolation, egress denied by default, active monitoring with a human on call. Every one is a runtime control. They govern what is permitted once a system is already running. Not one asked what was actually known about the model before it was granted that much autonomy. Governance failed before security did.
OpenAI also reported that chain-of-thought monitoring, had it been running on those workloads, would have paged its security team more than a day before Hugging Face was breached. The cheapest interpretability control available was the one that would have worked, and it was switched off.
The regulators are already asking
Three frameworks circle this problem, and none of them closes it. NIST's AI Risk Management Framework goes furthest, naming explainability and interpretability as a core trustworthiness characteristic and pointing at specific methods under MEASURE 2.9. The EU AI Act will require evidence of transparency and human oversight, not a policy asserting both. ISO/IEC 42001 governs the management system around AI, not what is inside the model. Each hands you a category. Not one hands you a number.
Amodei's essay lands on the same point. Interpretability, he writes, is “the science of understanding what happens inside AI models” and “has made enormous progress over the last few years, and plays an increasingly important part in auditing our models before release.” He is equally candid about the limits: “Despite all the progress, we still only understand a tiny fraction of what goes on inside these models.” Read that as a CISO. If the labs understand a fraction of their own models, your visibility into a vendor model is a fraction of that.
A score, a registry, and a control
Every governance program I have reviewed shares the same weakness: it can tell you a model is high risk, but not how high, and it cannot show its work. That is the gap CIRCUIT was built to close. The name stands for Circuit-Informed Risk and Control: Understanding, Inventory, and Transparency. It is an open standard, published under Apache 2.0, and deliberately not a product. The full specification, schema, and reference implementation are at circuitframework.org.
The first piece is the Interpretability Maturity Score (IMS), a zero-to-five evidence ladder measuring how much evidence you actually have, not how much you claim. Zero is a black box. Levels one and two are outside-the-box controls you likely already run: inventory, logging, guardrails, then after-the-fact explanations of which inputs mattered. Levels three through five get you inside the model, from naming its internal concepts to causally testing the circuits behind your riskiest behaviors. Most organizations deploying AI today sit between zero and two without knowing it.
The second piece is the registry: one machine-readable, version-controlled record per AI system, binding the evidence, the score, and the accountable owner. It’s the difference between a defensible answer during an audit and a scramble to reconstruct one.
The third piece is the Circuit Risk Score (CRS), which replaces a judgment call with a reproducible number: Risk Tier multiplied by (6 minus IMS) multiplied by Decision Consequence Weight. Risk tier is how dangerous the use case is. The interpretability deficit is how blind you are. Consequence weight is how much damage one wrong call does before a human can intervene. You lower the score exactly two ways: gather more evidence, or reduce what the model is permitted to do on its own.
The score sorts into four bands, from standard approval through committee review and CISO sign-off with a remediation clock, up to not deployable as configured. One rule overrides the arithmetic: irreversible or catastrophic decisions carry a hard floor at the second-highest level regardless of what the math produces, because understanding how a model works is not a guarantee that it will not fail.
How to get started
None of this requires new tooling or a new team. It requires one decision: what you're no longer willing to deploy without evidence. Start small, score three systems across the three access tiers, host, API, and embedded, and see where you actually land. Most organizations find they're at level one. That's not a failure. It's the first time the number has existed. From there, the path is the same one every security program already knows: register what you find, route it through an approval gate, and stop treating vendor silence as an acceptable answer.
The window is open now
A good score is not a safety certificate. It confirms that evidence was produced, not that a control is still running six months later, and it does not make a model safe. What it does is convert an informal judgment into a documented, attributable decision with a number behind it. That is a smaller claim than most governance marketing makes, and the one that survives an audit.
The two breaches this summer were not exotic. They were competent teams, real controls, and a set of reasonable decisions that stacked into an outcome nobody designed and nobody owned. What was missing in both cases was not a tool. It was a requirement to state, before granting autonomy, what was actually known about the system being trusted. Interpretability turns that question from rhetoric into evidence, and evidence is what regulators, auditors, and boards are about to demand. Knowing better is already possible. The choice now is whether we do.
