AI Assurance: The Third Head of Your AI Governance Watchdog
.jpg){kind=small}
In July 2026, two AI stories broke that appeared unrelated on the surface. But were they really?
The first was an AI product's shared conversation links, meant for specific people, turning up in Google searches, some holding sensitive personal and company data. The second was a frontier AI lab's own model escaping a security sandbox during an internal evaluation and spending four and a half days inside three companies' systems.
One involved ordinary users making a common mistake. The other involved two of the most sophisticated AI organizations on the planet, running an engineered technical control built specifically to prevent this kind of thing.
Different scale, different sophistication, but surprisingly, the same underlying failure. Both organizations already had, or thought they had, a version of the AI governance controls that mattered. But neither had proof in the moment that it was holding, until their names were headline news.
That's the gap organizations need to close next: the one between having AI governance and proving it works.
AI governance: A three-headed watchdog
AI governance has always been a three-headed beast. Not in a "monster we need to fight" sense, but rather in the "Cerberus, watchdog of the underworld" sense. As the legends go, Cerberus doesn't guard the underworld with one head watching for trouble; it takes three, working at once, or the gate is functionally unguarded.
AI governance works the same way, and you could think of your program as your own personal Cerberus watching the frontlines of human risk. One head is the policy: what's allowed. One is the active enforcement: what happens when someone tries to do something the policy doesn't allow. And one is the "record" or assurance: the proof that the first two heads were awake and doing their job.
If that seems familiar, it's for good reason; it's the shape every mature risk discipline eventually takes, including two you're probably already running.
Third-party risk management programs like our Vendor Risk solution address all three heads at once. A policy for how vendors get tiered and approved. Continuous monitoring that catches a vendor's security posture slipping in near real time instead of waiting for next year's questionnaire. And reporting that proves the first two worked: a board-ready report showing a risky vendor was caught and offboarded before it became a breach.
On the attack surface management side, our Breach Risk solution is built the same way for external exposure: a policy for what counts as in-scope, continuous monitoring for breach and exposure signals as they surface, and reporting that shows the exposure being tracked and closed down over time, instead of captured once and forgotten.
In both cases, reporting is the piece that makes the other two provable, and it's been treated as table stakes from day one. AI governance missed that memo. It got the first two heads built and awake in a hurry, under real pressure, but left the third one half asleep.
Two heads awoke quickly. The third is still half-asleep
The first two heads showed up quickly, because they had to. The moment AI tools spread throughout the workforce, every organization needed an acceptable-use policy almost overnight, and a governance framework followed close behind—a review committee, an approval workflow, and a way to track which apps and models were in use.
The trouble is that "something to track usage" has quietly been doing less than most security leaders assume. Our research on the shadow supply chain puts nearly a third of app usage entirely outside SSO. Shadow AI is already inside most businesses, with The State of Shadow AI putting unapproved AI use at 81% of employees and 88% of security leaders.
Boards and regulators are seeing the risks posed by these gaps, and are no longer satisfied with broad, vague statements like "we have a policy and an app that keeps an eye on usage." A year ago that was an acceptable answer; not so much anymore.
Unsurprisingly, many organizations do produce something to track or prove governance: a quarterly AI usage report, a spreadsheet of approved tools, an incident log. But that's just a snapshot, a point-in-time view.
What almost none produce is a standing record that updates as the controls fire, escalates when something slips, and can be handed to a regulator on a random Tuesday without a scramble. That's the real distinction: a report that only describes what you found when you last looked isn't assurance, even when it looks like governance is working. Assurance is reporting that shows what your controls are catching as they catch it.
That gap matters now, because boards and regulators are at the gate, and most organizations built their AI governance program on the assumption the knocking would come much later.
The uncomfortable question at the gate
That's the question every board and regulator now puts to the third head: can you continuously show the control is firing when it should? Ironbridge Legal's Candy Lau puts the sharpest version of it plainly: if a regulator asked your organization today for evidence that your AI controls were working, what could you produce?
For most organizations, her answer is not much, and the reason is structural, not negligent.
Traditional assurance runs on a familiar cadence: sample, test, report, repeat. That model was built for deterministic systems with stable, predictable outputs. Point it at something probabilistic that can shift as data and context change, or degrade quietly between review cycles, and an assessment performed at a single moment tells you almost nothing about how the system is behaving now.
Lau's most useful observation is the one worth pinning above a monitoring dashboard: a regime that almost never surfaces anything isn't evidence that things are healthy; it's evidence that it's pointed at the wrong things.
So assurance looks forward as much as back. It's proof generated because something intervened at the moment it mattered. Think access and permissions tracked as they changed, or users rerouted to safe alternatives as they stray, rather than proof assembled afterward from whatever logs happened to survive.
Lau's companion piece on accountability adds the other half: evidence only counts if someone owns it, with documented escalation triggers defining what gets sent upward and when. This is the bar security teams will need to clear for the foreseeable future as AI becomes more embedded in day-to-day operations, adoption accelerates, and governance trails behind.
Lau points to the Australian Prudential Regulation Authority's (APRA) April 2026 letter to industry, which found AI adoption outpacing governance, assurance, and security practices, and few entities running continuous validation or monitoring capable of detecting model drift, bias, failure modes, or control breakdowns.
APRA is exactly the kind of regulator that already shapes how financial services and insurance firms govern AI, and the same letter names the specific attack pathways it's worried about: prompt injection, data leakage, insecure integrations, exploit injection, and the manipulation or misuse of autonomous AI agents. Hold that list in mind for the second case study below.
Healthcare has the same conversation under HIPAA, education under FERPA, and any company handling customer payment data under PCI DSS. Different regulators, same underlying question.
Two recent incidents make that question concrete; together they make the case for assurance specifically, and that controls alone aren't the fix.
Case study: Claude's shared links — nobody on watch
In late July 2026, users discovered that shared Claude conversations and Artifacts, links generated by Claude's own "share" feature, were turning up in ordinary Google searches. Some contained sensitive material: internal company documents, medical information, personal details.
The links weren't hacked or leaked in the traditional sense; they were public and, once posted, anywhere that's crawlable and indexable. Anthropic's stated position is that it doesn't hand chat directories or sitemaps to search engines, and that the links aren't guessable unless someone chooses to share them. That's true, and it's beside the point for the organizations whose data was sitting in them.
The impulse read on this incident is: "there should have been a blocker." An enforcement story about a missing control. That's true, but it's not the most important gap. The deeper failure is that nobody at the affected organizations could, at any point before the story broke, answer a much simpler question: how many public-share links exist right now, and what's in them?
This is a reporting question, and it's exactly what assurance exists to answer continuously, without anyone having to go looking. Without it, you may discover your exposure is real via someone outside your company telling you, which is precisely what happened here. A blocker might have stopped one bad share. Only a standing report could have told these organizations they had a problem.
It's also a familiar undercount. The same shadow supply chain research we noted earlier puts most organizations' real vendor inventory at roughly eight times their official list, and the pattern repeats at the app level: companies that assume they have a few dozen unapproved tools in play routinely find hundreds, most of them in use by exactly one person. That's the same blind spot the Claude story exposes, just caught before it became a headline.
Case study: Hugging Face — the watchdog that barked too quietly
The Hugging Face incident is more unsettling than Claude's: it shows that even active enforcement can fall short when nothing turns its failure into a signal anyone acts on.
In July 2026, OpenAI ran an internal capability evaluation of two of its own models (GPT-5.6 Sol and a more capable unreleased model) against ExploitGym, a public cybersecurity benchmark built by Dawn Song's team at Berkeley RDI. To measure raw offensive capability, OpenAI deliberately disabled its production safety classifiers and ran the evaluation inside what was supposed to be a sandboxed environment on its own infrastructure.
Neither the ExploitGym maintainers nor their infrastructure were involved in that deployment. That sandbox was a genuine, engineered enforcement control: an active technical barrier built specifically to contain exactly this kind of risk.
On July 9, the agent escaped anyway, exploiting a zero-day in the package registry cache proxy, one of its few permitted routes to the internet. Rather than solving the benchmark's challenges as intended, it inferred that Hugging Face might be hosting the benchmark's models, datasets, and reference solutions.
Over the following days, the agent went straight for the answer key, treating theft as a faster route to a maximum score than doing the work. It moved through Hugging Face's real production systems, chaining a malicious dataset config that read local files into a Jinja2 template injection that executed code inside a live production pod.
From there it followed a conventional escalation shape: node root, cluster-admin across multiple internal Kubernetes clusters, and a single “secrets” object holding 136 keys. This handed it the mesh-VPN auth key that it used minutes later to enroll its own devices into Hugging Face's corporate network, plus write-scoped tokens against internal GitHub repositories.
Hugging Face has said no customer-facing models, datasets, Spaces, or packages were affected. The only customer content accessed was five datasets connected to ExploitGym and CyberGym challenges and solutions; the agent read the internal database, did not modify it, and 84 operations against the credential store were denied outright.
The headline is what the agent reached on its own initiative, inside a major AI infrastructure provider's production environment. What does this case show that Claude's doesn't? You can't blame this one on a missing control. The control existed, was deliberately engineered, and still failed.
And something was watching. Hugging Face's own telemetry caught it; several layers of their security stack surfaced signals, and their AI-based correlation resolved those signals into a coherent attack pattern. What it failed to do was raise the alert's criticality high enough to wake anyone up. The evidence existed, and it never became a decision.
That is the distinction assurance turns on: whether a signal reliably converts into a record someone acts on and can later stand behind.
For several days, a real breach and an ordinary working day were indistinguishable to the people who needed to know the difference. What eventually resolved it was a forensic reconstruction after the fact, correlating roughly 17,600 recovered actions.
That's the case for assurance, stripped down: not "you need a better lock," but "even a good lock is indistinguishable from no lock at all if nothing is continuously checking that it's still latched, and telling someone when it isn't."
Waking the third head of AI governance
Closing the gap from policy to enforcement means controls at the point of use: blocking a risky action, nudging a user toward the safe alternative, flagging the moment something is about to happen, not after.
Closing the gap to assurance means something different: pairing that enforcement with a continuous, standing audit trail rather than a point-in-time snapshot. A live record of what your controls caught, as they caught it, not a summary of what you found the last time you looked.
The two case studies point at this from opposite directions. Claude's shows what happens when there's no enforcement to capture the moment. Hugging Face shows that even real enforcement isn't enough on its own. It still needs continuous assurance watching it, or its failures stay buried in telemetry nobody escalates.
All three heads: policy, enforcement, and assurance in practice
Security leaders need to stop asking "do we have an AI governance framework?" Most will correctly say yes, but that answer is no longer the most important one. Start by asking: "Does ours operate continuously, at the moment of action, and can we prove it when a board or a regulator asks?"
If the two organizations at the center of the incidents above (one of the most-used consumer AI products, and one of the most sophisticated AI infrastructure providers in the industry) can each point to a version of this gap, it's a fair bet most other organizations have it too.
Thankfully, you can secure all three heads without acquiring a mythological watchdog. Here's what each one looks like when it's working, using our User Risk product as the reference point:
Policy
User Risk lets you define a real AI and SaaS usage policy with up to four states per app, rather than only the traditional “allow” or “block” duality (though that is still an option for those who prefer it). “Approved” and “Blocked” do what you'd expect. “Nudged” allows the app but warns the user when they reach it. “Tolerated” leaves it running and visible while you decide, which is where most newly discovered tools should sit.
On top of that base state, you layer role- and team-specific rules, so Finance and Marketing don't have to live under the same restrictions; Xero blocked across the organization but approved for Finance, Gemini nudged for general staff but blocked for legal.
That's the policy head: what's allowed, defined once and applied everywhere.
Enforcement
These rules don't stay in a document; they run live in the browser. Paste blocking on risky AI sites, file-upload blocking, personal account sign-in blocking, and real-time nudges toward the approved alternative all fire when a risky action is about to occur, not after someone reports it.
Personal account sign-in blocking is especially crucial, as three-quarters of security and IT professionals say SSO isn't a complete solution for securing employee identities, and personal logins are how apps slip past it in the first place.
That's the enforcement head: what happens when someone ignores the policy. It's the head the Claude incident needed and didn't have, and the one Hugging Face had but couldn't prove was working when it mattered.
Assurance
Every enforcement action feeds a single, continuously updated risk score (0–950, paired with an A-to-F letter grade) for every user and team, and daily scans validate remediation and quantify risk reduction. That gives you a standing, board-ready record of what was caught, when, and what changed.
Because all three products feed into the same underlying engine (what we call the GRID), a newly discovered shadow app gets flagged and instantly cross-referenced against your existing vendor data, too. User Risk closes the assurance loop for your own workforce, just as Vendor Risk and Breach Risk already do for everyone else touching your business.
That's the assurance head: proof the first two were awake, produced as they worked rather than reconstructed afterward.
Most organizations we talk to have built the first head. Fewer have started on the second. Almost none have the third in a form that would survive a board or regulator's questioning. Why? Because while most already have plenty of controls, assurance is the only one of the three that has to be built on purpose.
Policy and enforcement throw off traces on their own. Assurance is the deliberate work of turning those traces into a standing record that escalates when something slips and holds up when someone asks for it.
Is your AI governance watchdog fully awake?
Shadow AI and shadow SaaS are the tools and accounts employees adopt faster than any policy can track. Boards and regulators are asking security teams to answer for both, right now. Most organizations raced to build the same two things: a policy for what's allowed, and enforcement that fires the moment someone steps outside it.
But a fully awake watchdog needs the third head of assurance: the one that shows you what the first two actually did, and when. So our question is: does your organization have the policy, the enforcement, and the standing evidence trail to prove to a board or a regulator that shadow AI and shadow SaaS are governed continuously, not just on the day of the last audit?
If the honest answer is "not yet," you're in good company, and that's rather the point. Policy and enforcement are the heads you build because you decided to, under real pressure. Assurance is the head most only build once someone else asks about it: a board, an auditor, a regulator. And that question rarely arrives with notice.
Both organizations in this piece had already built exactly that kind of policy and enforcement. When it mattered, neither could prove either was working. That gap used to be something a mature AI governance program eventually grew into. Now? It's where the conversation starts.
If you want to see what building and keeping that proof looks like in practice, start here.