An unauthorized party accessed a third-party file-storage system. That’s it. No zero-day exploit. No nation-state tooling. A third-party platform holding protected health information didn’t have sufficient controls to prevent unauthorized access -- and patients in nine US cities are now learning their medical records, government IDs, and health insurance data were exposed.

Amazon-owned One Medical disclosed the breach on June 22. The access window ran June 8 to June 11, targeting records archived from One Medical Seniors -- the organization formerly known as Iora Health. The same day, extortion group ShinyHunters issued a “final warning” claiming to hold 8.8 TB of One Medical data.

The extortion claim may be inflated. The breach is confirmed.

The Attack Vector Is the Story

Sophisticated attacks make for good headlines. This wasn’t one.

The third-party file-storage problem is endemic to how healthcare operates. Patient records flow through dozens of vendor systems -- labs, insurers, billing platforms, specialty referral networks, acquired practices with legacy architectures. Each integration point is a potential exposure surface. Iora Health was acquired, rebranded as One Medical Seniors, and absorbed into Amazon’s One Medical. The archival system holding its records predated that acquisition chain -- a pattern common in healthcare M&A, where inherited infrastructure outlasts the organizations that built it.

What HIPAA Actually Requires Here

The HIPAA Security Rule requires covered entities and business associates to implement technical safeguards on every system that handles PHI: access controls, audit trails, transmission security, encryption. The rule is not aspirational. It is law.

The practical reality is that a Business Associate Agreement is only as good as the platform behind it. Healthcare organizations sign BAAs with dozens of vendors. Fewer evaluate whether those vendors’ platforms actually implement the technical safeguards the BAA claims to provide. The HIPAA Minimum Necessary Rule requires that access to PHI be limited to what is minimally necessary for a specific purpose -- but a general-purpose file-storage platform with broad organizational access grants doesn’t enforce that distinction.

For archival systems specifically -- platforms that store historical records from patients who may no longer be active in the care relationship -- the access governance challenge is acute. The authorization model needs to reflect the current organization’s structure, not the legacy entity’s. It needs to enforce minimum-necessary access on a per-record basis. Most general-purpose file-storage platforms don’t provide this level of granularity. They were designed for enterprise productivity, not clinical data governance.

The Extortion Layer Changes the Calculus

ShinyHunters’ 8.8 TB claim adds a dimension that most healthcare incident response plans weren’t built for.

Traditional breach response follows a regulatory playbook: investigate, determine scope, notify affected individuals, notify regulators. That playbook is unchanged. But it now runs in parallel with an extortion actor who has a financial incentive to maximize the organization’s exposure -- and who will use the data’s sensitivity as leverage.

The regulatory obligation and the adversarial pressure operate under different logics, different timelines, and different stakeholder interests. Legal wants to control disclosures. Communications wants a clear narrative. The attacker wants uncertainty and urgency.

The organizations that handle this best are the ones that can credibly bound the exposure. When you know exactly what was accessed -- because your audit trail says so -- and you know the data was encrypted in a way the attacker can’t readily decrypt, the leverage dynamic shifts. When the scope is unknown and the data is plaintext, you’re negotiating blind.

The Architecture That Prevents This

PHI in archival storage needs AES-256 encryption at rest and in transit, attribute-based access controls that enforce minimum-necessary access on a per-record basis, and an audit trail that captures every access event with enough fidelity to reconstruct the breach scope in minutes rather than weeks.

Kiteworks secure data exchange is built for exactly this use case -- sensitive content exchange and archival in healthcare and other regulated environments, with HIPAA compliance built into the architecture rather than layered on afterward. Single-tenant deployment eliminates the shared-infrastructure risk class that made the One Medical incident possible. ABAC means that access is governed by what a user is authorized to see based on their role, department, and the data’s classification -- not just whether they have an organizational login.

The One Medical breach involved a third-party platform that apparently lacked these controls. The fix is not to avoid third-party platforms. It is to choose ones built for the data classification and sensitivity of the data they hold.

What This Means for Every Healthcare Organization

One Medical is Amazon-backed, well-resourced, and presumably invested in security. They still disclosed a breach affecting patients in nine cities.

The third-party risk doesn’t discriminate by organizational size or sophistication. It affects every healthcare entity that has ever acquired another practice, integrated with a legacy vendor, or relied on a general-purpose platform for clinical data archival.

The work is an audit: identify every third-party system that holds PHI, review the BAA and the underlying security documentation, assess whether the platform’s access controls and audit capabilities meet the HIPAA Security Rule’s technical requirements. Then replace the ones that don’t.

Every week that audit is deferred is a week the exposure remains open -- and a week closer to the moment a ShinyHunters final warning arrives in your inbox.

The attack didn’t require stolen credentials. It didn’t trigger an anomaly alert. It didn’t need malware. Varonis Threat Labs disclosed CVE-2026-42824 last week -- a vulnerability chain in Microsoft 365 Copilot Enterprise they named SearchLeak. A crafted link, one victim click, and Copilot -- already authenticated, already trusted, already holding access to email, calendar, and files -- harvested MFA codes, calendar events, and private documents and routed them to attacker-controlled infrastructure.

No credential theft. No malware. No anomalous traffic pattern. The AI did it.

Microsoft patched it on June 4. The architecture it exposed has not been patched at all.

The Architecture That Made This Possible

Three weaknesses, none individually critical, chained into something that was.

A parameter-to-prompt injection let attackers embed instructions directly into a Copilot Search query via a malicious URL. An HTML rendering race condition let those instructions execute before the session’s security checks resolved. A CSP bypass using Bing SSRF -- routing data requests through a trusted Microsoft domain -- let the results flow out without triggering browser security controls.

Together, these turned the victim’s own AI assistant into a fetch-and-transmit agent for the attacker. The victim’s session was legitimate. The data access was authorized. The exfiltration was invisible to every SIEM, DLP, and zero trust network control in the path -- because they were all looking for anomalies, and this produced none.

The patch is deployed. The vulnerability class it represents is not patched at all.

Every enterprise AI tool with broad access to email, files, and communications carries a version of this risk. The specific chained weaknesses Varonis found in Copilot are closed. The architectural condition that made them exploitable -- AI agents that operate under implicit trust, with inherited permissions and no independent access governance -- remains the default deployment model for virtually every major enterprise AI platform.

The Part the Incident Reports Don’t Say Clearly Enough

Here’s what is actually happening, and why framing this as a “Microsoft Copilot bug” understates the problem.

Enterprise AI assistants are useful because they can access everything. They read email to draft replies. They search file repositories to surface documents. They synthesize calendar data to prepare meeting summaries. The breadth of access is the product. That breadth is also what makes these tools an extraordinarily attractive target for anyone who can influence their instructions.

SearchLeak worked because influencing Copilot’s instructions was achievable via a crafted URL parameter. Other attack paths exist: injecting instructions into documents the AI will summarize, embedding adversarial content in shared files, manipulating data the AI ingests from a connected integration. Any input channel through which attacker-controlled content can reach the AI’s instruction context is a potential injection surface.

The fundamental question isn’t “can Copilot be patched?” It’s “what prevents an AI agent with broad data access from being instructed to do things it shouldn’t?” For most organizations right now, the honest answer is: not much.

What AI Data Governance Actually Means

Traditional security controls were designed for humans. Anomaly detection looks for unusual patterns -- large transfers, unexpected destinations, off-hours access. Identity verification checks that the credential matches the principal. DLP watches for keywords and data patterns crossing defined boundaries.

SearchLeak defeated all of these because the activity it produced was indistinguishable from normal AI-assisted work. A Microsoft service, under legitimate credentials, accessing Microsoft data, routing through Microsoft infrastructure. Every detection signal said “this is fine.”

AI data governance operates at a different layer. Instead of detecting anomalous behavior after it happens, it enforces policy at the point of access -- controlling what the AI agent is permitted to query, access, and transmit in the first place. This requires treating AI agents as governed principals rather than extensions of the user. The AI assistant’s access to sensitive content should be governed by explicit policy: what categories of data it can access, under what operational context, for what purposes. An AI that can help draft a proposal should not have access to MFA codes and HR records, regardless of what the user’s session technically permits.

Attribute-based access control is the mechanism that makes this possible. Policies evaluate data attributes (classification, sensitivity labels, folder path), user attributes (role, department, clearance level), and contextual attributes (the nature of the access request, the pathway it arrived through) before returning content. Kiteworks secure data exchange is built around this model -- applying ABAC to every sensitive content access event, whether initiated by a human or an AI agent, within defined policy boundaries and with a complete audit trail for every interaction. The architecture that makes SearchLeak-class attacks possible is ungoverned AI access. The architecture that prevents them is content-level zero trust.

Why This Is the Moment

The Kiteworks 2026 Forecast Report identified AI data governance as the defining security challenge of the year, noting that organizations were deploying AI productivity tools faster than they were implementing governance infrastructure to protect the data those tools access. SearchLeak is the incident that turns that forecast from a warning into a record.

Non-human identities -- AI agents, service accounts, automated pipelines -- now account for a growing share of all enterprise data access. The identity and access management frameworks most organizations have were built for humans. The policies, audit scopes, and detection logic were designed around human behavior patterns.

SearchLeak is the first major public demonstration of what happens when that gap is weaponized. It won’t be the last. Researchers who understand prompt injection, SSRF, and AI session mechanics are now actively looking for this class of vulnerability across every enterprise AI platform. The next disclosure is a question of who finds it first.

The organizations that get AI governance right before the next incident are the ones that will be able to say “our architecture prevents this” instead of “we were also patched on June 4.”

What CISA actually found

CVE-2026-42271 is a command injection vulnerability in LiteLLM, the widely deployed open-source AI gateway that routes agent requests across LLM providers through a unified API. The affected endpoints are POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list -- the MCP server test interfaces that let the gateway verify connections to external data sources and tools.

Input passed to these endpoints goes directly to system-level operations without adequate sanitization. The result: arbitrary command execution on the proxy host.

On its own, this requires credentials. That barrier disappears when CVE-2026-42271 is chained with CVE-2026-48710, a BadHost/Starlette authentication bypass in the same platform. Forged host headers the framework accepts as valid eliminate the credential requirement entirely. The combination is unauthenticated remote code execution, reachable by anyone who can reach the LiteLLM gateway on the network.

CISA described this as evidence of “sustained targeting of AI gateway infrastructure.” This is the second LiteLLM flaw weaponized in active attacks within a month. AI gateways -- long treated as middleware rather than security boundaries -- are being systematically probed. Threat actors have identified them as high-value entry points: they sit in a privileged position between enterprise data systems and the AI models consuming that data.

Federal civilian agencies have until June 22 to patch under BOD 22-01. Organizations operating under FISMA or with federal contracts subject to CMMC 2.0 requirements should treat that deadline as a hard floor, not a suggested timeline.

Why MCP is the new perimeter

The Model Context Protocol standardizes how AI agents connect to data sources, tools, and services. Its adoption has been fast and largely ungoverned.

That gap is structural. MCP is new. The governance frameworks are still catching up. Organizations that spent years building careful access controls for human users -- role-based permissions, attribute-based policies, immutable audit trails -- have deployed MCP infrastructure with almost none of that rigor applied. The LiteLLM exploit shows what that looks like in production: test endpoints left accessible on a live AI gateway, processing arbitrary network input, connected to a platform that can reach document repositories, communication archives, and data warehouses.

LiteLLM exposes over 200 data connectors through its gateway architecture. Each connector is a potential data access path. An ungoverned MCP endpoint grants AI agents access to whatever the gateway can reach -- and AI agents can retrieve, summarize, and act on data at a speed and scale that no behavioral detection tuned for human patterns will catch.

Patching CVE-2026-42271 removes one vulnerable instance. It doesn’t change the architecture that made it vulnerable in the first place.

AI agents are service accounts. Govern them like it.

Paras Malhotra, CISO of Starburst, published a piece the same day CISA dropped the CVE. His framing is the right one: AI agents querying enterprise data through MCP endpoints are, from a security architecture standpoint, service accounts -- automated principals that need scoped permissions, short-lived credentials, documented owners, and the same RBAC and ABAC enforcement that governs human users.

Most organizations are granting AI agents implicit trust they would never extend to a contractor. No credential rotation. No documented ownership. No audit trail recording what the agent retrieved and why. Access rights that often reflect the scope of the engineer who deployed the agent rather than the minimum the agent actually needs for its defined function.

Service account governance for AI agents isn’t complicated. It’s the same discipline security teams already apply to automated systems -- transferred to a new category of principal that most organizations haven’t formally classified yet.

Minimum necessary permissions. An AI agent that summarizes contract documents doesn’t need read access to the HR system. Scope every MCP connection to the minimum dataset the agent requires for its specific task.

Short-lived credentials and documented ownership. Long-lived credentials for AI agents carry the same liability as long-lived credentials for any privileged account: they maximize the damage window when compromised. Treat agent credentials with the same rotation cadence applied to human service accounts.

Enforcement at the platform layer, not the model layer. LLMs can be manipulated through prompt injection to request data outside their intended scope or take actions their configuration was never meant to permit. Enforcement must happen at the infrastructure layer -- at the point where the agent’s request meets the data system. If the model’s output is the last line of defense, there is no defense.

Audit trails for every agent action. Regulatory frameworks from HIPAA to CMMC 2.0 to FedRAMP require organizations to demonstrate who accessed what data, when, and under what authorization. That obligation doesn’t stop applying because the “who” is an AI agent. Audit logs of every query, retrieval, and action aren’t just a compliance requirement -- they’re how you reconstruct what happened when something goes wrong.

The LiteLLM CVE is a symptom of a governance posture that treats AI gateway infrastructure as middleware rather than as a security boundary. The fix isn’t just a patch. It’s deciding that AI agents get the same access control discipline you’ve spent years building for humans.

At Build 2026, Microsoft’s security research team extended their AI agent threat taxonomy with seven new failure modes. The list is worth reading carefully, not because Microsoft discovered these vulnerabilities but because naming them matters. Security programs cannot systematically defend against threats they can only describe vaguely. “AI agents are risky” is not an operational posture. Seven named attack vectors with documented characteristics and recommended test coverage is.

Here they are:

1. Agentic Supply Chain Compromise, adversarial influence through natural language embedded in prompts, retrieved documents, or instructions from upstream agents, without any malicious code required

2. Goal Hijacking, instructions that appear aligned with the agent’s legitimate task while silently redirecting its terminal objective

3. Inter-Agent Trust Escalation, a compromised agent claiming false identity or inflated permissions to an orchestrator that lacks cryptographic verification

4. Computer Use Agent Visual Attack, adversarial content rendered in a graphical interface that redirects the agent’s actions through the visual channel

5. Session Context Contamination, data introduced early in a session that biases the agent’s reasoning in later steps, without triggering safety controls at any individual decision point

6. MCP/Plugin Abuse, exploitation of the Model Context Protocol or plugin layer to access data the agent should not reach, exfiltrate content, or cross organizational boundaries

7. Capability/Architecture Disclosure, agents revealing implementation details that enable more targeted attacks

Number 6 is the one I want you to think about most carefully, because it is not theoretical.

The One That Already Happened

In May 2025, Asana launched MCP server integration with LLM capabilities. A logic flaw in the implementation meant that users in one organization could, under certain conditions, see task data, project metadata, comments, and uploaded files from other organizations. Not a hack. Not an external attacker. A logic flaw in the MCP integration itself that crossed tenant boundaries.

Roughly 1,000 customers were affected before Asana discovered the problem in June 2025 and took the server offline.

Microsoft now calls this category MCP/Plugin Abuse and treats it as one of seven priority AI agent attack surfaces. The Asana incident is what that failure mode looks like in production, no exploit code, no credential theft, just a misconfigured integration producing cross-organizational data visibility at scale.

The reason I find this particular incident clarifying is what it says about where the risk lives. The instinct when thinking about AI agent security is to focus on external adversaries deliberately constructing attacks. The Asana breach required no adversary. It required only an AI integration deployed without sufficient policy enforcement at the protocol layer. The MCP server had the access. The logic to scope that access correctly was absent.

What Microsoft Built in Response

Two things arrived alongside the taxonomy.

The Microsoft Execution Container is runtime containment for AI agents, an enforcement environment that restricts what agents can access and do, independent of how the agent itself is configured or instructed. Agent output, plugin calls, and tool invocations are treated as untrusted until evaluated against policy. The architecture stops trusting the agent to self-limit.

Agent Control Specifications are portable, auditable policy definitions that describe what an agent is permitted to do: which tools, what data, which external endpoints. The specifications are separate from the agent implementation, so they can be versioned, reviewed, and updated without modifying agent code.

ASSERT (Adversarial Stress and Security Evaluation for Resilient Thinking) is Microsoft’s red-teaming toolset that operationalizes the seven failure modes into testable scenarios.

Together, these three tools create what I’d call an agent security perimeter, a bounded, enforceable, auditable space for agentic workloads. For enterprises building on Microsoft’s stack, this is a meaningful starting point.

But notice what it is: an execution-layer control. It governs what agents can do at runtime. It does not, by itself, govern what sensitive content agents are permitted to retrieve, process, and transmit, particularly for organizations with regulated data under CMMC, HIPAA, GDPR, or ITAR.

The Gap That Still Exists

Here is the governance problem that the Execution Container does not solve on its own.

An AI agent in an enterprise workflow operates asynchronously. It chains tool calls. It acts on behalf of a user whose session may have concluded hours before the agent finishes the work that session triggered. It can invoke external APIs, write to connected systems, and process content from sources that traditional DLP tools were not built to inspect.

Traditional access controls were designed for users with sessions, roles, and static permission sets. They do not map cleanly onto agents that need continuous authorization across multi-step tool chains, that may be operating across dozens of MCP-connected systems simultaneously, and whose “session” in any meaningful sense is not the human session that initiated the workflow.

For regulated industries, this gap has compliance teeth. AI agents accessing Controlled Unclassified Information for a defense contractor, or processing protected health information in a healthcare workflow, are subject to the same access control, audit logging, and transmission security requirements as human access to that data. The CMMC assessor or HIPAA auditor will not accept “an AI agent did it” as an explanation for why the access was not logged or why the content moved without authorization.

The content governance layer, explicit policies on what data agents can reach, classification-aware access controls, audit documentation, has to exist separately from the execution containment layer. One governs what agents can do. The other governs what they can touch.

What Practitioners Should Do Right Now

Microsoft’s recommended response to the seven failure modes is concrete and worth following:

• Inventory your agent supply chain. Know every agent you’re running, what tools it can invoke, and what data it can reach.

• Generate a software bill of materials for every deployed agent.

• Verify agent identity cryptographically where possible, not through assertion.

• Add all seven failure modes to your red-team coverage matrix.

• Audit human-in-the-loop controls as security controls, not just usability features.

I’d add two things to that list.

First, map every MCP integration in your environment against the data it can access. Then ask whether the policy enforcement at the MCP layer is explicit and auditable, or whether it simply inherits whatever permissions the underlying service exposes. The Asana breach is what the latter looks like when it goes wrong.

Second, if your organization handles regulated content (CUI, PHI, ITAR-controlled technical data) treat AI agent access to that content as a compliance event that requires the same documentation as human access. That means audit logs. That means classification-aware access controls. That means a content governance framework that extends to cover AI actors, not just human ones.

Microsoft’s taxonomy is a gift to security teams. It turns “AI agents are risky” into seven specific things you can test for, engineer against, and report on to leadership. Use it that way.

A presidential order signed June 2, 2026 did something no executive order has done before: it named AI agents as distinct legal actors in a data-access liability context. Section 4 of Promoting Advanced AI Innovation and Security criminalizes using AI agents to unlawfully access data subsequently used for criminal purposes.

The 30-day voluntary pre-release review for frontier models got all the headlines. Section 4 got almost none. That’s a problem, because the pre-release provisions apply to AI developers. Section 4 applies to you

What Section 4 Actually Says

The provision is precise. It criminalizes using AI agents to unlawfully access data that is then used for criminal purposes. The order doesn’t fully define “unlawful” -- enforcement and litigation will build that standard. But its shape is visible in the governance requirements that HIPAA, CMMC, PCI DSS, and SOX already impose: authenticated identity, purpose-limited access, minimum necessary scope, and a tamper-evident audit trail.

If your AI agents touch regulated data and you cannot produce a governance record demonstrating that access was authorized, scoped, and attributable to a human decision-maker -- Section 4’s liability attaches to that gap.

Here’s the hard part. Most organizations cannot produce that record

The Numbers Behind the Exposure

Kiteworks Data Security and Compliance Risk: 2026 Forecast Report surveyed 225 enterprise leaders in Q4 2025. The governance gap it documented is not a future risk. It describes the current state of enterprise AI deployments.

63% of organizations cannot enforce purpose limitations on their AI agents. 60% cannot quickly terminate a misbehaving agent. 33% lack evidence-quality audit trails. 61% have fragmented logs that cannot produce a coherent chain of custody for a single agent interaction.

Think about that last number. Not poorly formatted logs. Logs that are structurally incapable of producing the record Section 4 now implicitly requires.

The shadow AI dimension makes this worse. The 2026 DTEX/Ponemon Insider Threat Report found shadow AI is now the top driver of negligent insider incidents. 92% of organizations say generative AI has fundamentally changed how employees access and share information. Only 13% have integrated AI into their business strategies.

That 79-point gap between behavioral change and governance response is where unauthorized agent data access happens. And it’s now where Section 4 liability lives.

The Governance Record Is the Defense

Section 4’s practical test: can you demonstrate that your AI agent’s data access was authorized, scoped, and attributable? That answer lives in four components.

Authenticated agent identity. Every agent interaction must trace to an authenticated identity linked to a human authorizer. The delegation chain must be preserved. Without it, attributability is impossible.

Operation-level access control. Role-based controls designed for humans don’t work for agents. An agent authorized to read a folder is not automatically authorized to download its contents. Minimum necessary access must be enforced at the operation level.

Tamper-evident audit trail. Not reconstructed after the fact. Contemporaneous, complete, and immutable. A record assembled in retrospect is a forensic project, not a defense.

FIPS 140-3 validated encryption. For federal agencies and regulated enterprises, the encryption protecting agent-accessed data must meet validated cryptographic standards.

This isn’t a new governance architecture. It’s the architecture HIPAA, CMMC, and SOX already require for human data access. The problem: organizations deployed AI agents before building the equivalent governance layer for them.

The Threat Environment Is Not Patient

The 2026 CrowdStrike Global Threat Report documented an 89% year-over-year increase in AI-enabled adversary attacks, with 82% of detections now malware-free. Attackers are already using AI agents as operational tools. They’re targeting the same data your agents access.

The governance record that defends against Section 4 liability is identical to the architecture that limits blast radius when an agent is compromised by an attacker. The two problems have one solution. The urgency is not hypothetical.

What to Do This Week

Inventory every AI agent currently in production that touches enterprise data -- including shadow deployments. The inventory gap is the liability gap.

Audit your audit trail against the Section 4 standard. The test is not whether logs exist. It is whether they can produce -- without reconstruction -- the authenticated identity, human authorizer, specific operation, data accessed, and policy context for any agent interaction.

Brief your General Counsel. Section 4 converts what was a CISO-level technical conversation into a federal criminal liability question. Your legal team needs to be in the room before the first enforcement action, not after.

For federal agency readers: Section 2(c) mandates CISA Binding Operational Directives within 30 days of the June 2, 2026 order. They are mandatory for civilian agencies. Your procurement timeline is measured in weeks.

The architecture platforms like Kiteworks are building -- data-layer governance that intercepts every agent request, enforces ABAC policy at the operation level, and produces a tamper-evident audit trail -- is what Section 4 presupposes must exist between enterprise data and AI systems.

Section 4 is not the end of this story. California’s 20+ AI laws are already in force as of January 1, 2026. The EU AI Act’s high-risk provisions are enforcing this year. The regulatory arc is not bending toward less accountability for AI agents.

The question is not whether governance requirements are coming. It’s whether your organization builds the record before the first inquiry -- or under it.

U.S. financial institutions spend $35-40 billion annually on AML compliance -- and investigators waste most of that budget manually assembling evidence before any real analysis can begin. That is the problem FIS and Anthropic built the Financial Crimes AI Agent to solve: a system that compresses anti-money-laundering case investigations from hours to minutes, assembling evidence automatically, evaluating transactions against known typologies, and surfacing the highest-risk cases for human review.

BMO and Amalgamated Bank are the first in line. Broader availability is planned for H2 2026.

At the same time, job listings from Kirkland & Ellis tell a different story -- not a press release, but a hiring binge. Two AI Infrastructure Director roles posted May 27, 2026 call for experience with “on-premise GPU environments.” Approximately 85 AI-related roles are open. The firm has stated around 180 people will execute the project. The job listings point toward fine-tuning open-source LLMs on Kirkland’s own hardware, trained on Kirkland’s own data.

Two institutions. Two of the most regulated data environments on earth. Same fundamental problem.

The Governance Gap That Makes Both Announcements Uncomfortable

Kiteworks Data Security and Compliance Risk: 2026 Forecast Report -- drawn from a Q4 2025 survey of 225 enterprise leaders -- found that 100% of organizations have agentic AI on their 2026 roadmap. Only 37-40% have meaningful containment controls. Sixty-three percent cannot enforce purpose limitations on their own agents. Sixty percent cannot quickly terminate a misbehaving agent.

That gap was already alarming before the most regulated industries in the economy decided to go agent-first.

AML investigations touch BSA-regulated transaction data, SAR filings, and customer identity records. Legal AI agents will touch privileged communications, discovery materials, and client confidences. These are not general-purpose productivity tools. They are agents operating inside the most legally sensitive data environments that exist.

The Bank Secrecy Act does not know it’s 2026. Attorney-client privilege was not suspended because the model is good.

What FIS Got Right -- and What Everyone Else Has to Reckon With

FIS built the governance architecture into the agent from the start. Client data stays within FIS-controlled infrastructure. Every conclusion links back to its source. Every decision stays with the human investigator.

Anthropic’s Jonathan Pelosi, Head of Financial Services, put it precisely: “We embedded our Applied AI team inside FIS to build the Financial Crimes AI Agent together, so every conclusion the agent reaches links back to its source data, and every decision stays with the investigator.”

That is what governed agentic AI looks like.

The problem is that most deployments do not start there. The 2026 DTEX/Ponemon Insider Threat Report found that 92% of organizations say generative AI has fundamentally changed how employees share information -- yet only 13% have integrated AI into their business strategies. Shadow AI is the top driver of negligent insider incidents. Employees are uploading client files, entering transaction data, and generating AI artifacts that persist far beyond the original task.

The 2026 Forecast Report frames this as a structural gap: 15-to-20 points between the governance controls organizations claim to have and the containment controls that would actually stop a misbehaving agent.

The Fine-Tuning Question Nobody Is Asking Loudly Enough

Kirkland’s GPU ambitions raise a specific problem that deserves more attention than it is getting.

When you fine-tune a model on your own data, that data does not merely inform the model -- it is, in a real sense, embedded in it. If privileged client communications, strategic memoranda, or unreleased deal information enters a fine-tuning pipeline, the question of who can access that knowledge -- and how it might be reconstructed or elicited from the model -- is genuinely unanswered by existing privilege doctrine.

The “Agents of Chaos“ study -- a 38-author collaboration led by Northeastern University, with co-authors from Harvard, MIT, Stanford, Carnegie Mellon, and other institutions, published February 2026 -- documented what happens when AI agents operate without robust identity verification. Agents accepted instructions from anyone who messaged them, including attackers who changed their display names to impersonate the system owner. Researchers broke production-deployed agents with conversation alone -- no technical expertise required.

A legal AI agent that can be manipulated through a prompt injection embedded in opposing counsel’s documents is not a distant risk. It is an architectural gap that exists today.

The Architecture That Cannot Be Bolted On After the Fact

Authenticated identity with a human delegation chain. Every agent must be authenticated before accessing any data, and every interaction must be traceable back to a human who authorized it. The Agents of Chaos researchers found agents failed because there was no reliable way to verify who was giving instructions. Cryptographic identity verification at the data layer is the fix -- not a smarter model.

Attribute-based access control at the operation level. Authorization granted at connection time and left open is not access control -- it is an attack surface. An AML agent authorized to read case files is not thereby authorized to download them or transmit them externally. Every request must be evaluated against the data’s classification and the specific operation, in real time.

Evidence-quality audit trails. The 2026 Forecast Report found that organizations with evidence-quality audit trails are 20-32 points ahead on every other governance dimension. The audit trail is not one control among many. It is the foundation that makes every other control defensible when the examiner arrives.

This is the architectural pattern that data-layer governance platforms like Kiteworks are building around: every AI data request authenticated, authorized, and logged at the data access point -- independent of the model, independent of the agent framework.

What to Do Before Your Agents Go Live

Map what agents will actually touch. Not capability descriptions -- data classifications. If an agent can access financial records, transaction logs, or client files, existing compliance obligations apply immediately.

Enforce the delegation chain before deployment. Every agent workflow needs a named human authorizer identifiable in the audit record. If current architecture cannot produce that record, close that gap first.

Treat shadow AI in regulated environments as a critical incident. 73% of organizations worry unauthorized AI use is creating invisible data loss pathways. In a bank or law firm, that translates directly to BSA violations, privilege waivers, and discovery failures.

Audit the containment gap. A frank internal assessment against purpose binding, kill switch capability, network isolation, and audit trail completeness takes a week. Explaining the gap to an examiner takes considerably longer.

The agent-first bank is open. The agent-first law firm is being built. The governance infrastructure -- in most organizations -- is not ready for either.

That gap closes one of two ways: through deliberate architecture, or through an incident that makes it impossible to ignore.

The filing happened quietly. No breach notification. No ransomware headline. Just an 8-K -- the SEC form public companies use to disclose material events to investors -- tied to unauthorized AI use by an employee. It is the first of its kind. It will not be the last.

Shadow AI governance has been a known problem for years. Employees route sensitive work through unapproved AI services. Data leaves the organization without logging, attribution, or any enforcement control. Security teams flag it. Policies get written. And then the next quarter’s productivity numbers arrive and the policies sit.

That calculation changed the day that 8-K landed. Under SEC Regulation S-K Item 106, public companies must disclose material cybersecurity incidents within four business days. When an employee AI incident crosses the materiality threshold and triggers that requirement, it is no longer an internal governance failure. It is an investor-facing disclosure event, filed under penalty of securities law.

The Risk Profile Was Already Visible

The data on shadow AI exposure has been accumulating for two years. Cyberhaven’s 2024 research found that 11% of the data employees paste into ChatGPT is confidential. Samsung learned this through direct experience when engineers leaked proprietary source code through the same tool, leading to an internal ban.

Those numbers describe the pre-governance state most enterprises are still operating in. According to the same research, 68% of organizations have experienced data leaks linked to AI tool usage, and only 23% have formal AI security policies in place. The gap between exposure and preparedness is not narrow.

Cyera Research Labs’ 2025 State of AI Data Security Report sharpens the picture: only 13% of enterprises have strong visibility into how AI is being used across their organization. That means 87% of companies face the 8-K scenario without the basic telemetry to detect it, contain it, or characterize it within a four-day disclosure window.

Citizen Developers Make It Worse

The exposure is not limited to individual employees copying text into a chat interface. The EY Responsible AI Pulse Survey found that two-thirds of companies allow citizen developers -- employees without formal engineering roles -- to independently build and deploy AI agents. Only 60% of those companies provide any formal organization-wide policy governing that development. Half have no meaningful visibility into how those agents are using AI tools at all.

An employee-built agent that routes sensitive documents through an unapproved AI service does not look like a data breach from the inside. It looks like productivity. The agent is doing what it was designed to do. The data is flowing to where the employee intended. The problem is that the employee’s intent is not the same as the organization’s authorized data handling policy -- and no one is watching.

That is the definition of shadow AI at scale: not rogue employees, but well-meaning ones, building things no governance framework has accounted for.

What “Material” Actually Means

NowSecure CEO Alan Snyder’s framing at Help Net Security is precise: the core risk is data leakage -- actual transfer of sensitive information to unapproved AI services. Not theoretical exposure. Not potential access. Actual transfer.

Snyder’s recommended framework maps the AI usage landscape into three categories: authorized, unauthorized, and unknown. Most organizations know their authorized tools. They do not know the scope of unauthorized or unknown usage. And it is the unknown category -- AI embedded in third-party applications, SDKs, and agent frameworks that employees never consciously chose -- that creates the most unpredictable exposure.

The 8-K precedent applies that unknown exposure to the materiality test. If a data transfer through an AI tool meets the threshold for material impact on investors -- financial, operational, or reputational -- it triggers the four-day clock. An organization with no visibility into its shadow AI footprint cannot know whether that clock has already started.

The Cost Baseline Is Established

The financial frame is not speculative. The IBM Cost of a Data Breach report puts the global average breach cost at $4.88 million. That number represents detection, containment, notification, and remediation -- before any regulatory penalty, securities enforcement, or class-action exposure.

An 8-K filing adds a new cost layer. It signals to investors that a cybersecurity event was material -- which invites inquiry into what controls were in place, what governance existed, and what the organization knew before the incident. A company that filed no AI governance policy, maintained no AI usage log, and had no enforcement controls in place answers those questions badly.

The standard for reasonable care in AI governance is being written right now, in real time, by the filings and enforcement actions that follow incidents like this one. Organizations that act before the next filing have a narrower window than they may assume.

What Infrastructure-Level Enforcement Looks Like

Policy documents do not stop data transfers. Enforcement controls do.

Kiteworks‘ Compliant AI and Data Policy Engine classifies AI interactions against the exact authorized, unauthorized, and unknown framework Snyder describes -- but at the infrastructure layer, not the policy memo layer. An employee who attempts to route sensitive content through an unapproved AI service hits an enforcement control before the transfer completes. Every AI agent interaction with Kiteworks-managed content is attributed, logged, and available for audit. That kind of record turns an 8-K event into a contained incident with a defined scope rather than an uncontrolled disclosure with an unknown blast radius.

The Precedent Is Set

The first 8-K tied to employee shadow AI use is already in the public record. Every CISO and general counsel now has a precedent to cite when arguing that AI governance is an investor-facing issue. Every board that has not yet asked its security leadership about shadow AI exposure has one more reason to add it to the next agenda.

Snyder’s recommended starting point is specific: establish an AI ops team, publish a pre-cleared tool list, build a classification system for AI usage, and gain visibility into AI embedded in applications and agent frameworks. Those are operational steps, not aspirational ones. They are achievable before the next incident -- which is the only timeline that matters now.

The 8-K has been filed. The materiality threshold has a reference point. Shadow AI governance is no longer a compliance nuisance -- it is a disclosed, investor-facing category of risk, and the organizations without controls are already behind.

I’ve sat in enough M&A due diligence rooms to know what the data discovery conversation sounds like. The acquiring company asks for a data inventory. The target company produces one. It covers the systems everyone knows about -- the production databases, the primary cloud storage, the SaaS platforms in active use. Then the first discovery scan runs post-close and finds the abandoned S3 bucket from a 2019 SaaS migration that nobody decommissioned. The customer records inside are four years old, still contain PII, and the retention policy that was supposed to apply to them was never implemented.

That pattern is not unusual. It’s nearly universal.

Enterprise Data Discovery Governance Is Failing at the Architecture Level

Avani Desai, CEO of Schellman, has watched this play out across organizations of every size. Discovery scans routinely surface shadow data in abandoned cloud buckets, old development environments, and legacy SaaS exports -- including customer data in systems that were supposed to be decommissioned years ago. The tooling exists. The investment has been made. The scans just keep finding things the data map didn’t account for.

Her most incisive observation: when she asks executives “who is accountable for validating your data map after operational change?” there is always a pause. Because nobody owns it.

This is the accountability gap. And it isn’t a technology problem -- it’s an architecture problem.

The Map Doesn’t Update Itself

Every enterprise believes its data map is accurate -- until something changes. An acquisition closes. A system gets decommissioned. A team is reorganized. The data moves. The map doesn’t update. And when an external auditor or a post-M&A discovery scan runs, the gap between the map and reality becomes a breach notification and a regulatory headache.

The data map is only as good as the last time someone validated it. Most organizations treat that validation as a project -- something done before an audit, before a certification, before a deal closes. That’s the wrong model. Data doesn’t wait for audit cycles.

Consider the scale of the problem. The average enterprise now runs 371 SaaS applications. Forty-five percent of breaches involve cloud assets, according to IBM’s Cost of a Data Breach report, which also puts the global average breach cost at $4.88 million -- with cloud-based breaches running 28% higher than on-premise. Every one of those SaaS apps is a potential source of data the map doesn’t reflect.

AI Is Making the Governance Debt Worse

The AI adoption wave has accelerated the problem in a specific way. Cyera Research Labs found that 83% of organizations use AI in daily operations -- but only 13% have strong visibility into how that AI is being used. That means models are being trained, fine-tuned, and queried against data that governance teams haven’t fully mapped.

KPMG found that 62% of organizations cite insufficient governance as the top barrier to scaling AI. The frameworks built for structured relational data are straining under AI’s appetite for unstructured content -- documents, emails, shared files, collaboration exports. That content lives in dozens of systems, moves constantly, and rarely appears on the official data map.

The governance model designed for last decade’s architecture cannot account for this decade’s data movement. The gap between where data lives and where the map says it lives grows every time a new tool gets deployed, every time a team migrates a workflow, every time a SaaS contract expires and exports land somewhere nobody tracks.

The Regulatory Pressure Is Structural, Not Episodic

This isn’t just an internal hygiene problem. Privacy law makes data map accuracy a legal obligation. Under GDPR and state-level frameworks like CCPA/CPRA, organizations must respond to data subject access requests -- which require knowing where every copy of a person’s data lives. An inaccurate data map makes that legally impossible, not just operationally difficult.

OneTrust’s 2026 privacy enforcement analysis tracks an enforcement environment that is tightening in every major jurisdiction. Regulators are not interested in the organization’s investment in tooling. They’re interested in whether the organization could locate the data when it mattered.

EY’s research found that 99% of organizations reported financial losses from AI-related risks. Most of those risks trace back to data they didn’t fully account for.

Governance Built Into Architecture, Not Layered Onto It

Desai’s argument -- and it’s correct -- is that governance must be built into architecture from the beginning, not added afterward. The question “who validates the data map after operational change?” only goes unanswered when the architecture expects humans to do it manually, reactively, after the fact.

The architecture itself has to make accountability the default. That means data movement generates records. File exchange requires authentication. Every outbound sharing event is attributed, logged, and policy-bound at the moment it happens -- not reconstructed later from logs that may or may not have been retained.

Kiteworks takes this approach through its private content network: every file transfer, every collaboration, every sharing event is attributed, logged, and policy-bound at the point of exchange, which means the data map stays current because the platform writes to it continuously rather than relying on periodic human review. Abandoned cloud storage buckets and legacy SaaS exports exist because file transfer happened outside a governed channel. When every outbound data movement requires authentication and generates an audit record, the platform answers Desai’s accountability question -- not a person, not a process, the architecture itself.

What Needs to Change

The organizations that will close the data discovery gap are not the ones that run more frequent scans. Scans find what’s already wrong. The organizations that close the gap are the ones that redesign how data moves in the first place -- so that movement itself generates the record that keeps the map accurate.

Governance cannot be a layer applied after data has already spread across 371 SaaS apps and an unknown number of decommissioned cloud environments. It has to be the condition under which data is allowed to move at all.

The accountability gap exists because the architecture created it. The same logic closes it.

The npm package codexui-android had 29,000 weekly downloads and a clean reputation. It was functional, actively maintained, and apparently harmless -- until it wasn’t. For roughly one month, every installation silently read ~/.codex/auth.json and shipped the full OAuth blob -- access tokens, refresh tokens, and account IDs -- to an attacker-controlled server. The same exfiltration chain appeared in two Android apps with more than 60,000 combined downloads.

This is the architecture of a modern credential harvest: embed the theft inside something developers already use and trust, let adoption compound, then collect.

Why the Refresh Token Changes Everything

Most token theft has a natural ceiling. Access tokens expire. Sessions time out. The window for misuse is measured in hours.

The Codex attack erased that ceiling. The refresh token -- the credential that generates new access tokens without re-authentication -- does not expire. An attacker holding one does not need to act quickly. They can wait, probe quietly, and impersonate the account owner indefinitely without triggering any re-login event that would alert the user.

This is not a vulnerability in the traditional sense. There is no unpatched flaw to remediate, no CVE to assign priority. It is a harvest -- a deliberate collection of credentials that continue to work long after the package is removed from the registry.

The Supply Chain Is the Attack Surface

The Codex incident fits a documented and accelerating pattern. According to the CrowdStrike 2026 Global Threat Report, AI supply chain attacks via third-party models have increased threefold since 2022. CrowdStrike’s research also tracks campaigns like BeaverTail packages and the ShaiHulud info-stealer, where compromised maintainers or malicious lookalike packages propagate credential theft to millions of downstream users through a single point of trust.

The attack logic is consistent: target the developer ecosystem, not the application itself. Developers install dependencies constantly, often without auditing them thoroughly. A package that passes initial inspection and behaves correctly during early use builds trust that becomes the attack vector.

OWASP’s Top 10 for LLM Applications 2025 ranks supply chain vulnerabilities third on its list -- above prompt injection, above insecure output handling. The threat model is not theoretical.

The AI Platform Multiplier

Stealing a credential to a conventional service is damaging. Stealing one to an AI platform is different in kind, not just degree.

Salt Security research cited in the 2026 AI Security Statistics report documents a 78% year-over-year increase in API-related security incidents on AI platforms. The same report notes that 98% of organizations now use at least one third-party SaaS application with AI capabilities built in -- and that 62% have no formal AI vendor security policy in place (Gartner).

When an attacker holds a non-expiring token for an AI platform, they inherit access to everything that platform can reach: training data, retrieval-augmented generation pipelines, document stores, API integrations, and the outputs those systems produce. The blast radius is not bounded by what the stolen account explicitly held -- it is bounded by what the AI system has been granted access to across the enterprise.

The Financial Signal

The losses from AI-related credential compromises are no longer theoretical. An EY survey published in 2025 found that 99% of organizations reported financial losses tied to AI-related risks, with an average incident cost of $4.4 million. That number reflects detection, containment, regulatory response, and reputational damage -- not just the direct cost of the breach event.

The organizations absorbing those losses are not outliers. They are the early majority of enterprise AI adopters, building on toolchains and dependency graphs that were never designed with credential exfiltration as a threat model.

What Secure AI Data Access Actually Requires

The supply chain attack surface exists because AI tools are granted broad, session-based access to enterprise data -- and because a stolen session token is indistinguishable from a legitimate one. Closing that gap requires something structurally different from token management.

Kiteworks addresses this through a zero-trust architecture and an attribute-based access control (ABAC) policy engine that evaluates access on every individual request -- not at session establishment. Even a compromised AI platform credential cannot reach sensitive enterprise content unless the requester’s attributes, the data’s classification, and the request context all satisfy the governing policy simultaneously. The Kiteworks MCP Server extends this model to AI tools directly, defining which tools can interact with enterprise content at all and limiting the surface area exposed to any compromised developer toolchain.

The Attack You Didn’t See Coming

The codexui-android package was not invisible. It was trusted. That distinction matters because it means the standard advice -- vet your dependencies, check maintainer history, review changelogs -- is necessary but not sufficient against an attacker who is willing to invest in building that trust before weaponizing it.

The AI developer tool supply chain attack is not a niche concern for security researchers. It is a production risk for every engineering team that installs npm packages, integrates AI assistants into their workflow, or assumes that a high-download-count package has been vetted by someone else.

The credential is not the end of the attack. It is the beginning of a quiet, persistent, and potentially permanent presence inside every system that credential can reach.

The DataGrail Privacy and AI Trends Report 2026 lands with a number that deserves a second look: 145 AI-related laws enacted by U.S. state legislatures in a single calendar year. Add the 1,000-plus additional bills introduced or revised, and you get a picture of legislative machinery running at full speed.

What that machinery produced is not clarity. It produced a tracking problem.

AI Privacy Compliance 2026: The Vendor Disclosure Gap

Of the 2,400 software providers DataGrail reviewed that advertise AI capabilities, 63.6% do not disclose their third-party AI subprocessors in legal documentation. That is not a minor oversight. When an enterprise deploys a vendor tool and that tool routes sensitive content through undisclosed AI subprocessors, the organization carries the exposure without knowing the chain exists.

This is shadow AI in its most consequential form -- not rogue employees using ChatGPT on a personal device, but production software your legal team approved, your procurement team licensed, and your compliance team never fully mapped.

The Future of Privacy Forum’s January 2026 analysis flagged this exact structural tension: the GDPR definition of personal data is narrowing in some jurisdictions while state-level AI requirements proliferate in others. Legal teams are doing interpretive work across incompatible frameworks simultaneously.

High-Risk Activities Are Already Running

The DataGrail data includes another figure worth sitting with: 32.8% of AI systems participate in at least one high-risk activity. Under emerging frameworks like the EU AI Act -- which is phasing into active enforcement this year -- high-risk classification triggers documentation, conformity assessment, and ongoing monitoring requirements.

The OneTrust 2026 global privacy trends report maps the specific statutes now active or entering enforcement: Colorado’s AI Act is effective this year, the Texas Responsible AI Governance Act took effect in January 2026, and California’s AI Transparency Act adds disclosure obligations on top of the state’s existing privacy architecture.

These are not future considerations. They are current operational requirements affecting systems that many organizations deployed before any of this legislation existed.

The Headcount Equation Is Broken

Here is where the DataGrail findings become genuinely difficult: privacy teams are managing this regulatory expansion with headcount cuts of up to 33%. The average annual cost of manually handling data subject requests at a mid-sized company is $1.5 million -- before accounting for the additional work that AI-specific compliance layers now require.

The math does not resolve. More obligations, fewer people, higher per-request costs, and an accelerating pace of vendor-side changes that privacy teams have no systematic way to monitor.

According to Practical DevSecOps research on AI security in 2026, 68% of organizations experienced data leaks linked to AI tool usage, while only 23% have formal AI security policies in place. The gap between deployment pace and policy development is not closing on its own.

Why 42% of Companies Walked Away

The DataGrail report notes that 42% of companies abandoned AI projects specifically because of data privacy concerns. That figure tends to get read as a failure of nerve. It is actually a rational response to an unresolved infrastructure problem.

KPMG’s data governance research identifies the underlying issue directly: 62% of organizations cite lack of data governance as the main barrier to scaling AI. You cannot enforce what you cannot see, and most organizations cannot see across the full chain of how their AI tools process sensitive data.

The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report puts a specific number on this: 63% of enterprises cannot enforce purpose limitations on AI agents. An AI agent with access to sensitive content and no enforceable purpose constraint is not a productivity tool -- it is an unresolved liability.

California’s Executive Attestation Requirement

Starting this year, California requires formal privacy risk assessments with executive attestation -- filed under penalty of perjury, annually beginning in 2028. That language -- “penalty of perjury” -- changes the nature of the compliance conversation at the executive level.

Attestation requires documentation. Documentation requires audit trails. Audit trails require that every system touching personal data produce reliable, attributed records of what happened, when, and why. For AI systems, that is a design requirement, not a reporting task.

What Infrastructure-Level Enforcement Looks Like

The organizations positioned to meet this moment are not the ones with the largest legal teams or the most complete statutory reading lists. They are the ones whose AI infrastructure enforces compliance without requiring a lawyer in the loop for every agent interaction.

Kiteworks‘ Compliant AI framework gives enterprises a governed, auditable channel for AI interactions that does not route sensitive content through undisclosed third-party AI subprocessors -- directly addressing the 63.6% disclosure gap the DataGrail report identifies. Every AI agent interaction with Kiteworks-managed content is policy-enforced, attributed, and logged, producing the documentation trail that California’s executive attestation requirement will demand.

The Compliance Curve Is Not Flattening

One hundred forty-five laws in one year, with 1,000 more in progress. Vendors hiding their AI subprocessors. Privacy teams down by a third. Forty-two percent of AI projects cancelled over privacy concerns that no one resolved before deployment.

The organizations that get through this are the ones that stopped treating compliance as a reading comprehension problem and started treating it as an infrastructure requirement -- building systems that make the right data handling the default behavior, not the manual override.

That is not a prediction. That is the condition the data already describes.

The Cloud Security Alliance and Darktrace’s State of AI Cybersecurity 2026 report landed last week with a number that should stop most security leaders cold: 92% of security professionals are concerned about the enterprise security impact of AI agents. That is close to unanimity. You rarely get 92% agreement on anything in security.

Then you get to the organizational readiness data, and the story changes. Only 37% of organizations have a formal AI policy -- and that number actually went down from the prior year. Another 52% are still in “discussion mode.”

Awareness without action is not a security posture. It is a liability that compounds every quarter you spend talking instead of building.

What AI agents actually do to your attack surface

The concern about AI agents is not abstract. AI agents act with broad permissions across multiple systems. When an employee deploys one, that agent typically inherits their GitHub access, cloud credentials, API tokens, and filesystem permissions -- not a subset, the whole set. The agent then operates autonomously, making decisions and taking actions across those systems at machine speed.

This is a materially different risk profile from a SaaS tool or a chatbot. An AI agent that gets compromised -- or that makes a bad decision -- can do sustained, wide-ranging damage before anyone notices.

The CrowdStrike 2026 Global Threat Report documents an 89% year-over-year increase in attacks by AI-enabled adversaries. The threat side is moving fast. The defense side is in meetings.

The three specific gaps the data names

The CSA report breaks down where the concern concentrates. 61% of respondents cite sensitive data exposure as their top AI concern. 56% flag data security and policy violations. 51% worry about tool misuse and abuse.

Those three categories share something: they are all downstream consequences of agents operating with permissions nobody fully scoped and policies nobody fully wrote.

Kiteworks research from the Kiteworks Data Security and Compliance Risk: 2026 Forecast Report adds specifics that make the CSA numbers feel concrete. 63% of enterprises cannot enforce purpose limitations on AI agents -- meaning an agent built to summarize contracts can query your HR system and nobody has configured a control to stop it. 60% cannot quickly terminate a misbehaving agent. 55% cannot isolate AI systems from the broader network.

These are not policy failures. They are architectural gaps.

Why the formal policy number went down

The statistic that deserves more attention than it is getting: the percentage of organizations with a formal AI policy did not hold flat from last year. It declined. This happened while AI agent deployment accelerated.

One explanation: AI governance requires cross-disciplinary ownership that most organizations have not assigned. Identity, cloud, application, data, and supply chain security all have to be addressed simultaneously. That is not how most security teams are organized. Each domain has an owner. Nobody owns the intersection.

The WEF Global Cybersecurity Outlook 2026 found that only 40% of organizations conduct periodic AI security reviews. Roughly 33% have no process at all to validate AI security before deployment. When Gartner projects that AI agents will autonomously execute more than 15% of all enterprise security decisions by 2028 -- and that 80% of current security stacks are unprepared to detect a compromised agent -- those numbers get harder to sit with. Source: Practical DevSecOps AI Security Statistics 2026.

What “discussion mode” actually costs

The EY data is worth quoting directly. According to EY’s survey on responsible AI governance, 99% of organizations reported financial losses from AI-related risks. 64% suffered losses exceeding $1 million. The average loss was $4.4 million.

Those are not hypothetical future costs from some agent-gone-wrong scenario. Those are current-year losses from organizations that were also, presumably, in “discussion mode” about their AI governance posture.

The PwC 2025 Responsible AI survey found that only 50% of organizations cite operationalization as the biggest hurdle -- and that organizations that have moved past strategy into actual implementation are 1.5 to 2 times more likely to describe their AI security capabilities as effective. The variable that separates them is not budget or headcount. It is whether someone made the decision to stop discussing and start building.

The cross-disciplinary ownership problem

Here is the thing about the awareness-action gap that the report identifies but does not quite name directly: when governance requires five different domain teams to cooperate, and none of those teams owns the outcome, the default is inertia. Identity says it is a data problem. Data says it is an application problem. Application says it is a cloud problem. Cloud says talk to security. Security is in the meeting.

This is not a failure of concern or intent. It is a structural problem. The organizations that have closed the gap tend to have done one of two things: appointed a cross-functional AI governance lead with real authority, or adopted a platform that enforces policy across those domains rather than documenting it.

The Kiteworks Compliant AI platform is designed for exactly that structural problem. The Kiteworks MCP Server governs identity and tool access. The ABAC Data Policy Engine governs data and application permissions. Tamper-evident audit logging covers attribution and supply chain audit requirements. All from a single platform that enforces the policy rather than documenting it. For organizations still working out cross-disciplinary ownership, the Kiteworks Innovators in AI Program offers a governed infrastructure path that does not require resolving that question before getting started.

The number that should drive the next board conversation

92% concern, 37% formal policy, declining year over year. That gap is the story.

The security professionals who responded to this survey are not uninformed or unserious. They see the risk clearly. What they are missing -- mostly -- is an organizational structure that converts that concern into enforceable controls. Getting there requires assigning cross-disciplinary ownership, not just cross-disciplinary awareness.

The organizations that have formalized AI governance are not smarter than the ones still in discussion. They just stopped waiting for perfect conditions and built something.

Every AI agent running in your enterprise has a memory. That memory shapes every decision the agent makes. And right now, in most organizations, that memory has no defense layer protecting it.

AI agent memory poisoning is the attack pattern where an adversary writes malicious content into an agent’s persistent memory -- its conversation history, its vector store, its RAG index, its scratchpad -- and every subsequent action the agent takes carries that attacker’s intent forward. The user believes they are interacting with a trustworthy system. They are not. The agent is working, in part, for someone else.

OWASP released Agent Memory Guard on June 1, 2026, as an open-source runtime defense layer targeting exactly this threat. It is the reference implementation for the OWASP Top 10 for Agentic Applications, addressing the ASI06 threat class. That classification matters: it means memory poisoning is no longer a theoretical concern catalogued in a research paper. It is a named, enumerated vulnerability class with a published standard.

Why Memory Is the Target

Prompt injection has held the #1 position on the OWASP Top 10 for LLM Applications 2025. Memory poisoning is an extension of that same attack surface -- except it is more durable. A prompt injection attack operates within a single session. A memory poisoning attack persists. It survives session resets. It travels with the agent.

Agents are not stateless. They are designed to remember -- because memory is what makes them useful across time. Conversation history tells the agent what it has already done. The RAG index tells it what it knows. The scratchpad tells it what it is currently working on. An attacker who can write to any of those stores gains a channel into the agent that no authentication layer, no API gateway, and no perimeter control currently inspects.

What OWASP Agent Memory Guard Actually Does

The tool intercepts every memory read and write through five detection layers: prompt injection screening, secret and PII leakage detection, key tampering detection, SHA-256 integrity baselines, and size anomaly detection. Administrators configure response behavior through a YAML policy that can allow, redact, quarantine, or block any flagged operation.

The published results are meaningful: 92.5% recall, 100% precision, zero false positives, and a 59-microsecond median latency overhead. The tool also supports rollback to a known-good memory state -- which is the capability that will matter most when a poisoning event is discovered after the fact.

This is the first runtime defense tool built explicitly to the OWASP agentic security standard. Prior tools addressed model behavior or API security. None addressed the memory layer as a discrete attack surface.

The Cross-Agent Propagation Problem

The threat extends beyond a single compromised agent. Research published in February 2026 by a team spanning Northeastern, Harvard, MIT, Stanford, and CMU -- the Agents of Chaos study -- documented live cases where one compromised agent shared its “constitution,” its behavioral rules, with other agents in the same network. Identity spoofing succeeded in new communication channels where prior context was unavailable to verify authenticity.

The implication is direct: a single poisoned agent can become a propagation node. The attacker does not need to breach every agent individually. They need to breach one agent that communicates with others, and the poisoned behavioral instructions spread through the network’s normal operation.

The WEF Global Cybersecurity Outlook 2026 flagged this exact dynamic -- agents that accumulate excessive privileges or absorb manipulated instructions through design flaws can propagate errors at scale before any human reviewer notices.

Enterprise Governance Is Not Ready

The organizational readiness gap is measurable. Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found that 63% of enterprises cannot enforce purpose limitations on AI agents and 60% cannot quickly terminate a misbehaving agent. Those two numbers describe organizations that cannot stop an attack they cannot see, targeting a memory layer they are not monitoring, propagating through a multi-agent network they cannot shut down fast enough.

The NIST AI Agent Standards Initiative, launched in February 2026, identified agent identity, authorization, and security as priority standardization areas. That initiative provides the standards scaffolding. OWASP Agent Memory Guard provides the runtime implementation. The gap that remains is organizational -- governance structures and tooling pipelines that can actually deploy and enforce both.

What the Protocol Layer Can Do

Kiteworks‘ MCP Server operates at the protocol layer, governing which data AI agents can access and which tools they can invoke before any agent interaction reaches sensitive content. A poisoned agent memory that attempts to access data outside its authorized scope encounters Kiteworks’ attribute-based access control policy engine, which evaluates every request independently -- regardless of what the agent’s memory instructs it to do. The tamper-evident audit log records every agent interaction, so anomalous behavior triggered by memory manipulation is detectable in real time rather than in a post-incident review weeks later.

The Conversation Has Changed

Security reviews that evaluated AI deployments six months ago asked about model safety and API access controls. Reviews happening now need to ask about memory architecture -- what persists, what writes to the memory store, what reads from it, and what prevents an adversary from treating that store as a reliable attack channel.

OWASP naming the threat class and shipping a reference implementation is the point at which “we’re monitoring the situation” stops being an acceptable posture. The memory layer is now a documented, enumerated attack surface with an available defense. Organizations that deploy AI agents without addressing it are leaving a privileged channel into their systems ungoverned.

The agents are running. The memory is filling. The attack surface is open.

On May 4, FedRAMP published CR26 -- Consolidated Rules for 2026 -- in public preview. Final release is targeted for the end of June. Mario Lunato, field CISO at Knox Systems, called it plainly: the whole game is changing. He is right, but not for the reason most vendors are focused on.

The conversation in federal contracting circles has centered on the new Certification Classes -- A through D replacing the familiar Low/Moderate/High impact labels. That is a real change. But it is not the structural one.

FedRAMP CR26 Compliance Requirements Are Now a GitHub API

The deeper shift is in how requirements are expressed. CR26 replaces narrative guidance with declarative MUST/MUST NOT statements designed to be machine-checkable. The entire requirements catalog is published as structured data at GSA’s FedRAMP automation repository on GitHub.

That last part deserves a pause. FedRAMP requirements are now, effectively, an API.

When a compliance standard publishes its requirements as structured data, software can query them. Software can compare them against your running configuration. Software can flag the delta between what your System Security Plan claims and what your infrastructure actually does -- at any moment, not just at authorization time.

This is a different kind of accountability than narrative guidance ever created. Narrative guidance accommodates interpretation. Machine-readable MUST/MUST NOT statements do not.

What “FedRAMP Ready” Becomes After July 28

The “FedRAMP Ready” designation retires on July 28 and becomes “Legacy FedRAMP Ready.” This is not a cosmetic rename. Vendors holding that status need to understand what it signals to agency procurement teams in a post-CR26 environment.

The Certification Class structure -- A through D -- maps to different verification thresholds. Class A covers lower-risk use cases. Class D covers the most sensitive. The practical implication is that vendors need to determine which class their offering falls into and map their current SSP documentation accordingly -- before the final version publishes, not after.

Lunato’s guidance on this is worth following directly: map your documentation to the new class structure now, file substantive comments through GitHub before end of June, and do not rewrite authorization packages against preview language until the final text is stable.

The 30-Month Planning Window Is Genuinely New

One underreported element of CR26: the rules are stable through December 31, 2028. For vendors who have spent years watching FedRAMP requirements shift without a fixed horizon, this is not a minor footnote.

A 30-month planning window means engineering roadmaps, contract terms, and authorization timelines can be built against a known floor. That has not been possible in the modern FedRAMP era. The compliance posture that earns authorization in July 2026 will not be invalidated by a rule update in Q1 2027. That is new.

The Larger Pattern: Machine-Readable Compliance Is Arriving Across the Board

CR26 does not exist in isolation. CMMC 2.0 Level 2 mandatory third-party assessments for defense contractors handling CUI take effect November 10, 2026 -- running directly parallel to the CR26 finalization timeline. The convergence of machine-readable federal compliance standards is not a FedRAMP-specific story.

Federal agencies are operating under budget pressure and threat pressure simultaneously. The US federal AI security budget reached $3.1 billion in 2025 per OMB, yet only 38% of government agencies had a formal AI security policy as of GAO’s 2024 review. CISA identified AI-assisted cyberattacks on critical infrastructure as the top emerging threat in 2024, with a 110% year-over-year increase in AI-augmented intrusion attempts on government and defense targets.

The agencies purchasing cloud services are not abstract compliance bureaucracies right now. They are organizations under active pressure to verify that the software they authorize actually does what it claims to do.

The Documentation Gap Is About to Get Expensive

IBM’s Cost of a Data Breach report puts the global average at $4.88 million per incident -- with cloud-based breaches running 28% higher than on-premise equivalents. The federal procurement context adds reputational and contractual consequences on top of that.

For years, FedRAMP authorization has functioned partly as a documentation exercise. SSPs describe intended controls. Auditors review documentation. The gap between description and implementation is a known, tolerated ambiguity in the process.

Machine-readable requirements eliminate that ambiguity from the verification layer. When a MUST statement can be evaluated programmatically against your actual configuration, the documentation gap becomes a compliance gap -- visible, flaggable, and no longer deniable.

Vendors who have invested in real control implementation will find CR26 easier than they expect. Vendors who have invested primarily in documentation sophistication will find it harder.

Where Architecture Matters More Than Policy

This is where Kiteworks is worth noting. Kiteworks holds FedRAMP authorization, and CR26’s shift to machine-checkable MUST/MUST NOT statements -- organized into Certification Classes -- maps directly to how the Kiteworks Data Policy Engine enforces compliance controls programmatically rather than documentarily. As FedRAMP’s requirements become verifiable by software, a platform where compliance controls are embedded in architecture rather than described in policy documents becomes the model CR26 is moving toward. The stable 30-month rules horizon also gives Kiteworks’ federal customers a clear compliance planning window for the first time.

What to Do Before June Ends

The comment window on CR26 preview language closes at the end of June. That is a real deadline with real consequences -- the final rule language is shaped by substantive technical comments filed now, not by objections raised after publication.

Three things matter in the next 30 days: map your current SSP to the new Certification Class structure, identify which MUST/MUST NOT requirements your existing controls satisfy programmatically versus documentarily, and file comments on any requirements where the preview language creates implementation ambiguity.

The vendors who treat the comment period as a formality will live with the final language as written. The vendors who engage technically will have contributed to shaping the requirements they will be authorized against through 2028.

FedRAMP CR26 does not just raise the bar -- it changes what the bar measures.

Antonija Vojnovic, a governance, risk, and compliance expert speaking at the Span Cyber Security Arena conference, described the situation plainly: EU organizations are buckling under three major regulatory frameworks arriving simultaneously, each with overlapping but distinct requirements, each enforced by a different authority, and each implemented inconsistently across member states.

That framing is accurate. It is also incomplete. The real problem isn’t the volume of regulation -- it’s that most organizations haven’t built the underlying capability any of these frameworks require.

NIS2 demands incident reporting and supply chain security. DORA demands data resilience and operational continuity for financial services. The EU AI Act demands documentation, risk classification, and data governance for AI systems. Three different frameworks, three different enforcement bodies, three different compliance calendars. But underneath all of them is the same requirement: you need to know where your data is, who can touch it, what it’s being used for, and what happened when something went wrong.

The DORA number that should concern everyone

A Censuswide survey found that 96% of financial services firms in EMEA say their data resilience does not meet DORA’s expectations. Read that again: 96%. That is not a compliance gap -- it is a near-universal admission that the sector hasn’t built what the regulation requires.

DORA isn’t asking for anything exotic. It requires financial institutions to maintain operational continuity, protect data integrity, and demonstrate they can recover when something breaks. These are not new concepts. They are the things security teams have been asked to do for years. The fact that 96% of respondents acknowledge they still aren’t there suggests the gap isn’t awareness -- it’s execution.

The organizations in that 96% aren’t just behind on DORA. They are almost certainly behind on NIS2 incident reporting timelines and EU AI Act documentation requirements too. The same governance infrastructure that would satisfy DORA’s data resilience standard -- immutable logs, defined data flows, tested recovery procedures -- is what NIS2 and the EU AI Act are also asking for. The compliance problem isn’t which regulation you face. It’s that they all require the same underlying capability you haven’t built yet.

The AI Act adds a different kind of pressure

The EU AI Act’s high-risk AI provisions become fully enforceable in August 2026. Fines for non-compliance reach up to €35 million or 7% of global annual turnover, whichever is higher. Those numbers are not hypothetical -- they are the enforcement ceiling for systems classified as high-risk that cannot demonstrate the required documentation, testing, and data governance.

EU AI spending is forecast to reach $290 billion by 2029, per Vojnovic’s remarks. At that scale, the AI Act is not a niche compliance question. It touches every organization deploying AI systems across regulated use cases -- which, as the definitions are applied, turns out to be a very long list.

Vojnovic made a point worth holding onto: awareness that AI tools can use private data for training is more operationally valuable than the regulatory text alone. That’s not a soft observation. An organization that understands where its data goes -- including into AI training pipelines -- is already solving the documentation problem the AI Act requires. An organization that doesn’t know can’t document what it can’t see.

The GDPR enforcement record on AI data processing makes the stakes concrete: €1.2 billion in GDPR fines tied to AI data processing violations in 2023 alone, according to the European Data Protection Board. The AI Act adds a second enforcement layer on top of a GDPR framework that is already producing billion-euro outcomes.

NIS2 implementation is inconsistent -- which is its own problem

NIS2 varies by member state. The directive sets minimum requirements; national transposition determines enforcement posture, timelines, and the definitions of “essential” and “important” entities. For multinational organizations operating across the EU, that means managing compliance against multiple national implementations of the same underlying directive.

The Future of Privacy Forum’s January 2026 analysis flagged GDPR Omnibus proposals introduced in November 2025 as a further policy shift -- including a technology-neutral data protection law imprinted with AI provisions. The OneTrust 2026 regulatory outlook adds that the EU has extended UK adequacy through December 2031, and that the Digital Omnibus proposal from late 2025 aims to align GDPR, the AI Act, and the ePrivacy framework. The regulatory stack is not stabilizing -- it is layering.

For organizations trying to manage NIS2 across member states while simultaneously preparing for DORA’s operational resilience requirements and the AI Act’s August enforcement date, the sequencing problem is real. There is no comfortable runway. The deadlines are already here or arriving within weeks.

What the cost of getting this wrong looks like

IBM’s Cost of a Data Breach report puts the global average breach cost at $4.88 million. That is the baseline before regulatory penalties are applied. An organization that experiences a breach, fails to report it within NIS2’s 72-hour window, and cannot demonstrate DORA-compliant resilience is facing the breach cost plus enforcement exposure from at least two separate regulatory bodies -- potentially three if AI systems were involved in the incident.

The enforcement math changes the incentive structure. Building the governance infrastructure that satisfies all three frameworks isn’t a cost center -- it’s a hedge against outcomes that cost substantially more.

The common infrastructure problem

Kiteworks addresses NIS2, DORA, and the EU AI Act within a single platform: jurisdictional data residency controls and tamper-evident audit trails for NIS2 incident reporting obligations; immutable logging and secure file exchange for DORA data resilience requirements; and Compliant AI governance for EU AI Act documentation. For multinational enterprises managing variable member-state implementation, a unified platform that enforces the same controls across all three frameworks simultaneously is both the compliance solution and the audit answer.

Three frameworks, one question

The regulators writing NIS2, DORA, and the EU AI Act are not coordinating with each other. They have different mandates, different enforcement mechanisms, and different timelines. But they are asking the same operational question: do you know what your data is doing, and can you prove it?

That question doesn’t have three different answers. It has one -- and most organizations in the DORA survey have told us they don’t have it yet.

The 96% figure isn’t an indictment of financial services specifically. It’s a measurement of how far the gap between regulatory expectation and operational reality has grown -- across every sector, in every member state, for all three frameworks at once.

On May 26, the FBI issued a FLASH alert naming law firm data exfiltration as the defining threat U.S. practices face from the Silent Ransom Group -- also known as Luna Moth, Chatty Spider, and UNC3753. The group has run a concentrated campaign against law firms since Spring 2023, with activity intensifying sharply through the first half of 2026. The playbook is deliberate: call the helpdesk, impersonate an employee, get remote desktop access, find the sensitive files, copy them to Google Drive with a hidden Rclone installation, and disappear. The whole sequence can finish before incident response has opened a ticket.

No ransomware. No encrypted servers. No ransom note on the screen.

I’ve been watching the law firm threat landscape for a long time. The “no encryption” detail in this alert is the one I think practitioners are going to underestimate. The absence of ransomware isn’t a sign of a less capable threat actor -- it’s a sign of a more strategically patient one.

Law Firm Data Exfiltration Starts With Tools You Already Have

Silent Ransom Group’s exfiltration playbook runs on WinSCP and Rclone -- two legitimate file transfer utilities found in enterprise environments everywhere. That is deliberate. Detection logic trained on malware signatures doesn’t flag them. Endpoint tools built to catch executable payloads don’t catch a Rclone process syncing 40 gigabytes of client files to an attacker-controlled OneDrive account, because Rclone isn’t malware. It’s a tool your operations team may use for completely authorized reasons.

The CrowdStrike 2026 Global Threat Report documented how widespread this technique has become: 82% of detections in 2025 were malware-free. Attackers have shifted to native tools, valid credentials, and legitimate utilities because those techniques don’t trigger the alerts that malware drops trigger. CrowdStrike also recorded an average eCrime breakout time of 29 minutes in 2025, with the fastest documented breakout at 27 seconds. By the time a Silent Ransom Group operator has remote desktop access, the window for detection before the data is gone is measured in minutes.

The FBI Internet Crime Complaint Center recorded $16.6 billion in cybercrime losses in 2025 -- a 33% increase from the prior year. Law firms account for a disproportionate share of those losses precisely because of what they hold: client confidences, deal strategy, litigation plans, and personnel files. The data is the product.

Why Law Firms Are the Target

Every attorney understands that attorney-client privilege is the moat around the castle. Clients share information under the explicit assumption that it stays within the relationship. That expectation -- combined with state bar ethics rules, e-discovery obligations, and the malpractice exposure that follows a breach notification -- makes law firms structurally reluctant to disclose and structurally inclined to negotiate.

Silent Ransom Group was built around that reluctance. The group doesn’t need to encrypt systems and watch operations halt. It doesn’t need to trigger your incident response playbook. It needs to demonstrate that it has the data. The more sensitive the practice area -- M&A work, regulatory investigations, litigation strategy, employment matters -- the higher the leverage.

The FLASH alert noted that stolen files were staged to Google Drive or Microsoft OneDrive before exfiltration was complete. By the time the vishing call ends and the session closes, the data has already left the environment to a cloud account the attacker controls. The endpoint was never truly compromised in the traditional sense. Your ransomware controls never fired. The data is gone before the alert fires.

The IBM Cost of a Data Breach Report puts the global average breach cost at $4.88 million. For law firms, where breach disclosure can trigger regulatory inquiries, bar complaints, and client departures simultaneously, the practical exposure runs higher -- but the more important point is that Silent Ransom Group’s model doesn’t require operational disruption to be profitable. The extortion value is entirely in what was taken.

The Gap Is in the Transfer Layer

Every firm I’ve talked with in the past year has invested significantly in endpoint detection, identity management, and phishing resistance. Almost none can tell me what happened to the last file that left their environment through a non-governed channel.

That’s the gap Silent Ransom Group is walking through. Not a failure in endpoint defenses. Not a weakness in MFA rollout. A gap in governance over the file transfer layer -- the paths data takes out of the environment -- that creates an exfiltration surface large enough to breach regardless of how well the perimeter is defended.

The Deloitte Cyber Threat Trends Report identified voice phishing combined with business email compromise as one of the dominant credential theft vectors in 2025. What distinguishes Silent Ransom Group is what happens after the credential theft: instead of pivoting to ransomware, operators pivot to data movement. And data movement, in most enterprise environments, has no governance layer.

A Rclone sync to an external cloud account not on an approved list should generate an alert. In most law firm environments, it doesn’t.

Governing the Channel

The architecture question is not how to stop a vishing call -- that’s a training and verification problem. The question is how to ensure that even after an attacker has remote access, they cannot move sensitive data out of the environment through uncontrolled channels.

This is what platforms like Kiteworks are built around. A private content network replaces ad-hoc file transfer tools -- WinSCP, Rclone, personal cloud storage uploads -- with a governed transfer plane where every outbound file movement is attributed to an authenticated identity, evaluated against access policy, encrypted to FIPS 140-3 standards, and captured in a tamper-evident audit log in real time. An attacker with remote access who routes through the governed channel encounters a policy engine that catches the anomaly. Routing around it to an unsanctioned tool is blocked at the network layer.

That’s a prevention control, not a detection control. For a threat model where breakout time is 29 minutes, that distinction is not academic.

What the Alert Is Really Saying

The FBI FLASH alert on Silent Ransom Group isn’t about a sophisticated nation-state adversary. It’s about a criminal organization running a repeatable playbook against a specific vertical because the combination of data sensitivity and disclosure reluctance makes it profitable.

The playbook works because the file transfer layer is ungoverned. Closing that layer doesn’t eliminate vishing as a threat vector -- but it eliminates the attacker’s ability to convert a successful vishing call into a successful data theft.

Every law firm treating file transfer governance as an IT implementation detail rather than a risk control is keeping that door open. The FBI just told you who is walking through it.

The Cloud Security Alliance study released in March 2026 lands a number that should make every CISO uncomfortable: more than two-thirds of organizations cannot clearly distinguish AI agent actions from human actions in their audit and access logs. Not “struggle to.” Cannot. The logs don’t support it.

That’s not a monitoring problem. That’s an AI agent audit trail compliance problem -- and it’s a different animal entirely.

What the data actually says

The CSA finding is damning on its own. Pair it with the access side of the picture and it gets worse. Most organizations have granted AI agents broader permissions than any individual human employee receives. There is no systematic process for reviewing those permissions, scoping them, or revoking them.

So you have agents operating at elevated privilege, and logs that can’t tell you what they did.

The EY survey on AI governance found that 99% of organizations reported financial losses from AI-related risks, with 64% suffering losses over $1M. A lot of those losses trace back to exactly this gap -- not a breach in the traditional sense, but an agent doing something nobody authorized, or something nobody can now prove was authorized.

The question regulators will ask

Here is the question that matters. Not “do you have AI governance?” Not “did you do a pre-deployment risk assessment?” The question is: “Show me exactly what that AI agent accessed, when, under what authorization, and who approved it.”

If your logs mix agent actions and human actions -- or worse, only capture human actions -- you cannot answer that question. You fail the audit.

This is not a hypothetical. HIPAA, SEC, CMMC, and the EU AI Act all require attribution-grade records. The EU AI Act’s high-risk AI system requirements -- which take effect August 2, 2026 -- mandate detailed documentation and audit trails for AI decision-making. SEC Regulation S-K and its emerging enforcement posture in financial services require trails that attribute actions to specific systems or humans.

If your audit log says “file accessed at 2:17am” with no indication of whether that was a human or an agent, and no policy reference for why access was granted, you do not have an audit trail. You have a timestamp log.

Why pre-deployment reviews don’t close this gap

A lot of security teams treat AI governance as a pre-deployment activity. You assess the model, you scope the permissions, you sign off, you ship. The problem is that what happens after deployment -- the actual runtime behavior of agents in production, against real data, on real schedules -- generates no attribution-quality record in most environments.

NIST’s AI Agent Standards Initiative, announced in February 2026, identifies agent identity, authorization, and security as priority areas precisely because the field has not solved these problems. Agent identity at runtime -- meaning the ability to say “this action was performed by Agent X acting under Policy Y delegated by User Z” -- is not yet standard practice.

The WEF Global Cybersecurity Outlook 2026 flags the same risk: without governance that operates at runtime, agents accumulate excessive privileges or propagate errors at scale. “At scale” is the part that matters. A human employee making a bad access decision affects one incident. An agent making the same bad decision can affect thousands of records before anyone notices.

The Kiteworks 2026 data makes the operational picture concrete

Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found that 63% of enterprises cannot enforce purpose limitations on AI agents -- meaning an agent authorized for one task can perform others -- and 60% cannot quickly terminate a misbehaving agent. These aren’t edge cases. They describe the majority of enterprise AI deployments right now.

The organizations that can answer a regulator’s attribution question share a common architecture: they have a logging layer that records every agent operation with the agent’s identity, the policy that authorized or denied the request, the data involved, and a timestamp -- meaning what happened and why it was allowed to happen.

Kiteworks builds this into the platform at the infrastructure level. The tamper-evident audit trail records every file access, transfer, and AI agent operation with the identity of the requestor, the policy that authorized or denied the request, the data involved, and the timestamp. The ABAC Data Policy Engine evaluates access on every operation, and AI agents inherit the rights of the delegating human without the ability to escalate. That is the architecture the CSA study identifies as absent in most enterprise environments -- a constraint enforced at every operation, not bolted on afterward.

What closing the gap actually requires

Attribution-quality logging requires three things that most current implementations don’t have. First, a persistent identity for each agent that travels with every operation -- meaning an agent-specific identity that maps to a specific deployment, authorization context, and delegating human -- a service account is not enough. Second, a policy reference captured at the time of access, not reconstructed after the fact. Third, tamper evidence -- logs that can’t be altered after the fact, because a regulator will ask whether the log itself is trustworthy.

None of this requires ripping out existing infrastructure. It does require making the attribution question -- “which agent, under what authority, touching what data” -- a first-class logging requirement rather than an afterthought.

The liability math is simple

You cannot retroactively create an audit trail. When the SEC asks for records of AI-driven decisions in a financial services audit, or when HHS asks for an access log under HIPAA, or when a CMMC assessor asks for evidence that controlled unclassified information was only accessed by authorized systems -- the log either has the record or it doesn’t.

Two-thirds of organizations are currently operating AI agents with logs that don’t have those records. The EU AI Act deadline is August 2, 2026. That gap between current state and regulatory requirement is not a future risk. It is a present liability, accruing with every agent operation that runs without attribution.

The organizations that will clear these audits already built the attribution layer before the audit arrived.

A building inspection happens once. The inspector walks through, signs off, and hands over the keys. After that, you’re on your own. AI runtime security governance has the same structural problem: a review at deployment time is a snapshot of intended behavior, not a guarantee of actual behavior. The moment an agent goes live, that snapshot starts aging out.

The Security Boulevard analysis from May 2026 puts the scale of the problem into numbers I find hard to look away from. Enterprise AI agent deployments grew more than 300x between January 2025 and January 2026. Behavioral monitoring did not come close to keeping pace. Only 14.4% of organizations send AI agents to production with full security or IT approval. The other 85% are running agents that have never cleared any formal gate -- and in many cases, never will.

The static configuration problem

Pre-deployment security is not worthless. Threat modeling, access scoping, and configuration review all matter. But they answer one question: is this agent safe to deploy? That is a different question than: is this agent behaving safely right now?

Configurations are static. Behavior is not. An agent trained and tested on a stable dataset will drift when the underlying model is updated, when the tools it calls change their APIs, when the data it processes shifts in character. Research aggregated by Practical DevSecOps puts a number on that drift: unmonitored production models degrade in security posture by up to 40% within six months. The same source cites Gartner’s projection that by 2028, AI agents will autonomously execute more than 15% of all enterprise security decisions. Nobody is inspecting 15% of enterprise security decisions every six months.

What organizations actually know about their agents

The visibility gap is worse than the approval gap. The EY Responsible AI Pulse Survey found that half of organizations have no high level of visibility into how employees are using AI agents day to day. Two-thirds allow citizen developers to independently build and deploy agents. Of those companies, only 60% provide any formal org-wide policies.

Think about what that means operationally. A line-of-business team builds an agent, deploys it, and starts using it to process data. Security doesn’t know it exists. There’s no policy covering it. And when something goes wrong -- when the agent starts hitting endpoints it shouldn’t, or pulling data outside its intended scope -- nobody has the instrumentation to catch it in real time.

The WEF Global Cybersecurity Outlook 2026 found that only 40% of organizations run even periodic AI security reviews. A third have no process at all to validate AI security before deployment. Periodic reviews won’t catch runtime drift. No pre-deployment process will.

The response gap is the kill shot

Here’s where the static configuration problem becomes a real incident problem. Kiteworks Data Security and Compliance Risk: 2026 Forecast Report found that 60% of enterprises cannot quickly terminate a misbehaving AI agent. Fifty-five percent cannot isolate AI systems from the broader network. You can have all the pre-deployment documentation in the world -- if you can’t stop the agent when it starts doing something wrong, that documentation is a liability record, not a control.

Detection gaps and response gaps compound each other. An agent that quietly expands its data access over weeks is hard to catch without continuous behavioral monitoring. An agent that’s caught doing something wrong is actively harmful if you can’t contain it fast. Both problems trace back to the same root: organizations built their AI security posture around the deployment moment and assumed it would hold.

What runtime governance actually means

Per-operation policy enforcement is the answer to the timing problem. Not checking that an agent was configured correctly at deployment. Evaluating each discrete operation the agent executes -- each API call, each data access request, each action -- against policy, in real time.

This is categorically different from logging. Logging tells you what happened. Per-operation enforcement decides what happens. It catches anomalous behavior at the moment it occurs, not in a report three weeks later.

The EU AI Act makes this mandatory for high-risk AI systems starting August 2, 2026. The requirement isn’t a deployment-time audit. The Act requires continuous monitoring and documentation of AI behavior post-deployment. Post-deployment. Continuous. That’s the legal floor -- and for most organizations, it’s still above where they’re operating today.

The architectural answer

Kiteworks’ Secure MCP Server enforces attribute-based access control at the operation level -- on every discrete request an AI agent makes, not at connection or deployment time. That’s the architectural definition of runtime governance applied to the data access layer where regulated content actually lives. For organizations that need to govern AI behavior around sensitive content, per-operation enforcement is the control plane that makes that possible. Every request is evaluated against policy. There is no assumption that a clean deployment stays clean.

The governance gap is a timing gap

The framing I keep coming back to is this: pre-deployment security answers the question “should this agent exist?” Runtime governance answers “what is this agent allowed to do right now?” Those are not the same question, and conflating them is how organizations end up with a 14.4% approval rate and a 40% posture degradation curve.

Citizen development isn’t going away. Agent deployment volume is going up. The answer isn’t tighter deployment gates -- agents will route around them, and the data shows they already are. The answer is continuous enforcement at the operation level, so that what the agent does in week 12 is governed by the same policy as what it did in week one.

A security review at deployment is a photograph. Runtime governance is a camera that’s always on.

File transfer compliance 2026 is not a single-framework problem

I’ve been in more compliance conversations in the last 18 months than in the five years before that. The question used to be “which regulation applies to us.” Now it’s “which ones don’t” -- and the answer is almost never “none.”

Six frameworks with hard deadlines are reshaping how file transfer gets governed in 2026. They come from different jurisdictions, different regulatory bodies, and different policy concerns. But they share a common diagnosis: ungoverned file movement is where compliance programs break down, where breaches start, and where liability accumulates. The convergence isn’t bureaucratic redundancy. It’s six regulators reaching the same conclusion from different directions.

The organizations that will struggle are the ones still treating file transfer as a technical implementation detail -- something IT handles below the compliance layer. That framing has definitively run out of runway.

The six frameworks and what they actually require

FedRAMP’s CR26 revision moves cloud service providers from point-in-time authorization to continuous compliance monitoring. A snapshot authorization is no longer sufficient. Cloud providers serving federal agencies now have to demonstrate that their controls hold under real operating conditions, not just at audit time. For any organization using a CSP to move data with federal agencies, that’s a requirement that flows down.

CMMC 2.0 Level 2 takes effect November 10, 2026 for defense industrial base contractors handling Controlled Unclassified Information. Mandatory third-party assessments replace the self-attestation that gave contractors wiggle room. The assessment covers 110 practices from NIST SP 800-171, and file transfer controls sit squarely in scope. Kiteworks’ 2025 CMMC Preparedness research found significant preparedness gaps across the DIB -- which is consistent with what I hear from contractors who’ve started their assessment prep and discovered their file sharing practices weren’t what they assumed.

The updated HIPAA Security Rule closes the “addressable” escape hatch on ePHI encryption. AES-256 at rest, TLS 1.2 or higher in transit, both required. Any system that moves protected health information -- not just your EHR, but every file transfer pathway touching PHI -- now has a specific technical standard to meet, not a documentation path around it.

GDPR’s enforcement posture on Standard Contractual Clauses for cross-border transfers has sharpened considerably. The EU data protection authorities levied €1.2 billion in fines tied to AI data processing violations in 2023 alone. Those numbers reflect what happens when data movement goes undocumented -- you can’t demonstrate a lawful transfer basis for data you can’t trace.

The EU AI Act’s high-risk AI system provisions are fully enforceable August 2, 2026. The penalty ceiling is €35 million or 7% of global annual turnover. File transfer sits in scope wherever AI touches personal data in motion -- and given how quickly AI-assisted processing is being embedded in document workflows, that’s a broader surface than most legal teams have mapped.

CIRCIA requires critical infrastructure operators to report significant cyber incidents within 72 hours. That clock starts when you detect the incident -- not when you finish investigating it. Organizations that can’t reconstruct what moved, when, and where during a file-transfer-related breach are going to have a very hard time meeting that window.

The same failure mode underneath all six

What strikes me about these frameworks is that they’re not targeting different problems. They’re all targeting the same one.

Ungoverned file movement is the failure mode. Data moves outside approved channels, without encryption enforcement, without audit trails, without controls that verify where it went or who accessed it. When that happens under FedRAMP scope, it’s a continuous monitoring gap. Under CMMC, it’s a CUI control failure. Under HIPAA, it’s a breach. Under GDPR, it’s an inability to demonstrate lawful transfer. Under the EU AI Act, it may be a prohibited processing activity. Under CIRCIA, it’s a gap in your incident reconstruction.

The same bad practice -- “we just used email / a personal Dropbox / an FTP server we set up years ago” -- creates simultaneous liability under all six frameworks. That’s not a coincidence. It’s the regulators catching up to a risk pattern that practitioners have known about for years.

IBM’s Cost of a Data Breach 2025 report puts the average breach at $4.88 million globally. Cloud-based AI-involved breaches run 28% higher than on-premise equivalents. And 65% of new cyber insurance policies written in 2024 include AI risk exclusion clauses, according to Munich Re data cited in AI Security Statistics 2026. The financial exposure from ungoverned file transfer is no longer theoretical -- and insurers are already pricing it.

Why the patchwork approach doesn’t work anymore

Most organizations I talk to have layered their compliance tools over time. An SFTP setup for one workflow. A secure email gateway for another. A vendor portal for a third. Each tool was the right answer for one requirement at one moment. Together they produce something worse than a single bad tool -- a multi-system estate with inconsistent controls, inconsistent logging, and no unified audit trail.

That architecture makes multi-framework compliance almost impossible to demonstrate. Your CMMC assessor wants evidence that CUI moved through controlled channels. Your HIPAA auditor wants encryption validation logs. Your GDPR counsel needs transfer mechanism documentation. Your CISO needs incident reconstruction capability for CIRCIA. If those records live in four different systems with incompatible formats, you’re spending compliance budget on reconciliation instead of remediation.

The Cerberus FTP Server team’s analysis of 2026 compliance requirements frames this accurately: the burden isn’t one new rule -- it’s the simultaneous enforcement of six frameworks that each treat file transfer as a compliance control surface, not an IT utility.

What a consolidated architecture actually buys you

Kiteworks holds FedRAMP Authorization, is CMMC-ready, operates with FIPS 140-3 validated encryption for HIPAA compliance, includes jurisdictional data-residency controls for GDPR, and produces tamper-evident audit trails for CIRCIA incident reporting -- a private content network built to address all six frameworks from a single governed architecture. For organizations managing multi-framework compliance from a patchwork of separate tools, consolidation is both a compliance simplification and a cost decision. Fewer systems means fewer integration gaps, fewer places where the audit trail breaks, and fewer control failures that create simultaneous liability across frameworks.

The November 10 date is worth putting in your calendar

CMMC 2.0 Level 2’s mandatory assessment date -- November 10, 2026 -- is the hardest deadline in this set. A third-party assessment is not something you pass on goodwill. The assessor will examine your actual controls, not your documented intent to have them.

The DIB preparedness data suggests a lot of contractors are going to discover gaps during that process that they should have found earlier. File transfer controls are among the most commonly cited deficiencies in CMMC readiness reviews, because they touch so many of the 110 practices -- access control, audit logging, system and communications protection, configuration management.

If November 10 is relevant to your organization, the work that needs to happen before then is already in progress or already late.

Six regulators looked at the same breach data, the same enforcement history, and the same pattern of organizations treating file transfer as infrastructure rather than control -- and they all reached the same conclusion. The frameworks are different. The deadlines are different. The penalties are different. The failure mode they’re all targeting is identical.

The HIPAA encryption requirement 2026 changes what “addressable” ever meant

For 20-plus years, HIPAA’s encryption standard for electronic protected health information operated on a legal fiction. The Security Rule categorized encryption as an “addressable” implementation specification -- not “required.” In practice, a covered entity could look at encryption, document why it wasn’t “reasonable and appropriate” for their situation, and walk away without encrypting a single email.

That’s done now.

HHS OCR has a May 2026 publication target for the updated Security Rule. Once it publishes, covered entities get 180 days to meet the substantive requirements. Business associate agreements get 240 days. The window sounds long until you realize most healthcare organizations haven’t seriously looked at their email encryption posture in years.

170 breaches. 2.5 million patients. One category of failure.

HHS OCR’s breach portal reported 170 email-related HIPAA breaches in 2025 alone, affecting over 2.5 million individuals. That’s a single attack vector -- email -- producing patient harm numbers that would embarrass any other regulated industry.

The “addressable” flexibility didn’t protect patients. It protected organizations from the cost of doing the right thing.

HHS looked at two decades of breach data and concluded the flexibility was being used as a permanent workaround rather than a temporary accommodation. The new rule is the regulatory equivalent of: we gave you the option, you didn’t take it, people got hurt, and now it’s not optional.

What the rule actually requires

The updated HIPAA Security Rule moves encryption from addressable to required, with specific technical standards attached. AES-256 encryption at rest. TLS 1.2 or higher in transit. Not one or the other -- both, with no documentation path out.

Beyond encryption, the rule adds mandatory annual security risk assessments -- not periodic, annual -- and MFA across all systems that access ePHI. Documentation requirements get substantially more detailed. A one-paragraph risk assessment justifying no encryption no longer works.

Medcurity’s analysis of the rule frames this correctly: organizations that treated “addressable” as “optional” now face a concrete remediation timeline, not another documentation exercise.

The AI problem sitting inside the encryption problem

The encryption mandate doesn’t exist in a clean environment. Healthcare’s security posture has gotten more complicated precisely as the regulatory bar is rising.

67% of healthcare organizations now use AI tools with PHI access, according to Ponemon research. More alarming: 46% of clinicians share patient data with AI tools without IT approval -- Kaspersky data from the same report. Data moving to unsanctioned AI tools is data outside the encryption perimeter, by definition.

HHS OCR has already issued $14.5 million in fines for AI-related HIPAA violations. The 2023 breach data showed 725 AI-related PHI breaches affecting over 133 million records -- and that predates the current wave of AI tool adoption in clinical settings. An AES-256 encryption mandate matters a lot less if clinicians are pasting patient notes into consumer AI tools before anyone can encrypt them.

Why healthcare keeps losing

IBM’s Cost of a Data Breach 2025 report puts the average healthcare breach cost at $9.77 million per incident -- highest of any industry, 13th consecutive year. That number is a direct consequence of long system replacement cycles, clinical staff prioritizing workflow speed over security protocols, and years of regulatory flexibility that made deferring hard infrastructure decisions the path of least resistance.

The 180-day clock will hit organizations differently depending on how much of that deferral has accumulated. A health system on a modern cloud email platform with native encryption controls faces mostly a configuration and documentation task. An organization still running on-premises Exchange or routing clinical coordination through unencrypted email has a real problem on its hands.

The architecture question most organizations haven’t answered

Encryption compliance forces a question that goes beyond email: where does ePHI actually travel, and what protects it at each hop?

Most organizations have a reasonable handle on their EHR. The ten other applications touching PHI are murkier -- referral workflows, scheduling systems, patient portal integrations, billing clearinghouse connections. Each is a transit point that now needs TLS 1.2 or above, not as a best practice but as a condition of compliance.

Kiteworks built its content security platform around FIPS 140-3 validated encryption, AES-256 at rest, and TLS-enforced transport with tamper-evident audit logging -- the specific controls the updated rule requires. For healthcare organizations that haven’t modernized the infrastructure carrying ePHI outside the EHR perimeter, the compliance deadline is also a procurement decision.

Where to focus before the clock runs out

Three things worth doing before the final rule publishes:

Map your ePHI flows -- the EHR and every other system touching patient data, including email, file sharing, and any AI tools clinical staff have adopted with or without IT’s knowledge.

Audit your current encryption state against AES-256 at rest and TLS 1.2+ in transit. Most modern systems support these standards. The question is whether they enforce them or just list them as an option.

Schedule your annual security risk assessment if you haven’t done one in the last 12 months. The updated rule makes it mandatory, and it’s the foundation for demonstrating compliance across everything else.

The organizations that will have trouble with this rule are the ones that treated “addressable” as a permanent answer. It never was -- and 170 email breaches affecting 2.5 million patients are the evidence HHS cited for finally closing it.

I’m at BankIT USA this week in New York, and the session that’s drawing the most hallway conversation is Kiteworks’ presentation on AI data governance in banking -- specifically the framing that 63% of enterprises cannot enforce purpose limitations on AI agents operating over regulated data. That number lands differently in a room full of bank CISOs and CCOs than it does in a general enterprise security audience. They know exactly what “purpose limitations” means under GLBA. They know what failing to enforce them looks like in an exam.

The conversation about banking AI governance compliance has shifted sharply in the last six months. A year ago, the question was whether AI belonged in regulated workflows at all. Now the question is how to demonstrate to a regulator -- in writing, with attribution-grade records -- that AI operations on customer financial data are authorized, bounded, and auditable.

That’s a harder question than it looks.

The frameworks already apply -- they just weren’t written for this

GLBA doesn’t have an AI carve-out. The FTC Safeguards Rule, updated in 2023, requires financial institutions to implement administrative, technical, and physical safeguards for customer financial information -- including access controls, encryption, and monitoring. Those requirements don’t disappear because the actor accessing the data is an AI agent rather than a human employee.

The same is true for SEC Regulation S-K Item 106, which requires public companies to disclose material cybersecurity incidents within four business days and to describe cybersecurity risk management processes annually. When an AI agent makes an unauthorized access to customer financial records -- or when you can’t determine whether it did -- the disclosure question is live immediately. “We don’t have attribution-quality logs for AI agent activity” is not an answer that plays well in that context.

What the risk actually looks like

Here’s what’s being underreported in most AI governance conversations: this isn’t primarily a future risk. It’s a present one.

EY’s research found that 99% of organizations reported financial losses from AI-related risks in the past year. 64% of those losses exceeded $1 million. The average came in at $4.4 million. In banking, where IBM’s Cost of Data Breach research puts the average financial sector breach cost at $6.08 million -- second only to healthcare -- those numbers compound fast.

The control problem is equally concrete. Akeyless research published in 2026 found that only 7% of organizations believe their current controls would stop a compromised AI agent. When an AI agent starts behaving badly -- accessing data outside its authorized scope, making decisions outside its intended purpose -- the average detection time is 14 hours. Containment takes nearly a week.

For a bank operating under GLBA, 14 hours of undetected unauthorized access to customer financial data is not an operational inconvenience. It’s a reportable event, a potential exam finding, and possibly a material incident under SEC reporting obligations.

The identity problem is the hardest part

Most of the AI governance conversation focuses on access control -- what data can an AI agent reach? That’s important. But there’s a prior question that most banks haven’t solved: who authorized this AI agent to act, and can you prove it?

When a human employee accesses customer records, you have a clear identity, a clear role, a clear authorization chain, and a documented access event. When an AI agent does the same thing, you often have none of those. The agent acts under service account credentials. The authorization was implicit -- someone configured the workflow, and the workflow runs. There’s no cryptographic link between the AI agent’s action and the human who authorized it.

Regulators are starting to ask about this. The Institute of International Finance’s October 2025 AI governance survey found that financial institutions are still working out which executives own AI governance and which Key Risk Indicators apply. The governance ownership question and the technical attribution question are the same problem from different angles.

What banking AI governance compliance actually requires

The four-pillar framework that Kiteworks is presenting at BankIT addresses this precisely: authenticated agent identity cryptographically linked to the human authorizer; per-request policy enforcement evaluated on every operation (not just at session establishment); FIPS 140-3 encryption with jurisdictional sovereignty; and a tamper-evident audit trail that produces attribution-grade records. The argument isn’t “here’s our product.” It’s “here’s what a GLBA examiner or an SEC enforcement attorney is going to ask for, and here’s the architecture that produces a defensible answer.”

The reason that four-pillar framing matters is that it maps directly to what examiners actually look for. Access control isn’t just “this agent can access these systems” -- it has to be evaluated on every request, based on the specific content being accessed and the specific purpose claimed. Encryption isn’t just “we use TLS” -- it has to meet the validated standard for regulated data. And audit records aren’t just logs -- they have to be tamper-evident and granular enough to reconstruct exactly what an AI agent accessed, when, under what authorization, and why.

The exam question banks aren’t ready for

The bank CISOs I talk to are good at answering exam questions about human-actor access controls. They’ve built those programs over decades. They can show an examiner which employees have access to which customer records, what controls govern that access, and what the audit trail looks like.

They’re not ready to answer the same questions about AI agents. And regulators are going to start asking.

The IIF survey found financial institutions are still debating internal ownership of AI risk. That debate needs to resolve before the next exam cycle -- not after. The frameworks that apply aren’t new. GLBA, the FTC Safeguards Rule, and SEC Regulation S-K already create the obligation. AI agents operating on customer financial data are inside that obligation, not outside it.

What changes the calculation

Banks that get ahead of this aren’t just managing compliance risk. They’re building something that actually works operationally. An AI agent operating under authenticated identity with per-request policy enforcement and a tamper-evident audit trail is an AI agent you can actually trust with regulated workflows -- because you can demonstrate, at any moment, what it was authorized to do and what it actually did.

That’s not just a regulatory answer. It’s the foundation for deploying AI at scale in a regulated environment without exposing the institution to exam findings, enforcement action, or the kind of incident that triggers four-day disclosure obligations under SEC Reg S-K.

The banks that wait for AI-specific regulations before building this governance architecture will be behind. The frameworks that matter are already in force.