On July 28, 2026, security specialists at Switzerland’s Federal Office for Information Technology and Telecommunication (BIT) noticed something wrong on their on-premises SharePoint servers. Three days later, BIT confirmed that roughly 200 user and technical accounts had been compromised. Passwords reset, external access blocked -- then the servers came down entirely for a clean reinstall. By any reasonable standard, that’s a fast, competent incident response. No notes.

That’s not the story.

The story is that BIT did almost everything a security team is supposed to do -- detect quickly, contain same-day, patch, reset credentials, bring in outside help -- and still ended up disclosing 200 compromised accounts three weeks after Microsoft shipped the fix. If a well-run federal IT agency gets this outcome from a textbook response, “patch faster” was never going to be the control that saved you.

Two CVEs, One Attack Surface, 200 Accounts

BIT hasn’t confirmed exactly which vulnerability the attackers used, but the timeline points at one of two flaws Microsoft disclosed in its July 2026 Patch Tuesday cycle. CVE-2026-56164 is a missing-authentication flaw in on-premises SharePoint Server that lets an unauthenticated attacker escalate privilege remotely -- no credentials, no user interaction required. CISA added it to the Known Exploited Vulnerabilities catalog with a three-day remediation deadline for federal agencies.

The second candidate, CVE-2026-50522, is worse. It’s a deserialization flaw that gives a remote, unauthenticated attacker code execution on the SharePoint server -- and once inside, the documented objective isn’t data theft. It’s stealing the IIS machine keys that sign authentication tokens. BleepingComputer reported that watchTowr’s honeypot network caught exploitation attempts within hours of a public proof-of-concept going live on July 20. The Swiss agency’s own disclosure lines up with both flaws -- The Record noted BIT acknowledged the intrusion “presumably” exploited vulnerabilities patched that same month.

Two hundred accounts. One Patch Tuesday. Read that again.

This Is the Second Time in a Year

Here’s the part that should bother you more than the Swiss disclosure itself: this exact failure mode already happened in 2025. The “ToolShell” wave -- CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 -- hit on-premises SharePoint Server through the same combination of authentication bypass and deserialization RCE. Palo Alto’s Unit 42 warned at the time that organizations exposing SharePoint Server to the internet should assume compromise, and that patching wouldn’t undo what attackers had already taken.

A year later, the mechanism repeated almost exactly: unauthenticated access, deserialization RCE, machine key theft. CERT-EU’s advisory on the July 2026 cluster put it plainly: “Given the number of recent critical vulnerabilities affecting SharePoint, organizations should reconsider exposing any Microsoft SharePoint Server directly to the internet.” Not “patch faster.” Reconsider the exposure.

This tracks with a broader pattern CrowdStrike documented in its 2026 Global Threat Report: adversaries are systematically targeting internet-facing, under-monitored infrastructure because patch cycles measured in weeks are mismatched against exploitation timelines measured in hours. SharePoint Server, sitting on-premises with a monthly patch cadence, is exactly that kind of target. Twice in twelve months isn’t a vulnerability. It’s a category.

The Patch Closes the Hole. The Keys Don’t Care.

Here’s what gets me about the machine-key detail: “we patched” doesn’t close the loop the way everyone assumes it does. When an attacker exploits a deserialization flaw to grab IIS machine keys, they walk away with the cryptographic material that signs and validates session tokens. As The Record reported, citing CISA’s guidance on the cluster: once stolen, those keys let an attacker forge legitimate-looking requests that a fully patched server will still accept. The patch fixes the door. It does nothing about the copy of the key already sitting in the attacker’s pocket.

Call it the eviction gap -- the space between “vulnerability patched” and “attacker actually gone.” It’s exactly why CISA and CERT-EU are both telling defenders to rotate machine keys and restart IIS rather than trust the patch by itself. BIT is reinstalling its affected servers from scratch instead of relying on a patch-and-rotate cycle. That’s the correct call. It’s also an admission that the patch was never going to be enough on its own.

It also explains why BIT’s language is so carefully hedged: “no indication” data was accessed beyond credentials, “analysis is ongoing.” That caveat isn’t evasive -- it’s honest. Kiteworks’ 2026 Data Security and Compliance Risk Forecast Report found that 61% of organizations are trying to build evidence-quality audit trails on top of fragmented infrastructure, and 33% don’t have one at all. When your proof of what an attacker touched depends on logs scattered across a general-purpose collaboration platform, “we found no evidence” and “we have no evidence to find” start to look the same from the outside.

Patching Fast Isn’t the Architecture Question

None of this means any specific vendor would have stopped this particular attack chain -- that depends on patch cadence, exposure, and configuration on any platform. But the July 2026 SharePoint cluster does surface the actual question every CISO running sensitive data through on-premises collaboration infrastructure should be asking, and it isn’t “how fast can we patch.”

It’s this: is your sensitive-data platform a general-purpose collaboration tool that got extended into data exchange over a decade, or was it built for governed data exchange from the start? On-premises SharePoint Server requires the customer to independently secure the authentication pipeline, manage the deserialization attack surface, and protect the IIS machine key store -- then repeat that exercise every Patch Tuesday. A platform architected around vendor-managed patching, isolated tenancy, and audit trails built to hold up as evidence rather than scattered log files shifts that ongoing burden off the customer’s side of the ledger entirely. That’s an architecture comparison worth having with your own vendors -- not a claim that unpatched CVEs are survivable everywhere else. Bring the comparison to your board before they bring it to you.

What to Do by Next Week

1. Inventory every internet-facing SharePoint Server instance in your environment today. If it’s exposed and unpatched against CVE-2026-56164 or CVE-2026-50522, treat it as compromised until proven otherwise -- not “vulnerable.”

2. Rotate IIS and ASP.NET machine keys and restart IIS on any server that was exposed before patching. Patching alone does not evict an attacker holding stolen keys.

3. Pull your audit logs and ask a hard question: can you produce a defensible timeline of exactly what was accessed, by whom, in the last 90 days -- or are you, like 61% of organizations Kiteworks surveyed, reconstructing it from fragmented logs across systems that were never built to talk to each other?

4. Separate regulated and sensitive workflows from general collaboration infrastructure. Not everything needs to move. The workflows carrying CUI, PHI, or contractual data are the ones that need a platform built for evidentiary-grade governance, not a platform that happens to store files.

5. Brief your board before a regulator or a reporter does it for you. Five CISA KEV entries and a national government disclosure in the same cycle is a board-level question, not a patch-ticket footnote.

BIT did the fast version of everything right and still had to reset 200 accounts and reinstall its servers from scratch. The lesson isn’t that Switzerland was careless. It’s that “patched” and “safe” stopped being the same word the moment machine key theft entered the playbook -- and if your sensitive data still lives on the same kind of platform, that gap is yours too.

Picture the CISO scorecard review at a mid-sized software company on a Tuesday morning. Encryption: deployed. SIEM integration: mostly there. MFT: locked down. The security team walks out of that meeting feeling good, and by the numbers, they should. Now picture the AI governance review two floors down, covering the copilot embedded in the codebase, the customer-facing support agent, and the internal chatbot employees have been pasting client data into since March. That review does not happen. Not because nobody scheduled it. Because almost nobody in Technology has built the muscle to run it.

That is the finding buried in the 2026 Data Security and Compliance Risk Report, based on 459 security, compliance, and technology leaders surveyed in Q2 2026. Technology’s mean Data Security Maturity Score (DSMS) is 40.7 – the second-highest of any sector measured, behind only Financial Services (43.3) and just ahead of Energy & Utilities (43.2) and Manufacturing (43.0). Its AI Governance Maturity Score (AIGMS) is 35.3, tracking almost exactly to the survey mean of 34.7. On paper, an above-average sector with an average governance posture. Read that again, because the paper is lying to you.

The quadrant that names the problem

The report’s DSMS × AIGMS framework sorts organizations into four profiles: Dual Exposure (weak on both), Foundation First (AI governance ahead of security, rare), AI-Ready (both strong, 11% of the survey), and one the report calls “False Confidence” – high DSMS, low AIGMS. Its one-line description of that quadrant: “Strong general security, no AI governance. Technology sector profile. Feels protected. Is not.”

Not implied. Named. Technology is the profile the framework was built to catch.

Here is where the aggregate numbers stop telling the truth. Despite that above-average DSMS, 65% of Technology respondents fall into the EXPOSED quadrant – DSMS below 50 and AIGMS below 50 simultaneously. Another 16% sit specifically in the FORTIFIED/False-Confidence pocket: strong security infrastructure, weak AI governance. Combined, that’s 81% of the sector sitting somewhere between blind and half-blind, propped up by a sector average that masks how unevenly the maturity is actually distributed. The mean flatters. The distribution convicts.

Sophisticated reputation, ordinary score

Here’s the uncomfortable part for anyone who has ever pitched Technology as the sector that “gets” AI. Its Data Security and Compliance Readiness Index – DSMS multiplied by the AI governance factor – comes in at 16.8, just above the survey mean of 16.2. Neither dimension distinguishes it meaningfully from an average organization. I’ve sat through enough of these scorecard reviews to know which number gets the applause and which one gets buried in the appendix, and it’s rarely the honest one. That gap between perception and measurement also shows up at the top: the World Economic Forum’s Global Cybersecurity Outlook 2026, published in January 2026, found 87% of cyber leaders now name AI-related vulnerabilities as the fastest-growing cyber risk, yet CEOs still rank data leaks as their single highest AI-related concern. Leaders can see the risk and still misjudge their own exposure to it.

And the representation analysis is worse than the readiness score. Across the survey, Technology produces DSMS/AIGMS “leaders” – organizations scoring 45 or above on both – at only 1.04 times the expected rate. Barely above proportional. Healthcare, a sector nobody nominates for a security award, produces leaders at 1.57 times the expected rate. The sector building the tools is not the sector governing them best. It is, statistically, an average performer wearing a sophisticated-industry costume.

Why the math got worse this year

None of this would matter much if Technology’s AI footprint were small. It is not. Across the full survey, 64% of organizations have AI deployed in production, and among those, 70% are running three or more distinct AI use cases at once. Copilots, customer-facing agents, internal chatbots, code-generation tools: each one is a separate data access point, and Technology, as the heaviest AI adopter in the sample, carries more of them than anyone else. It’s not a coincidence that the Thales 2026 Data Threat Report finds only 47% of sensitive cloud data is actually encrypted, and only one in three organizations claims to know where its sensitive data lives. Stacking AI use cases on top of a data estate you can’t fully see doesn’t produce governance. It just produces more surface you can’t see.

Here’s the whole game: containment has not kept pace with deployment, in Technology or anywhere else. No AI containment control measured in the survey – kill switch, purpose binding, AI-specific DLP, behavioral monitoring – is deployed by more than 35% of organizations, regardless of sector. Technology’s above-average DSMS buys encryption, MFT, and SIEM coverage for the data infrastructure it already understood. It doesn’t buy a kill switch for the agent nobody tested. CrowdStrike’s 2026 Global Threat Report clocked the fastest recorded eCrime breakout time at 27 seconds. Google Cloud’s Mandiant M-Trends 2026 report backs up the trend: the window to intervene has collapsed from hours to seconds. An untested kill switch doesn’t help at 27 seconds. It doesn’t help at 27 minutes either.

The architectural question

Two easy answers exist here, and both fail. The first is “Technology doesn’t need to worry, its DSMS is above average.” The quadrant data kills that outright: 65% exposed, a 16.8 DSCRI, a 1.04x leadership rate. The second is “just buy more AI security tools,” which treats the gap as a shopping problem. It isn’t. The report’s own math shows AI governance investment returns more DSCRI improvement per dollar than incremental security spend at current baselines, because DSMS and AIGMS sit on separate axes. You can’t buy your way up one with money spent on the other.

What actually closes the gap is architecture, not another point tool. Organizations that score well on both axes treat data access and AI governance as one control plane instead of two disconnected budgets: a single place where policy, logging, and containment apply whether a human or an AI agent is requesting the file, so an agent’s access gets reviewed and revoked using the same evidence trail as an employee’s. Technology has plenty of the data infrastructure and not enough of the AI-specific containment governing it. Closing that gap is an architecture decision, not a shopping list.

The Kiteworks 2026 Forecast Report, published in December 2025, projected this exact widening gap between AI deployment and AI containment. The Annual Survey confirms it arrived on schedule, and worse than modeled.

What to do Monday morning

If you run security for a Technology company, or any organization whose DSMS makes you feel comfortable, the scorecard review is not the meeting that matters this week. This one is:

1. Pull your AI use case inventory. If you have not counted every production AI system touching sensitive data, you cannot govern what you have not found. The report puts the sector average at three-plus concurrent use cases – confirm your own count before you assume it’s lower.

2. Test the kill switch you think you have. Across the survey, 23% of AI-deploying organizations have never tested their AI agent termination capability. A documented policy is not a tested control.

3. Separate the DSMS conversation from the AIGMS conversation in your next board update. If they’re one line item, they’re getting one budget, and one budget is how you end up in the False Confidence quadrant.

4. Check purpose binding, not just DLP. General DLP policies do not restrict what an AI agent is authorized to touch. That’s a distinct control, and most organizations don’t have it.

5. Ask who owns AI governance, specifically. Not “who owns security.” Who owns the 19 AI-specific capabilities the AIGMS actually measures.

Technology built the AI. That does not mean Technology governs it. The data says the opposite, and the data is not impressed by the reputation.

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

On August 4, 2026, IEH Corporation discovered that a phished Microsoft 365 credential had been sitting inside its network for an unknown stretch of time. IEH makes hyperboloid connectors that fly inside PATRIOT, AMRAAM, THAAD, and the MARK-48 torpedo. Here is what is not the story: an employee fell for a fake Microsoft sharing link from someone posing as a prospective business contact, and handed over their password. That happens constantly. Here is what is the story: for however long that account sat compromised, the entire contents of a defense contractor’s inbox were sitting in plaintext – purchase orders, engineering documentation, and potentially export-controlled technical data – one login away from anyone holding the keys.

IEH says it found no evidence the data was copied. It also says it cannot determine when access actually began. Sit with that for a second. A company that makes parts for missile defense systems cannot tell you how long an outsider had standing access to its correspondence with customers and suppliers. That is not a failure of this one IT team. It is the default behavior of every mailbox built this decade.

The Phishing Kit Got a Serious Upgrade

Credential phishing used to mean a bad Outlook lookalike page and hope. Not anymore. CrowdStrike’s 2026 Threat Hunting Report found device-code phishing attempts jumped 15-fold in the first half of 2026 compared to the second half of 2025, and voice phishing doubled in that same window after already climbing 134% the year before. These techniques exist specifically to slide past the controls organizations already bought. As CrowdStrike’s Adam Meyers put it to reporters: attackers realized email filters catch email phishing, so they stopped emailing and started calling the help desk instead. “You don’t have to hack in,” he said. “You just have to log in.”

That is precisely the move IEH’s attacker made. A fake sharing link, a convincing login page, one set of harvested credentials. No malware, no exploit, no CVE. Just a key that opened every door in the building at once.

Credentials Are Still Doing Most of the Damage

The 2026 Verizon Data Breach Investigations Report found the human element – error, manipulation, or misuse – involved in 62% of breaches this year, and credential abuse showed up somewhere in the intrusion chain of 39% of them, even as raw vulnerability exploitation edged ahead as the single leading initial-access vector. Read the two findings together and the story is not that credential theft is declining. It is that attackers increasingly pair a stolen credential with something else – a vendor relationship, an exposed system, a moment of trust – to get further than the credential alone would take them. IEH’s attacker did not need to go further. The mailbox itself was the whole prize.

The Login Moat Problem

Security teams keep fighting this the same way: better training, better MFA, faster detection. All of it targets the login. None of it addresses what happens once someone is past it.

Call it the login moat. Everything defensive gets built around the perimeter – the password, the MFA prompt, the conditional access policy – and once an attacker clears that single moat, there is nothing behind it. Not because organizations are careless, but because the mailbox itself was never designed to be anything other than a wide-open filing cabinet once you are inside. Native email platforms store messages and attachments as plaintext, and access control lives entirely at authentication. That architecture is fine right up until the authentication fails, and phishing guarantees it periodically will.

The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found only 39% of organizations have unified data exchange governance with actual policy enforcement across channels – the rest are running partial coverage, channel-specific point tools, or close to nothing. That gap is exactly where an incident like IEH’s lives: not in the phishing email, but in the fact that nothing downstream of the login screen was watching what left the building, or even watching what an authenticated session could see.

The Architectural Fix Nobody Wants to Talk About

The uncomfortable answer is that you cannot patch your way out of this. You have to stop treating the mailbox as a passive container and start treating it as a governed asset with its own policy layer, independent of whoever is currently logged in.

This is the premise behind email gateways built to enforce data-level policy rather than just scan for malware: encrypt or quarantine sensitive and export-controlled content automatically based on what it is, not who happened to send it; apply digital rights controls – view-only, expiration, no forwarding – so a compromised account cannot simply harvest years of correspondence; and log every message, sensitive or not, in an immutable audit trail that can actually answer “what did this account touch and when.” Kiteworks’ Email Protection Gateway is one example built on that premise, running inside a single-tenant hardened virtual appliance rather than a shared mailbox architecture – not because it is the only approach, but because it illustrates what “governed at the content layer” actually looks like in practice. The point is not the vendor. The point is that the policy has to live below the login, not just at it.

What to Do Now

1. Inventory what is actually sitting unprotected in your mailboxes right now – CUI, export-controlled data, contracts, engineering files. Most security teams have never run this exercise.

2. Move to phishing-resistant MFA, per CISA’s own guidance, not the push-notification kind that device-code and vishing attacks are specifically built to defeat.

3. Stop treating audit logging as a checkbox. If you cannot answer “how long was this account compromised” within hours, you have a logging architecture problem, not just a phishing problem.

4. If you are in the defense industrial base, map this exposure to CMMC 2.0 and ITAR now. That mapping matters more, not less, after the Pentagon suspended CMMC’s third-party assessment requirement on July 13 and reverted to self-assessment for the foreseeable future. No assessor is coming to catch what your own NIST 800-171 score misses.

5. Ask your security team one direct question: if a credential gets phished today, what stops the attacker from reading everything, not just logging in?

The next phished employee is not the risk. The unprotected inbox waiting for them is.

Here is a number that should ruin your morning coffee. CrowdStrike’s 2026 Global Threat Report documents AI-enabled lateral movement in as little as 27 seconds. Mandiant’s M-Trends 2026 report tracked the same collapse from a different angle: the median time from initial access to secondary threat group handoff fell from more than eight hours in 2022 to 22 seconds in 2025. Both figures show up in the 2026 Data Security and Compliance Risk Report, cited from those two source reports, and both describe the same event. Attackers do not need hours anymore. They need less time than it takes to read this paragraph.

Now put a second number next to it. Fifty percent of organizations cannot produce a complete AI data access audit record within one business day. Eighty-three percent cannot produce one within one hour. Ten percent cannot produce one at all.

Read that again. Twenty-seven seconds to compromise. A business day, or longer, to even find out what happened. That is not a gap. That is two different centuries trying to occupy the same network.

Here’s the Whole Game

Every AI governance conversation I sit in eventually drifts toward the same comfortable framing: “We’re closing the gap.” Boards like that phrase. It implies a plan, a timeline, a Gantt chart. It is also wrong, and it is wrong in a way that matters. You cannot “close” a 27-second exposure window with a governance program that convenes quarterly. Closing implies both sides are moving toward each other. They are not. The attacker’s clock keeps compressing – eight hours to 22 seconds in three years – while the average enterprise’s audit-response clock is still measured in days. This is not a gap to close. It is a structural mismatch between two systems operating on incompatible units of time, and no amount of incremental investment changes the unit.

The Control Built for This Moment Doesn’t Exist at Most Companies

An AI kill switch is exactly what it sounds like: the ability to sever an agent’s access the instant it misbehaves. It is the one control purpose-built for a 27-second threat window. Only 30% of organizations have one formally deployed. Seventy percent do not.

It gets worse before it gets better. Of organizations running AI in production, 23% have never tested the kill switch they have deployed. An untested kill switch is not a control. It is a rumor about a control, repeated in a compliance questionnaire until someone believes it.

Human-in-the-loop review for high-risk AI actions fares no better – deployed at only 30% of organizations, meaning 70% have no human checkpoint standing behind the missing automated one. So the honest inventory, for most companies, looks like this: no automated stop, no manual stop, and an adversary that closes the distance between “in” and “everywhere” in the time it takes to glance at a phone.

The Logging Infrastructure That Can’t Answer the Question

Containment gaps compound with visibility gaps. Only 37% of organizations have real-time alerting for AI data access anomalies. Only 33% forward AI access logs to a SIEM. Only 29% generate any logs of AI system data access at all. One in four organizations – 25% – has no formal AI detection process whatsoever.

Sit with that last figure. A quarter of the market has put AI systems into production against sensitive data and built no formal mechanism to notice when those systems touch something they shouldn’t. Not a slow mechanism. No mechanism.

None of this is speculative risk sitting on a heat map somewhere. Eighty percent of organizations experienced at least one security incident, general or AI-specific, in the past 12 months. The incidents already happened. The only open question is whether the organization found out in 27 seconds or 27 days.

Two Comfortable Answers, Both Wrong

Faced with numbers like these, organizations reach for one of two comfortable answers. The first: slow AI adoption until governance catches up. That fails on contact with the business – AI deployment is not waiting for anyone’s governance committee, and freezing rollout just delays the reckoning while competitors ship. The second: keep adding monitoring dashboards and call the accumulation “progress.” That fails on contact with the math. A dashboard a human checks on a schedule is still bound to human tempo, and human tempo cannot answer a 27-second question no matter how many dashboards you stack on top of it.

The real variable is not adoption speed and it is not dashboard count. It is whether containment and audit logging happen at the point of data access itself, automatically, or whether they happen afterward, manually, on a schedule a human set. That is the only variable that moves your response time from days to seconds.

The Architecture, Not the Meeting

This is where a unified data governance control plane earns its place in the conversation – not as a silver bullet, but as one working example of governing at machine speed instead of meeting speed. Kiteworks’ Control Plane applies one policy engine and one tamper-evident audit trail across every channel where sensitive data moves – email, managed file transfer, SFTP, web forms, APIs – and extends that same enforcement to AI agents, governing human and machine data access under a single plane rather than as separate, unevenly instrumented systems. The point isn’t the product category. It’s the principle: logging and containment have to be a condition of access, generated the instant data moves, not a report someone assembles after the fact. The Kiteworks 2026 Forecast Report called this exact containment gap the central battleground for 2026. It was right about the direction. This survey shows it was optimistic about the pace.

What to Do Monday Morning

Stop scheduling the meeting. Start doing this instead:

1. Test your kill switch this week. If nobody has fired it against a live agent session, you don’t have a kill switch. You have an assumption with a name.

2. Run a mock audit request today. Give your team one hour to produce a complete AI data access record for a single system. Whatever you get back, that’s your real number – not the one in last quarter’s board deck.

3. Check whether “real-time alerting” actually means real time. If AI access logs hit your SIEM on a batch job, you are in the 63% without it, regardless of what the dashboard says.

4. Put a human checkpoint in front of every high-risk AI action that doesn’t have one, as a stopgap while you build the automated version.

5. Retire the phrase “closing the gap.” It describes a process. What you have is a mismatch, and mismatches get fixed by architecture, not by patience.

Your attacker already reset the clock to 27 seconds. The only decision left is whether your governance runs on that clock or on the old one.

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

In December 2025, Kiteworks published the 2026 Data Security and Compliance Risk: Forecast Report, surveying 225 security and risk leaders. One finding stood out from the other fourteen: 54% of organizations had no standing AI data governance agenda item at board level. The report called it the strongest correlation in the entire survey – organizations with board engagement scored 26 to 28 points higher on every single AI maturity metric measured. Not a marginal edge. A structural one.

That was six months ago. The new 2026 Data Security and Compliance Risk Report surveyed 459 security and risk leaders in Q2 2026, explicitly built as what its authors call “the accountability document” – a test of all fifteen Forecast predictions against what actually happened. On board governance, the verdict lands in one sentence: 54%. Identical. Not directionally similar. The same number, to the point.

Here’s the whole game: this was never a measurement problem, a tooling gap, or a maturity curve that needed more time. It was a decision, made once in December and made again in June by simply not making it. Boards had six months, a named correlation, and a specific number telling them exactly what to do. They did not move.

The Best Control in the Survey Is Still a Minority Practice

Look at what “engaged” actually means before you assume your board clears this bar. Board-level AI data governance reporting as a standing agenda item – the highest-rated governance control in the entire survey – is present at only 46% of organizations that have deployed AI systems. Across all organizations surveyed, regardless of AI deployment status, that figure drops to 30%.

Read that again. The single best-performing control Kiteworks measured, out of nineteen AI governance capabilities, is still something most organizations don’t do. This isn’t a case of boards lagging behind a strong industry norm. There is no strong industry norm. There is a minority practice that happens to correlate with everything else going right, and a majority that has decided it can wait.

Boards Can Do This. They Choose Not To.

The excuse writes itself: boards are generalists, AI is technical, directors can’t be expected to govern what they don’t build. That excuse doesn’t survive contact with how boards behave on adjacent risk.

The National Association of Corporate Directors’ 2025 Public Company Board Practices and Oversight Survey found 77% of directors now discuss the material and financial implications of cyber incidents at the board level – a 25-point jump since 2022. Boards moved on cyber risk in three years. They have had AI data governance sitting in front of them, with a named correlation attached, for six months and haven’t moved at all.

So the capacity argument fails. Boards can absorb a technical risk category into standing governance when they decide it matters enough. On cyber, they decided. On AI data governance, at 54% of organizations, they haven’t.

Gartner’s own 2026 predictions forecast that 40% of enterprises will demote or decommission autonomous AI agents by 2027 because governance gaps only surface after a production incident. That is the cost of deferring the board conversation: you find out what you should have governed after it’s already broken.

Why This Is Getting More Expensive, Not Less

While boards sat still, the exposure compounded. The Annual Survey found 80% of organizations experienced at least one security incident – general or AI-specific – in the past twelve months, and 63% faced a compliance consequence: an audit finding, a remediation order, a regulatory investigation, or a board escalation that arrived only after something had already gone wrong. The World Economic Forum’s Global Cybersecurity Outlook 2026 puts data leaks at the top of CEOs’ AI-related concerns – which makes the board’s silence on AI data governance specifically, not AI generally, harder to explain away.

Ownership tells the same story from a different angle. Only 24% of organizations have a dedicated team for AI data governance. Thirty-nine percent bolt it onto an existing role – usually the CISO or CIO, who already owns general security, incident response, and now, apparently, AI governance too, without a board mandate or a budget line to match. IBM’s 2025 Cost of a Data Breach Report, produced with the Ponemon Institute, found 97% of organizations reporting an AI-related security incident lacked proper AI access controls, and 63% had no AI governance policy at all to stop it. The people closest to the problem know it. The people who set organizational priority have not said so.

The Architectural Question Boards Keep Avoiding

Here’s where it gets uncomfortable. A board agenda item is a governance decision, not a technology purchase – but it is also true that boards defer decisions when the underlying evidence is hard to produce. Ask a typical security leader for a complete AI data access audit record and half can’t deliver one within a business day. That is not a board failing to ask the right question. That is a board with nowhere to point when it does ask.

Architecture won’t make a board show up. But it can take away the excuse that the evidence doesn’t exist. A unified policy engine that governs how humans and AI systems alike access, move, and exchange sensitive data – built on a hardened, single-tenant architecture with evidence-quality, tamper-evident audit trails – gives a board something to review on a quarterly cadence instead of a status update built on trust. Kiteworks’ Control Plane is one example of a platform built on that premise. It doesn’t manufacture board accountability. It just removes the last excuse for not having it. The Annual Survey’s Mean AI Governance Maturity Score across all 459 respondents is 35 out of 100 – the average organization has deployed roughly 7 of 19 measured governance capabilities. That gap closes faster with a board paying attention than without one.

What to do Monday morning

1. Put AI data governance on the board agenda as a standing line item – not folded into general cybersecurity reporting, not addressed ad hoc when something breaks.

2. Bring the board a number, not a narrative: your AI Governance Maturity Score, your audit-record turnaround time, your percentage of AI systems with logged, reviewable access.

3. Assign dedicated ownership. If AI data governance is still an add-on to your CISO’s or CIO’s existing job description, name that as the gap it is, on the record, to the board.

4. Ask your board directly whether it has discussed AI data governance in the past two quarters. If the honest answer is no, that answer is now the first agenda item.

Six months bought this industry nothing. The next six are optional in exactly the same way the last six were: boards can keep choosing not to decide, or they can act on a correlation they already have the data to justify. The number doesn’t move on its own. Someone with a board seat has to move it.

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

Bans dropped 21 points in a year. Technical controls didn’t move. That’s not progress – that’s a policy department admitting defeat and calling it strategy.

Picture the memo. Some VP of Security Policy, sometime in late 2025, drafts an update to the acceptable-use policy. The line that once read “employees may not use unauthorized AI tools to process company data” quietly disappears. Nobody frames it as surrender. It gets filed under “modernizing our AI governance approach.” The all-hands slide says the company is “embracing AI while managing risk.” What actually happened is simpler: the ban wasn’t working, nobody built the thing that should have replaced it, and someone decided the cleanest fix was to stop having a rule that everyone was already breaking.

That’s not a hypothetical. It’s the finding.

The Cisco 2026 Data and Privacy Benchmark Study found that outright bans on AI tool usage fell from 28% of organizations in 2025 to 7% in 2026. Twenty-one points, gone in twelve months. Cisco found no corresponding rise in the technical controls that would need to exist for that retreat to be safe. Same study: enterprise AI usage more than doubled in 2025, and 62% of workers now use AI at work. Adoption accelerated. Governance did not follow it. Those two facts sitting next to each other are the entire story of this piece.

What actually happened while nobody was watching

Here’s the whole game: organizations didn’t defeat shadow AI. They ran out of the will to keep pretending the ban was enforceable, and quietly downgraded the problem from “prohibited” to “somebody else’s responsibility to notice.”

The 2026 Data Security and Compliance Risk Report puts a number on how much there is to notice. Sixty-five percent of organizations discovered employees using unapproved AI tools with organizational data in the past twelve months. Sixteen percent are finding it monthly or more. Twenty-eight percent quarterly. Twenty-one percent have caught it at least once, rarely. Add those up and you get an organizational habit, not an isolated incident.

The 35% who report no discovery at all deserve a second look, and not a reassuring one. Detection gaps and clean environments look identical from the outside. An organization with no logging on AI data flows and no alerting on anomalous transmissions will report zero shadow AI incidents right up until the breach notification arrives. Absence of evidence, in this specific case, is evidence of a blind spot.

The data isn’t generic, and that’s the part that should worry you

Shadow AI usage isn’t employees asking a chatbot to summarize a press release. Among organizations using employee-facing AI chatbots, 36% report customer and client data flowing through them. Thirty-three percent route IT credentials and access requests. Thirty-one percent route employee personal and HR data. Thirty percent route financial data.

Read that again. A third of these organizations have employees handing IT credentials to a consumer AI tool with no enterprise contract, no data processing agreement, and no audit trail. That’s not a training gap. That’s a data exfiltration channel that happens to be voluntary.

Why the response doesn’t match the exposure

Here’s where it gets uncomfortable. Discovering shadow AI and doing something about it are two different events, and the report shows most organizations stop after the first one. Among organizations that found shadow AI in use, the most common response was issuing updated policy guidance. Fewer than half went on to deploy technical controls that would actually prevent it from happening again.

Training keeps winning the budget argument anyway. Thirty-six percent of organizations name workforce training on AI data security as a top investment priority – the single most commonly planned response to a problem that training cannot structurally fix. An employee who has read the policy and still has an unblocked path to a consumer AI tool hasn’t been protected. They’ve been informed of a rule they remain fully capable of breaking, with documentation now proving they knew better.

The 2026 Cost of Insider Risks Global Report from the Ponemon Institute names shadow AI as the leading driver of negligent insider incidents, pushing average annual insider risk cost to $19.5 million per organization. That figure isn’t rising because employees got worse at following instructions. It’s rising because the instructions were never backed by anything that could stop the behavior.

The architectural question everyone is avoiding

Stop asking whether employees should be trusted to follow the updated AI policy. Here’s the question that actually matters: what, mechanically, stops sensitive data from reaching an unapproved AI tool if an employee decides to send it anyway?

For 72% of organizations, the answer is nothing. Only 28% have AI-specific data loss prevention deployed – the control that blocks sensitive data at the transmission layer instead of just documenting the violation after the fact. Purpose binding, which restricts AI agents and tools to authorized tasks and data scopes, is deployed at just 27%. Both numbers are governed the same way for human users and for the AI agents acting on their behalf – an unbound agent is exactly as capable of moving data somewhere it shouldn’t as an unsupervised employee, and neither has anything stopping them without a technical layer in place.

This is the point where the industry usually reaches for a policy fix, because policy fixes are cheap and fast to announce. But a policy is a sentence. A transmission-layer control is an architecture – something that inspects and blocks AI-bound traffic across every channel sensitive data actually moves through, rather than relying on a general-purpose network tool that was never built to recognize an AI destination in the first place. Detection after the fact is documentation. Enforcement at the transmission layer is the only thing that changes behavior that policy alone has already failed to change.

What to do Monday morning

The ban was never the control. It was a placeholder standing in for a control that most organizations never built, and now the placeholder is gone too. Here’s what closes the gap it leaves behind:

1. Pull your AI data access logs and check them for gaps, not incidents. If you have no real-time alerting on AI data transmissions, your “no shadow AI discovered” result measures blindness, not safety.

2. Map which of the four high-risk data categories – customer data, credentials, HR data, financial data – has an actual technical block in front of unapproved AI tools. If the answer is policy language instead of a control, you don’t have a mitigation.

3. Stop funding training as the primary response to a discovered shadow AI incident. Budget the transmission-layer control instead, and treat training as the secondary layer, not the first line of defense.

4. Ask your vendor governance team the blunt question: can we verify, technically, whether our approved AI vendors use our data for model training, or are we relying on a signed attestation we’ve never actually tested?

5. If your organization dropped its AI ban in the last year, find out what replaced it. If the honest answer is “updated guidance,” you didn’t modernize your policy. You repealed your only control and never built the next one.

Twenty-one points of bans disappeared in a single year. Zero points of technical control appeared to take their place. That’s not an evolution in AI governance. It’s a governance vacancy with a press release attached.

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

Here’s what a live red-team exercise just proved about what happens next.

It’s a Tuesday morning in February 2026, and a researcher at a security lab is about to break an AI agent using nothing but a Discord display name. Twenty researchers from MIT, Stanford, Carnegie Mellon, and Harvard spent two weeks running live, non-sandboxed agents built on the open-source OpenClaw framework, then attacked them the way a bored teenager would. One researcher renamed themselves to match an agent’s owner. The agent caught it instantly inside the channel it already knew. Then the same researcher opened a fresh private channel with no history attached, and the agent, faced with an identity it had no way to verify, handed over its memory files, its name, and its administrative access. No exploit. No malware. Just a display name.

Here’s the whole game: enterprises are deploying agentic AI faster than they are building any way to govern it, and the industry has quietly agreed to call this “early days” instead of what it is, which is a governance failure at scale. Agents will always outrun policy. That’s not a prediction, it’s a design fact, and every number below is just a different way of measuring the gap.

What the researchers actually found

The study, Agents of Chaos, documented at least ten significant security breaches across eleven representative case studies, and the pattern across them is not sophistication – it’s the absence of a stakeholder model. In one case, an agent refused a direct request for “the SSN in the email” but handed over the entire email, unredacted Social Security number and bank details included, when the same person asked it to forward the message instead. The agent could recognize an explicit ask for sensitive data. It could not recognize that the container holding that data was the identical exposure wearing a different hat.

The researchers call this a structural problem, not a bug. Large language model agents process instructions and data as the same kind of token in the same context window, which means the model has no reliable way to tell “do this” from “here is information” once both arrive in the same stream. Prompt injection isn’t a vulnerability you patch. It’s a property of how these systems currently work.

The pattern is bigger than one lab

If this were confined to one open-source framework, you could file it under “early days” and move on. It isn’t. CrowdStrike’s 2026 Global Threat Report tracked an 89% year-over-year increase in operations by AI-enabled adversaries and found attackers injecting malicious prompts into GenAI tools at more than 90 organizations, on top of abusing AI development platforms directly. The World Economic Forum’s Global Cybersecurity Outlook 2026 adds the enterprise-side mirror image: roughly a third of organizations have no process at all to validate an AI system’s security before deployment, and only about 40% run periodic AI security reviews once it’s live.

Put those two findings next to each other: an 89% jump in AI-enabled attacks on one side, 63% of organizations unable to enforce a purpose limit on their own agents on the other. Attackers are getting faster at exploiting AI systems. Most defenders aren’t checking whether their own AI systems are exploitable in the first place. That’s not a gap. That’s an open door with a welcome mat.

Why the math got worse this year

Governance debt on agentic AI has been accumulating quietly for two years. What changed is that agents stopped being a lab curiosity and became a procurement line item. The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found that 100% of surveyed organizations now have agentic AI on their roadmap. Sixty-three percent cannot enforce purpose limitations on what those agents do once deployed. Sixty percent have no way to terminate a misbehaving agent. Fifty-five percent cannot isolate their AI systems from the broader network if something does go wrong.

Read that again. Every organization surveyed is building toward agentic AI. Most of them have no brakes, no steering, and no wall between the car and the rest of the building.

Inside government specifically, the same report found 90% lack purpose binding for AI agents and 76% have no kill switch at all. That’s the sector with the most sensitive data and the least ability to stop an agent mid-task. The NIST AI Agent Standards Initiative, announced this February, names agent identity, authorization, and security as the priority areas for standardization. Standards bodies only move this fast when the field has already outpaced them.

The architectural question

The tactical response to all of this – write better system prompts, add a content filter, tell the agent to “be careful” – was never going to hold. You cannot patch your way out of a structural problem in how the model separates instruction from data. The fix has to sit outside the model, at the point where the agent actually touches a file, a folder, or a record, evaluating every request against policy the agent cannot argue its way around.

That’s the premise a small number of platforms are now building toward: treat the AI client as a governed identity, not a trusted one, and enforce the same role-based and attribute-based access controls on it that already apply to human users. Kiteworks’ Secure MCP Server is one example – it routes every AI request through a policy engine before data ever reaches the model, running on FIPS 140-3 validated cryptography, so the access decision, not the agent’s judgment, determines what comes back. For what it’s worth, we run this internally too: our own teams connect through the Connector day to day, which is a useful forcing function for finding the gaps in your own story before a customer does. It’s a narrow example of a broader architectural shift: governance has to move to the front of the request, for humans and agents alike, or it doesn’t count.

What to do this week

1. Ask your AI/ML team a direct question: can we terminate any deployed agent within sixty seconds, and can you show me the control that does it? If the answer is “we’d have to shut down the whole service,” you don’t have a kill switch, you have a hope.

2. Audit whether any AI agent in production has standing access to a data store, versus access gated per-request against RBAC or ABAC policy. Standing access is the CS8 failure mode waiting to happen with your data instead of a researcher’s.

3. Check whether identity verification for an AI client persists across sessions or channels, or resets to zero the moment context changes. If it resets, you have the same cross-channel gap the OpenClaw agents had.

4. Stop treating “the agent behaved correctly in testing” as evidence of anything. The Agents of Chaos researchers weren’t testing average-case behavior. They were looking for one counterexample, because demonstrating a vulnerability only takes one.

5. Put a number on your purpose-binding and containment controls this quarter, not next year’s roadmap. Sixty-three percent of your peers already can’t answer this question. Being able to is now a competitive fact, not a compliance nicety.

The agent that deleted its own memory files didn’t do anything an attacker forced it to do in the technical sense. It did exactly what it was designed to do: trust the identity in front of it. That’s the whole problem, and it’s the whole opportunity. Fix what the agent trusts, and you fix the incident before it has a chance to happen.

DataTribe published its Q2 2026 Insights Report on July 27. Two days later, Help Net Security ran the number that mattered: AI and agent security is now the single largest category of cybersecurity seed-stage investment, close to a quarter of every deal done last quarter. That is not the story. The story is why investors are suddenly this specific about it.

They are not funding “AI security” in the abstract. They are funding one mechanism: an agent that spins up a second agent, mid-task, and hands it live credentials – no verification, no scoping, no log. DataTribe found roughly a quarter of deployed agents can do this today. Read that again. A quarter of the agents already running in production environments can silently create a new, unaccountable identity and give it the keys.

The Number Investors Actually Priced

Here’s the whole game: DataTribe measured every control in its dataset for impact on incident rates, and one control beat all the others by a wide margin. Scoping agent privileges to least-privilege access took incident rates from more than two-thirds of deployments down to below 20%. Not a modest improvement. A collapse.

That is what seed money is chasing – not agent security as a category, but the specific, provable lever inside it. Everything else investors funded this quarter is downstream of that one finding.

The Handoff Nobody Is Watching

Call it silent succession: an agent, mid-task, creates a subordinate agent and passes it working authority without telling anyone. No identity provider checks who the new agent is. No policy engine scopes what it can touch. No log records that the handoff happened at all.

This is not a hypothetical. It is the mechanism DataTribe is describing when it says a quarter of deployed agents can spawn sub-agents and hand off live credentials with no verification, scoping, or audit trail. The sub-agent inherits whatever access its parent happened to be holding, which is almost always broader than the actual sub-task requires. Nobody approved that grant. Nobody is accountable for it. It just happened, in milliseconds, because the architecture allows it.

Kiteworks’ own Data Security and Compliance Risk: 2026 Forecast Report found 60% of organizations cannot terminate a misbehaving AI agent once it is running, and 63% cannot enforce purpose limitations on what an agent is allowed to do in the first place. Those two numbers explain why silent succession works as an attack path. You cannot scope what you cannot see, and you cannot kill what you have no switch for.

Why the Math Got Worse This Quarter

None of this would matter as much if defenders still had time to notice. They don’t. DataTribe cites CrowdStrike’s 2026 Global Threat Report, which puts the fastest observed breakout time this year – initial compromise to lateral movement – at 27 seconds.

Twenty-seven seconds. That is not a detection window. That is barely enough time for a SOC dashboard to refresh. A human analyst cannot triage an alert, rule out a false positive, and contain an incident inside 27 seconds. Nothing built around “detect, then respond” survives contact with that number.

Meanwhile the old front door hasn’t closed. Verizon’s 2025 Data Breach Investigations Report found edge device and VPN exploitation rising sevenfold. So attackers are getting through the perimeter faster than ever, and once inside, they are increasingly finding unscoped, unlogged agent identities waiting for them. Fast entry plus ungoverned agent sprawl plus a 27-second window is not three separate problems. It’s one compounding one.

The Architectural Question

Here’s where it gets uncomfortable for anyone still thinking about this as a detection problem. If breakout happens in 27 seconds and a quarter of your agents can silently mint new identities with inherited access, faster alerting does not save you. The only control that acts inside that window is one that was already in place before the agent asked for anything.

That means the fix has to live at the point of the request, not at the perimeter and not in a SIEM dashboard after the fact. Every time an agent – or a sub-agent it just created – asks to touch a file, a record, or a dataset, something has to evaluate that specific request against policy before access is granted, and log it regardless of the outcome. This is the architectural bet a handful of vendors are making, Kiteworks among them: a unified policy engine that enforces per-request RBAC and ABAC for both human and agent identities under one plane, so a sub-agent inherits governance the moment it’s created instead of inheriting whatever access its parent happened to be holding. It is one example of the pattern, not the only one, and it does nothing for the edge and VPN exploitation Verizon is describing. Perimeter hardening and content-layer governance are two different budget lines that need to move together.

What to Do This Week

1. Inventory which of your deployed agents can spawn sub-agents. Most security teams cannot currently answer this question. That is the actual gap, not a lack of tooling.

2. Require that any sub-agent creation event triggers its own identity verification and scoped credential issuance – never inherited, unscoped access from the parent.

3. Confirm you have a working kill switch. If 60% of organizations can’t terminate a misbehaving agent, assume you’re in that group until you’ve tested it.

4. Push least-privilege scoping to the top of the AI governance roadmap, ahead of general AI policy work. It is the only control DataTribe measured that cut incident rates by two-thirds.

5. Stop treating this as a perimeter problem or a content-governance problem. It is both, funded from the same conversation, on the same timeline.

Venture capital isn’t betting on agentic AI security because it sounds forward-looking. It’s betting on it because DataTribe just showed the industry which control actually works, and most enterprises haven’t installed it yet. That gap is not a research question anymore. It’s a Monday morning task list.

Picture a Tuesday morning in July 2026: your patch dashboard has already ranked forty new CVEs by exploitability, and the AI did that ranking overnight, unsupervised, while you slept. All that is left is one click: deploy across production. You do not click it. Neither would 53% of your peers, according to Action1’s newly released 2026 Survey Report: AI Impact on Sysadmins. Two years ago, this same population told researchers that by now AI would be running patch management, vulnerability prioritization, and incident response with minimal human involvement. It is not. And the reason has nothing to do with whether the models got good enough.

What Sysadmins Actually Said

Start with the number that should embarrass every AI roadmap slide from 2024: fewer than one in five sysadmins currently use AI for patch management or vulnerability prioritization – the two workflows they themselves flagged as most automatable. Twenty-three percent said they have never used AI professionally at all. Not “rarely.” Never.

Then look at where trust actually breaks. Only 14% would let AI deploy patches across production systems without supervision. Just 11% would let AI override an existing patching policy under any circumstance, and 40% said they never would. Sysadmins will let AI schedule maintenance windows and triage alert noise. They will not let it touch the thing that keeps the business running, unwatched.

Here is the sentence in the report that matters more than any of those percentages: when AI acting on file or identity management makes an error, accountability for the resulting harm is left ambiguous. Read that again. The industry has spent two years debating whether AI is capable enough. Nobody built the part where someone is on the hook when it is wrong.

The 2024 Predictions Didn’t Miss. They Inverted.

AI did not fail to keep pace with a 2024 roadmap. A different fear just won out. Back then, sysadmins worried the technology would mature too slowly. Now the worry has flipped: it matured fast enough to act, not fast enough to be trusted with the blast radius of that action.

That fear is not isolated to IT operations. IBM’s 2026 Cost of a Data Breach Report, based on Ponemon Institute interviews with staff at more than 600 breached organizations, found that among organizations reporting an AI-related security incident, 92% were missing basic role-based access controls, MFA, or equivalent safeguards on the AI systems involved. Fewer than half of organizations secure the non-human identities their AI workflows depend on. Close to seven in ten of those breached organizations lack governance policies for AI use at all. The sysadmin who will not let a model touch production unsupervised is not being a Luddite. He has seen the breach data the rest of the industry is still catching up to.

Why the Math Got Worse, Not Better

Two years ago, “AI in IT operations” mostly meant a chatbot summarizing logs. In 2026, it means agents with standing access to systems, credentials, and file stores – acting continuously, not on request. That shift changes the risk calculus entirely, and a separate 2026 survey from 1Password of 1,000 security and engineering staff at large U.S. firms shows exactly how. Seventy-one percent said their AI agents can reach sensitive information. At roughly four in ten organizations, agents reach data outside what was ever approved for them – agents touched, on average, twice as much data as anyone had signed off on. Forty percent of developers grant agents persistent access that outlives the task. One in three respondents who use agents reported a breach or incident tied specifically to overprivileged non-human identities.

Then ask who answers for it. In that same survey, 65% of respondents said accountability should sit with someone other than whoever is currently assigned it. Five percent said the agent itself should be accountable. An agent cannot be fired, sued, or deposed. That five percent is not an edge case. It is what happens when an organization deploys autonomy faster than it defines ownership.

Gartner has already priced this in at the portfolio level: it predicts more than 40% of agentic AI projects will be canceled by the end of 2027, largely on escalating costs and inadequate risk controls. The sysadmins in the Action1 survey are not lagging the roadmap. They are the roadmap correcting itself.

The Architectural Question

Here is the question I keep coming back to: why does every conversation about AI trust default to “is the model good enough” instead of “can we see and constrain what it just did?” Those are different problems, and only one of them has a mature answer today.

Faster patch algorithms do not close an accountability gap. Better prompts do not either. What closes it is treating every AI action – human-initiated or agent-initiated – as a governed, logged request against a defined policy, the same way you would treat a privileged employee action, not as a separate autonomous actor operating outside the rules humans follow. A handful of vendors are starting to build access-governance layers on exactly that premise: a single policy engine that enforces per-request rules on what any identity, human or AI agent, can actually reach, and that logs each request in an audit trail detailed enough to survive a post-incident investigation. None of that makes an AI model trustworthy on its own merits. It makes an organization’s exposure visible and provable when the model gets it wrong, the exact accountability layer the Action1 and 1Password data show is missing. One boundary matters here, though: that kind of access governance covers content and credential access, not the IT operations task of pushing a patch to a production server. Those are neighboring problems, not the same problem, and Kiteworks’ own 2026 Data Security and Compliance Risk Forecast Report tracks them separately for that reason.

What This Means Monday Morning

1. Pull your own numbers before you argue with the sysadmins. What percentage of your patch, vulnerability, and identity workflows actually touch AI unsupervised right now? Most teams do not know.

2. Write down who is accountable for an AI-driven access error before one happens, not after. If your answer is “the vendor” or “the model,” you have the same gap 65% of the 1Password respondents flagged.

3. Separate the two governance problems on your roadmap: operational autonomy (should AI deploy the patch) and data access governance (what can the agent touch while doing anything). Different controls, different owners, different timelines.

4. Audit non-human identities the way you audit privileged human accounts – expiration, scope, logging – because fewer than half of organizations currently do, per IBM’s 2026 data.

5. Demand an audit trail before you demand autonomy. The sysadmins already figured this out. The rest of the industry is still arguing about model capability.

The gap was never between what AI could do and what sysadmins would let it do. It was between what AI could do and what anyone could prove it did.

On August 2, 2026, the European Commission’s AI Office and national authorities stopped publishing guidance about the AI Act and started enforcing it. Chatbots now have to say they are chatbots. Deepfakes need labels. AI-generated content needs a machine-readable mark. The Commission paired the date with its first published list of more than 180 organizations that signed the EU’s Code of Practice on transparency of AI-generated content.

None of that is the interesting part. The interesting part is that most compliance teams could not produce a complete inventory of the AI systems this enforcement action now applies to if a regulator asked tomorrow. That gap, not the labeling rule, is what should keep you up tonight.

What Article 50 actually requires

The AI Act’s transparency obligations sit in Article 50, and they are narrower and more mechanical than the headlines suggest. Providers must disclose when a user is interacting with an AI system rather than a human. Deployers of emotion-recognition or biometric-categorization systems must inform the people exposed to them. Anyone generating or altering image, audio, or video content must label it, and that label has to be machine-detectable, not just a footer disclaimer a human might read. Legal analysis from the AI Transparency Code of Practice rollout makes clear the Commission built the Code specifically so signatories get “streamlined compliance” and more predictable enforcement, which is a polite way of saying: everyone else gets first-in-line scrutiny.

That is a narrow, mechanical set of obligations. It is also the easy 20% of the problem. The hard 80% is knowing which systems in your environment are subject to it in the first place.

The governance gap the enforcement sweep will not find

Here is the uncomfortable arithmetic. A 2026 study from Smarsh found that 55% of enterprises are actively deploying AI, but only 26% believe their governance keeps pace with that deployment. Separately, Salesforce’s 2026 Workforce AI Survey found that 67% of employees now use AI tools at work, while only 18% of their employers have a formal AI security policy in place. Read those two numbers together and the picture is not subtle: most of the AI activity touching enterprise data is happening outside whatever governance process exists to catch it.

This is not a new problem. It is the same shadow IT story security teams have been telling since the first employee synced a work file to a personal Dropbox account. What is new is that regulators now have a specific, dated, enforceable hook to hang it on. You cannot disclose that a system is AI, or label its output, if nobody on your compliance team knows the system is running.

Why the math got worse this time

This enforcement date is different from the last five years of “AI governance is coming” warnings, and not for one reason. It is horizontal: it applies across sectors, not to a single regulated vertical, which means the DIY AI tool your marketing team adopted last quarter is now in scope alongside your core product’s chatbot. The penalty structure is not theoretical, either. Under Article 99 of the AI Act, the most serious violations carry fines up to €35 million or 7% of global annual turnover, whichever is higher, calculated on worldwide revenue regardless of where the company is headquartered.

And this transparency enforcement does not replace GDPR, NIS 2, or DORA obligations already layered on the same data. It stacks on top of them. An AI system that mishandles personal data while also failing to disclose that it is AI is now looking at two separate regulatory exposures from the same incident.

Regulators are not asking whether you have an AI policy document. They are asking whether you can produce evidence, for a specific system, on a specific date, that the required disclosures and controls were actually in place. That is an audit-trail problem before it is a labeling problem.

The architectural question underneath the labels

Most organizations will respond to this the way they respond to every new compliance deadline: patch the visible gap. Add a disclosure banner to the customer-facing chatbot. Update the AI usage policy. Neither of those actions touches the actual exposure, which is that AI systems – chatbots, retrieval pipelines, and a growing number of AI agents – request and generate content from enterprise data through dozens of uncoordinated paths, each with its own logging, its own access rules, and its own blind spots.

The organizations in better shape here are the ones that already treat AI-to-data interactions – whether initiated by a human user or an AI agent – as something to be governed under one policy engine and one audit trail, rather than as a bolted-on afterthought scattered across whatever tool happened to generate the content. That architecture does not solve deepfake labeling. It solves the prior question – whether you can even see what your AI systems touched – that has to be answered before labeling means anything. Kiteworks’ 2026 Data Security and Compliance Risk: Annual Forecast Report has tracked this same pattern across multiple 2026 enforcement actions: regulators increasingly want evidence of continuous control, not a policy binder.

What this means Monday morning

Skip the debate about whether this enforcement date is a big deal. It is not going away, and the penalty structure means the cost of guessing wrong is not trivial. A few things worth doing this week, in order:

1. Build a real inventory of every interactive AI system and content-generation tool touching customer or enterprise data, including the ones marketing and sales adopted without a security review.

2. Assign an owner to each system on that list. An inventory with no accountable owner is just a spreadsheet.

3. Check whether your existing AI usage policy is technically enforced or merely documented. If a system can access data the policy says it should not, the policy is decorative.

4. Confirm your audit logging actually captures AI-to-data interactions with enough detail to answer “what did this system access, and when” without a multi-day forensic exercise.

5. Map which of your AI systems fall under Article 50’s disclosure and labeling duties, and which owner is accountable for each disclosure.

The label on the chatbot was never the hard part. Knowing the chatbot exists, and what it touched, always was.

On July 23, 2026, CISA, the NSA, the FBI, the UK’s National Cyber Security Centre, and agencies from more than a dozen allied nations published Advisory AA26-204A, attributing a sustained espionage campaign to a Russian state-supported group tracked as LAUNDRY BEAR, Void Blizzard, CL-STA-1114, and TA488. The group has been exploiting a cross-site scripting flaw in Zimbra Collaboration Suite webmail since at least July 2025, according to the advisory and BleepingComputer’s reporting. The patch timeline is not the interesting part. Zimbra shipped a fix in November 2025 and victims kept getting hit anyway, which says something about patch cadence but isn’t the point. The point is what got taken: 90 days of email history per victim, the organization’s internal directory, live two-factor authentication tokens, and any application passcode generated after compromise, all routed to a backend the actor internally calls “Flowerbed.”

Four days later, on the other side of the world, Bank of Baroda confirmed a breach with an uncomfortably familiar shape. No nation-state attribution, no CVE, no CISA advisory. Just a compromised employee email account, and, per the bank’s own statement, customer identity documents, loan and appraisal records, internal audit reports, and internal communications showing up on a dark-web marketplace. Two continents. Two unrelated threat actors. One shared architecture failure: the mailbox held more than anyone was governing.

What LAUNDRY BEAR actually took

CVE-2025-66376 is a persistent cross-site scripting flaw in Zimbra Collaboration Suite’s Classic UI webmail client, CVSS 7.2. LAUNDRY BEAR delivered it through phishing emails engineered so that Zimbra’s own webmail interface executed attacker-supplied JavaScript inside the victim’s authenticated session the moment the message was opened. The attack needed no separate malware payload, no macro. Just an opened email. From that foothold, per CISA, the group pulled the last 90 days of the victim’s mail, the organization’s global address list, active two-factor authentication tokens, and any application passcode generated afterward. Victims span the Defense Industrial Base, federal and local government, education, energy, law enforcement, media, NGOs, and technology. The campaign ran undetected from July 2025 until Zimbra patched it in ZCS 10.0.18 and 10.1.13 that November – four months as an unpatched zero-day, and organizations were still getting compromised in July 2026, eight months after a fix existed. AttackIQ’s response built adversary emulation scenarios so defenders can test detection coverage against the exact technique rather than wait for the next advisory to explain what already happened to them.

Why Bank of Baroda isn’t a different story

Reuters reported that metadata attached to the leaked cache suggested more than 700GB of data. Other outlets, citing unverified researcher claims, put the figure near 1TB. Neither number is bank-confirmed, and readers should treat both as attacker- and researcher-sourced until forensics says otherwise. What Bank of Baroda has confirmed is the initial access vector: one employee’s email account, not its core banking systems, which the bank says remain secure. No group has formally claimed the breach. Some researchers have linked it to an actor called TripleX, previously associated with an attack on Indonesia’s PT Bank Negara Indonesia, per Gulf News’s reporting – unconfirmed, and the forensic investigation is still open.

Here’s why that matters beyond one bank. The 2026 Verizon Data Breach Investigations Report found vulnerability exploitation overtook credential-based access as the single largest initial-access category for the first time, climbing to 31% of breaches from 20% the year before. Add phishing (16%), credential abuse (13%), and pretexting (6%) back together, though, and identity- and email-adjacent access still accounts for 35% of breaches, with the human element present in 62% of all incidents DBIR tracked. LAUNDRY BEAR and whoever hit Bank of Baroda are not exploiting a rare misconfiguration. They are exploiting the modal path in.

Why the math got worse

Here’s where it gets uncomfortable. For a decade, the standard advice for exactly this scenario was: turn on MFA. LAUNDRY BEAR didn’t need to defeat multi-factor authentication. It stole live two-factor tokens and freshly generated application passcodes straight out of the browser session the cross-site scripting flaw handed it. A stolen session token walks past MFA entirely, because the second factor was never the barrier. The authenticated session was.

The 90-day retention window that made LAUNDRY BEAR’s haul so large isn’t a Zimbra misconfiguration, either. It’s the default. Most webmail platforms keep months of history live and searchable because that is what users expect from an inbox. Nobody designed that retention policy assuming an attacker would eventually read all of it in a single sitting. Layer in that the same DBIR found 44% of AI-assisted initial-access attempts were phishing-related, and the one thing that used to give defenders a fighting chance – a lure with broken grammar or a mismatched domain – is disappearing as a reliable tell.

The architectural question

This is where “patch faster” runs out of road. Patch discipline matters, obviously. It is not sufficient on its own, because the thing an attacker steals is not the mail server. It’s the content that accumulated inside it while nobody was treating the mailbox as a data repository requiring its own controls.

The architectural alternative treats inbound and outbound email as a governed content channel rather than a trusted internal system. Kiteworks’ Email Protection Gateway is one example of that category: it scans inbound and outbound mail with antivirus, DLP, and advanced threat protection ahead of delivery, and logs access to a unified audit trail independent of the mail client itself. Neither incident here ran through a Kiteworks-governed environment. LAUNDRY BEAR’s victims were running native Zimbra webmail; Bank of Baroda’s compromise ran through a native corporate mailbox. So this is a description of an architectural category, not a claim about what would have happened in either case – a scanning gateway in front of webmail doesn’t eliminate every application-layer vulnerability in the webmail platform itself, and its value is bounded by what gets scanned and how long content sits under policy versus how long it sits by default. What it changes is the assumption underneath the mailbox: instead of an unmonitored 90-day archive that the platform’s own code can be tricked into executing, email content becomes something to which access is scanned, logged, and provable after the fact. The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report treats ungoverned communication channels, email chief among them, as a structural exposure organizations will keep re-discovering through 2026 rather than a one-off headline they can patch their way out of.

What this means Monday morning

• Pull your webmail platform’s default retention window and ask who approved it. If the answer is “nobody, it’s just the default,” that’s your 90-day exposure figure sitting unmanaged right now.

• Inventory which webmail and email gateway products in your environment handle XSS and injection in user-supplied content, and check each against CVE-2025-66376’s disclosure timeline. A four-month zero-day window followed by an eight-month patch gap is not a Zimbra problem. It’s an update-cadence problem you likely share.

• Treat stolen session tokens and application passcodes as a distinct incident category from stolen passwords. Your MFA metrics do not cover this failure mode.

• Ask your incident response team, in writing, whether your email logging would let you answer “what exactly did the attacker read” – not “did they get in,” but the actual content scope – within 24 hours of detection.

• If the answer to that last question is no, that gap is the finding. Both of these incidents made the news because of what leaked, not because of how the attacker got in. Your mailbox is not a communication tool anymore. It’s the least-governed data warehouse in your environment, and it already has a door.

In April 2026, a frontier AI model found thousands of high-severity vulnerabilities buried across every major operating system and browser – flaws human researchers had missed for years. That’s the finding everyone’s been talking about since IBM’s 2026 Cost of a Data Breach Report came out this month. It’s not the one that should worry you.

Page 40 has the real number. Among organizations that suffered a security incident involving their own AI models or applications, 92% lacked proper AI access controls at the time. Not weak controls. Not partial coverage. No role-based access, no MFA, nothing standing between a compromised AI system and the data it could reach.

Read that again. These are companies already breached through AI, and the postmortem still found no lock on the door.

What ninety-two percent actually means

IBM and Ponemon studied 602 organizations across 17 industries this year, and security incidents involving an organization’s own AI models grew from 13% of breaches to 21% – a 61% jump in twelve months. The average cost when AI was involved: USD 5.33 million, against USD 4.70 million when it wasn’t.

Break down the incident types and the pattern gets sharper. Model inversion attacks, where an attacker reconstructs sensitive training data from a model’s outputs, averaged USD 6.07 million – the costliest AI incident type in the report. Prompt injection came in close behind at USD 5.89 million. Cloud misconfigurations touching AI workloads: USD 5.25 million.

None of that is a model behaving badly. IBM’s own language: the root causes were “structural – compromise of connected APIs, applications and cloud misconfigurations, indicating governance failures, not model risk.” Translation, from the people who ran 3,558 interviews to produce this data: you didn’t get breached because the AI hallucinated. You got breached because nobody put a fence around it.

This is shadow IT’s sequel, and it’s worse

Ten years ago it was Dropbox accounts and unsanctioned Slack workspaces. Security teams eventually built visibility programs and moved on. Shadow AI is repeating that exact failure, except this time the unapproved tool doesn’t just store your data – it reads it, transforms it, and sometimes retains it in ways a personal cloud drive never could.

IBM found shadow AI security incidents more than doubled this year, from 20% to 43% of breached organizations, pushing average costs from USD 4.63 million to USD 5.39 million. Regulatory fines now show up in roughly one in five of those incidents – a new data point this year, and the clearest sign yet that shadow AI has crossed from an internal-controls problem into a compliance exposure with a dollar figure attached.

Verizon’s 2026 Data Breach Investigations Report backs this up from a different angle: across more than 22,000 confirmed breaches, unauthorized AI use is now the third most common non-malicious insider action in its dataset, a fourfold increase year over year, with source code the single most common thing employees upload to unauthorized AI tools. The World Economic Forum’s Global Cybersecurity Outlook 2026 found 94% of security leaders now call AI the single biggest driver of change in their threat landscape this year – and yet roughly a third of organizations still have no process at all to assess an AI tool’s security before someone starts using it.

Three separate research organizations, three different datasets, the same finding: adoption outran oversight, and nobody closed the gap behind it.

Why the math just got worse

Governance debt is not new. What’s new is what happens when frontier AI models are the ones finding the cracks. Researchers at UC Berkeley, in a study on frontier AI’s impact on the cybersecurity landscape that IBM cites directly, project that within two years AI capability will favor attackers over defenders by 31.7%. Not eventually. Within two years.

IBM’s own numbers already show this compounding. AI-driven attacks – attackers using AI as the weapon, not the target – rose 56% year over year and now add roughly USD 1 million to the average cost of a malicious breach. Ransomware operators are folding AI into extortion too: 41% of ransomware incidents this year threatened public shaming and media leaks alongside encryption, a shift toward reputational pressure that a governance program built around “detect and patch” was never designed to counter.

Here’s where it gets uncomfortable for anyone still treating this as a 2027 problem. Only 36% of organizations use security AI and automation extensively, and even among those, adoption skews hard toward detection and response. Just 18% apply AI agents to vulnerability scanning – precisely the area where frontier models are moving fastest. Defenders are pointing their best tools at cleanup while attackers point theirs at the front door.

The architectural question nobody’s asking

Every fix under discussion right now is tactical: patch faster, hire more analysts, buy another detection tool. Those all help. None of them close a 92%-lacked-access-controls gap, because that gap isn’t a tooling problem. It’s an architecture problem – the absence of a governed layer between AI systems and the sensitive data they touch, the same layer zero trust already demands for human users.

That’s the premise a small number of platforms are actually built around: apply one policy engine, one audit trail, and one identity model to AI systems and agents that already governs human access, instead of bolting controls on after the model is in production. Kiteworks is one example – its architecture runs on a single-tenant, hardened virtual appliance rather than shared multi-tenant infrastructure, and it extends the same role-based and attribute-based access controls to AI and MCP-based integrations that it applies to a human opening a file. The Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report found the same governance lag IBM did: security programs are extending policy to AI agents far more slowly than they’re extending AI adoption itself. That’s the variable. Not whether you deploy AI. Whether you govern it with the same seriousness you govern everyone else.

What this means Monday morning

1. Pull the access logs on every AI system and application your organization runs in production, including the ones nobody remembers approving. If you can’t produce role-based access and MFA evidence for each one today, you already match the 92%.

2. Force a coordination meeting between whoever owns AI governance and whoever owns security operations. IBM found only 19% of organizations have these two functions actually talking to each other – ask that question in your next staff meeting and watch the room go quiet.

3. Extend identity and lifecycle management to your non-human identities. Only 46% of organizations currently do this, and every AI agent, service account, and API key you can’t inventory is an access-control gap you haven’t found yet.

4. Stop budgeting AI security as a 2027 line item. Eighty-five percent of breached organizations now say they’re increasing spend specifically because of frontier AI threats – that number was 64% before they understood what these models could do. Move before the incident forces the conversation.

The model was never the weak point. It never is. The question was always whether anyone built a fence before turning it loose – and this year’s data says most of you didn’t.

Three independent studies on AI agent governance landed within days of each other this quarter: a developer survey from a password-management vendor, a CISO survey from an identity vendor, and an offensive-security research disclosure headed to Black Hat. None of the three research teams compared notes. All three converged on the same underlying condition – AI agents already reach more data than anyone approved, and almost nothing is watching for it. That convergence isn’t a coincidence, and it isn’t a coding problem. It’s a governance problem, and Kiteworks’ own 459-respondent primary research had already put a number on it before any of these three studies published.

Developers already know their agents are overreaching

Start with the people closest to the keyboard. 1Password surveyed 1,000 security and engineering professionals at large U.S. firms in late May and early June 2026, and 46% said they now run AI agents in production. 71% said those agents can reach sensitive information as a matter of course, not as an edge case. In roughly four out of ten organizations, agents reach data outside their approved scope. Across the full sample, agents touched, on average, twice as much data as anyone had actually signed off on.

Read that again.

Forty percent of developers grant agents persistent access to systems and secrets that stays live after the task that justified it has ended. Forty-seven percent had an agent take an unintended action after following instructions buried in a webpage, a document, an email, or tool output – textbook prompt injection, working exactly as attackers designed it to. A third of developers using agents said their company had already had a breach or incident tied to overprivileged non-human identities. And when Help Net Security’s coverage of the survey asked who should be accountable when an agent causes harm, 65% said someone other than the person currently holding the bag. Five percent said the agent itself should answer for it.

That last number tells you what’s actually broken here. It isn’t the technology. It’s the chain of custody.

CISOs confirm it from the boardroom down

If this looked like a developer-floor problem that leadership had already contained, Okta’s Global CISO Insights 2026 report says otherwise. Okta surveyed 306 security executives globally and found 81% worry about excessive AI access – worry, not merely acknowledge. Fewer than half can do anything about it. Less than half are confident they can identify every AI agent running in their environment (47%), control what those agents can reach (46%), or say what any individual agent is actually allowed to do (45%).

These aren’t executives who lack awareness. They lack visibility, and there’s a difference.

SC World’s coverage of the report lists what’s keeping them up at night: AI-powered phishing (61%), malicious AI agents (49%), deepfake authentication bypass (54%). Meanwhile, only 31% of CISOs globally, and just 12% in the U.S., say they’re fully aligned with their own C-suite and board on what level of AI risk is acceptable. One in four organizations applies the same identity-lifecycle discipline to agents that it applies to humans. Twenty-one percent are still running agents on shared credentials or broad-permission service accounts. Twenty percent leave agent management to individual teams, ad hoc, with no central policy at all.

Two false stories get told about this gap. One says CISOs are behind the curve and just need better dashboards. The other says the technology is moving too fast for any governance model to keep pace, so the sensible move is to wait. Both are wrong. The dashboards exist. What’s missing is a policy layer that applies to non-human identities with the same rigor organizations already apply, however imperfectly, to human ones.

The vulnerability that passes every safety check

Here’s where it gets uncomfortable, because this isn’t a story about misconfigured permissions. It’s a story about permissions that were configured correctly and still failed.

Novee Security researcher Elad Meged found that Claude Code Action, Gemini CLI, and Codex CLI could each be manipulated into leaking secrets despite passing every safety check the harness runs. Anthropic patched the disclosed issues in its tools and paid bounties for the findings. Google’s advisory for the Gemini CLI flaw, tracked as GHSA-wpqr-6v78-jr5g, carries a CVSS score of 10.0 – the maximum severity NVD’s scoring scale recognizes, reserved for flaws that are both trivially exploitable and catastrophic in impact.

The mechanism matters more than the patch. Per Help Net Security’s reporting, the flaw isn’t in the prompt layer at all. A command gets approved as safe at one point in a workflow, then gets consumed downstream by a different component running with different privileges – and nothing re-validates whether that command is still safe in its new context. The safety check did its job. The architecture just didn’t ask it to check twice. Meged presents the full research at Black Hat USA 2026, roughly two weeks from this writing.

That’s the tell. Nobody can patch their way out of a design where trust, once granted anywhere in a pipeline, is assumed to travel everywhere in that pipeline.

The architectural question nobody’s tooling answers

Here’s the whole game: none of this is a detection problem. It’s a containment problem, and containment requires purpose-bound access, a way to cut it off, and a record of what happened, for every identity touching sensitive data, human or agent, under one policy plane rather than two.

Kiteworks put an actual number on it. Kiteworks’ 2026 Data Security and Compliance Risk: Annual Survey Report, fielded in Q2 2026 across 459 respondents, measures the same gap the other three studies describe from the outside. The average organization’s AI Governance Maturity Score came in at 35 out of 100, roughly 6.7 of 19 measured capabilities actually deployed. Data Security Maturity Score averaged 39 out of 100. Multiply the two into the combined Data Security and Compliance Readiness Index and the mean drops to 16.2 out of 100, with a median of 11.5.

Half of organizations are below 11.5. Sit with that for a second.

Now look at the specific controls that would close this gap. Purpose binding, restricting an agent to the task and scope it was actually authorized for, is deployed at just 26% of organizations; 74% lack it entirely. An AI kill switch, the control that would cut off an agent’s lingering access after a task ends, exists at only 21%. Human-in-the-loop review for high-risk AI actions sits at 30%. AI-specific DLP: 28%. AI access logs actually forwarded to SIEM: 33%.

Then there’s the audit trail, which is the part that should worry you most. The survey asked whether organizations could produce a complete AI audit record within one business day – the artifact needed after an incident, not before one. Only 27% said yes. Roughly half couldn’t produce one at all. Within one hour, only 17% could. No AI containment control measured is deployed at more than 31% of organizations, and this isn’t a theoretical gap: 64% of organizations have already put AI into production, and 70% of those are running three or more use cases simultaneously. Eighty percent had at least one security incident, general or AI-specific, in the past year. Sixty-three percent faced a compliance consequence. Sixty-five percent discovered shadow AI usage they didn’t know existed.

This is the same gap 1Password measured in developers, Okta measured in CISOs, and Meged demonstrated in production tooling. It just has a number attached now.

The fix isn’t a new layer bolted onto agents. It’s one governance plane covering every identity that touches sensitive data, human employee or AI agent, with the same purpose binding, the same revocation, and the same evidence-quality audit trail – one policy, not two. That’s the premise behind platforms like Kiteworks’ approach to AI data governance: single-tenant isolation and one policy engine covering email, managed file transfer, SFTP, web forms, and APIs, instead of five systems each guessing independently at what “safe” means. Whether the request comes from a person or an agent, the same access rule, the same kill switch, and the same audit trail apply. Kiteworks is one example of that architecture, not the only one, and not a checkbox to tick either.

What to do Monday morning

1. Inventory every agent with production access this week – not the ones IT knows about, the ones actually running. Nobody can govern what nobody can enumerate, and roughly half of CISOs in the Okta data can’t fully enumerate their own agents.

2. Bind every agent’s access to the task it was provisioned for, with an expiration, not a standing grant. Persistent access that outlives the task is the default failure mode in the 1Password data, not the exception.

3. Build the kill switch before it’s needed. Test it quarterly. Twenty-one percent of organizations have one today; the goal is to be in that group before an incident forces the question.

4. Route agent access logs to SIEM and set a one-business-day SLA for producing a complete audit record. Roughly half of organizations currently cannot do this at all.

5. Re-scope safety checks to re-validate at every privilege boundary a command crosses, not just at the point of initial approval. That’s the exact gap Meged is presenting at Black Hat.

The agent that reached data nobody approved didn’t break any rule it was given. It just wasn’t given enough rules that traveled with it.

Something strange showed up in Clyde & Co’s newest boardroom survey. The same executives who spent the last two years building out AI governance committees are now telling researchers, anonymously, that the risk outran the committee. Clyde & Co’s Corporate Risk Radar 2026 polled 700 board members, C-suite executives, and General Counsel across ten sectors and eight regions, and the technology risk number didn’t inch up this year. It jumped from 46% to 86% rating it high impact, in twelve months. Forty points. Read that again. That’s not a trend line. That’s a category getting re-priced in real time.

The confidence number and the capability number don’t match

Here’s the part that should bother a skeptical CISO more than the 40-point jump itself. Seventy-six percent of Clyde & Co’s respondents say AI, data privacy, and cybersecurity regulation is evolving faster than their organization can absorb. Only 68% say they have a mature AI governance framework in place. And yet 88% say they feel prepared to mitigate technology risk overall.

Sit with that math for a second. Confidence: 88%. Regulatory pace outrunning capability: 76%. Actual governance maturity: 68%. Those numbers describe three different organizations, except they’re the same organization, answering three different questions on the same survey. Clyde & Co’s own researchers called it out directly, noting the 88% figure “may suggest confidence is running ahead of maturity.” That’s the polite version.

This isn’t one survey’s anomaly

Here’s where it gets uncomfortable. Kiteworks ran its own survey of 225 security, IT, and risk leaders for the 2026 Data Security Forecast, published five months before Clyde & Co’s, across a completely different sample. It found the same gap, gave it a name, and the name is worse than “governance maturity.” Call it the containment gap. Sixty-three percent of organizations cannot enforce purpose limitations on their own AI agents. Sixty percent cannot quickly terminate an agent that’s misbehaving. Fifty-five percent cannot isolate an AI system from the broader network once something goes wrong. Organizations are watching their AI systems closely. Watching is not the same as stopping.

The timing makes it worse. CrowdStrike’s 2026 Global Threat Report found AI-enabled adversary operations increased 89% year over year, and average breakout time, the window between initial access and lateral movement, fell to 29 minutes, with the fastest observed intrusion completing in 27 seconds. A governance model built around quarterly reviews and after-the-fact log analysis was already slow. Against a 29-minute breakout window, it isn’t a governance model. It’s a postmortem.

Why the math got worse this year

Three things compounded at once, and none of them are going to reverse.

Start with dependency. It concentrated. Clyde & Co found that as AI adoption accelerated, organizations became more reliant on a smaller pool of third-party technology providers and more exposed at the integration points between systems. Verizon’s 2025 Data Breach Investigations Report shows exactly where that leads: third-party involvement in breaches doubled year over year, to 30% of all incidents analyzed. Fewer vendors, more blast radius per vendor.

Then there’s geopolitics. It stopped being background noise. Clyde & Co found geopolitical risk’s direct commercial impact rose from 49% to 72% in a single year, and the World Economic Forum’s Global Risks Report 2026 puts geoeconomic confrontation at the top of its global risk list, with half of the 1,300-plus experts it surveyed expecting a turbulent world over the next two years, up 14 points from last year. Hostile actors use instability as cover. Instability is no longer occasional.

The piece that actually ties the first two together is audit trails, the thing that would let a security team prove what happened and shut it down fast, and they’re the weakest link in most environments. Kiteworks’ Forecast Report found 33% of organizations lack evidence-quality audit trails entirely, and another 61% have logs fragmented across systems, present but not aggregated, normalized, or usable in a timeframe that matters. Organizations without evidence-quality audit trails trail by 20 to 32 points on every AI governance metric measured, more than industry, region, or budget explains on its own.

The architectural question

None of this gets fixed by buying another monitoring dashboard. Monitoring is precisely the capability everyone already has. Sixty-three percent purpose-limitation failure and 60% containment failure exist alongside heavy investment in visibility tools, not because of their absence. The gap isn’t seeing the problem. It’s stopping it before the 29-minute window closes.

That reframes the actual question. Not “how do we watch AI systems more closely,” but “where does the decision to allow or block a specific data access get made, and how fast can it execute.” An architecture that enforces access, encryption, and audit logging at the point where data actually moves, rather than reconstructing it later from five different systems, closes exactly the gap both surveys describe. Kiteworks is one example of a platform built on that premise: a single-tenant hardened virtual appliance with one policy engine governing email, managed file transfer, SFTP, web forms, and APIs, generating one evidence-quality audit log instead of the fragmented version 61% of organizations are stuck reconciling. It’s not the only way to build this. It is the property the containment gap is actually asking for.

What to do Monday morning

• Pull your AI agent inventory. For each one, ask: can you terminate its access in under five minutes, without a change ticket? If the answer isn’t yes across the board, that’s a containment problem, not a monitoring problem.

• Check whether your audit logs are aggregated or just accumulated. Five systems logging separately isn’t an audit trail. It’s a filing cabinet you’ll open after the damage is done.

• Get AI governance onto the board’s top-five list this quarter. Boards that already prioritize it run 26 to 28 points ahead on every maturity metric measured – the biggest single lever in either survey.

• Map your third-party AI and data providers the way you’d map a single point of failure. A 30% third-party breach rate says that’s what they are.

The organizations that get hit hardest in 2026 won’t be the ones with the smallest security budget. They’ll be the ones whose board minutes never mentioned AI governance until the incident report did.

On June 23, 2026, a general practice network running 21 clinics across Sydney, Melbourne, Canberra, and Queensland discovered someone had been inside its systems, reading Medicare numbers, pathology results, and referral letters. Patients found out more than three weeks later, according to SBS News’s reporting on the Partnered Health breach.

That three-week gap between discovery and disclosure is not the interesting part of this story. Regulators already told you what is. In October 2025, Australia’s Federal Court fined a different pathology company $1.6 million for exactly that kind of gap, stacked on top of $4.2 million for the breach itself. Read the judgment and you’ll notice something practitioners rarely say out loud in a vendor briefing: not knowing fast enough is now its own compliance failure, penalized separately from whatever let the attacker in.

What actually happened at Australian Clinical Labs

The case is Australian Information Commissioner v Australian Clinical Labs Limited (No 2) [2025] FCA 1224 – the first civil penalty ever ordered under Australia’s Privacy Act 1988. The underlying event was a 2022 ransomware attack on IT systems Australian Clinical Labs (ACL) had inherited three months earlier through its acquisition of Medlab Pathology. Health data belonging to more than 223,000 people ended up on the dark web.

The Federal Court split the $5.8 million penalty three ways: $4.2 million for failing to take reasonable steps to protect the data in the first place, $800,000 for taking too long to assess whether the breach was serious, and another $800,000 for taking too long to tell the regulator once it was. ACL also picked up a $400,000 costs order.

Two of those three penalty lines have nothing to do with the ransomware. They exist because the organization couldn’t work out fast enough what had happened and who needed to know. That’s the part worth sitting with. The court didn’t treat detection speed as a mitigating factor in sentencing. It treated detection speed as a standalone legal obligation, with its own price tag.

The pattern: regulators are pricing the gap, not just the breach

Under Australia’s Notifiable Data Breaches scheme, once an entity has reasonable grounds to suspect an eligible breach, it gets 30 calendar days to complete an assessment, full stop, and the OAIC treats that as a ceiling, not a target. Notification to affected individuals and the regulator has to follow “as soon as practicable” after that.

Partnered Health is currently living out the same math in public. Twenty-one clinics, a malicious actor with access to clinical data, and a three-week window between discovery and patient notification, per the same SBS reporting and coverage from ACS’s Information Age. Nobody outside the organization yet knows whether that timeline will draw the same kind of penalty ACL did. What we do know, from the ACL precedent, is that the regulator now has a court-tested template for arguing it should.

Why the math got worse

Here’s the part that should bother you more than the fines. According to CrowdStrike’s 2026 Global Threat Report, the average eCrime breakout time – how long it takes an attacker to move from initial access to lateral movement inside your environment – fell to 29 minutes in 2025, with the fastest observed breakout clocked at 27 seconds. In one case in the report, data exfiltration started within four minutes of the initial compromise.

Attackers now operate on a clock measured in minutes. Regulators now expect an answer measured in days. Most security organizations are still operating on a clock measured in weeks, because their evidence about what happened lives in five or six different systems: email logs, file-share logs, VPN logs, endpoint telemetry, whatever the SFTP box happens to keep. None of those speak the same language, and nobody owns correlating them until an incident forces the question. That mismatch – attacker speed, regulatory expectation, and actual organizational capability all moving at different velocities – is why a three-week disclosure delay increasingly reads as negligence rather than diligence.

The architectural question

The tactical response to this is “hire more forensics analysts” or “buy another SIEM connector.” Neither fixes the actual problem, which is architectural: if sensitive data moves across email, file sharing, SFTP, APIs, and increasingly AI agent workflows acting on an employee’s behalf, and each of those channels logs independently, you don’t have a security gap so much as an accounting gap. You cannot answer “what left, through which channel, to whom, and when” quickly if the answer requires reconciling five formats first.

This is the argument behind platforms built as a single control plane for data exchange rather than a stack of point tools. Kiteworks, for instance, is built around one consolidated, tamper-evident audit log across every channel it governs – rather than a separate log per protocol that a security team has to normalize by hand during an incident. That’s an architectural choice, not a feature checkbox, and it’s the kind of gap Kiteworks’ 2026 Data Security and Compliance Risk: 2026 Forecast Report flags as a recurring blind spot across sensitive data channels. Whether you buy Kiteworks or build the equivalent yourself, the point stands regardless of vendor: a fragmented logging architecture is now a legal liability, not just an operational inconvenience.

What this means Monday morning

1. Time yourself. Pick a random 72-hour window and see how long it actually takes your team to produce a complete list of who accessed what, from where, across every channel you run. If the honest answer is more than an hour, you’ve found your gap.

2. Count your consoles. If answering that question above requires logging into more than one system, you don’t have a SIEM problem – you have an architecture problem that a SIEM can’t fully solve on its own.

3. Check your incident response plan for a hard clock. Not “notify when we’re confident,” but a documented 30-day assessment deadline that maps to the actual NDB scheme requirement, with an owner attached.

4. Ask your board a specific question, not a general one. Not “are we secure,” but “how long would it take us to answer the four forensic questions regulators will ask after a breach: what, through which channel, to whom, and when.”

5. Read the ACL judgment before your next tabletop exercise. It is the closest thing Australia has to a court-tested rubric for how slow is too slow.

The ransomware attack against ACL happened in 2022. The penalty for not knowing fast enough landed in 2025. Regulators are no longer willing to wait for your forensics team to finish before deciding whether you were negligent – which means your architecture can’t wait either.

On March 25, 2026, the Nuclear Regulatory Commission approved 10 CFR Part 53, the first entirely new reactor licensing framework since 1989. It took effect five weeks later, on April 29. The trade press covered it as a licensing story: faster paths to market for small modular and advanced reactors, a win for an industry riding AI-driven power demand. That’s not wrong. It’s also not the story that matters to you. The real story is buried in the framework’s design: Part 53 is risk-informed and technology-inclusive, which means it trades fixed prescriptive checklists for continuous, metric-driven proof. You don’t file a safety case once. You maintain one. And most of the sector currently cannot.

The rule everyone is reading wrong

10 CFR already required more than paperwork before Part 53 showed up. Section 73.54 requires licensees to maintain “high assurance” that digital systems tied to safety, security, and emergency preparedness are protected against cyberattack, consistent with NIST SP 800-53 and NRC Regulatory Guide 5.71. Section 73.77 requires notification of a qualifying cyberattack within a fixed window, followed by a written report. Part 21 makes suppliers, vendors, and licensees jointly responsible for evaluating and reporting defects in safety-relevant components, across everything from fuel fabrication to waste storage.

None of that is new law. What’s new is that Part 53 removes the fallback option. Under the older frameworks, a licensee could point to a static safety analysis report and call it done. Part 53’s risk-metric model assumes you’re continuously generating the evidence that report used to freeze in place. “High assurance” was always supposed to mean assurance, not intention. Part 53 just removed the last places to hide that distinction.

This is not a nuclear problem

Here’s the uncomfortable part: nuclear’s evidence gap isn’t unique to nuclear. It’s the default condition of regulated industry, and the data says so directly. The Black Kite Third-Party Breach Report 2026 found that across roughly 200,000 organizations it monitors, the average cyber-risk grade is a 90.27 -- an A. At the same time, 53.77% of those same organizations carry at least one active critical vulnerability. Read that twice. A grade that good and a failure rate that high are not supposed to coexist, and yet they do, because a compliance grade measures whether you documented the right things, not whether the things you documented are actually enforced.

The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found the same split inside the energy and utilities sector specifically, the category nuclear sits within: the highest AI governance maturity score of any industry surveyed, second-highest data security maturity score, and a dominant behavioral pattern the report labels “Policy-Led” -- governance and regulatory awareness running roughly 1.86 times further ahead of enforced technical controls than the survey’s baseline expectation. Translation: the sector knows exactly what good compliance looks like. It has not finished building the plumbing that proves it’s happening.

Why the timing makes it worse

Three things are converging on nuclear at once, and none of them were designed with the others in mind. AI-driven power demand is pulling a wave of new reactor developers into the licensing pipeline right as that pipeline shifts to a continuous-evidence model. Operational technology threat activity is accelerating industry-wide -- Dragos’s 2026 OT Cybersecurity Report tracked 119 distinct ransomware groups hitting more than 3,300 industrial organizations in 2025, up from 80 groups the year before, and found elevated weaknesses in secure remote access configurations in nearly half of its services engagements. And Part 21’s supply-chain obligation depends on visibility the sector’s own vendor base doesn’t reliably provide: Black Kite’s analysis of its “Elite 50” -- the vendors most shared across the Forbes Global 2000 -- found 70% carry at least one unpatched, already-known-exploited vulnerability, and the median gap between breach detection and public disclosure runs 73 days, stretching to a 117-day average. Black Kite calls that gap the “silent window.” A nuclear supplier sitting inside that window is still, for months at a time, a supplier whose defect attestations a licensee is legally relying on.

Stack a growth cycle, an accelerating OT threat curve, and a supply chain with a multi-month blind spot on top of a licensing framework that assumes continuous proof, and you get a sector where the compliance program most people built for the old rules is already behind the rules that just replaced them.

The architectural question

The instinct here is to answer with more documentation: a longer policy, a more detailed supplier questionnaire, another audit checklist. That instinct is not wrong, exactly. It’s just no longer sufficient, because the thing Part 53 and Section 73.77 actually test is whether you can produce a real-time, defensible record of who touched what data, when, and through which channel -- on demand, not reconstructed after the fact from five disconnected systems.

That’s an architecture problem, not a policy problem. The World Economic Forum’s Global Cybersecurity Outlook 2026 found that organizations it classifies as highly resilient are far more likely than less-resilient peers to build security into procurement and formally assess supplier maturity as a standing practice, not a point-in-time gate. That only works if the underlying exchange of data, between licensees, suppliers, and regulators, runs through a system built to log and prove it continuously, not five disconnected tools stitched together after the fact. The specific vendor matters less than the requirement: one policy layer across every channel data actually moves through, generating a single exportable record instead of five partial ones. And whatever architecture you land on, it needs to govern people and AI agents under the same policy from the outset -- Part 53’s technology-inclusive framing means more of this data traffic will be agent-touched soon, and a system that governs humans carefully while leaving machine access as an afterthought hasn’t actually closed the gap.

What this means Monday morning

If you’re inside 10 CFR, or watching it because your industry is three years behind nuclear on the same curve, the checklist is short:

1. Pull your Section 73.54 evidence trail and time how long it takes to produce a real-time access record for a single safety-relevant system. If the answer involves exporting logs from more than two tools, you’ve found your gap.

2. Map which of your suppliers fall under Part 21’s reporting obligation, and ask when each last had its security posture independently assessed -- not attested, assessed.

3. Time-box a tabletop for Section 73.77: from detection to a defensible written report, how many hours, and how many of them are spent reconciling data instead of writing the notification.

4. If you’re a new entrant building a Part 53 program from scratch, build the evidence architecture before the point solutions, not after.

A compliance program that looks finished on paper and one that survives a Section 73.77 clock are not the same program. Part 53 was written to make sure everyone finds out which one they built.

It’s Tuesday morning. Your identity provider is degraded, half your file shares won’t resolve, and the board wants a recovery timeline before the 10am bridge call. You say “a few days, tops.” Everyone on the call nods. That nod is the problem.

Accenture’s newly released cyber resilience research -- a pulse survey of 1,000 C-suite executives across 13 countries -- found that 81% of leaders assume critical IT downtime will run 10 days or less in a serious incident. The measured average: three to six months. That’s not an estimation error. That’s a plan built on a number that has almost nothing to do with what actually happens once the plan gets tested.

The 10-Day Number Was Never Real

Start with what the survey actually measured. Eighty-seven percent of organizations now describe cyber disruption as a recurring operating condition, not a rare event. Seventy-two percent say preventing all disruption is no longer realistic given how interconnected their systems have become. Fifty-four percent still believe strong protection controls are sufficient to guarantee continuity after an attack -- and CEOs are 136% more likely than CISOs to say regulatory compliance alone assures resilience.

Put those together and you get an executive population that is, on average, more confident than its own security leadership and less accurate. Sixty-four percent of respondents told Accenture they design and govern technology on the assumption that systems stay generally stable and available, even though eight in ten of those same people expect degraded operations during a real disruption. They are planning around a condition they already admit won’t hold.

This Is a Structural Gap, Not a Knowledge Gap

Here’s the part that should bother you more than the wrong number: Accenture frames this as a “false consensus.” CEOs and CISOs aren’t uninformed. They’re each assuming the other one already agrees on ownership, on sequencing, on what gets protected first. Seventy-four percent of organizations report that resilience is treated primarily as a security or IT responsibility. Only 43% actually govern it as a shared enterprise outcome. That gap between “we agree” and “we’ve never actually tested whether we agree” is what turns a contained technical incident into a business-wide one.

The World Economic Forum’s Global Cybersecurity Outlook 2026, produced in partnership with Accenture, backs this up from a different angle: 94% of respondents now name AI as the most significant driver of change facing their security programs, yet CEO and CISO risk priorities still diverge on what to do about it. Two roles, one incident, two different mental models of who’s supposed to act first.

AI Broke the Math That Made “10 Days” Plausible

Ten days used to be a defensible planning number, back when the gap between a vulnerability being discovered and being weaponized ran in weeks. That gap is gone. CrowdStrike’s 2026 Global Threat Report clocked average breakout time -- the interval between initial compromise and lateral movement -- at 29 minutes, down from 48 minutes the year before, with a fastest observed breakout of 27 seconds. AI-enabled attacks were up 89% year over year. Separately, a benchmark cited in Accenture’s research found frontier AI models now succeed at finding and exploiting a vulnerability on the first attempt 83% of the time, a rate that was close to zero not long ago.

A response plan built for weeks-long attacker timelines cannot survive contact with a 29-minute breakout. That’s not a tooling problem you patch your way out of. It’s a design assumption that quietly expired while most incident response plans stayed exactly as written.

Your Recovery Plan Assumes You Own the Failure. You Often Don’t.

Sixty-nine percent of organizations in Accenture’s survey say their operations increasingly depend on complex internal and third-party digital ecosystems. Sixty-one percent say their ability to sustain critical operations depends directly on external partners. Only 38% have a clear view of which of those dependencies actually matter most. That’s not a hypothetical exposure -- Black Kite’s 2026 Third-Party Breach Report found a median disclosure lag of 73 days between a vendor’s breach and public notification, with an average silent window stretching to 117 days. Attacks get detected in a median of 10 days. Everyone downstream of that vendor finds out months later, if they’re told at all.

This is the point where “patch faster” and “buy another detection tool” stop being sufficient answers, because neither one addresses a partner’s breach happening on their timeline, not yours. The trait that actually separates a fast recovery from a six-month slog is simpler than most incident response plans admit: knowing exactly where sensitive data lives, who -- internal or external, human or automated -- can reach it, and being able to prove and revoke that access without waiting on someone else’s process. That’s an architectural property, not a control you bolt on afterward. It’s the premise behind treating data governance as a single, unified plane rather than a stack of point tools with their own logs and their own blind spots -- which is the design idea behind platforms like Kiteworks, built with single-tenant isolation and a consolidated, real-time audit trail specifically so an organization can answer “who touched this file, when, and from where” without stitching together five systems during an active incident. And the standing-access problem isn’t limited to human partners anymore: Kiteworks’ own 2026 Data Security and Compliance Risk: Annual Forecast Report found that among organizations already running AI agents in production, 63% cannot enforce purpose limitations on what those agents are allowed to touch, and 60% cannot terminate a misbehaving one. AI agents are a fast-growing category of identity with standing access to sensitive data, right alongside your human users -- and most organizations still haven’t extended the same access governance and kill-switch controls to them that they’d never skip for a new employee.

What This Means Monday Morning

You don’t need a new framework. You need five uncomfortable conversations this week.

1. Ask your CEO, in the same room as your CFO and general counsel, what recovery timeline they’re actually assuming. Write the number down. Compare it to Accenture’s three-to-six-month average.

2. Identify the smallest set of functions the business cannot survive without, and name who owns the decision to sequence their recovery -- before an incident, not during the bridge call.

3. Pull the list of third parties with standing access to your sensitive data. If you can’t produce it in an afternoon, that’s your answer to whether you have “a clear view of your value chain.”

4. Test your incident response plan against a 30-minute breakout window, not a 30-day one. Most tabletop exercises still assume the slower world.

5. Ask who can revoke a partner’s data access right now, without a change request or a ticket queue. If the answer takes more than a sentence, fix that first.

The 10-day number was never a forecast. It was a story executives told each other because testing it felt unnecessary until the week it wasn’t. Accenture just handed every CISO the data to have that conversation before the incident forces it.

Consider a coding agent inside your engineering org that merges nine pull requests before your first standup. It authenticates the same way it did last Tuesday: as a senior engineer, through a service account nobody ever got around to replacing. Nothing breaks. Nothing trips an alert. That’s the problem. The agent didn’t hack anything. It just used a login nobody built for it, and now nobody can prove who did what.

That scene isn’t a stretch. It’s the pattern a new dataset just confirmed at scale.

The Okta numbers say the quiet part out loud

The Okta Enterprise AI Index, built from anonymized sign-on data spanning June 2022 through June 2026 across more than 20,000 organizations, tracked over a hundred distinct AI products and consolidated them into 74 vendor suites. The market split in two. AI-native companies (Anthropic, OpenAI, Cursor) grew their enterprise customer base more than four times over that period, while established software makers like Microsoft, Google Workspace, and Adobe added AI features at a slower clip. Anthropic passed OpenAI in enterprise accounts in March 2026 and led it in monthly active users the month after, according to Help Net Security’s coverage of the index. Microsoft 365 still dwarfs both on raw volume.

None of that growth is the real story. The real story is what rides along with it: every new AI platform shows up with its own logins, its own permissions, and its own web of app-to-app connections built on secrets and tokens that nobody centrally tracks.

Vendors multiply. Credentials sprawl faster.

Fei Liu, Principal Emerging Tech Researcher at Okta, put it plainly: “Our data shows that as the number of platforms grows, so does the risk of over-permissioned apps and orphaned tokens.” Her prescription is a mindset shift. Security teams need to stop treating each new AI tool as “adding a new software vendor” and start treating it as an expansion of the identity fabric they’re already failing to fully govern.

Here’s where it gets worse. When agents need credentials to actually do the work (read a repo, query a database, send an email), most organizations reach for what’s already lying around. “We’re seeing a heavy reliance on traditional service accounts and static API keys, and unfortunately, we still see instances of shared human logins being used to authorize agentic workflows,” Liu told Help Net Security. The consequence isn’t abstract. “When an AI agent inherits a human’s login, you completely lose your audit trail – you can no longer distinguish whether a critical action was taken by an employee or autonomously by an algorithm.”

Sit with that sentence. You cannot answer “who did this” for actions your own agents took, using logins your own IT team issued. That’s not a hardening gap. That’s a structural blind spot in the thing every incident response plan assumes exists: a trustworthy log.

Why this is worse than the same problem looked last year

Credential-based blind spots aren’t new. What’s new is the speed at which adversaries exploit them and the sheer number of machine identities piling up behind each human one.

CrowdStrike’s 2026 Global Threat Report found AI-enabled adversary operations up 89% year over year. Average eCrime breakout time fell to 29 minutes; the fastest observed breakout occurred in 27 seconds. Attackers are already moving through trusted identities and SaaS sessions at machine speed. An audit log that reads “the engineer” when an agent actually took the action isn’t just a compliance headache during an audit. It’s a detection failure at the exact moment defenders have the least time to notice anything is wrong.

Layer on the sheer scale of the identity sprawl. CyberArk’s 2025 Identity Security Landscape study found 82 machine identities for every human in the average enterprise, with 42% of those machine identities carrying privileged or sensitive access. That’s despite 88% of organizations still defining “privileged user” as something that only applies to humans, a gap between what security teams think privileged access covers and what it actually covers. And Verizon’s 2026 Data Breach Investigations Report found that “shadow AI is now the third most common non-malicious insider action” in enterprise data-loss-prevention datasets, a fourfold increase over the year before. The unsanctioned, ungoverned instance of AI is growing faster than any identity program built to contain it.

Put those three data points together and you get an uncomfortable picture: more machine identities than anyone can track, a growing share of them privileged, attackers who already know how to move through trusted sessions in minutes, and an expanding chunk of agent activity that never shows up as agent activity in the log.

The architectural question

The instinct is to patch this the way security teams patch everything: more identity tickets, faster service-account rotation, a project to inventory every API key by Q4. That instinct doesn’t scale, because it treats an agent’s identity as a provisioning artifact, something you set up once and forget, rather than something you govern continuously, at the moment of data access, alongside every human who touches the same content. I don’t think this is really a technology problem. It’s a laziness-at-scale problem: it’s easier to hand an agent somebody’s login than to build it one of its own.

The alternative is to stop asking IAM to solve a data-access problem. The architectural approach worth examining evaluates every agent request at the moment it’s made, against role- and attribute-based policy scoped to that specific agent and task, so credentials never sit in a config file or a prompt where they can be copied or exposed. Done right, every action lands in an audit trail that names the agent that acted, not a human whose login it happened to be using. It’s one policy plane governing what humans and agents alike are allowed to touch. Not a separate, looser set of rules for whichever agent got provisioned last. Kiteworks’ 2026 Data Security and Compliance Risk Forecast Report names this exact failure mode (agents inheriting human credentials to reach sensitive content) as one of the defining AI governance gaps enterprises will be graded on this year.

That’s the architectural bet worth making: govern the access, not just the account.

What this means Monday morning

• Pull your SSO logs this week and separate “service account doing agent work” from any identity that was actually provisioned as non-human. Most organizations can’t currently answer this question in under an hour.

• For every agent with write access to anything sensitive, answer Okta’s three questions in writing: where does it run, what can it connect to, and what can it actually do.

• Stop provisioning new agents against shared human logins, even as a temporary bridge. Temporary is how an unauditable action shows up in a breach investigation eight months from now.

• Push authorization decisions down to the data layer, per request, so revoking one agent’s access doesn’t mean rotating a password that nine humans also use.

• Put a lifecycle and an access review on every non-human identity you create, the same way you already do for employees who change roles or leave.

The next nine pull requests your agent merges will carry somebody’s name in the log. Make sure it’s the agent’s, and not yours.

Picture a mid-size insurer’s Tuesday standup in early July: the security architect pulls up a dashboard of active AI agents provisioning claims data, and nobody in the room can say with confidence how many of those agents still hold credentials from a pilot that ended back in March. That’s not a hypothetical. It’s the ordinary condition VentureBeat’s Q3 2026 trends survey of 800 IT leaders across the US and UK just put a number on, and the number is worse than a slow news week would suggest, in exactly the way that matters. The share of IT leaders describing their organization as “mature” in AI deployment fell from 40% six months ago to 23% today, a 17-point drop, according to VentureBeat’s coverage of the survey. Read that as bad news and you’ve missed the point. Read it as the first honest self-assessment IT leaders have produced all year, and here’s the real thesis: the confidence gap isn’t eroding trust in AI. It’s exposing a governance gap that was there the whole time, hiding behind six months of overstated maturity claims.

Twenty-three percent now call themselves mature. Six months ago it was forty.

The VentureBeat survey didn’t ask leaders to guess at industry sentiment. It asked them to self-report against a defined maturity model, and the honest answers dropped by nearly half. The same survey isolated why: of every AI security practice measured, non-human identity governance is the least adopted, in place at just 21% of organizations -- the practice covering service accounts, API keys, and autonomous agents. Credentials that don’t sleep and don’t show up in a quarterly access review unless somebody builds one specifically to catch them.

Here’s the number that makes the gap indefensible rather than merely inconvenient: non-human identities now outnumber human users at 83% of organizations surveyed. In four out of five organizations, the majority identity type accessing systems and data is the one with the least governance attached to it. VentureBeat’s own maturity tiering makes the payoff for closing that gap explicit: organizations in the top tier were five times more likely to report no barriers to expanding their AI agent deployments than the average organization surveyed. Maturity isn’t a badge. It’s the gap between scaling agents on purpose and discovering how many you have after something goes wrong.

The machines already outnumber you, and nobody governs them

This lines up with every other identity-focused research shop’s numbers, too, just with different figures attached. Palo Alto Networks’ 2026 Identity Security Landscape report, based on a survey of nearly 2,930 cybersecurity decision-makers, put the ratio of machine identities to human identities at 109 to 1, up from 82 to 1 just a year earlier, according to Help Net Security’s coverage of the report. Of those 109 machine identities per human, 79 are AI agents specifically. The same report found nine out of ten organizations had suffered a successful identity-related breach in the prior twelve months.

Put the two data sets side by side and the pattern stops looking like a coincidence. Identity governance programs were built for humans who get onboarded, badge in, and get offboarded on a predictable schedule. They were never built for a population that now dwarfs the human one and keeps growing. CrowdStrike’s 2026 Global Threat Report adds the attacker’s view of what that gap costs: 82% of detections last year were malware-free, meaning adversaries increasingly succeeded by using valid credentials and trusted identity flows rather than breaking anything, with valid account abuse behind 35% of cloud intrusions, per CrowdStrike’s own summary of its findings. An unmanaged non-human identity is a standing credential an attacker doesn’t even need to steal cleverly. They just need to find it sitting there, unattended.

More agents, same credentials, compounding debt

Here’s a question I keep coming back to: why is this getting worse now, after years of warnings about service-account sprawl? The answer is velocity. Palo Alto’s report projects machine identities will grow 77% over the next twelve months, with AI agent identities specifically growing 85% in that window. Gartner, meanwhile, predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs and inadequate risk controls as leading causes.

Those two numbers describe the same problem from opposite ends. Agent deployment is accelerating faster than any identity program built around human onboarding cycles can absorb, and a meaningful share of those deployments will get killed specifically because nobody built the governance layer first. Most organizations are still provisioning agents the way they provisioned service accounts a decade ago: one shared credential, broad scope, renewed automatically, reviewed rarely. That approach was already a liability when the ratio of machines to humans sat in the single digits. At 109 to 1, and climbing, it’s not a liability anymore. It’s an admission that nobody is actually in control of what has access to what.

Identity provisioning was never built for this volume

The tactical response -- buy another identity governance module, extend the existing IAM tool to cover service accounts, run a quarterly cleanup script -- treats this as a scale problem. It’s an architecture problem. Human identity governance answers “who is this person, and what should they be allowed to do.” Non-human identity governance at 109-to-1 ratios has to answer a harder question continuously and automatically: what specific data can this specific agent touch, for this specific task, right now, not what it was granted eighteen months ago when somebody provisioned it in a hurry.

That reframing is why a handful of vendors are building AI governance directly into the data access layer instead of bolting it onto the identity layer after the fact: mediating every agent request against a unified policy engine at the point of access, rather than issuing agents standing credentials to a file share or a database, and logging each access as an evidence-quality audit record instead of a line in a log file nobody reads. Kiteworks’ own 2026 Data Security and Compliance Risk Forecast Report names exactly this gap -- ungoverned non-human identity access to sensitive content -- as one of the defining exposures organizations will carry into next year. This isn’t the only architecture built on that premise, one that treats agents as governed identities alongside humans rather than an afterthought bolted onto human IAM. But it’s a credible answer to a question every organization in the VentureBeat survey is now being forced to answer, whether it has a vendor picked out or not.

What this means Monday morning

The 17-point confidence drop is a market correcting its own instrumentation, not a market losing faith. Treat it as your cue to act, not your excuse to wait until the number stabilizes.

1. Inventory non-human identities as a standalone exercise, separate from your human identity audit. If you can’t produce a current count of active service accounts, API keys, and agent credentials, you don’t have a governance program. You have an assumption.

2. Map access at the data layer, not the account layer. Knowing an agent exists isn’t the same as knowing what content it can reach. Build the second map.

3. Kill standing, broad-scope credentials for agents wherever you find them. Replace blanket access with per-agent, per-task authorization that expires by default.

4. Demand evidence-quality logs for every non-human access event, not just alerts. An auditor asking “prove it” six months from now won’t accept “we believe so.”

5. Re-run your own maturity self-assessment honestly before your next board update. A lower, accurate number this quarter beats a flattering, wrong one from last quarter.

The organizations whose confidence dropped 17 points didn’t get worse at AI. They got honest about it first. Everyone else is still measuring the wrong thing.

It’s Tuesday morning. The board deck is due at noon. Somewhere in your building, a senior executive who personally signed off on the AI acceptable use policy is pasting a client contract into a personal ChatGPT account to get a faster first draft, because the sanctioned enterprise tool requires two extra approval clicks and this is due in three hours. This is not a hypothetical. It’s the median behavior of your leadership team, and the data says so with a straight face.

Two-thirds of the C-suite is doing this right now

A 2026 survey by Microsoft solutions partner TrustedTech found that 65% of senior decision-makers admit to using unapproved, unsanctioned AI tools at work, more than double the 31% rate among lower-level employees. Three in four employees in that same survey said they understand the security and privacy risks involved. Read that twice. This isn’t a knowledge gap. It’s a compliance gap, and it’s concentrated exactly where the blast radius is largest.

Teramind’s 2026 Shadow AI Behavior Report puts a finer point on it: 69% of C-suite leaders prioritize speed over security when using AI, against 37% of frontline staff. And 67% of enterprise AI activity now runs through personal accounts on platforms the company already licenses. Not unvetted tools. Not shadow startups nobody heard of. The same enterprise-grade platform IT paid for, minus every control that made it enterprise-grade in the first place.

This isn’t shadow IT. It’s something worse

Classic shadow IT is an employee reaching for a tool nobody approved. What TrustedTech and Teramind describe is different, and it’s harder to defend in front of a board. The tool is approved. The contract is signed. The admin controls, the retention limits, the training opt-out, all of it negotiated and paid for. The executive just isn’t using any of it, because the personal login is one tab over and nobody’s checking.

TrustedTech’s own research team doesn’t dance around the motive: most shadow AI users aren’t ignorant of the risk. They’re deliberately choosing to take it. A meaningful share, 24% of senior decision-makers by TrustedTech’s count, said they route around approved tools specifically because they worry the company is watching how often they use AI and that it could affect how they’re perceived. So the honest read isn’t “leadership doesn’t understand AI risk.” It’s “leadership understands the risk, weighed it against looking slow or looking surveilled, and picked convenience.” That’s not a training failure. That’s a decision, made repeatedly, by the people who are supposed to model the opposite.

Why the excuse doesn’t hold anymore

For years, the industry let executives off easy with some version of “they’re busy, they’re not technical, cut them slack.” That excuse dies here. These are the same people asking a board about AI ROI on Thursday and asking IT why the sanctioned tool is “too slow” on Friday. They know what a data exfiltration headline costs the company, they’ve probably approved the budget for the incident response retainer, and they’re routing regulated content through an account with zero of the contractual protections anyway. This isn’t a literacy gap in a population that reads breach disclosures for a living. It’s a rank-has-its-privileges problem, and it’s compounding as AI-forward pressure from boards and investors gets louder every quarter.

The fix isn’t another policy. It’s governing the data

Every acceptable use policy assumes the reader intends to comply and just needs reminding. That assumption collapsed the moment 65% of the people who wrote the policy admitted to breaking it with open eyes. A document has no enforcement mechanism against someone who has already decided the personal account is worth the risk.

The only approach that survives contact with this data moves control off the login screen and onto the content itself: every AI request against sensitive data evaluated against classification and policy at the moment it happens, regardless of which account, which device, or which job title is asking. That’s a different architecture than most AI governance programs have built. It puts per-request access control and audit logging on the data, enforced through a single-tenant, hardened deployment rather than left to whichever account an executive happens to be logged into that afternoon. It doesn’t ask the CFO to behave. It doesn’t care whether the CFO behaves. The content either meets the access rule or it doesn’t.

That’s the uncomfortable design principle here: the control has to work precisely because you cannot count on the person with the most access and the least oversight to opt into being governed.

What this means Monday morning

1. Pull actual usage data comparing sanctioned-account AI activity to total estimated AI usage across your org. If the Teramind ratio holds, two-thirds of your activity is probably happening somewhere your logs can’t see.

2. Build an executive-specific track for AI governance, separate from the general staff training deck a VP skims and deletes. The population driving this risk isn’t the population most compliance programs are built to reach.

3. Audit friction on your sanctioned AI tools honestly. If the personal version is faster, that’s a product complaint hiding inside a compliance violation, and it needs a product fix, not just a policy memo.

4. Move enforcement to the data layer: per-request access control and audit logging that applies the same way whether the request comes from a governed account, a personal one, or an AI agent acting on someone’s behalf.

5. Stop presenting shadow AI to the board as an awareness problem. Three in four employees already know the risk. Present it as what it is: an accountability gap at the level with the least accountability pressure on it.

The people who approved your AI policy are, by the numbers, the people most likely to be routing around it right now, on a platform your company already pays for. Governance that depends on them choosing otherwise has already failed. Build the version that doesn’t ask.