On August 11, Rapid7’s Stephen Fewer published proof-of-concept code for CVE-2026-55040, a JWT authentication bypass in on-premises Microsoft SharePoint Server. Microsoft had shipped the fix a month earlier, on July 14. Researcher Defused clocked the code being used in live attacks the next day. That is not the story. Patches lag exploitation constantly; nobody’s surprised by that anymore. The story is what happened two weeks later, on August 24, when VulnCheck’s Jonathan Peterson dropped a second exploit for a completely different flaw, CVE-2026-63520, and the two chained into full remote code execution on any server that hadn’t closed both.

Two independent bugs, disclosed weeks apart, by two different research teams, became one weapon the moment someone had the patience to connect them. That is the actual thesis here. Your patch inventory tracks CVEs one at a time. Attackers don’t.

What Actually Happened

CVE-2026-55040 breaks JWT token validation badly enough that an attacker with zero credentials can forge a session and act as a SharePoint site user, or a site administrator. No password, no phishing, no prior foothold. CVE-2026-63520, rated CVSS 8.1, lives somewhere entirely different. It sits inside SharePoint’s Business Connectivity Services, the integration layer that talks to external line-of-business systems. VulnCheck traced the root cause to an unsafe .NET type instantiation, exploitable through a deserialization gadget chain built on System.Web.UI.LosFormatter. On its own, that is an obscure finding a patch-management dashboard would rank somewhere below “nice to fix eventually.”

Chain it behind an authentication bypass and it stops being obscure. CVE-2026-55040 gets you in the door. CVE-2026-63520 gets you code execution once you’re inside. Neither vulnerability is remarkable in isolation. The chain is what turns two medium-priority tickets into a full server compromise.

The Pattern You’ve Seen Before, Under Different CVE Numbers

This exact shape, authentication bypass chained into an integration or deserialization flaw for unauthenticated RCE, already burned SharePoint Server once, in 2025, in the campaign researchers called “ToolShell.” Palo Alto Networks’ Unit 42 studied that wave and landed on a sentence every security team should have tattooed somewhere visible, “Patching alone is insufficient to fully evict the threat.” Attackers in that campaign moved laterally after initial access and, in documented cases, stole IIS machine key material on the way through, credentials that outlive both the patch and the removal of whatever web shell got planted.

A year later, different CVE numbers, same platform, same outcome. That is not bad luck. That is what happens when a platform’s authentication layer grants durable, session-based trust instead of checking every request against policy. Forge the session once and you own everything the session can touch, indefinitely, until someone thinks to revoke it.

Why the Math Got Worse This Year

Here’s the part that should worry you more than either CVE number. The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation is now the single most common way attackers get in, present in 31% of breaches, up from 20% the year before. That’s a 55% jump in twelve months. Over the same stretch, the median time to patch went from 32 days to 43 days, and only 26% of vulnerabilities on the CISA Known Exploited Vulnerabilities catalog got fully remediated in 2025, down from 38% the year before.

Sit with that. Exploitation is accelerating. Remediation is getting slower. Those two lines are moving in opposite directions, and the gap between them, not either number alone, is your actual exposure. The one-day weaponization window on CVE-2026-55040 isn’t an outlier. It’s what the DBIR data predicted would start happening more often.

The Architectural Question

The tactical response to all of this is “patch faster.” Patch faster. Also accept that faster patching alone is a losing race against a 55% year-over-year jump in exploitation speed, because the DBIR numbers say so directly. The more durable response is architectural. Stop building systems where authenticating a session once buys an attacker standing, durable access to everything that session can reach.

Kiteworks is one example of a platform built on the opposite premise from the start. Every request for content, human or machine, gets evaluated against policy individually through the Kiteworks Control Plane rather than inheriting trust from a session token, and the platform runs as a single-tenant hardened virtual appliance rather than a general-purpose collaboration surface retrofitted with security controls. That is not a claim that per-request policy enforcement makes any platform immune to every future vulnerability class; no honest vendor claims that. It is a description of which category of attack surface, forge a token once and walk around indefinitely, simply doesn’t exist in that model. Kiteworks’ own 2026 Data Security and Compliance Risk: Annual Forecast Report has tracked this exact tension between platform consolidation and governed, per-request access control as one of the year’s defining data security questions, and the SharePoint chain is a live illustration of why.

Where to Spend the Next Two Weeks

A checklist, because architecture arguments don’t patch servers on their own:

1. Confirm CVE-2026-55040 and CVE-2026-63520 are patched on every on-premises SharePoint Server 2016, 2019, and Subscription Edition instance you run. SharePoint Online was not affected; don’t waste the week chasing the wrong environment.

2. Rotate IIS machine keys and any credentials the server could reach, regardless of patch status. Unit 42 said it about the 2025 campaign and it’s true again now. The patch doesn’t undo what a stolen key already did.

3. Pull authentication and Business Connectivity Services logs for the window between disclosure and patch, and treat any gap in that logging as its own finding, not a footnote.

4. Ask your architecture team, in writing, which of your platforms grant durable session trust versus which check every request against policy. Get an actual list. Most teams have never written it down.

5. Put time-to-patch next to time-to-exploit on the next board slide. The DBIR just told you the gap between them is the number that matters, not either one in isolation.

Two bugs, disclosed weeks apart, by two people who’d never met, became one exploit chain because attackers do the connecting work your patch tracker isn’t built to do.

On a Tuesday in March 2026, a Meta employee posted a technical question to an internal forum. An engineer ran it through an approved internal AI agent to draft an analysis. The agent posted that analysis publicly, on its own, without asking anyone first. According to The Hacker News’s coverage of the incident, the employee then acted on the agent’s advice, and for more than two hours, sensitive company and user data sat exposed to engineers who had no business seeing it. Meta logged it as a Sev 1.

Here is what did not happen. Nobody used an unsanctioned tool. Nobody went around a policy. The agent was approved, deployed, and sanctioned by the same process that governs every other piece of Meta’s internal tooling. That is not the exception to the shadow AI story security teams have been telling for two years. It is the story they have not been telling at all.

The Vocabulary Security Got Wrong

Security has spent two years building a vocabulary around unauthorized AI use. Shadow AI is an employee routing company data through an unapproved chatbot. The fix is visibility and blocking. It is a real problem, and it is the wrong problem for what happened at Meta.

The Hacker News piece, contributed by workflow-automation vendor Tines, draws the distinction the industry needs. Shadow AI is unapproved tool use. What happened at Meta was an employee using an approved tool in a way nobody approved. Call it shady AI if you want a name for it. The tool passed procurement. The tool passed security review. Nobody built a fence around what the tool could do once it was inside the building.

Security teams are already being asked to own this problem. The SANS Institute’s July 2026 AI survey of 536 cybersecurity and IT practitioners found that 76% of security teams now hold a formal governance role for enterprise AI, up from 68% a year earlier. But governance ownership and governance capability are two different assets. You can own a function on an org chart and still lack the technical control to exercise it. That is the gap the Meta incident just exposed in public, one most CISOs are carrying without their boards knowing it.

The Data Says the Agents Are Already Off the Leash

Purpose binding is the technical control that would have stopped Meta’s agent cold, a rule that restricts an AI agent to its authorized task and its authorized data scope, enforced in the infrastructure rather than written into a policy document. Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report, a survey of 459 security and compliance leaders published in July 2026, found that 73% of organizations have no purpose binding deployed on their AI agents. Not weak purpose binding. None.

That absence shows up as a reported incident, not a hypothetical. Among organizations in the same survey running AI in production, 13% reported an AI agent exceeding its authorized scope in the past 12 months, and 19% reported discovering shadow AI usage as a distinct incident type. Neither figure describes Meta by name. Both describe the exact failure mode Meta demonstrated for the entire industry to read about.

The instinct to answer this with a ban is understandable, and it is also over. Cisco’s 2026 Data and Privacy Benchmark Study found that outright organizational bans on generative AI tool usage fell from 28% of organizations in 2025 to 7% in 2026, a 21-point drop in a single year, with no corresponding rise in the technical controls that would need to replace a ban. Organizations are not choosing to govern AI agents more precisely. They are choosing to stop blocking them and have not yet built what comes next.

Why the Math Got Worse

An AI assistant that started as a document summarizer six months ago may now search internal knowledge bases, call business applications, and take actions on an employee’s behalf, all without a second procurement review. The Hacker News piece names this pattern plainly. The tool has not changed from a governance perspective, but what an employee can do with it has, and that expansion has outrun the annual or semiannual review cycle most enterprises apply to approved software.

Speed is the compounding variable, and it cuts in both directions. CrowdStrike’s 2026 Global Threat Report documented AI-enabled lateral movement happening in as little as 27 seconds after initial access. That statistic gets cited constantly as an external-attacker problem. It applies with equal force to an internal AI agent operating inside its own permission set. An agent does not need ninety minutes to decide whether posting an analysis publicly is wise. It decides in the time it takes to generate the next output. A governance model built around quarterly access reviews and annual tool audits is not slow relative to an external adversary. It is slow relative to the tools your own employees already have standing permission to use.

The Architectural Question

None of this is an argument for more training or a longer acceptable use policy. SANS found that 76% of security teams now own AI governance. Nobody has found that 76% can technically enforce it, and training a workforce on a policy the infrastructure does not enforce produces documented awareness of a violation employees remain fully able to commit.

The alternative is building the restriction into the environment where the AI-assisted work happens, so the governed path is also the easiest one to follow. That means purpose binding and role- and attribute-based access controls enforced at the point an AI agent or a human requests sensitive data, not after the fact, backed by an audit trail detailed enough to reconstruct what was accessed, by which identity, and under what authorization. It would not have stopped Meta’s agent from drafting a flawed analysis. It would have stopped that analysis from reaching engineers who had no authorization to see the underlying data, because the posting action itself would have required a permission the agent did not hold. That is a narrower claim than “solves AI risk,” and it is the honest one. Governance built into the access layer controls what data an agent can reach and expose. It does not control whether the agent makes a good decision with the access it is given.

Where Purpose Binding Needs to Live This Quarter

The Meta incident is a preview, not an outlier. Here is what to do with it before your own approved agent produces the next one:

• Inventory every AI agent with write or publish access to internal or external-facing systems, not just the tools with read access to sensitive data. Meta’s agent could publish. That is a different risk than an agent that can only summarize.

• Ask your AI vendors to demonstrate purpose binding live, in the product, rather than describe it in a data sheet. Seventy-three percent of organizations in the Kiteworks 2026 Annual Survey Report have none deployed. Confirm you are not one of them.

• Name a single accountable owner for AI agent governance who is not the same person who approved the underlying tool procurement. Approval and containment are different jobs.

• Confirm you can produce a complete record of what a given AI agent accessed, and what it did with that access, within one business day. Most organizations in the same survey cannot.

• Report the gap to your board as a compliance exposure, in the language of audit and liability, before an examiner or a plaintiff’s attorney asks the question first.

The next Sev 1 will not come from a tool nobody approved. It will come from one everybody already signed off on.

On September 3, 2026, the Pentagon signed Revision 3 of its DFARS class deviation, locking in a suspension of mandatory third-party CMMC assessment through November 2028. Self-attestation now carries the weight of law for two more years. CyberSheath’s 2026 State of the Defense Industrial Base report, an annual survey of 302 US defense contractors fielded that same year, found something that should worry anyone celebrating the extra runway. Contractor confidence in the accuracy of their own compliance scores just hit its lowest recorded level, even as the scores themselves hit a multi-year high.

Read that again. Scores are up. Confidence in them is down.

That is not the story most of the trade press is telling about the Cybersecurity Maturity Model Certification program right now. The story everyone is telling is that the Pentagon suspended Phase 2 assessments again in September, pushed the real deadline out to November 2028, and the defense industrial base can finally exhale. The confidence data says otherwise. What was supposed to catch the gap between what a company claims and what is actually true was never the paperwork itself. It was independent verification, and that is exactly the piece that just got suspended. If anything, the gap got more dangerous, because now almost nobody outside the company is checking it.

What Revision 3 Actually Suspended

DARS Class Deviation 2026-O0025, Revision 3, signed September 3, 2026, writes a new automatic trigger date directly into the DFARS text. November 10, 2028, two years later than the market had built toward. CMMC Level 1 and Level 2 can now be satisfied through self-assessment instead of a C3PAO or government review. Contracting officers are stripping the mandatory assessment requirement out of active solicitations.

What the revision does not touch is DFARS 252.204-7012 or the underlying NIST SP 800-171 control set, all 110 of them, which remain fully in force. A self-attested Conditional CMMC status is valid for 180 days before it must convert to Final status, itself valid for three years. The Defense Contract Management Agency retains full authority to run a Medium or High assessment on any covered system at any time, self-assessed or not, and that result overrides whatever was previously posted. A contractor gets 14 business days to rebut an adverse finding before it becomes the record the government relies on for the next award. None of those clocks paused. Only the independent check on whether a contractor’s own number is true did.

The Confidence Theater Underneath the Numbers

Here’s where it gets uncomfortable. Kiteworks’ State of CMMC 2.0 Preparedness in the DIB report, surveying 273 defense contractors after the suspension took effect, found 96% confident their SPRS score would hold up under scrutiny. Only 29% could produce both a current submission and a platform capable of proving it. Seventy-one percent of a market that says it’s fine cannot show its work.

That is not compliance. That is confidence theater.

That gap is not unique to Kiteworks’ sample. It is the same disconnect CyberSheath found industry-wide. Confidence in score accuracy fell from 89% to 65% in a single year, even as the mean self-reported score climbed to its highest level in the five years CyberSheath has tracked it. Two different surveys, two different samples, the same shape of gap.

Why the Suspension Makes the Math Worse, Not Better

Here’s the whole game: the suspension didn’t lower the risk. It removed the only mechanism that was catching the gap between claim and reality before the government did.

There is a remote legal wrinkle here worth a sentence and nothing more. A Lawfare analysis by Michael McLaughlin and Harvey Rishikof questions whether the Pentagon had the authority to suspend the program this way. It is a long shot, not a plan. The extension just got extended again, and self-attestation carries the full weight of law for two more years with nobody double-checking it either way.

Meanwhile the enforcement side of the ledger is not slowing down to match the market’s mood. The Department of Justice recovered a record $6.8 billion in False Claims Act settlements and judgments in fiscal year 2025, and cybersecurity certification is one of its most active enforcement lanes. A regulator relaxed the check. A prosecutor did not relax the standard.

Stop Waiting for the Audit. Start Building the Evidence.

The tactical response to a paused assessment is to wait for it to resume, or scramble when a court or a new administration reinstates it. That is exactly backward. The contractors who come out ahead over the next two years are the ones treating evidence generation as infrastructure, not as a project that starts when the assessor calls.

That is the architectural shift worth naming. Platforms like Kiteworks, built with single-tenant isolation and FIPS 140-3 validated encryption, produce an audit-ready trail as a byproduct of normal operation, the kind of evidence a contracting officer, a DCMA assessor, or a False Claims Act relator can all be handed without three weeks of scrambling to reconstruct it. That is the difference between a company that can prove its SPRS score and the 71% that currently cannot.

What to fix before the assessors come back:

1. Pull your own SPRS submission this week and check it against what you can actually document, not what you remember attesting to.

2. Map every subcontractor touching controlled unclassified information. DFARS 252.204-7012 flows down through the whole chain, not just the name on the prime contract.

3. Track the 180-day and three-year clocks on any Conditional status personally. Nobody in Washington is tracking them for you anymore.

4. Build toward continuous, automatic evidence generation instead of a spreadsheet somebody updates before an audit that might not come for two years, or might come next month if a court intervenes.

5. Do not wait on a court to settle this. Whoever spends the window building a defensible evidence trail gets a real edge over whoever spends it waiting.

The assessment got suspended. The proof you owe the government did not.

A Tier 2 machining subcontractor spent the second half of July watching two solicitations it had counted on get away. Not because its price moved. Not because its past performance slipped. Because a prime further up the chain wanted proof of Level 2 posture before it would let anyone touch controlled unclassified information, and the subcontractor could not put that proof on the table fast enough. The Department of War suspended third-party CMMC 2.0 assessments on July 13, 2026. To this shop, the suspension changed nothing that mattered.

That is the part the headlines missed. When the assessment machinery paused, a lot of the market read it as a reprieve. The data says the opposite. Buyers did not stop pricing Level 2 into their decisions. They just stopped waiting for a certificate to do it -- and the firms that already carry the requirement in their bones are using the pause to take share from the firms that do not.

We surveyed 273 Defense Industrial Base organizations between July 17 and July 31, 2026, all confirmed to do DoW business under an active CMMC 2.0 requirement -- one of the first clean reads of how the base behaved once the assessments stopped. The market story inside the State of CMMC 2.0 in the DIB report is blunt.

The Suspension Moved the Deadline, Not the Requirement

Start with what buyers are doing, not what the policy says. Fifty-five percent of respondents are now bidding on solicitations they previously would have avoided over Level 2 concerns. Read that twice. A majority of the base is chasing work it used to walk away from, because the enforcement checkpoint everyone was bracing for slipped.

That is not caution. That is a scramble for open ground.

At the same time, 52 percent have withdrawn from a bid, and 38 percent have already lost or been disqualified over Level 2. Those are not the numbers of a market waiting for clarity. This market is already sorting winners from losers on posture, with or without an assessor in the room. The certificate was never what buyers wanted. Confidence in the supplier was, and they are buying it from whoever can demonstrate it today.

The suspension paused an assessment step. It did not pause DFARS 252.204-7012, NIST SP 800-171, the Phase 1 self-assessment, or the SPRS submission. Every one of those obligations still stands, and so does the False Claims Act on the score you attest to. The requirement did not leave the building. It just stopped announcing itself at the door.

The Loss Rate Has a Tier Number On It

Here is the finding that should reorganize how you think about your exposure: the pain is not spread evenly across the base. It concentrates by position.

Tier 2 and deeper subcontractors are losing bids over Level 2 at 55 percent -- nearly double the 31 percent rate primes report. The further you sit from the contracting officer, the more often the requirement costs you the work. That gap is structural. Obligations cascade down the chain; bargaining power, budget, and compliance staff do not cascade with them. The tier that inherits the requirement is the tier least equipped to prove it, and the bid outcomes show exactly that.

The insulation runs the other direction too. Aerospace and Defense Manufacturing -- the segment that has lived inside ITAR and defense contracting rigor for decades -- posts the lowest loss rate in the survey at 16 percent. These firms priced Level 2 into their operations years ago. When the assessment step vanished, their bidding did not change -- their readiness never depended on it.

So the suspension did not create a level field. It exposed the one that was already tilted.

Readiness Runs Along the Same Fault Line

The bid outcomes are not random. They track a readiness gap you can measure.

We scored every respondent on a CMMC Suspension Readiness Index, combining current compliance maturity with governance actions taken since July 13. The full base averages 60.0. Break it out by role and the pattern reappears. Firms that operate as both prime and sub score 64.7. Pure primes come in at 61.6. Tier 1 subs drop to 52.1, and Tier 2-plus subs sit at 52.2 -- a full twelve points under the dual-role firms winning the work.

The organizations losing bids are the same organizations carrying the weakest readiness. Position, readiness, and outcome line up on one axis.

They also know it. Flow-down is the anxiety that gives the pattern away. Concern about cascading Level 2 obligations runs at 86 percent across the base, but it climbs to 92 percent among Tier 1 subcontractors -- the firms staring directly up at requirements their primes will pass down whether the assessments resume or not. They feel it most sharply because they hold the least control over it.

Why Position, Not the Pause, Decides Exposure

The strategic picture is clear. Level 2 is not a future compliance event the base is waiting on. It is a present-tense market filter that buyers are already applying. The World Economic Forum’s Global Cybersecurity Outlook 2026 found 65 percent of large organizations now rank third-party and supply-chain risk as their greatest challenge to cyber resilience, up from 54 percent a year earlier. Primes are not softening their demands during the pause. They are hardening them, because the risk they are managing did not pause either.

That reframes the response. If exposure tracks position in the chain, buying another point tool or filing another self-attestation does not move you. What moves you is demonstrating governed handling of controlled unclassified information on demand -- the audit-ready evidence a prime accepts in place of a certificate that no longer exists. Platforms built on that premise matter here for a structural reason, not a marketing one: a single-tenant system that keeps CUI inside one governed boundary and produces its own audit trail is FedRAMP High In Process and FedRAMP Moderate Authorized, which is the kind of proof a nervous prime will take today. The Kiteworks Control Plane is one example of that architecture. The point is not the product. The point is that proof-on-demand is now a bidding asset, and the firms that have it are converting it into contracts.

What This Means Monday Morning

The suspension bought time. It did not buy relief. Here is where a competent bid team spends the week.

1. Map your loss rate by tier, not in aggregate. If you sit at Tier 2 or deeper, benchmark against the 55 percent loss rate, not the 31 percent prime figure -- and put that tier-specific number in front of your board.

2. Treat every open solicitation as a posture test. With 55 percent of the base now bidding on work they used to avoid, the field you compete against just got more crowded and more prepared. Assume your prime is screening on demonstrable readiness.

3. Build the evidence package a prime can accept without an assessor. A current SPRS submission plus audit-ready handling of CUI is the substitute for the certificate the market is missing.

4. Pressure-test your flow-down before your prime does. Ninety-two percent of Tier 1 subs are already worried about it. If your subcontractors cannot show posture, their gap becomes your disqualification.

The assessors will come back. Fifty-eight percent of the base expects Phase II to return in modified form. But the bids are being decided now, on posture the market can see -- and the firms treating the pause as a finish line are handing share to the firms treating it as a head start.

Read the full analysis in the State of CMMC 2.0 in the DIB report.

On July 13, 2026, the US Department of War suspended third-party assessments under Phase II of CMMC 2.0. From where I sit in the EMEA market, a lot of people read that as a reprieve. It was not. The suspension paused who checks the work. It paused nothing about the work itself.

That gap between what was suspended and what was heard is where European defense suppliers are most exposed, and least aware of it.

Think about the shape of a typical US defense supply chain from this side of the Atlantic. A French avionics software house, a Dutch logistics integrator, an Italian components maker – each one sitting several tiers down, each carrying a CMMC requirement it inherited from a prime it may never speak to directly. A new study of 273 DIB organizations that do business with the DoW and carry an active CMMC 2.0 requirement included 104 European entities. That is 38% of the sample. It is also the weakest posture in the report.

The Numbers Europe Would Rather Not Read

The study scores readiness on a combined index that multiplies current compliance against active governance behavior since the suspension. The full sample lands at 60.0. North America lands at 64.7. Europe lands at 53.9 – an eleven-point gap, the largest regional divergence in the data.

Break that open and it gets sharper. Of the four readiness quadrants, Europe puts 44% of its organizations in the Exposed category, against 31% for the full sample. Only 15% of European entities reach Audit-Ready, against 23% overall. So Europe carries more organizations at the bottom and fewer at the top than any other region measured.

Here is the one that should stop a compliance lead cold. Just 43% of European organizations have a current SPRS submission. In North America that figure is 70%. Across the full sample it is 59%. The self-attested score sitting in the US government’s Supplier Performance Risk System is, for most European suppliers, out of date.

And yet 94% of them remain confident that score would hold up under review.

Flow-Down Doesn’t Care Where You Are Registered

The reason a Rotterdam or Toulouse supplier carries this obligation at all is flow-down. When a US prime accepts a DoW contract with DFARS clause 252.204-7012, that clause travels down every tier of the chain. NIST SP 800-171 controls travel with it. So does the Phase 1 self-assessment. So does the SPRS submission. None of that paused on July 13.

Neither did the enforcement mechanism. The False Claims Act still applies to the self-attested score, and the DOJ’s Civil Cyber-Fraud Initiative is the vehicle for pursuing it. A stale or unsupported score is not a paperwork problem. It is a representation made to the US government, and being registered in Milan rather than Maryland does not change that.

The suppliers themselves feel the pressure. Across the full sample, 86% named flow-down as a concern, rising to 92% among tier-one subcontractors. What worries me is the knowledge gap underneath the confidence. In Europe, 55% of respondents did not know the Phase 1 self-assessment obligation continues during the suspension, above the 48% full-sample figure. You cannot maintain an obligation you believe has been paused.

The Pattern Runs Wider Than CMMC

CMMC did not appear out of nowhere. It exists because third-party risk has become the dominant way defense data gets exposed, and the wider evidence backs that up.

The Verizon 2026 Data Breach Investigations Report found that breaches involving a third party grew 60% year over year, reaching 48% of all breaches analyzed. In Public Administration specifically, a third party was present in 36% of incidents. The World Economic Forum’s Global Cybersecurity Outlook 2026 reports that 65% of large organizations now rank third-party and supply-chain risk as their greatest challenge to cyber resilience, up from 54% a year earlier.

The cost side matches. The IBM Cost of a Data Breach Report 2026 puts supply-chain compromise as the single largest cost-increasing factor, adding $227,250 to the average breach, with regulatory noncompliance close behind at $201,112. CMMC is the DoW’s structural answer to exactly this problem. A European supplier that treats it as a distant US formality has misread the direction of the whole market.

Why Confidence Is the Wrong Instrument

Confidence, in this data, is not tracking readiness. It is decoupled from it.

Look inside Europe by country, where the sample supports it. In France, the largest European cohort at 58 organizations, 43% hold a current SPRS submission while 88% report concern about False Claims Act exposure. That is a workforce that senses the legal risk clearly and has not yet closed the evidence gap underneath it. The Netherlands, at 22 organizations, sits at 50% current submissions and 86% FCA concern. The pattern holds: the worry is real, the paperwork is not caught up.

Across Europe as a whole, 82% report FCA concern and 83% have engaged legal or compliance review since the suspension. Those are healthy instincts. But legal review does not produce a current SPRS score, and it does not generate the audit trail that a review would demand. When the full study asked what would most increase confidence, the top answer was an audit trail at 47%, well ahead of legal review at 11%. The suppliers know what they are missing. Most have not yet built it.

The Architectural Question

If the gap is evidence, then the fix is not another policy memo. It is infrastructure that produces defensible proof of how sensitive data moves and who touched it, generated as a byproduct of normal operations rather than assembled by hand before an assessment.

This is the architectural bar to hold any platform to. Kiteworks, as one example, runs a single-tenant Control Plane that generates audit-ready evidence across the channels regulated data moves through – and the platform is FedRAMP High In Process and FedRAMP Moderate Authorized, which matters when the obligation you inherited originates from the US federal government. The point is not the vendor. The point is that a stale self-attestation and a folder of screenshots is not evidence, and a European supplier defending a flow-down obligation needs the real thing.

What This Means Monday Morning

If you sit inside a US defense supply chain from Europe, this week:

1. Pull your actual SPRS submission date. If it predates your last material system change, it is stale, and 43% of your European peers are in the same position.

2. Confirm in writing that your Phase 1 self-assessment obligation is live. It did not pause on July 13, whatever the suspension headlines suggested.

3. Map every DFARS 252.204-7012 flow-down clause in your active contracts. You cannot maintain an obligation you have not located.

4. Ask one question of your current controls: if the DOJ requested evidence tomorrow, could you produce an audit trail, or only assurances?

5. Separate the legal review from the evidence work. One tells you the risk. Only the other reduces it.

The suspension did not lower the bar for European suppliers. It removed the assessor who was going to tell you where you stood – and left the liability exactly where it was.

Kiteworks has published a European Executive Summary of the full findings for exactly this audience. Read it here.

Marc ten Eikelder is Senior Director Marketing EMEA at Kiteworks.

On August 18, 2026, Microsoft shipped a fix for three vulnerabilities in Copilot Personal that Varonis Threat Labs named CoSnitch, tracked as CVE-2026-24301. A crafted link could make Copilot run an attacker’s prompt the instant the page loaded, no click required beyond opening it, and pull mail, calendar, Google Drive metadata, and chat history out through a webhook that looked, to every network monitor watching, exactly like Copilot summarizing a web page. Varonis found no evidence anyone exploited it. Good.

Now forget the patch. That’s not the story. Here is the story: this is a shadow AI evidence problem, not a Microsoft patch problem, and every enterprise treating it as the second thing is going to get surprised by the first.

What CoSnitch Actually Proved

Varonis got there by meta-hacking Copilot itself, asking it repeatedly why a prompt couldn’t run without a user gesture until the assistant’s own refusals named the bypass: an undocumented autorun=1 parameter, paired with Copilot’s existing q parameter. Pair the two and the prompt executes on load, inside the victim’s authenticated session, with the same reach as anything the victim typed. It kept running even after the tab closed. The Hacker News covered the technical detail in full: mail bodies, calendar attendees and locations, Drive file metadata, entire chat histories, all reachable, all exfiltrated through Copilot’s own built-in URL fetch.

Here’s the part that should bother a CISO more than the exploit chain: Varonis says the exfiltration request was indistinguishable at the network layer from ordinary Copilot summarization traffic. Not disguised. Not obfuscated. Identical. A second, related bug let a summarized web page write attacker instructions into Copilot’s persistent memory, where they survived password resets, session revocation, and device re-enrollment until someone manually found and deleted them. Standard incident response neutralizes a compromised credential. It does nothing to a poisoned memory that isn’t stored in the credential at all.

This Is Not the First Time, and That’s the Pattern

CoSnitch reused the same parameter-to-prompt entry point Varonis exploited months earlier in its Reprompt research. Two weeks before CoSnitch, the same team disclosed RovoBlast, a nearly identical one-click attack against Atlassian’s Rovo assistant. Researcher Håkon Måløy documented a related memory-poisoning path in Microsoft 365 Copilot’s own summarization flow back in June. Johann Rehberger found memory writes and deletions through indirect prompt injection in the same window.

Read that again: four disclosures, three vendors, one shape. URL parameters or summarized content seed a prompt into someone else’s authenticated AI session, and the resulting traffic is architecturally indistinguishable from the tool doing its job. This is not a Copilot problem. It is what happens when every AI assistant ships a URL-fetch capability and nobody outside the vendor is watching what that capability actually does with a user’s standing permissions.

Why the Math Got Worse This Year

None of this would matter much if personal AI accounts stayed personal. They don’t. A July 2026 survey of 500 employed U.S. adults, commissioned by the litigation firm Kolmogorov Law and fielded through Pollfish, found that 38% had entered at least one type of work information into a personal AI account their employer doesn’t control, and 36.8% use AI tools for work at least partly through a personal account. Only 35.8% said their employer had a clear written policy on what could be shared with AI tools at all.

Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report, fielded with 459 security and compliance leaders in Q2 2026, found the enterprise side of the same coin: 65% of organizations discovered employees using unapproved AI tools with organizational data in the past 12 months. Half could not produce a complete AI data access audit record within one business day. Sit with that number. Half.

CoSnitch existed for roughly eight months before it was patched. During that window, an unknown share of the 65% was connecting personal Copilot, or something like it, to mail and files the compliance program had no idea existed outside its walls. Nobody has to prove exploitation happened. The exposure existed whether or not anyone used it, and the audit trail to rule it out doesn’t exist either.

The Architectural Question Nobody Wants to Answer

The tactical response to CoSnitch is patch and move on. That’s necessary and insufficient. The real question is not whether Copilot Personal had a bug. It’s whether your organization can answer, for any AI tool touching regulated data, what was accessed, by what authority, and whether that access is logged somewhere you control rather than somewhere the AI vendor controls.

Access-governance platforms can’t stop a client-side URL-parameter flaw from existing; that’s on the vendor writing the client. What a governance layer sitting in front of the content can do is make the request that follows subject to a policy check and an audit entry that exists independent of the AI vendor’s own logging: per-request authorization instead of standing access, and an audit trail that is evidence-quality by design rather than reconstructed after an incident forces the question. That’s an architectural answer, not a product name. The point is that the answer has to live outside the AI client, because CoSnitch just proved the AI client’s own controls are not something you can audit, patch on your own timeline, or trust to log its own compromise.

Where to Spend the Next Two Weeks

Stop debating whether employees should use personal AI tools. That argument is already lost; 36.8% settled it without asking permission. Start doing the things that turn “we don’t know” into an answer:

1. Inventory which personal AI accounts touch work mail, calendar, or file storage, this week, not next quarter.

2. Write the AI-sharing policy your organization doesn’t have. Kolmogorov Law’s data says two in three of you don’t.

3. Treat every AI assistant, sanctioned or not, as a privileged insider for access review and anomaly detection, not as a productivity tool that happens to read files.

4. Ask your incident response team, specifically, whether their playbook accounts for AI memory as a persistence mechanism distinct from credentials and sessions. Most don’t.

5. Build or buy an audit trail for AI data access that exists independent of whatever the AI vendor logs, because the vendor’s log is the first thing you lose visibility into when the vendor is the thing that got played.

Microsoft closed CoSnitch in eight months and found no victims. The next one won’t announce itself, and the personal AI accounts already connected to your data won’t wait for a CVE number to be dangerous.

When the Department of War suspended CMMC 2.0 Phase II third-party assessments on July 13, 2026, the Defense Industrial Base did not go quiet. It moved. We surveyed 273 DIB organizations between July 17 and 31, all of them confirmed DoW contractors carrying an active CMMC 2.0 requirement, and 98% had taken at least one concrete action within days. Only 2% did nothing.

So the question was never whether the DIB was busy. The question was whether busy meant ready. To answer it, we had to build a number. And the first decision in building that number – multiply or average – determined everything that came after.

Eight Facts, Not Eight Feelings

We built two indices, and we built them out of facts a third party could check, not opinions a respondent could inflate.

The first is the CMMC Compliance Maturity Score, or CCMS: eight binary indicators of where an organization stands on current compliance obligations. Do you have a current SPRS submission or not. Are you on a FedRAMP-authorized platform or not. Each indicator is a yes or a no, gathered across the sample, and the mean landed at 78.2 out of 100.

The second is the Suspension Governance Score, or SGS: eight binary indicators of what an organization has done since July 13 – legal review engaged, audit trail work started, assessment continued voluntarily. Also checkable. Also a yes or a no. Mean of 74.9.

Two numbers in the high 70s. Read them side by side and the instinct is to relax. Both dimensions look healthy. A tidy summary would blend them and report a single readiness figure somewhere in the mid-to-high 70s, and the DIB would look like it had absorbed the shock and kept its footing.

That summary would be a lie of arithmetic.

The Number You Get Depends on the Operator

To combine current compliance with active governance into one readiness index, you have to pick an operator. Add the two and divide, and you get an average. Multiply them, and you get something else entirely.

We chose to multiply. The CMMC Suspension Readiness Index is CCMS times SGS-over-100, computed for each organization and then aggregated. Average the two dimensions and the DIB scores about 77. Multiply them and the mean CSRI is 60.0.

Seventeen points vanish between those two operators. Not because the data changed. Because the honest operator refuses to let one strong dimension paper over a weak one.

Why Multiplication Tells the Truth

An average is generous by design. It treats a shortfall on one dimension as something a surplus on the other can repay. Score 90 on compliance and 60 on governance, and the average hands you 75 – the 90 quietly covering for the 60. That trade is fine when the two things you are blending are interchangeable. Readiness is not that kind of quantity.

Current compliance and active governance are not substitutes. They are both necessary. An organization with an immaculate paper trail that has done nothing since the suspension is not ready. An organization frantically convening legal reviews on top of a stale SPRS submission is not ready either. Readiness requires both to be true at once, and multiplication is the operator that enforces “both.”

Multiply, and a low score on either dimension caps the result. A 90 and a 40 do not average to a comfortable 65; they multiply to 36. Strong compliance cannot mask thin activity. Busy activity cannot mask weak compliance. The ceiling on your readiness is set by your worse dimension, not rescued by your better one – which is exactly how a competent auditor, a contracting officer, or a plaintiff’s counsel under the False Claims Act would read your posture. The math is only doing on paper what enforcement does in practice.

An average measures how good your best excuse sounds. A product measures whether your weakest link holds.

The Quadrant the Average Would Have Hidden

Multiplication does more than lower the headline number. It sorts the population in a way an average cannot.

Set a threshold of seven of eight indicators on each dimension – an index value of 87.5 – and cross the two axes, and the 273 organizations fall into four quadrants. Audit-Ready, strong on both, is 23% (63 organizations). Coasting, compliant but passive since the suspension, is 28% (76). Scrambling, active but not yet compliant, is 18% (49). And Exposed, weak on both, is the largest group at 31% (85 organizations).

The largest single quadrant is the one with nowhere to hide. An average would have folded those 85 organizations into a reassuring middle. The product pulls them out into the open.

One more number from the same cross-tab settles the matter. Only 2% – five organizations out of 273 – score a perfect eight of eight on both dimensions at once. Perfection on one dimension is common. Perfection on both is nearly extinct. Any scoring method that lets a single strong dimension carry the summary would have missed how rare genuine, two-sided readiness is.

Mean 60.0, Median 65.6

Look at the distribution and the shape confirms the choice. The mean CSRI is 60.0. The median is 65.6. When the mean sits below the median, the distribution is left-skewed: a tail of low scorers is dragging the average down while the typical organization sits higher.

That gap between 60.0 and 65.6 is not noise. It is the Exposed quadrant exerting gravity on the whole population. A method built on averages would have reported the central tendency and stopped. Multiplication plus the median tells you where the weight sits – and it sits in the tail, among the organizations least able to back their own attestations.

The metric is only as honest as the evidence under it. Our indicators are checkable at all – SPRS currency, platform authorization, audit-trail completeness – because they are artifacts a system either produces or does not. A single-tenant platform that generates audit-ready evidence, as the Kiteworks Control Plane does for CMMC Level 2 workflows, turns a “somewhat confident” self-attestation into a yes-or-no fact. Governance you cannot show is governance you cannot score.

What This Means Monday Morning

If you are building your own readiness metric – for CMMC or anything else – carry four rules out of this:

1. Make every input checkable. Score facts a third party could verify, not confidence a respondent self-reports. Eight yes-or-no indicators beat one five-point feeling.

2. Multiply necessary conditions; average only substitutes. If two dimensions must both be true, use a product so a low score on either caps the result. Reserve averaging for things that genuinely trade off.

3. Report the median next to the mean. The gap between them is your skew, and the skew tells you whether a weak tail is hiding inside a comfortable average.

4. Cross your axes before you trust your headline. A single blended number can conceal that your largest population is weak on every dimension at once.

The suspension paused the assessment. It did not pause the obligation, the DFARS clause, or the False Claims Act exposure that rides on a self-attested score. The DIB knows it is busy. The harder question is whether busy is ready, and the only way to answer honestly is to pick the operator that refuses to lie.

Read the full report, State of CMMC 2.0 in the DIB.

On July 13, 2026, the Department of War suspended Phase II third-party assessments under CMMC 2.0. Within days, some defense contractors read that headline as permission to exhale. That reading is a mistake, and a growing share of the Defense Industrial Base has already figured out why.

The suspension removed the assessor. It removed nothing else.

DFARS 252.204-7012 still binds you. NIST SP 800-171 still defines the controls. Phase 1 self-assessment and your SPRS submission are still required, and the score you posted there is still a representation to the federal government. The False Claims Act still reaches that representation, and the Department of Justice’s Civil Cyber-Fraud Initiative is still the mechanism that enforces it. Take the C3PAO out of the room and every one of those obligations stays exactly where it was.

So the question is not whether the pause is real. It is real. The question is what a competent contractor does with the window it opened.

What the pause changed -- and what it didn’t

A new Kiteworks survey of 273 DIB organizations, all confirmed to do business with the DoW and all carrying an active CMMC 2.0 requirement, was fielded July 17 to 31 -- days after the suspension. It is one of the first clean reads of how the base behaved once the assessor walked out.

The base did not stand still. 98% took at least one concrete action after the suspension. Only 2% did nothing.

That reaction makes sense once you separate the audit from the accountability. The assessor was the thing that got paused. The accountability -- the self-attested score, the flow-down clauses, the fraud exposure -- did not move an inch. 84% of respondents told us they are concerned about False Claims Act exposure. 92% engaged legal or compliance review after July 13. Nobody who reads DFARS closely mistook this for a reprieve.

The gap between feeling covered and being covered

Here is where it gets uncomfortable.

96% of respondents are confident their self-attested SPRS score would hold up under review. Read that again, then read what sits underneath it. Of the confident group, 60% have a current SPRS submission. 36% are on a FedRAMP-authorized platform. Just 29% have both.

Fewer than three in ten who feel confident can fully back the feeling.

That is the confidence-evidence gap, and it is the single most dangerous posture in the current environment. A self-attestation you cannot substantiate is not a compliance status. It is an unpriced liability sitting in a federal database, waiting for a whistleblower or a DOJ inquiry to price it for you. The assessor’s absence does not shrink that liability. It just delays the day someone else checks your work.

What the DIB is buying tells you the move

Ignore what contractors say about their confidence. Watch what they are spending money on. Procurement is the honest signal.

89% are using or plan to adopt a FedRAMP-authorized platform within six months. 93% say independent third-party authorization is essential or important to how they select a vendor. And despite the suspension, 96% have engaged a C3PAO -- with 32% continuing a scheduled assessment voluntarily, paying for an audit no rule currently forces them to take.

That is not the behavior of a base that thinks the obligation went away. That is the behavior of a base that understands independent validation is the thing standing between a self-attestation and a defensible one.

The most telling number is about what would raise confidence. Asked what would most increase confidence in their compliance posture, respondents chose an audit trail at 47%, FedRAMP authorization at 36%, and legal review alone at just 11%. Evidence beats paperwork, four to one. The practitioners closest to this problem have already concluded that a memo from counsel does not survive contact with the Civil Cyber-Fraud Initiative. Contemporaneous, tamper-evident records do.

The external data says the same thing from a different angle. The Verizon 2026 Data Breach Investigations Report found breaches with third-party involvement grew 60% year over year, to 48% of all breaches. The IBM Cost of a Data Breach Report 2026 puts the cost of regulatory noncompliance at $201,112 per breach and supply-chain compromise at $227,250 -- the top cost-increasing factor. Your exposure runs through your subcontractors and your evidence, not through your intentions.

The architectural question underneath the checklist

You can generate audit evidence by hand. Screenshots, spreadsheets, quarterly attestations stapled together the week before a review. Every contractor who has tried it knows how that ends: gaps, reconstruction, and a record that looks manufactured because it was.

The alternative is to make evidence a byproduct of how sensitive data moves, so the audit trail writes itself as work happens rather than getting assembled after the fact. That is an architectural choice, not a policy one. Platforms built on single-tenant isolation that support CMMC Level 2 requirements and generate audit-ready evidence -- Kiteworks is one, FedRAMP High In Process and FedRAMP Moderate Authorized -- treat the evidence trail as the point, not an export you scramble to produce. The distinction matters because the thing DOJ asks for is not your confidence. It is your records, dated, complete, and matching what you attested.

What to do before the Reform Task Force reports back

The pause is a window. Windows close. 58% of the base expects Phase II to return in a modified form; only 4% think it disappears. Meanwhile 93% plan to comment on the DoW’s RFI. The people betting this is over are a rounding error. Do not join them.

Here is what a competent contractor does this week:

1. Make your SPRS submission current. If the score in the database predates your last environment change, it is stale, and stale plus attested is the exact fact pattern the False Claims Act was built for. Fix the record before someone else audits it.

2. Generate contemporaneous audit evidence, not reconstructed evidence. Capture how sensitive data moves now, while you can document it in real time. Evidence created after an inquiry starts is worth a fraction of evidence created before one.

3. Get independent validation while it’s voluntary. The 32% continuing their C3PAO engagement are not wasting money. They are buying a defensible position at a moment when the market for assessors is not yet a bottleneck.

4. File a comment on the RFI. The rule is being rewritten right now. The contractors shaping what Phase II looks like when it returns are the ones in the room this month, not the ones reacting to it next year.

The assessor went home. Your name is still on the score. Close the gap between the two while you still control the timing -- because when Phase II returns, you won’t.

Read the full report, State of CMMC 2.0 in the DIB, for the complete data on where the base stands and what separates the audit-ready from the exposed.On July 13, 2026, the Department of War suspended Phase II third-party assessments under CMMC 2.0. Within days, some defense contractors read that headline as permission to exhale. That reading is a mistake, and a growing share of the Defense Industrial Base has already figured out why.

The suspension removed the assessor. It removed nothing else.

DFARS 252.204-7012 still binds you. NIST SP 800-171 still defines the controls. Phase 1 self-assessment and your SPRS submission are still required, and the score you posted there is still a representation to the federal government. The False Claims Act still reaches that representation, and the Department of Justice’s Civil Cyber-Fraud Initiative is still the mechanism that enforces it. Take the C3PAO out of the room and every one of those obligations stays exactly where it was.

So the question is not whether the pause is real. It is real. The question is what a competent contractor does with the window it opened.

What the pause changed -- and what it didn’t

A new Kiteworks survey of 273 DIB organizations, all confirmed to do business with the DoW and all carrying an active CMMC 2.0 requirement, was fielded July 17 to 31 -- days after the suspension. It is one of the first clean reads of how the base behaved once the assessor walked out.

The base did not stand still. 98% took at least one concrete action after the suspension. Only 2% did nothing.

That reaction makes sense once you separate the audit from the accountability. The assessor was the thing that got paused. The accountability -- the self-attested score, the flow-down clauses, the fraud exposure -- did not move an inch. 84% of respondents told us they are concerned about False Claims Act exposure. 92% engaged legal or compliance review after July 13. Nobody who reads DFARS closely mistook this for a reprieve.

The gap between feeling covered and being covered

Here is where it gets uncomfortable.

96% of respondents are confident their self-attested SPRS score would hold up under review. Read that again, then read what sits underneath it. Of the confident group, 60% have a current SPRS submission. 36% are on a FedRAMP-authorized platform. Just 29% have both.

Fewer than three in ten who feel confident can fully back the feeling.

That is the confidence-evidence gap, and it is the single most dangerous posture in the current environment. A self-attestation you cannot substantiate is not a compliance status. It is an unpriced liability sitting in a federal database, waiting for a whistleblower or a DOJ inquiry to price it for you. The assessor’s absence does not shrink that liability. It just delays the day someone else checks your work.

What the DIB is buying tells you the move

Ignore what contractors say about their confidence. Watch what they are spending money on. Procurement is the honest signal.

89% are using or plan to adopt a FedRAMP-authorized platform within six months. 93% say independent third-party authorization is essential or important to how they select a vendor. And despite the suspension, 96% have engaged a C3PAO -- with 32% continuing a scheduled assessment voluntarily, paying for an audit no rule currently forces them to take.

That is not the behavior of a base that thinks the obligation went away. That is the behavior of a base that understands independent validation is the thing standing between a self-attestation and a defensible one.

The most telling number is about what would raise confidence. Asked what would most increase confidence in their compliance posture, respondents chose an audit trail at 47%, FedRAMP authorization at 36%, and legal review alone at just 11%. Evidence beats paperwork, four to one. The practitioners closest to this problem have already concluded that a memo from counsel does not survive contact with the Civil Cyber-Fraud Initiative. Contemporaneous, tamper-evident records do.

The external data says the same thing from a different angle. The Verizon 2026 Data Breach Investigations Report found breaches with third-party involvement grew 60% year over year, to 48% of all breaches. The IBM Cost of a Data Breach Report 2026 puts the cost of regulatory noncompliance at $201,112 per breach and supply-chain compromise at $227,250 -- the top cost-increasing factor. Your exposure runs through your subcontractors and your evidence, not through your intentions.

The architectural question underneath the checklist

You can generate audit evidence by hand. Screenshots, spreadsheets, quarterly attestations stapled together the week before a review. Every contractor who has tried it knows how that ends: gaps, reconstruction, and a record that looks manufactured because it was.

The alternative is to make evidence a byproduct of how sensitive data moves, so the audit trail writes itself as work happens rather than getting assembled after the fact. That is an architectural choice, not a policy one. Platforms built on single-tenant isolation that support CMMC Level 2 requirements and generate audit-ready evidence -- Kiteworks is one, FedRAMP High In Process and FedRAMP Moderate Authorized -- treat the evidence trail as the point, not an export you scramble to produce. The distinction matters because the thing DOJ asks for is not your confidence. It is your records, dated, complete, and matching what you attested.

What to do before the Reform Task Force reports back

The pause is a window. Windows close. 58% of the base expects Phase II to return in a modified form; only 4% think it disappears. Meanwhile 93% plan to comment on the DoW’s RFI. The people betting this is over are a rounding error. Do not join them.

Here is what a competent contractor does this week:

1. Make your SPRS submission current. If the score in the database predates your last environment change, it is stale, and stale plus attested is the exact fact pattern the False Claims Act was built for. Fix the record before someone else audits it.

2. Generate contemporaneous audit evidence, not reconstructed evidence. Capture how sensitive data moves now, while you can document it in real time. Evidence created after an inquiry starts is worth a fraction of evidence created before one.

3. Get independent validation while it’s voluntary. The 32% continuing their C3PAO engagement are not wasting money. They are buying a defensible position at a moment when the market for assessors is not yet a bottleneck.

4. File a comment on the RFI. The rule is being rewritten right now. The contractors shaping what Phase II looks like when it returns are the ones in the room this month, not the ones reacting to it next year.

The assessor went home. Your name is still on the score. Close the gap between the two while you still control the timing -- because when Phase II returns, you won’t.

Read the full report, State of CMMC 2.0 in the DIB, for the complete data on where the base stands and what separates the audit-ready from the exposed.

Picture a Tuesday morning that plays out on laptops everywhere: a developer opens a terminal, types claude, and hands an AI coding agent the keys to a Git repository. The agent reads the codebase, writes a patch, runs the test suite. It also, without anyone deciding it, has read access to the SSH key at ~/.ssh/id_ed25519, the AWS credentials in ~/.aws/credentials, and every other file the developer has touched in a decade of accumulated home-directory sprawl.

That is not a hypothetical. It is how every terminal-based coding agent runs today, by default, on nearly every laptop in nearly every engineering org. On August 17, 2026, Help Net Security profiled a tool built specifically to close that gap: Hazmat, an open-source project that wraps Claude Code, Codex, OpenCode, Cursor Agent, and other harnesses inside a separate operating-system user account.

Here’s the whole game: an agent launched the ordinary way runs as you. Hazmat’s own framing of the problem, quoted directly, is blunt about what that means: “An agent launched the ordinary way runs as you, which means it can read anything you can read. That includes SSH keys, cloud credentials, and the pile of configuration in your home directory that has accumulated over years.” Contain the account, not just the agent, and the credential-harvesting problem disappears at the OS layer. That’s the pitch. It is a good one. It is also not the whole problem, and the source article, to its credit, does not pretend otherwise.

What Hazmat Actually Does

Hazmat gives the agent its own home directory and shares only the project directory the operator points it at. On macOS, the tool backs up the project, builds a per-session sandbox policy, switches to the dedicated agent account, and starts the harness with a firewall rule already in force. Linux runs natively. An Apple container-tooling backend sits behind an experimental flag.

Before any of that happens, one command prints the session’s terms in plain language: the directory the agent can write to, the paths it can only read, whether it can reach the network or any services, and whether a backup runs first. Most containment tools ask you to trust the sandbox. Hazmat shows you the contract before you sign it.

The demo is simple: a script writes a file into a throwaway project while a private key sitting in the real home directory comes back unreadable. About 5.5 percent of the codebase is a formal TLA+ specification, a mathematically checkable model of how the containment boundary should behave. That is a real engineering signal, and also a narrow one. What got verified is the model on paper. The Go binary you actually install is separate work, with its own bugs, and the project’s own documentation says so.

The Pattern: Every Identity Now Has 108 Roommates

Hazmat is solving a version of a problem the rest of enterprise security is only starting to name. Palo Alto Networks’ 2026 Identity Security Landscape Report, a survey of more than 2,900 security decision-makers, found that machine identities, including AI agents, now outnumber human identities 109 to 1. Ninety-six percent of respondents said human identities already carry access far beyond what their roles require. Layer a coding agent that inherits the full read scope of whoever launched it on top of that ratio, and the exposure compounds. It doesn’t average out. It multiplies.

Accountability hasn’t caught up with deployment speed. Gravitee’s State of AI Agent Security Report 2026, a survey of 750 senior technology leaders across the UK and US updated in April 2026, found that 85 percent of organizations have no formal accountability structure for AI agent behavior, and only 7.2 percent have a named individual accountable for what an agent does. Read that again. Seven percent. The agent fleet is doubling every few months. The org chart for who owns it is not.

Why the Math Got Worse

None of this is new in kind. What’s new is scale and default trust. Coding agents in 2026 run longer, touch more of the filesystem, and get invoked with fewer human approvals per action than the chat-based assistants of two years ago. Hazmat’s own design notes make the point plainly: approval prompts are a workflow control, not an authority boundary. If a process can read your secrets, a bad instruction, a poisoned dependency, or a prompt-injected repository can use that authority just as easily as you can.

That caveat matters for how you read what follows. Hazmat contains what the agent’s operating-system process can reach. It says nothing about the content the payload was hunting for in the first place, because on most laptops that content is a file on disk. In an enterprise, it’s rarely a file. It’s a record in a content repository, a document management system, an MFT server, a CRM export sitting behind a login the agent was handed to do its job.

The Architectural Question

That’s the boundary Hazmat cannot see past, and it’s the one enterprise content governance has to answer. Kiteworks’ own 2026 Forecast Report, a survey of 225 security, IT, and risk leaders across 10 industries, found that 63 percent of organizations cannot enforce purpose limitations on the AI agents they’ve already put into production, 60 percent cannot terminate a misbehaving agent, and 33 percent have no evidence-quality audit trail at all. Same failure mode as Hazmat’s premise. Different layer.

Kiteworks’ Secure MCP Server is worth naming here, not as the fix, but as the same principle applied one layer up. Kiteworks enforces per-request RBAC and ABAC so an agent’s reach into enterprise content is scoped to what policy permits, not to what the human or system account that invoked it happens to be able to read, and it keeps credentials out of the LLM’s context window so a compromised or drifting agent has nothing to harvest even if it gets that far. The Kiteworks Control Plane governs that access, use, and exchange of sensitive content the same way for a human user and an AI agent under one policy, not as a separate track for machines acting on their own.

Be precise about what that buys you. Hazmat contains the agent’s host environment: the filesystem, the network egress, the credential store on the machine it runs on. Kiteworks governs what the agent may retrieve from the enterprise content repositories it’s allowed to touch. The two solve adjacent problems at different layers of the same stack, and an organization running AI coding agents at scale needs both, not one instead of the other. Neither tool inspects a prompt for an injection payload. That is a different control, and treating either one as if it did is a mistake.

What This Means for You Now

1. Inventory every machine running an AI coding agent with default credentials in scope. Isolate the ~/.ssh and ~/.aws directories first, not last.

2. Pilot OS-level containment, Hazmat or an equivalent, for any agent session running longer than a single approved task.

3. Ask your AI governance owner, by name, what the agent can reach in your content systems, not just on the endpoint. If nobody can answer that, you’ve found your gap.

4. Extend RBAC and ABAC enforcement to agent identities in your content platforms before you extend agent count. Scope precedes scale.

5. Log every credential path in the trust chain, human and agent, and audit both to the same evidentiary standard.

Hazmat is a real answer to a real problem, on one machine, at one layer. The agent still runs as you everywhere else.

Picture a plausible Tuesday morning: an agent in your environment calls a tool through an MCP server to pull a file, update a record, or kick off a workflow. Nobody in that chain checks who is asking, beyond the fact that something asked and the server answered. The scene is illustrative. The underlying gap is not. It’s the literal finding sitting inside entry MCP07 of the OWASP MCP Top 10, and it should bother you more than the last CVE alert you triaged. There’s no incident report attached to it. That’s the point.

Whoever Asks, Gets the Tool Call

Security Boulevard’s coverage, syndicating an Imperva analysis published in August 2026, lines up three OWASP lists against three layers of an AI system. The OWASP Top 10 for LLM Applications (2025) covers the conversation layer: prompt injection, sensitive information disclosure, system prompt leakage, improper output handling, and unbounded consumption make up five of its ten entries. The OWASP Top 10 for Agentic Applications (2026), released in December 2025 with ten ASI-prefixed entries running from agent goal hijack (ASI01) to rogue agents (ASI10), covers the action layer: what happens once a system stops answering and starts doing.

The third list is the one worth stopping on. The OWASP MCP Top 10, still in beta, covers what Imperva’s piece calls the connective tissue: the Model Context Protocol wiring that connects an assistant to the tools and data it acts on. MCP07 addresses insufficient authentication and authorization on tool calls. On the question of who may call a tool, the piece’s framing is blunt: the answer is whoever asks. That’s a missing identity layer for machines, and it now has a project number instead of just a bad feeling.

MCP09 Gave Shadow AI a Number, Not a Cure

Sitting two entries down the same beta list is MCP09: shadow MCP servers, frequently running on default credentials, that nobody in security ever inventoried.

Security Boulevard’s characterization is exact. The shadow AI problem now has an OWASP number.

Scale that against where machine identity actually sits today. Palo Alto Networks’ 2026 Identity Security Landscape report, based on a vendor-sponsored survey of 2,930 cybersecurity decision-makers, found that machine identities now outnumber human identities 109 to 1, up from 82 to 1 a year earlier. Of those 109, 79 are AI agents. Read that as a directional finding from one report, not settled fact. But even directionally, it means every MCP07 gap and every MCP09 shadow server sits underneath a machine-identity population that grew faster than most governance programs did.

63% Can’t Enforce Purpose Limits. That’s the Math That Changed

Here’s why this beta checklist lands differently than it would have a year ago. In the Kiteworks Data Security and Compliance Risk: 2026 Forecast Report, 100% of organizations surveyed have agentic AI on their roadmap and 51% already run agents in production. Yet 63% cannot enforce purpose limitations on those agents, and 60% cannot terminate one that starts misbehaving.

An agent you cannot purpose-bind and cannot kill is precisely the agent MCP07 describes: one that gets a tool call approved because it asked, not because anyone verified it should. And an environment where more than half of organizations already run agents in production, without a full inventory of what’s calling what, is precisely the environment MCP09 describes. The two OWASP entries aren’t describing a future risk. They’re describing the default state of AI programs that scaled adoption ahead of authorization. Call it the ask-and-you-shall-receive default: the tool call goes through because nothing in the chain was built to say no.

The Fix Is Architectural, Not Incident-Driven

Be clear about what this piece is and isn’t. There’s no breach disclosure behind MCP07 or MCP09, no regulator citation, no forensic timeline. The fit here is standards and architecture, not incident response. That distinction matters, and so does a second one: Security Boulevard’s own source article is syndicated Imperva content, and it closes on an Imperva product pitch. That doesn’t make the underlying OWASP mapping wrong. It means the argument should be evaluated against the checklist, not against either vendor’s sales page, including this one.

Patching individual MCP server configs one at a time is the tactical response, and it stops scaling the moment your organization’s MCP footprint matches a 51%-in-production adoption curve. The architectural alternative is a governed access layer that authenticates and scopes every tool call the same way, regardless of which server or which agent is asking, so there’s no server left ungoverned enough to go “shadow.” The Kiteworks Secure MCP Server is one example built on that premise: every file, folder, or record operation an agent requests is evaluated in real time against role-based and attribute-based access policy, credentials never surface inside the model’s context, and the resulting audit trail lands in the same log a human’s activity does.

That last point is the one to hold onto. This isn’t a case of extending governance to agents that were previously left alone while humans stayed supervised. An agent connecting through the MCP server inherits the access of the human or service account that authorized it, evaluated under the same policy engine, not a separate one carved out for machines. Kiteworks’ own framing for this is that regulators regulate data, not the model or agent framework moving it. HIPAA, CMMC, and GDPR don’t ask whether a person or a process touched the record. They ask whether the access was authorized, logged, and defensible. MCP07 and MCP09 are the OWASP-numbered version of that same question, aimed at the one layer, tool-call authorization, most programs haven’t gotten to yet.

What to Do Now

Here’s the whole game: you don’t need an incident to justify fixing this. You need an inventory and an owner.

1. Pull the OWASP MCP Top 10 beta list and score every MCP server you run against it, starting with MCP07 and MCP09.

2. Inventory every MCP server actually running in your environment, not just the ones IT provisioned. If you can’t produce that list today, MCP09 already describes your gap.

3. Ask whoever owns your AI agent program one direct question: when an agent calls a tool, what identity gets checked, and can you produce the log that proves it. “Whoever asks” is not an acceptable answer.

4. Map all three OWASP lists, LLM, Agentic, and MCP, against your AI governance committee’s charter. If nobody owns the connective-tissue layer, name an owner this week.

5. Treat this as an audit-evidence problem, not a threat-hunting problem. The question a regulator or a board member asks isn’t whether you detected an attack. It’s whether you can prove who was authorized to call that tool, and when.

OWASP didn’t find an incident this month. It found the gap between what your agents can already do and what you can prove they were allowed to do. That gap is the whole story, and it was there long before anyone gave it a number.

In late January 2026, TechCrunch reported that Madhu Gottumukkala, the acting director of the U.S. Cybersecurity and Infrastructure Security Agency, had uploaded at least four documents marked “for official use only” to the public version of ChatGPT the previous summer. He had requested permission to use ChatGPT at an agency that blocks it for most employees over data retention concerns. Sensors caught the activity roughly a week after it started. Nobody phished a credential or exploited a CVE. The nation’s top civilian cyber-defense official simply pasted sensitive material into a chat window because it was the fastest way to finish his work.

That is not a hacking story. It is the story Akamai’s new State of the Internet: Enterprise AI Usage Risk Report 2026 is telling. The report, built on data from Akamai’s LayerX platform (Akamai acquired LayerX earlier this year), argues the defining AI risk facing your organization stopped being “who can access AI.” The real exposure now is what a well-meaning employee shares with a tool they are fully authorized to use, one prompt at a time, in pieces too small for any control you own to flag.

The Fragmentation Problem Your DLP Was Never Built to Catch

Legacy DLP assumes sensitive data moves through named channels (an email attachment, a file upload, an SFTP transfer). AI does not move data that way. It moves through prompts, conversational context, code snippets, screenshots, copied text, and generated responses, and Akamai’s data shows how granular that fragmentation gets.

The average enterprise AI conversation contains 5.09 prompts, but the median is 2. The top 5% of conversations run 18 prompts or more. Usage concentrates the same way. The average user holds 36 conversations, the bottom half of users 12 or fewer, and the top 5% at least 144. A small population of power users drives a disproportionate share of activity, shares more sensitive business context per session, and increasingly delegates execution-level work to an AI agent.

None of that trips a single alert. It shows up as hundreds of unremarkable interactions that, stitched together, reconstruct exactly what your data classification policy exists to protect. In a follow-up survey to its own Kiteworks Data Security and Compliance Risk: 2026 Forecast Report, Kiteworks found that among 459 security and compliance leaders, 73% had no purpose-binding controls restricting what data their AI agents can reach, and half could not produce a complete AI data access audit record within one business day. That is not a detection gap. It is an evidence gap, and evidence gaps are what a regulator asks about first.

Half the Traffic Runs Through Accounts Nobody Manages

Fragmentation would be manageable if you at least knew whose data was fragmenting. You mostly do not. Akamai found that 47.11% of enterprise AI conversations run through personal identities rather than corporate-managed accounts, close to a coin flip on whether a given AI interaction sits inside your identity perimeter at all. Worse, 14.4% of conversations initiated from a corporate email address run on a personal freemium subscription instead of an enterprise license, so a corporate-looking login can still feed a vendor’s public training pipeline.

The split sharpens by platform. ChatGPT runs 61.36% personal, Copilot 63.92% personal, Claude 61.09% personal. DeepSeek runs 99.83% personal, essentially unmanaged, just as U.S. officials weigh adding the company to the Commerce Department’s Entity List over concerns it supports Chinese military and intelligence objectives. Purpose-built enterprise offerings look nothing alike. Gemini Enterprise runs 98.15% corporate; Copilot for M365 runs 90.55% corporate. The identity gap isn’t inherent to AI. It’s a function of which product got deployed and enforced.

Verizon’s 2026 Data Breach Investigations Report independently corroborates the shape of the problem. It found 45% of employees are now regular AI users on corporate devices, up from 15% the prior year, and that source code, not PII, is the single most common data type leaving the enterprise for external GenAI tools. The identity gap and the fragmentation gap are the same gap, described from two angles.

Attackers Have Stopped Bothering With the Human

The report’s fifth risk category should worry a CISO most. AI agents now operate inside the enterprise with broad access granted for speed, and attackers increasingly target them directly rather than the person who deployed them.

LayerX researchers demonstrated the shift twice in the past year. In CometJacking, a single malicious link hijacked Perplexity’s Comet browser agent through indirect prompt injection, instructing it to encode Gmail and Calendar contents in Base64 and exfiltrate them to an external server. In CursorJacking, a rogue browser extension disguised as a theme or productivity add-on queried the Cursor coding assistant’s unprotected local database directly, extracting API keys and session tokens with no user interaction. LayerX scored the flaw 8.2 on CVSS.

Neither attack touched the human user’s credentials. Both targeted the agent acting on the employee’s behalf, because that agent already holds the privileged access an attacker wants (email, calendar, active sessions, connected repositories). CrowdStrike’s 2026 Global Threat Report puts a number on the wider trend, an 89% year-over-year increase in operations by AI-enabled adversaries. The lesson isn’t that agents should be walked back. It’s that an agent acting on an employee’s behalf needs the same identity governance, monitoring, and revocation rights you’d demand for the employee.

Governance Must Cover the Agent and the Human, Not Just One

The fix is neither “block AI” nor “trust the vendor’s terms of service,” and both intuitive answers fail. Blocking AI pushes power users toward the personal accounts you can’t see at all, the 47.11% problem restated. Trusting a vendor’s data handling policy does nothing about a rogue extension or a hijacked agent walking in through the front door.

Akamai’s mitigation framework instead calls for treating prompts, uploads, downloads, and copy and paste activity as inspectable content in context, rather than as files run through pattern matching, and for extending identity and audit controls to AI agents as a new class of enterprise identity, governed alongside the humans who deploy them. Kiteworks’ original 2026 Forecast Report had predicted this collision was coming. Every organization surveyed expected agentic AI on its 2026 roadmap; fewer than 40% expected containment controls ready to manage it. The follow-up survey found the gap had widened, not closed.

A handful of vendors are now building toward exactly that architecture, one policy plane governing sensitive content across email, file transfer, web forms, and AI interactions under a single evidence-quality audit trail, whether the party on the other end is a person or an agent acting on their behalf. Kiteworks’ platform, built on a hardened virtual appliance with FIPS 140-3 validated encryption, is one example of a system designed around that premise rather than around detecting AI misuse after the fact.

The Three Questions to Ask Before Your Next Board Update

Get honest answers to these before a regulator, auditor, or board member asks first.

1. Who are your AI power users, and what share of your sensitive data exposure do they account for? App-access lists won’t show you; conversation depth will.

2. Which AI logins on your network are personal or freemium accounts, regardless of what email domain signed up? Treat every one as unmanaged until proven otherwise.

3. Can prompts, uploads, downloads, and copy and paste into AI tools be inspected in real time, the way file transfers already are?

4. Do you have an inventory of every AI agent running in your environment, what it can access, and one control point to revoke that access?

5. If asked for a complete AI data access audit trail tomorrow, could your team produce it inside a business day, not a sprint?

The CISA leak didn’t require a hacker. Neither will the next one.

On May 21, 2026, OpenTelemetry graduated from the Cloud Native Computing Foundation, the observability project with the second-highest project velocity of any CNCF project, trailing only Kubernetes, per the CNCF’s own graduation announcement. That milestone is not the story.

The story is what shipped alongside it. Over the two years leading up to graduation, the project built out generative AI semantic conventions: a standard vocabulary for describing what a model, an agent, or a tool did during a session, as OpenTelemetry’s own account of the milestone describes it. For the first time, agent behavior has a shape that any compliant backend can read the same way. There is no breach in this piece. No CVE, no enforcement action, no incident of any kind. This is a story about infrastructure, and that is exactly why it matters. The infrastructure AI governance depends on is standardizing, and the gaps left inside it are no longer someone else’s implementation detail. They are the whole argument.

What OpenTelemetry Actually Records

The new conventions organize an agent run into three span types, as Kovrr’s analysis of the standard lays out. A root span records the full, multi-turn agent session. Child spans record each individual model interaction, carrying token counts and the reason generation stopped. A separate span type records tool execution, and that third type was extended during 2026 specifically to cover Model Context Protocol calls, giving agent tool use a portable representation instead of a framework-specific log line buried in someone’s vendor console.

That MCP-specific extension is the detail worth sitting with. Before it, what an agent called through MCP, and with what arguments, lived in whatever shape the framework happened to emit. The Model Context Protocol project’s own maintainers had been wrestling with exactly this gap, proposing OpenTelemetry trace support for MCP precisely because agent-side traces and MCP server-side traces were disconnected from each other. Standardizing that span type means the question of what an agent invoked now has one answer instead of a dozen vendor-specific ones. That is a genuine advance. It is also, on its own, a smaller advance than it sounds.

The Governance Deficit This Standard Drops Into

Standardized telemetry did not arrive because the industry had gotten ahead of agentic AI. It arrived because the industry is badly behind. The World Economic Forum’s Global Cybersecurity Outlook 2026 found that 87% of cyber leaders identify AI-related vulnerabilities as the fastest-growing cyber risk they face, according to the WEF’s own report. Kiteworks’ own Kiteworks Data Security and Compliance Risk: 2026 Forecast Report, published in December 2025, predicted that 100% of organizations would carry agentic AI on their roadmap in 2026, with fewer than 40% having deployed containment controls to manage it.

Read that again. Full deployment, minority containment. A standardized way to record what an agent did does not close that gap. It documents it more consistently.

Three Things the Trace Will Never Tell You

Here is where the Kovrr analysis earns its keep, because it does not oversell the standard. It names three absences, and argues each is a deliberate design boundary rather than an oversight the next release will fix.

No verdicts. A span records that a model produced an output. It does not record whether that output was hallucinated, unfaithful, toxic, or a policy violation. Evaluation is a separate discipline, deliberately kept out of the telemetry layer.

No authorization, either. A span carries a service identity and a model provider. It does not carry whether the human on whose behalf an agent acted was actually authorized to touch the specific data the agent reached, and it does not distinguish an agent operating under its own credential from one operating under a delegated one. Knowing a call occurred is not the same as knowing it should have occurred.

And no data sensitivity. Content capture exists for prompts and completions. Nothing in the convention classifies what that content was. Whether a prompt carried regulated health data, financial data, or CUI is a determination applied to the trace afterward, by something else, or by no one at all.

Stop asking whether your organization has AI observability. Here is the question that actually matters: when the trace shows an agent touched a record, can you produce, on demand, who that agent was acting for and whether that person was cleared to see it?

Where the Architecture Has to Pick Up the Slack

None of the three gaps above is a flaw in OpenTelemetry. They are a boundary the standard drew on purpose, and Kovrr’s own framing treats the boundary as correct: a convention that tried to standardize a verdict would have to standardize the policy behind it, and policy differs by organization. That means the second gap, the authorization gap, cannot be solved by waiting for the next OpenTelemetry release. It has to be solved by the architecture the agent and the human both operate inside.

This is not an incident piece, and I am not going to pretend otherwise to manufacture urgency. There was no breach behind this story. What there is instead is a precise architectural fit, and it deserves to be described precisely rather than oversold. The Kiteworks Secure MCP Server enforces per-request attribute-based access control against every AI operation, mirroring the same role-based and attribute-based rules that already govern human users, and logs each action to a tamper-evident audit trail that feeds an organization’s SIEM. That closes the authorization gap specifically: it is a record not just that an agent called a tool, but that the human identity behind the call was evaluated against policy at the moment of the call, alongside every human who touches the same system. Agents and humans sit inside one governance plane, not two. The Secure MCP Server does not hand you an output-quality verdict, and it does not manufacture a data-sensitivity label your own policy hasn’t defined. If your attribute-based access control encodes data classification, that third gap narrows too. If it does not, it stays open, and no vendor closes it for you.

What This Means Now

• Pull the trace from your highest-privilege agent workflow and check whether it names the human identity the agent acted for. If it only names a service account, you have the authorization gap in production right now.

• Ask your platform or observability vendor whether their AI spans already cover the MCP tool-execution extension. If they answer with a roadmap instead of a version number, plan around the gap for the next two quarters.

• Separately track three things your telemetry will never hand you: an output-quality verdict, an authorization decision, and a data-sensitivity label. Assign an owner to each. None of them are the same owner.

• If your agents run under a shared service credential instead of delegated, revocable ones, fix that before you fix your dashboards. A beautifully instrumented trace built on top of an unauthorized access pattern is still an unauthorized access pattern, just a well-documented one.

OpenTelemetry gave AI governance a shared way to describe what happened. It was never going to tell you whether it should have.

Consider a security engineer at a mid-size insurer who reruns the same adversarial prompt suite against a customer-service model that cleared testing five months earlier. Same prompts. Same categories. Same environment -- nobody touched the network, the contract, or the guardrail configuration. Four attempts succeed that failed in March.

That is not a breach. Nobody attacked anything. Kovrr’s August 16 analysis makes the harder point: an AI security assessment doesn’t describe a system, it describes a moment, and the moment closes the day the report gets filed. Here’s the question that actually matters for anyone who has to sign that report: what exactly are you attesting to when you say a system “passed”?

What It Actually Is

Kovrr names three mechanisms, and only one of them resembles anything in a traditional software audit.

The first is non-determinism. A prompt injection attempt blocked on the first try can succeed on the fifth, and a single test run is a sample from a distribution, not a measurement of a fixed state. The OWASP GenAI Security Project’s 2026 Top 10 for LLM Applications, released ten days before Kovrr’s piece, ranks Prompt Injection first again, and for a reason that backs this up directly: the flaw is architectural, instructions and data share one channel, and, as the project leads put it, “the model will be fooled” no matter how much a team spends trying to prevent it.

The second is provider-side drift. The vendor revises the model on its own release schedule, and a guardrail validated in March can weaken in April with no change to your prompt, your configuration, or your code.

The third is retrieval corpus drift. Add one document to a RAG store and you change what the model can say. Add a document containing hidden instructions and you change what it might do -- that’s indirect prompt injection, and it means the model was never the whole system being tested. The corpus is half the surface, and it’s the half that changes weekly.

Read that again: all three failure modes can invalidate a signed-off assessment while nothing in your environment moved. That is not a vendor talking point. It is a structural property of the technology.

The Pattern

This isn’t a niche concern confined to chatbots. It’s what happens when non-human actors multiply faster than the controls built for them.

Palo Alto Networks’ 2026 Identity Security Landscape report found organizations now manage 109 machine identities for every human identity, and AI agents already account for a growing share of that number. Companies expect agent growth of 85% over the next 12 months. Most can explain what an agent is for. Far fewer can say what it’s allowed to touch, when its access gets revoked, or which systems inherit that access by default.

CrowdStrike’s 2026 Global Threat Report supplies the attacker’s side of the same coin. AI-enabled adversaries increased operations 89% year over year in 2025, and 82% of that year’s detections were malware-free -- meaning intrusions rode valid credentials and trusted identity flows instead of exploits. When the access path itself is the weapon, whose credential is doing the acting stops being a compliance footnote.

Why the Math Got Worse

Here’s the compounding factor that makes this different from the last five years of “patch faster, test more often” advice. Organizations are deploying agents faster than they’re deploying the identity controls to tell agents apart from the humans who authorized them.

The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found 100% of surveyed organizations have agentic AI on their roadmap, but only 37% enforce purpose binding on what those agents can do. Sixty-three percent cannot enforce purpose limitations at all. Sixty percent cannot terminate a misbehaving agent. Fifty-five percent cannot isolate an AI system from the rest of the network.

Now overlay Kovrr’s own observation about attribution: “an agent operating with a human’s credentials appears in logs as that human unless machine identity is resolved separately, and agent identity is the prerequisite rather than a refinement.” Put those two data points together and you get a specific, ugly scenario. An agent inherits a service account. It takes an action nobody would authorize a human to take alone. The log says a person did it -- because, as far as the log is concerned, a person did.

The Architectural Question

None of this means the fix is a better prompt-injection filter or a more frequent penetration test. Those address non-determinism and provider drift, and Kovrr is right that they need to run on a schedule, not just before launch. They do not address attribution. A guardrail that catches a bad prompt still can’t tell you, after the fact, whether it was Priya or Priya’s expense-report agent that pulled the file.

This piece of the problem lives at the data-access layer, not the model layer -- and it’s worth being precise about scope, because it’s tempting to oversell it. Resolving machine identity doesn’t make a model’s outputs deterministic. It doesn’t stop a poisoned document from reaching a RAG pipeline. What it does is make sure that when an agent touches a file, the audit trail records the agent, not the human whose session it borrowed.

That’s the specific gap Kiteworks’ Secure MCP Server is built to close: every AI request is authenticated and authorized against attribute-based access controls independently of the human who launched the session, then logged under its own identity in a tamper-evident audit trail. Kiteworks Compliant AI applies the same principle to programmatic workflows -- RAG pipelines, data extraction jobs, agent-to-agent exchanges. Both sit inside the same Kiteworks Control Plane that governs human and agent access under one policy engine, one encryption standard, one audit log. Humans don’t lose oversight because an agent is in the loop. The agent’s actions just stop hiding inside the human’s identity.

There’s no incident behind this argument, and it would be dishonest to pretend otherwise. Nothing in Kovrr’s piece describes a breach. The fit here is architectural: the attribution gap Kovrr names is exactly the non-human-identity problem this category of tooling exists to close. It is not a claim that any specific product would have stopped anything, because nothing here happened.

What This Means Monday Morning

Pull your last three AI vendor security attestations and check whether they name a model version, a test date, and an attempt count. If they just say “passed,” you’re holding a photograph, not a monitoring feed.

Ask your AI vendors how they detect provider-side model revisions, and whether that detection triggers a re-test rather than a release note buried in a changelog.

Audit your service accounts for agent traffic. If you can’t separate “this API key is a scheduled job” from “this API key is an agent acting semi-autonomously,” you have an attribution gap before you have a monitoring gap.

Put machine identity resolution on the same roadmap line as continuous monitoring, not after it. A perfectly monitored system that still logs agents as humans gives you a detailed record of the wrong actor.

When your RAG pipeline gets a new source connected, treat it as a production change and give it the review your code changes get. It is one.

The assessment you signed off on last quarter already expired. The only question left is whether your logs will tell you who acted while you weren’t looking, or just whose name happened to be on the session.

Picture a typical Tuesday morning. Someone on your finance team pastes a client contract into a free chatbot to get a faster summary. Someone in engineering feeds a repo’s worth of source code into an AI coding assistant to debug a release. Someone in HR uploads a spreadsheet of comp data to draft a policy memo. None of them think they did anything wrong. None of them will mention it to you. And none of it shows up on a single security dashboard you own.

That is the scene playing out inside most enterprises right now, and the instinct in security leadership is still to respond with a training module. That instinct is the problem. The 2026 Cost of Insider Risks Global Report puts a number on what happens when you keep treating an architecture failure as a behavior failure: average annual insider risk cost has reached $19.5 million per organization, and shadow AI is now the leading driver of negligent insider incidents -- employees routinely moving confidential documents, source code, and strategy through AI channels nobody approved.

Nineteen and a half million dollars. Read that again. That’s not a training gap. That’s a line item finance doesn’t know it’s carrying.

Here’s the thesis: shadow AI stopped being a policy problem the moment it became a recurring, quantifiable cost. It belongs on the same reporting line as fraud losses and breach remediation -- not buried in a security awareness budget.

What It Actually Is

The 2026 Data Security and Compliance Risk Report found that 65% of organizations discovered employees using unapproved AI tools with organizational data in the past 12 months. Sixteen percent discover it monthly or more. Twenty-eight percent discover it quarterly. This is not a rare lapse. It is a standing operational condition, discovered on a schedule, the way you’d discover a recurring vendor invoice.

And the data moving through those tools is not incidental. Among organizations using employee-facing AI chatbots, 36% route customer and client data through them. 33% route IT credentials and access requests. 31% route employee personal and HR data. 30% route financial data. None of those are categories any organization intends to hand to an AI vendor. They are categories employees hand over anyway, because the tool is faster than the approved workflow -- and because nothing in the environment stops the request.

The Market Reality: Bans Are Gone, Controls Never Arrived

For a while, the default corporate response to this was prohibition. That response is evaporating. Cisco’s 2026 Data and Privacy Benchmark Study found that outright bans on AI tool usage dropped from 28% of organizations in 2025 to 7% in 2026 -- a 21-point decline in a single year. Enterprise AI usage more than doubled over the same period, with 62% of workers now using AI at work.

Here is the part that should bother a CFO more than a CISO: that 21-point drop in bans did not come with a corresponding rise in technical controls to replace them. Organizations removed the barrier. They left the gap open. That is not a governance evolution. That is a governance vacancy, and vacancies compound.

Why the Math Got Worse

Twenty-six percent of organizations experienced sensitive data exposure through an AI tool in the past 12 months, per the same report. Run that against the discovery numbers and a pattern falls out: shadow AI use is nearly universal, exposure incidents are common, and the organizations catching the most of it are the ones with the best detection -- not the worst problem. North America reports the highest frequent shadow AI discovery rate, 24% monthly or more, and the highest overall AI incident rate, 84%. The report is explicit that detection capability, not shadow AI prevalence, drives the regional spread. Regions reporting less shadow AI are not cleaner. They are blinder. A lower discovery rate is not good news. It’s a visibility gap wearing a good-news costume, and it means the true exposure in weaker-detection regions is very likely higher than what shows up in any survey.

That reframes the entire risk conversation. If detection quality is the variable, the $19.5 million figure is not a ceiling. It’s a floor for organizations with above-average visibility, and an underestimate for everyone else.

The Architectural Question

Stop asking how to get employees to behave better. Here is the question that actually matters: where in your stack is sensitive data structurally prevented from leaving through an AI channel nobody approved? Only 28% of organizations have AI-specific data loss prevention deployed -- the control that actually blocks sensitive data from reaching an unapproved AI tool at the point of transmission, rather than documenting the violation after it already happened. Only 27% have purpose binding in place, restricting what an AI system or agent is even permitted to touch. Fewer than half of organizations that discovered shadow AI went on to deploy technical controls to prevent it from recurring. The most common response instead was updated policy guidance -- a behavioral fix bolted onto an architectural hole. Thirty-six percent name workforce training as a top investment priority: the most commonly planned response to a problem that training cannot structurally solve, because the gap it’s meant to close sits in the network, not in the employee’s judgment.

Call it what it is: governance theater. Policies get rewritten. Nothing in the network actually stops the data.

This is where the fix has to be architectural rather than administrative. You cannot train your way past a missing control layer. What closes this gap is a single governing layer that applies consistent, technically enforced policy across every channel where sensitive data can leave the building -- email, file transfer, web forms, APIs, and yes, the AI chatbot someone just opened in another tab -- so “unapproved” becomes a state the system enforces, not a state the handbook describes. A hardened, single-tenant architecture with unified policy enforcement and audit-quality logging turns “we told employees not to” into “the data literally could not leave through that channel.” That governance applies the same way whether a human or an AI agent is the one making the request -- one policy layer, not a separate memo for each. That distinction is the entire difference between a $19.5 million line item and a line item that shrinks every quarter.

What to Do Monday Morning

1. Pull your last four quarters of shadow AI discovery data and price it the way finance would -- as a recurring loss category, not an incident log.

2. Ask your AI governance owner one question: what percentage of sensitive data channels have technical enforcement versus policy language only. If you don’t have an answer, you don’t have a control. You have a memo.

3. Audit whether your organization dropped a usage ban in the last 18 months without replacing it with a technical control. If so, you have a documented, dated governance gap -- useful information for your risk register and uncomfortable information for your board deck.

4. Stop budgeting training as your primary AI data security investment. Budget detection and enforcement instead, and let training support the control layer rather than substitute for it.

5. Put the dollar figure in front of the board before the auditors put it in front of you.

Training doesn’t show up on a balance sheet. A $19.5 million exposure does. Start reporting it like one.

Read the full findings in the 2026 Data Security and Compliance Risk Report.

On March 18, 2024, the SEC fined two investment advisers a combined $400,000 for lying about the AI inside their products. Delphia claimed it used machine learning to analyze client data it never actually collected. Global Predictions called itself the “first regulated AI financial advisor” and was neither regulated in that specific way nor building the AI it advertised. The SEC’s own release is almost bored in its phrasing: false and misleading statements, Section 206 violations, penalties, done.

That is not really a story about two small advisers getting caught puffing. It’s a preview.

A working paper out of Carnegie Mellon’s AI Capstone Program, run with AI-adoption analytics firm Larridin, just put a number on exactly what that gap is worth across the market. The study scored roughly 500 large U.S. public companies on how concretely they describe their AI systems in 10-K filings, then checked that score against what actually happened to their revenue. Here’s the whole game: companies that named specific, deployed AI systems with quantified results grew about 8 percentage points faster, year over year, than companies that talked about AI in the abstract. Holding sector, size, and prior growth momentum constant.

Read that again. Eight points. Not from spending more on AI. Not from hiring more AI engineers. From being specific.

The study that priced specificity

The researchers – Yixiao Li, Siru Tao, Xin Xu, and Hanzhe Hong – built three independent signal sets: Larridin’s own AI Transformation Tracker scores for 562 companies, an LLM-extraction pipeline that scored 478 companies’ 10-K filings on investment intensity, “narrative concreteness,” and risk-disclosure depth, and a hiring-intensity measure built from 30,861 classified job postings across 536 companies. Every non-null disclosure score had to cite a verbatim passage from the filing – no score without a receipt. In an audit, 87 to 90% of those citations checked out against the source text.

Narrative concreteness – deployed, named use cases with measurable outcomes, not “AI-powered” marketing copy – was the only signal that survived every control they threw at it: sector, company size, and pre-existing growth momentum. Coefficient of 0.080, p = 0.009. Everything else in the study washed out, attenuated, or never mattered in the first place.

Every other AI metric washed out

AI investment intensity looked promising until the researchers controlled for company size, at which point it stopped being significant (p = 0.14). The AI-hiring signal, built from real job-posting data, showed no relationship with performance at all – and the researchers admit their hiring snapshots were collected after the financial quarter they were tested against, so it was never a fair predictive test to begin with. Risk-disclosure depth, the closest thing to an “AI policy” signal in the study, had almost no discriminating power because 75% of the companies sampled landed at the identical score. Boilerplate AI-risk language has become exactly that: boilerplate.

This is not an isolated finding. Gartner predicted in June 2025 that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and “agent washing” – chatbots relabeled as agents for the pitch deck. MIT’s Project NANDA went further: its 2025 State of AI in Business report, based on an analysis of 300 public AI deployments plus 52 executive interviews and a survey of 153 business leaders, found that 95% of generative AI pilots produce no measurable P&L impact despite $30 to $40 billion in enterprise investment. Three independent research efforts, three different methodologies, one converging answer: activity is not evidence, and the market – and now the researchers – have started telling activity and evidence apart.

Why the math got worse this year

Here’s where it gets uncomfortable. The CMU-Larridin effect was strongest, not among AI-native software companies where deployment is easy to verify, but inside the 285-company “physical-asset-heavy, late adopter” bucket – manufacturers, retailers, industrials – where AI claims are cheapest to make and hardest to check (n = 214, p = 0.025). That is precisely where most of the enterprise market sits.

And the SEC isn’t finished. AI-washing enforcement that started with two small advisers in 2024 has continued into 2026, and it maps onto the same variable the CMU-Larridin researchers isolated almost exactly: can you show your work? A regulator asking “prove it” and a market pricing “prove it” into your growth rate are the same test, arriving from two directions at once.

The architectural question

Stop asking whether your AI story sounds good. Here is the question that actually matters: if a regulator, an acquirer, or a reporter asked you tomorrow to produce the evidence behind your last AI claim – the system, the data it touched, who authorized that, and what happened – could you produce it by Friday, or would you be reconstructing it from memory and Slack threads?

Most organizations can’t. Kiteworks’ 2026 Data Security and Compliance Risk: Annual Survey Report found that 33% of organizations have no evidence-quality audit trail at all for their AI systems – and those organizations run 20 to 32 points behind on every other AI governance maturity metric measured. Fifty-one percent already have agents running in production. Sixty-three percent of those same organizations cannot enforce a purpose limitation on what that agent is allowed to do. Sixty percent cannot kill a misbehaving agent. The gap is not AI ambition. It’s proof.

This is an architecture problem, not a policy problem. A committee, a written AI policy, and a training deck do not generate evidence – they generate paper. What generates evidence is a system that logs, at the point of access, which identity (human or agent, same category) touched which data, under what authorization, and what it did next, in a format that survives being asked about eighteen months later. That is the design premise behind platforms like Kiteworks, which routes AI and human access to sensitive data through one policy engine and one audit trail rather than a dozen disconnected logs – not because Kiteworks invented the idea of evidence, but because “prove it later” has to be built in at the point data moves, not bolted on after an inquiry lands.

What to do Monday morning

1. Pull your last public AI claim – investor update, press release, sales deck. Does it name a specific system and a specific, quantified result? If not, that’s the same gap the SEC just fined two firms $400,000 over.

2. Ask whoever owns your AI or agent deployments to produce, this week, a log of every access to sensitive data by an AI system in the last 30 days – who or what accessed it, under what authorization. Time how long it takes. That’s your evidence-readiness number.

3. Stop scoring internal AI maturity by spend, vendor count, or headcount. None of the three predicted anything in the CMU-Larridin study. Score it by named use cases with quantified outcomes instead.

4. Compare your AI-risk disclosure language to a competitor’s. If a reasonable reader couldn’t tell them apart, rewrite yours – generic language no longer reads as maturity, it reads as absence.

5. Map one production AI workflow end to end: identity, data, purpose, authorization, action, destination, jurisdiction. If you can’t fill in all seven, you’ve found your actual risk, not the one in your slide deck.

The market has already started pricing the difference between AI you can prove and AI you can only describe. Regulators are just getting started doing the same thing.

That line is not my summary. It is the verdict stated in the 2026 Data Security and Compliance Risk Report about its own predecessor. In December 2025, Kiteworks published a Forecast Report built on 225 respondents and fifteen specific predictions about where AI data governance would stand in 2026. It predicted 100% of organizations would have agentic AI on the roadmap, with fewer than 40% holding any containment control capable of managing it. Five months later, the Annual Survey went back into the field with 459 respondents and measured what actually happened: 80% experienced at least one security incident of any type in the past twelve months.

I’ve read plenty of forecast-versus-reality reports over the years. Almost all of them find the forecast was too gloomy, because forecasts of this kind tend to assume the worst and reality lands somewhere more forgiving. Not this one. That is not a forecast that missed high. That is a forecast that undersold the exposure. Read that again: the report built to warn the industry turned out to be the optimistic version of events.

The verdict nobody at Kiteworks wanted to write

Every one of those fifteen predictions assumed some closing of the gap, because that’s what forecasts of this kind assume: organizations see the problem coming, budgets get allocated, controls get deployed, the number improves by the time anyone checks back. Six months is enough time to fix a checklist item. It is not enough time to fix an architecture. The Annual Survey checked, and almost nothing improved. Several things got measurably worse.

Here’s the whole game: this piece isn’t about a report being wrong. It’s about an industry that heard the warning, agreed with the direction, and still didn’t move fast enough to beat it.

Every line item moved the wrong direction

Look at the specific controls the Forecast flagged as the ones to watch, December against July:

AI kill switches: 60% lacking, then 70% lacking. Behavioral monitoring for AI systems: 60% lacking, then 69% – the detection deficit widened instead of closing, which is the opposite of what a maturing control environment is supposed to produce. Tamper-evident audit trails: 33% lacking in December, 67% lacking by July. Purpose binding – the control that restricts an AI agent to the task and data scope it was actually authorized for – 63% absent, then 74% absent.

One metric didn’t move at all, and that’s the one that should worry you most: 73% of organizations couldn’t produce a complete AI data access audit record within one business day in the Forecast. The Annual Survey found the same 73% unable to do it six months later. Flat. Zero progress on a control that DORA, NIS2, and the EU AI Act already expect to be operational.

Call it what it is: an optimism tax. The industry priced in improvement that never arrived, and now the gap is bigger than the number anyone budgeted against.

The boardroom never showed up

The strongest correlation in the entire Forecast Report was between board-level AI governance engagement and everything else measured: organizations where the board carried a standing AI data governance agenda item scored 26 to 28 points higher on AI maturity than organizations where it didn’t. The Forecast measured 54% of boards with no such agenda item. The Annual Survey measured the same 54%. Unchanged.

That’s a line item on a meeting agenda, not a budget request. Six months passed, and it still didn’t get added.

The gateway problem nobody closed

The Forecast identified centralized AI data gateways as the control that determines everything downstream of it – classification, purpose binding, audit capture, kill switch enforcement, all easier or harder depending on whether AI traffic runs through one governed point or scatters across a dozen ungoverned ones. It found 57% of organizations without one. The Annual Survey confirms the same picture from the other side: only 43% have achieved centralized AI gateway control. Same gap, six months apart, different survey.

Third-party AI vendor risk tells the same story with a different number attached. The Forecast found 89% of organizations had never practiced incident response with an AI vendor partner. The Annual Survey found 27% still haven’t even evaluated or technically verified whether their AI vendors train models on customer data. More than a quarter of organizations are handing sensitive data to AI vendors on trust alone, with no incident response plan behind it if that trust turns out to be misplaced.

And Government, which the Forecast called a generation behind – 90% lacking centralized AI gateways, 76% missing kill switches, 90% missing purpose binding – still posts the lowest maturity scores of any sector six months later. Federal Government and Defense Contractors haven’t moved off the bottom.

Here’s where it gets uncomfortable: none of this is a patching problem. You cannot bolt a kill switch onto an AI pipeline the week before an audit and call the 74% purpose binding gap solved. What the data describes is an architecture problem – AI data access running through as many paths as there are tools, with no single point where policy, logging, and containment get enforced consistently. That’s the premise behind the Kiteworks Control Plane, which I work on: one policy engine, running on single-tenant infrastructure, generating evidence-quality audit trails for every channel sensitive data moves through and every identity that touches it – human or agent, governed the same way, under the same plane. A gateway alone doesn’t fix a 54% board-engagement problem. But you cannot fix the board problem, the purpose-binding problem, and the audit-trail problem separately when they all run through the same ungoverned pipes.

What to do Monday morning

The Forecast told you what to fix in December. Most organizations didn’t. If you’re deciding where to start now:

1. Put AI data governance on the board agenda as a standing item, not a slide in the annual security review. The 26-to-28-point maturity gap tied to this habit hasn’t closed since December, and it costs nothing to fix.

2. Test your kill switch. 23% of organizations with AI in production have never tested theirs. An untested kill switch is a hope, not a control.

3. Get purpose binding in place before you add another AI use case. 74% absent means most of you are stacking capability on top of a control that doesn’t exist yet.

4. Route AI traffic through a centralized gateway before you audit anything else. Fragmented paths are why 67% still lack tamper-evident audit trails.

5. Verify, in writing, whether every AI vendor touching your data trains models on it. 27% of organizations still don’t know the answer to their own question.

Five months ago, we told you where this was headed. Nobody disputed the direction. The industry just didn’t move fast enough to beat it.

Read the full findings in the 2026 Data Security and Compliance Risk Report.

Picture the request. A regulator, an auditor, or a customer’s security team sends a one-line email: produce the complete AI data access audit record for the last quarter, by end of day. Not next sprint. Not “we’ll pull it together for the review.” Today.

Here’s what actually happens next, according to the 2026 Data Security and Compliance Risk Report: 83% of organizations cannot produce that record within one hour. Half cannot produce it within one business day. Ten percent cannot produce it at all – their logging infrastructure isn’t built to reconstruct what an AI system touched, no matter how long you give them.

Read that again. Ten percent of organizations, asked to show what their AI systems accessed, have no answer. Not a slow answer. No answer.

That’s the finding everyone should be arguing about, and almost nobody is. Instead, the industry conversation about AI governance still runs on model risk, bias audits, and responsible-AI charters – worthy topics, wrong emergency. The emergency is that most audit infrastructure was engineered for a world where you had days to respond to a request for evidence. The EU AI Act, ISO/IEC 42001, and DORA were built for a world where you have hours. That gap is not a future risk sitting on a roadmap somewhere. It’s the compliance posture you have right now, today, while you read this.

The One-Hour Test Nobody Passes

Only 17% of organizations can produce a complete AI audit record within one hour from existing dashboards, according to the report. Flip that number over and sit with it: 83% would fail if the request landed this afternoon.

This isn’t a story about organizations lacking a policy. Every company in this survey has an AI governance policy. Every company has an acceptable use document somewhere in a SharePoint folder that nobody has opened since the day it was approved. I have read a stack of these policies over the years. Not one of them generates a log.

The failure here is not documentation. It’s plumbing – whether the systems that actually touch AI data can produce a defensible, timestamped, complete record of what happened, to whom, and when. Fifty percent can’t do it in a day. Ten percent can’t do it at all. The policy document was never the control. It was the alibi.

Compliance Consequences Are Already Here, Not Coming

Sixty-three percent of organizations experienced at least one compliance consequence in the past 12 months, per the report – an audit finding, a required remediation plan, a board escalation, a contractual penalty, or a formal regulatory investigation. That is not a forecast about 2027. That is what already happened to two-thirds of the organizations surveyed, in the twelve months behind us.

And yet 7% of organizations have taken no action whatsoever on AI-specific regulatory requirements. None. Zero controls, zero governance changes, in a year when 63% of their peers got hit with a consequence severe enough to reach a board or a regulator.

The number that should worry a CISO more than either of the ones above: 61% of respondents rank AI-specific regulatory requirements in their top three compliance challenges, and 25% rank it as the single biggest challenge they face – more than any other item on the list, ahead of GDPR, ahead of PCI DSS, ahead of everything. Organizations know this is the hard problem. They rank it first. And they still can’t produce the record when asked.

Why “We Have a Policy” Doesn’t Survive Contact With a Regulator

ISO/IEC 42001 compliance is required for 40% of respondents in this survey. The EU AI Act imposes transparency, logging, and human oversight obligations that are enforceable now for high-risk system categories – not pending, not phased in on some horizon slide, active. DORA’s operational resilience obligations require financial entities to produce audit-quality evidence on short notice, and “short notice” in a regulatory context does not mean next quarter.

Here’s the whole game: an organization that cannot produce an AI data access record within one business day is not compliant with these frameworks’ audit obligations, regardless of what the policy document says. A binder full of governance language does not satisfy an auditor asking for a system-generated, timestamped access record from three weeks ago. Only one of those things is evidence. The other is homework you did to feel better.

And even where records exist, they may not survive scrutiny. Only 33% of organizations have tamper-evident audit trails – the specific evidence type investigators and auditors examine to confirm records haven’t been altered after the fact. The other 67% are exposed on any audit that requires evidence integrity, which is to say, any audit that matters. You can produce a log. Can you prove nobody touched it afterward? Two-thirds of you cannot.

The Architectural Question You’re Not Asking

The instinct here is to solve this the way security teams solve most gaps: add a dashboard, write a script that pulls logs from three systems into a spreadsheet before the auditor arrives. That approach is exactly what produced this problem. Only 40% of organizations apply a consistent evidence approach across all required compliance frameworks, per the report – meaning most are maintaining separate, ad hoc evidence trails for GDPR, the EU AI Act, ISO 27001:2022, and DORA simultaneously, reconciled by hand when someone asks.

That doesn’t scale to an hour-long deadline. It barely scales to a day-long one.

The architectural alternative is a single control plane that governs and logs data access, AI included, at the point of exchange rather than after the fact, across email, managed file transfer, SFTP, web forms, and API traffic alike. Kiteworks’ approach centers on exactly this premise: a hardened, single-tenant architecture that generates evidence-quality, tamper-evident audit trails as a byproduct of how data moves, not as a report someone assembles under deadline pressure. That same policy engine, the same audit trail, and the same evidence standard apply whether the identity accessing the data is a human employee or an AI agent acting on that employee’s behalf. An agent’s access produces the same defensible record a human’s does. Neither operates on the honor system.

That’s the difference between “we can eventually reconstruct what happened” and “here is the record, timestamped and unaltered, right now.” One of those satisfies DORA Article 19. The other satisfies nobody but yourself.

What This Means Monday Morning

1. Run the test yourself before a regulator does. Ask your team to produce a complete AI data access audit record right now, today, and time how long it actually takes.

2. Check whether your audit trails are tamper-evident, not just present. A log that can be edited after the fact is not evidence – it’s a story.

3. Map your evidence approach against every framework in scope simultaneously – ISO 27001:2022, GDPR, EU AI Act, DORA if applicable – and find out if you’re running one consistent evidence model or four incompatible ones stitched together by hand.

4. Assign ownership of AI audit readiness to a specific person with a specific deadline, not to “compliance” as a department.

5. Stop treating the policy document as the control. It never was. The system that produces the record on demand is the control.

The EU AI Act doesn’t care that your policy document is thorough. Neither does DORA. Neither does the auditor who emails you at 9 a.m. asking for the record by noon. The only question that matters is whether you can produce it, and right now, most of you cannot.

Read the full findings in the 2026 Data Security and Compliance Risk Report.

You know the DSMS number by heart even if you’ve never heard the acronym. Eleven controls – encryption, managed file transfer, SIEM integration, kill switches, the usual checklist. Your team has deployed four, maybe five of them. You feel reasonably good about that on a Tuesday. Then the 2026 Data Security and Compliance Risk Report hands you a new metric, the Data Security and Compliance Readiness Index, and your reasonably-good Tuesday gets worse.

Here’s the whole game: DSCRI is not another maturity score to stack on the pile. It’s a multiplication problem. And multiplication problems don’t forgive a zero anywhere in the equation.

What It Actually Is

The formula: DSCRI = DSMS × (AIGMS/100). Your Data Security Maturity Score – built from those 11 binary controls, normalized 0-100 – gets scaled by the fraction of AI Governance Maturity Score capabilities you’ve deployed. AIGMS measures 19 binary AI-specific governance capabilities: purpose binding, behavioral monitoring, AI-specific DLP, audit trail generation. Also normalized 0-100.

The survey mean DSMS is 39. The survey mean AIGMS is 35. Run the multiplication and the mean DSCRI lands at 16.2, with a median of 11.5. Half the organizations in this survey score below 12 out of 100 on organizational AI readiness. That’s not a rounding error in an obscure sub-metric. That’s the headline number a 459-organization sample produced when security maturity and AI governance maturity were forced to answer for each other simultaneously.

Here’s the part that makes the number bite: it’s multiplicative, not additive. An organization with a DSMS of 70 and an AIGMS of 20 doesn’t get credit for the 70. It gets a DSCRI of 14 – lower than an organization running a modest DSMS of 40 paired with an AIGMS of 45, which scores 18. Excellence in one dimension, unmatched in the other, gets discounted almost to nothing. That’s the design. It’s supposed to hurt.

The Market Reality

Only 19 respondents – 4% of the sample – broke the DSCRI midpoint of 50, and doing so required both DSMS and AIGMS to exceed 70 at the same time. Six respondents, barely 1%, cleared 70. The single highest scorer in the entire survey hit 84: a perfect DSMS of 100 paired with an AIGMS of 84, meaning 16 of 19 AI governance capabilities actually deployed, not planned, not budgeted – deployed.

Break it down by DSMS tier and the curve stops being gentle. Tier 1 Nascent organizations average a DSCRI of 2.0. Tier 2 Developing, 10.8. Tier 3 Established, 33.4. Tier 4 Advanced, 65.9. That’s roughly a 33-fold gap between the bottom tier and the top, and it isn’t linear – it compounds, because moving up a security tier only pays off in DSCRI terms if AI governance is climbing alongside it.

And the consequences aren’t theoretical. 74% of organizations in the survey experienced at least one general security incident. Among the 64% that had deployed AI, 64% experienced an AI-specific incident. Combine the two and 80% experienced at least one incident of either kind, with 63% facing a compliance consequence as a result. A DSCRI in the teens is what an incident rate like that looks like when you convert it into a single number.

Why the Math Got Worse

Here’s the part that should bother you more than the raw score does. At the survey mean DSMS of 39, raising AIGMS from 35 to 60 – deploying more of those 19 AI-specific capabilities – adds roughly 10 points to your DSCRI. Raising DSMS from 39 to 55 instead, bolting on four more general security controls while AIGMS sits untouched at 35, adds fewer than 6 points.

Read that again. It inverts the instinct every security budget in this survey seems to be running on. At current baselines, a dollar spent on AI governance returns more composite readiness than a dollar spent on general security controls. Not because general controls don’t matter. Because AI governance is the scarcer resource. You’re maxed out on the returns available from the side of the ledger everyone already knows how to fund. The multiplication is telling you where the marginal dollar actually works.

Most security roadmaps I see are still built almost exclusively around the DSMS side: more encryption, better SIEM tuning, another kill switch. Call it what it is. Governance debt – the AI capabilities the org keeps deferring while the general-security backlog gets funded first. All defensible on its own terms. None of it moves the number that’s actually predicting incident exposure, because the AI governance factor in that equation is sitting at 35 out of 100 and dragging everything above it down with it.

The Architectural Question

This is where the tactical response runs out of road. You cannot patch your way to a higher DSCRI by adding a twelfth control to an 11-control framework. The gap is architectural: most organizations have general-purpose security tooling that was never built to answer AI-specific questions – what a model touched, what an agent was authorized to do with a file, whether an inference request left an evidence-quality trail behind it.

That’s the premise behind the Kiteworks Control Plane – worth naming here, not as the fix, but as one example of what an architecture built for this problem actually looks like. A unified policy engine that governs data access, use, and exchange across email, MFT, SFTP, web forms, and APIs – for humans and AI agents alike, under the same rules, rather than a separate bolt-on for whichever AI tool showed up last quarter – is a different category of investment than a nineteenth binary checkbox. That distinction matters because AI data governance isn’t a feature you toggle on top of existing infrastructure; it’s a design decision, the same way FIPS 140-3 validated encryption is a design decision on the DSMS side. One platform doesn’t solve the equation. An architecture built to answer it does.

What to Do Monday Morning

1. Calculate your own DSMS and AIGMS separately before you calculate anything else. You need both halves of the equation, not a composite guess.

2. Stop routing the next security budget cycle exclusively at DSMS. If your AIGMS is anywhere near the survey mean of 35, that’s where the marginal dollar returns more.

3. Audit your AI-specific governance capabilities against the 19-capability list – purpose binding, behavioral monitoring, AI-specific DLP, audit trail generation. Most organizations in this survey have deployed under 7 of them.

4. Treat any DSMS-only “we hardened our security posture” claim from a vendor or an internal team as half an answer. Ask what it did to the other side of the multiplication.

5. Benchmark against DSMS tier, not just against peer spend. A Tier 3 organization with a stagnant AIGMS is still capped near a DSCRI in the low 30s, no matter how much more it spends inside Tier 3.

You cannot multiply your way past a zero. The organizations budgeting as if you can are the ones producing this report’s median score.

Read the full findings in the 2026 Data Security and Compliance Risk Report.

Picture this: it’s Tuesday morning, and a compliance manager at a mid-tier defense subcontractor is staring at a spreadsheet with 110 rows in it – the NIST SP 800-171 practices a C3PAO assessor will check line by line before the company can bid on its next DoD task order, formalized under the CMMC Program Final Rule at 32 CFR Part 170. Access control. Audit and accountability. Incident response. System and communications protection. Four categories, 110 controls, one outcome if the assessment fails: no CMMC certification, no contract. Not a strongly worded finding. A canceled bid.

That is the enforcement mechanism every other sector in the 2026 Data Security and Compliance Risk Report wishes it had. And it is the sector that scored the worst.

What the Numbers Actually Say

Defense Contractors post a Data Security Maturity Score (DSMS) of 15, the lowest of any of the ten sectors surveyed, more than 16 points below the survey mean of 39, and 28 points below Financial Services at 43.3.

Fifteen. Read that again.

Their AI Governance Maturity Score (AIGMS) is 22.8, also the lowest in the survey, nearly 12 points under the AIGMS mean of 34.7. Multiply the two and you get a Data Security and Compliance Readiness Index (DSCRI) of roughly 3.75 (DSMS 15 times AIGMS 25, divided by 100). That is the lowest composite readiness score of any sector measured.

One caveat, stated plainly because the report states it plainly: the Defense Contractors sample is three respondents. You cannot build an industry benchmark on n=3, and I’m not going to pretend otherwise. But three data points pointing the same direction, in the one sector facing a contractually enforced mandate, is not a number you get to wave off. It’s a flare.

The Company Defense Contractors Keep

Federal Government, the sector with the largest government-adjacent sample and no equivalent contractual teeth, doesn’t do much better. Its DSMS of 22.7 is the lowest among sectors with a meaningful sample size, more than 16 points below the mean. Its AIGMS of 25.4 is the second lowest in the survey. The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report, published in December 2025, called Government “a generation behind”: 90% lacking centralized AI gateways, 76% missing kill switches, 90% missing purpose binding. Six months and 459 respondents later, the Annual Survey confirms the profile hasn’t moved – a stall consistent with the World Economic Forum’s Global Cybersecurity Outlook 2026, which found 87% of cyber leaders identified AI-related vulnerabilities as the fastest-growing cyber risk of 2025.

Here is where the conventional explanation runs out. Federal Government’s weak showing is easy to explain: AI governance there lives in policy memos, not contracts, and policy without enforcement rarely beats a budget cycle. Defense Contractors don’t have that excuse. CMMC 2.0 Level 2 is a flow-down clause in the contract, backed by third-party assessment and tied directly to award eligibility. If any framework in this survey should have forced maturity, it’s this one. It didn’t.

Why a Mandate With Teeth Still Isn’t Enough

The representation analysis makes the failure harder to argue away. Plot every respondent on a DSMS-by-AIGMS grid and you get four quadrants: leaders, two mixed profiles, and laggards. Zero Defense Contractor respondents land in the leadership quadrant. Zero. The sector’s laggard-quadrant representation index sits at 1.27, meaning contractors show up in the bottom-left corner well above their proportional share. Federal Government’s laggard index is worse still at 1.70, the highest of any sector with a meaningful sample, against a leadership index of just 0.25.

Here’s the whole game: a mandate without enforcement teeth fails to move behavior. That’s Federal Government, and it’s exactly what you’d expect from policy memos competing with budget cycles. But a mandate with real enforcement teeth is failing too. That’s Defense Contractors, and it is not what anyone modeling CMMC’s deterrent effect would have predicted.

Both are true. Both at once. And the second one is the finding that should worry you, because it means contractual teeth alone don’t guarantee behavior change – they just change what the failure costs you. Federal Government’s failure shows up as an audit finding or an IG report. A defense contractor’s failure shows up as a lost award. Call it enforcement without adoption – the mandate exists, the penalty is real, and the controls still aren’t there. That is a categorically different kind of exposure, and a DSMS of 15 says the sector has not internalized it yet.

The Architectural Question CMMC Doesn’t Answer

Here’s the part the compliance spreadsheet misses: 110 discrete NIST SP 800-171 practices, assessed individually, tempt organizations into a checklist mentality: prove each control exists in isolation rather than build one governance layer that enforces all of them coherently. Access control, audit and accountability, incident response, and system and communications protection are exactly the categories the DSMS measures across every sector in this survey, and they are the categories that fragment fastest when sensitive data moves across email, MFT, web forms, and a growing list of AI tools with no shared enforcement point.

This is the argument for treating CMMC 2.0 compliance as an architecture decision rather than a documentation exercise. It matters more now than it did two years ago: CrowdStrike’s 2026 Global Threat Report documents AI-enabled adversaries moving laterally in as little as 27 seconds, and Thales’ 2026 Data Threat Report finds only 47% of sensitive cloud-resident data is actually encrypted despite near-universal channel adoption. A checklist assessed once a year cannot keep pace with a threat that moves in seconds, across channels most contractors have never fully inventoried.

The fix isn’t another point solution bolted onto the 110-control checklist. It’s consolidating every channel that carries CUI and FCI – email, MFT, web forms, API traffic – under one policy enforcement layer with continuous, evidence-quality logging, so the audit trail a C3PAO wants already exists instead of getting assembled the week before assessment. Enforce the controls centrally and the checklist becomes a byproduct of the architecture, not the goal of it. That’s the difference between passing an assessment and never having to wonder if you would.

What to Do Monday Morning

If you sit inside a defense contractor, or anywhere in that supply chain, the DSMS of 15 is not someone else’s statistic. It’s a preview of your next assessment if your controls are as fragmented as the sector average suggests.

• Pull your own DSMS-equivalent tally now: how many of the 11 controls this report measures (encryption, DLP enforcement, SIEM integration, kill switches, and the rest) are actually deployed, not just documented.

• Map every channel carrying CUI or FCI – email, file sharing, MFT, forms, API – against a single point of policy enforcement, not seven.

• Ask whether your audit trail exists because a system generates it continuously, or because someone will assemble it manually the week before assessment.

• Treat purpose binding and access logging as contract-preservation controls, not nice-to-haves – they map directly to the access control and audit-and-accountability families a C3PAO will test.

• Stop treating CMMC certification as the finish line. The DSCRI of 3.75 says certification and actual readiness are not the same thing, and only one of them keeps the contract.

A mandate with real enforcement teeth just proved it isn’t self-executing. The gap between “we have a framework” and “we have the architecture that satisfies it” is still yours to close – and in this sector, the bill for not closing it isn’t a finding. It’s the contract.

Read the full findings in the 2026 Data Security and Compliance Risk Report.

On July 16, 2026, delegates from 29 countries gathered in Shanghai to launch the World AI Cooperation Organization, a new China-headquartered body meant to coordinate global AI governance. Indonesia, Brazil, Malaysia, Russia, Pakistan, Kazakhstan, and two dozen other states signed on as founding members. UN Secretary-General António Guterres showed up for the opening. Not one G7 economy did. Neither did the European Union.

That’s not actually the story. The story is what happened inside China’s own regulatory apparatus in the weeks around that launch. Four rule sets and one draft law arrived in a six-week window, and they apply to any multinational with a China subsidiary, a China-based vendor, or a banking relationship touching Chinese financial institutions, regardless of whether that company has ever sold a product inside China’s borders.

Here’s what I keep coming back to: global AI governance stopped converging toward a single standard this year. It’s splitting into competing blocs, and the fastest-moving one just wrote rules that reach past its own border and land on your desk anyway.

What Actually Changed in China This Summer

Start with the mechanics, because they’re more specific than most “AI regulation” coverage suggests. China’s Interim Measures for the Administration of Anthropomorphic AI Interaction Services took effect July 15, 2026, one day before WAICO’s launch. The measures require life-cycle risk assessment, ethics review, content monitoring, and incident-response programs for any AI service designed to simulate humanlike interaction. They also mandate a “minor mode,” guardian consent with spending and usage limits for users under 14, and an outright ban on virtual companion or virtual-relative services for minors, plus a ban on emotionally manipulative design generally. Several major Chinese platforms suspended roleplay and companion features rather than retrofit compliance in time. That’s not a symbolic response to a symbolic rule.

A month earlier, on June 18, China’s National Financial Regulatory Administration had issued its Guidelines on the Safe Development and Application of AI in Banking and Insurance: 32 principles under seven pillars. Banks and insurers now need risk-control-committee approval before deploying AI for high-risk use cases, cannot use personal information as AI training data, and must file any externally sourced AI model with the Cyberspace Administration of China.

Layered on top, the CAC published new Q&A guidance clarifying cross-border transfer mechanics: what a valid “separate consent” disclosure must contain, how the “necessity” test applies to routine transfers like a job candidate’s CV, and what conditions govern renewing an already-approved transfer. On July 29, China issued a draft national Anti-Cyber Violence Law for public comment, prohibiting deepfakes and profiling-based targeting used to harass. Barbara Li of Reed Smith laid out this whole sequence for IAPP’s Asia-Pacific coverage on August 6, 2026. Read together, it looks less like one policy announcement and more like a regulator tightening several fronts at once.

The Bloc Problem

WAICO matters more than a photo-op suggests. Twenty-nine founding member states, a permanent headquarters in Shanghai, a UN Secretary-General in the room. China’s state media covered the launch as a serious institutional milestone, and The Diplomat’s analysis treats it the same way. No G7 economy joined. No EU member joined.

That absence is the tell. AI governance isn’t converging toward one rulebook that the EU AI Act, the U.S. approach, and China’s framework eventually reconcile into. It’s splitting into parallel systems, and a bloc of large economies including Brazil and Indonesia is aligning with Shanghai rather than Brussels or Washington. If your supply chain, banking relationships, or data flows touch any of those 29 countries, you already stand inside more than one jurisdiction’s rulebook. Whether your compliance team has mapped that yet is a separate question.

Why the Math Got Worse

Fragmentation alone would be a headache. What makes 2026 different is that China’s new rules attach concrete, auditable evidence requirements to the fragmentation rather than leaving it as broad principle.

The NFRA banking guidance is the clearest example. “Don’t use personal information to train AI models” and “file externally sourced models with the CAC” aren’t awareness campaigns. They’re things a regulator can demand you prove, on a specific date, with a specific document trail. The CAC’s cross-border Q&A doesn’t loosen the substance of China’s transfer rules either. It removes the ambiguity that used to let companies argue their way through a gray area, which means clearer rules and fewer places to hide a gap.

This isn’t a China-only anxiety. Kiteworks’ Data Security and Compliance Risk: 2026 Forecast Report found 34% of organizations already cite cross-border data transfer mechanisms as a top regulatory priority, and 29% cite cross-border transfers through AI vendors as a top privacy exposure, and that’s before Beijing’s second, diverging rulebook even entered the picture. One genuine relief valve arrives September 1, 2026: companies processing personal data on fewer than 100,000 individuals qualify in China as “small-scale personal information handlers,” with simplified notice, consent, and longer audit cycles. Claiming that exemption still requires knowing your headcount against the threshold, so the classification work happens either way.

The Architectural Question

Kiteworks doesn’t sell into China, so there’s no vendor angle to spin here. The point stands on its own: the exposure created by this summer’s rules doesn’t depend on whether your company has a presence in China. It depends on whether data crosses that border at all, personal information, CVs, financial records, model training sets, through a subsidiary, a vendor contract, or a banking relationship. Company presence is the wrong unit of analysis. The data crossing the line is the right one.

That reframes the response. Chasing each new Chinese regulation with a policy memo doesn’t scale once you’re tracking WAICO-aligned states, EU rules, and U.S. state law at the same time. What scales is governing the data itself: classification that flags what’s in scope, geo-conditioned policy that acts on that classification automatically, and audit evidence proving the policy held. Regulators are increasingly asking for exactly this layer. It’s the same one the 2026 Forecast Report found 33% of organizations still lack in evidence-quality form, a gap tied to measurably lower AI-governance maturity across the board.

Concretely, that looks like an attribute-based data policy engine that conditions on a documented value (geolocation “is” or “is not” China, for instance) and applies a graduated response, block, require approval, tag, or view-only rendering, to send, share, upload, and attach actions across email, file sharing, APIs, SFTP, managed file transfer, and the Secure MCP Server that AI applications use to reach the data. Both the people and the AI agents touching a file sit under that same policy. Neither side goes unmanaged. A separate data sovereignty control that pins a user’s data to their assigned country, in storage and in transit, with built-in location reporting, gives an auditor something to examine besides a policy document. None of that requires operating in China. It requires governing the border the data crosses.

What This Means Monday Morning

• Map every data flow that touches China – subsidiary, vendor contract, banking relationship, even a candidate’s CV headed to a China-based recruiter – before assuming no China office means no exposure.

• Classify what’s moving: personal information versus operational data, training data versus everything else. The NFRA rule turns “was this used to train a model” into a question you need a documented answer to.

• Build a geo-conditioned policy for that corridor specifically, not a blanket block that breaks legitimate business.

• If you bank in China or rely on a China-sourced AI model, confirm your CAC filing status now; that NFRA rule is already in force.

• Before claiming the September 1 small-scale-handler relief, count. The exemption requires the classification work you should be doing anyway.

• Generate the audit evidence before a regulator asks for it, not after.

WAICO’s 29 members and the G7’s absence make a tidy geopolitics story. The rulebook fragmenting underneath it is the one your auditor will actually ask about.

Danielle Barbour writes on data governance and regulatory strategy for Zero Trust Data Exchange.