Home > Security and Compliance Blog > Cybersecurity Risk Management > Agentic AI Governance Gap Is Now a Compliance Problem

Agentic AI Governance Gap Is Now a Compliance Problem

by Patrick Spencer updated November 10, 2026 Cybersecurity Risk Management

Reading Time: 11 minutes

Organizations are giving AI agents the ability to act on sensitive data far faster than they are building the controls to govern that access. A workplace law firm report, a university study, a securities regulator, a health records vendor and a cloud threat team all published findings within days of each other, and together they describe the same gap. The technology is moving from suggesting to doing, and the evidence that someone is watching what it does has not kept pace.

This post pulls those threads together for the people who will be asked to answer for it, the CISO and the Chief Compliance Officer. The argument is simple. An AI agent that can read a patient record, change a file or call a cloud model is an identity with privileges. Governing it looks a lot like governing any other privileged identity under a zero trust model, with a policy that limits what it can reach and a record that shows what it actually did. The rest of this article walks through what the latest evidence says, where the exposures are, and what a defensible position looks like.

Table of Contents

Key Takeaways

1. Deployment is outrunning governance.

Gartner figures relayed by a law firm show agent deployment expected to rise sharply while few organizations believe their governance is right.

2. Agents move AI from advice to action.

Once an assistant can act, the control question shifts from output quality to access and accountability.

3. Disclosure is thin.

An MIT study found most AI companies say little about the risks they create, which leaves enterprise buyers to do their own diligence.

4. Regulators now test AI claims.

The SEC’s enforcement director has said exaggerated AI capability statements will draw scrutiny, so claims need records behind them.

5. Least privilege is the practical answer.

Google’s own advice on stolen AI credentials is to deny every permission that is not explicitly required.

What the Latest Evidence Says About the Gap

Start with the numbers that frame the problem. Littler Mendelson’s report on agentic AI in the workplace says the technology “moves workplace AI from recommendation to action.” Citing Gartner’s 2026 CIO and Technology Executive Survey, it says deployment of AI agents is expected to rise from 17 percent in 2026 to more than 60 percent within two years, and that at least 15 percent of day-to-day work decisions are expected to be made autonomously through agentic AI.

The same material reports that 74 percent of organizations expect moderate AI use within two years, while only 13 percent think they have the right governance. It also relays a prediction that more than 40 percent of agentic AI projects will be canceled by the end of 2027, with cost, unclear business value and inadequate risk controls given as the reasons. These are secondary figures, Gartner statistics relayed by a law firm, so treat them as directional. They are still consistent with what a security team sees on the ground, which is a lot of enthusiasm and not much inventory of what the agents can reach.

The gap deserves a precise description. It is not that organizations lack AI policies. Many have written them, and good data governance practice already asks for more. It is that a policy statement and an enforced control are different things, and an auditor or regulator asks about the second. Littler offers employers a framework it calls Decide, Design, Defend, which is a reasonable shorthand for the discipline involved. Decide what the agent may do. Design the controls that enforce it. Defend the decision with records when someone challenges it.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

Why an Agent Is a Privileged Identity

It helps to drop the novelty and describe an agent in plain security terms. An agent holds credentials. It connects to systems. It reads, writes and sends. It acts on instructions it may receive from untrusted content. Every one of those properties belongs to a privileged identity, and every control security teams already use for such identities applies. The agent needs a defined scope, authentication that is not shared, authorization decisions made at the time of each request, and a log that records the action in an audit log you can produce on request.

The difference is speed and scale. A human with excessive access can do damage slowly. An agent with excessive access can do it in seconds and across thousands of records, and it may not tell anyone. That is why the question to ask is not whether the model is accurate but what the agent is permitted to touch and whether you could reconstruct what it did. The answer needs to exist before an incident, because afterward the evidence either is there or is not.

There is also a visibility problem that sits underneath. Teams cannot govern agents they do not know about. The first operational step, and the foundation of any AI data governance program, is an inventory of which agents exist, which data they can reach, who owns each one, and which connectors they use. Without that list, every downstream control is a guess.

A Health Records Connection Shows the Ambiguity

A recent health care example makes the abstract point concrete. Athenahealth unveiled a connection called athenaPatient MCP, according to reporting by HealthcareInfoSecurity, that lets patients authorize Anthropic’s Claude to retrieve labs, medications, diagnoses, allergies, immunizations, procedures and care plans from their records. It is initially available to U.S. Claude Pro and Max subscribers, who log in with their athenahealth patient portal credentials. Athenahealth says patients can revoke access at any time and that shared information is retained only for the duration of the session.

The legal question is the interesting part. Athenahealth’s position, in its words, is “It means that HIPAA is not applicable in this use case.” Attorney Jordan Cohen of Akerman LLP is quoted as saying HIPAA generally falls away once records reach the patient. Rachel Rose points to Texas House Bill 300 and its broader covered-entity definition, and advises keeping psychotherapy notes and 42 CFR Part 2 records out of these systems. In other words, experts disagree about whether any HIPAA protection follows the data once a patient authorizes an assistant to pull it.

The article cites an August 2026 Pew survey finding that 34 percent of U.S. adults used AI chatbots for health purposes, which means the scenario is not hypothetical. For an organization that handles protected health information, the lesson is not that this particular connector is good or bad. The lesson is that the moment sensitive records flow to an AI assistant through a protocol connection, the answer to who is responsible, which rules apply and what record exists can become unclear. Compliance teams should resolve that ambiguity in writing before the data moves, and they should keep high-risk categories out of the flow altogether until they have. The HIPAA minimum necessary rule is a useful reference point for how much data any connection should carry.

Disclosure Is Thin, So Diligence Falls to You

If vendors disclosed their risks clearly, enterprise diligence would be easier. An MIT report using early 2026 data suggests they do not. It found that 62 percent of the top 1,000 AI companies and 32 percent of the top 100 did not discuss potential risks. Companies that do disclose name only five categories, which are discrimination, weapons and cyberattacks, fraud and scams, loss of privacy, and devaluation of human creativity.

Finance and insurance firms acknowledge an average of 2.9 AI risks, compared with 7.1 for information sector organizations. Few companies address the risks of multi-agent systems despite rapid enterprise adoption. Peter Slattery of MIT FutureTech, a co-author, said “at the moment we have very little transparency about that.” The article notes that most of the data predates the June Hugging Face incident, so the picture may have changed.

The practical consequence is that a buyer cannot rely on a model provider’s public risk statements to satisfy its own regulators. The enterprise has to build its own record of how it assessed the risk, what it decided and what controls it applied. That record is the thing that turns a vendor claim into your evidence. It belongs in your supply chain risk management file, next to the inventory of agents and connectors.

Regulators Are Starting to Test the Claims

The disclosure problem cuts both ways. On October 30, 2026, SEC Enforcement Director David Woodcock told Reuters and Law360 that the agency is monitoring corporate AI disclosures, according to a post from the Debevoise Data Blog. He said enforcement will target public companies whose statements “may exaggerate their AI capabilities,” and flagged failure to disclose AI use or risks in a core part of a business. He cited earlier cases against private companies involving overstated AI and robotics capabilities and expects similar investigations of public companies.

The Debevoise authors advise reviewing investor materials for what they call AI hushing, defining AI and agentic capabilities precisely, substantiating performance claims with records, and using risk assessments to inform disclosures. The common thread with the governance gap is evidence. A company that says its agents operate under controls needs to be able to show the policy, the enforcement and the logs. A company that says its AI capabilities are advanced needs records that substantiate the claim. In both cases a statement that cannot be backed becomes a liability.

This connects to a lesson from enforcement in other areas of cybersecurity, where the exposure often comes from the distance between what was represented and what existed. The same logic now applies to AI statements.

Stolen AI Credentials Show the Cost of Broad Access

The final thread is the most direct illustration of what excessive permissions cost. Google Threat Intelligence Group and Mandiant analyzed a pattern called LLMjacking, in which attackers use stolen API keys or exposed model endpoints to run up cloud AI charges, according to BleepingComputer. Some victims lost more than $100,000 in a day, and cumulative charges reached $1,000,000 at some. Attackers sell access through services the report calls LLM mixers, and one, Jet Night, sells unlimited access plans for $60 a month.

Google names a threat cluster and a vulnerability in LiteLLM, and its advice is blunt. It recommends organizations “Deny all permissions that are not explicitly required, including access to Cloud LLM services.” The harm in these cases is billing fraud rather than content theft, so it sits at the identity and credential layer. It is still a clear demonstration of the principle. Credentials that can reach AI services are valuable, and the narrower they are, the less an attacker gains.

For agents that touch sensitive content the same advice applies with higher stakes. Scope each agent to the minimum data and actions it needs, as zero trust data protection strategies recommend, authenticate it as its own identity, and log every request it makes.

Existing Frameworks Already Reach AI

A common mistake is to wait for AI-specific law before acting. In practice several frameworks that organizations already follow reach AI access today. Health privacy rules govern how protected information is used and disclosed. Financial regulators have started to treat AI as part of cyber governance, and NYDFS Part 500 is one place where that expectation is being worked out. Privacy regimes such as GDPR already ask who processes personal data and on what basis, and an agent that processes personal data is subject to the same questions as any other processor.

The point is not that every framework mentions agents by name. Most do not. The point is that the underlying duties are technology neutral. A duty to limit access to what is necessary, to log access, and to be able to explain who saw what applies whether the actor is a person, a script or an agent. Teams that map their agent inventory onto the duties they already have will find most of the work is familiar. The new element is volume and speed, which makes automated enforcement and automated evidence more important than they were when a human did the work.

It is also worth separating two questions that often get blurred. The first is whether an agent is allowed to take an action, which is a policy and access question. The second is whether the organization can prove afterward what happened, which is an evidence question. Governance programs that answer only the first leave themselves exposed when someone asks the second, and the SEC’s stated interest in substantiating AI claims suggests the second question is coming from more directions.

What a CISO and CCO Should Do Now

The following steps are ordered by how quickly each reduces exposure, and none requires waiting for a new regulation.

Start with an inventory. List every AI agent, assistant and connector in use, including those a business unit adopted without a security review. For each, record the owner, the data it can reach, the credentials it uses and the approval date. This is the foundation for everything else.

Next, define what each agent may do and enforce it at the point of access. A written policy is a start. An enforced policy, evaluated on each request based on who or what is asking, what data is involved and what the action is, is the control. Apply least privilege and remove anything not explicitly required.

Then decide where regulated data may and may not go. Resolve the HIPAA-type ambiguities in writing for your context. Where experts disagree about whether protection follows the data, keep the highest risk categories out until counsel has settled the position.

After that, test whether you can reconstruct agent activity. Pick one agent and ask for a complete record of what it accessed last month, by which credential, and under which policy. If assembling it takes days and several systems, that is the priority gap.

Finally, check your outward statements. Compare what you have told investors, customers and regulators about your AI capabilities and controls with the records that support them. Fix any distance before someone else finds it.

One last habit is worth building into the program from the start. Review the inventory on a fixed schedule, whether quarterly or after any significant change in how agents are used, and record the review. Agent use changes quickly, with new connectors and new business uses appearing between audits. A dated review record shows that governance is a living process, and it gives the CISO and the Chief Compliance Officer a shared artifact to bring to the board when directors ask how the organization is managing AI risk.

A Simple Way to Test Agent Governance

A useful exercise for a security or compliance team is to pick a single agent, assistant or connector in use today and try to answer five plain questions about it. Who approved it? What data can it reach? Under whose identity does it act? What did it do last month? And who would you call if it did something wrong? Those are the questions a regulator, an auditor or an incident responder will ask, and they do not depend on which model sits behind the agent.

Most organizations find that the first two answers come easily and the last three do not. Approval and scope are usually written down at the start. Identity, activity records and ownership drift as a pilot grows into a dependency. The Gartner material relayed by Littler anticipates agents making at least 15 percent of day-to-day decisions autonomously, which means the gap between what was approved and what is actually happening will widen unless someone owns the question. Treat the exercise as a recurring check and not a one-time audit, and keep the answers in a form you could hand to a reviewer.

How Kiteworks Supports Governed AI Access

The part of this problem that involves AI reaching sensitive content, such as files, email and records, is where governance most often breaks down, because access is granted through a connection that sits outside normal controls. The Kiteworks Secure MCP Server evaluates every agent request against role-based and attribute-based access controls and records agent activity in a unified audit log. Compliant AI applies governance at the data layer, checking authenticated identity, policy and encryption before content is released, and it works with MCP-compatible AI models. That gives a compliance team one place to ask what an agent touched.

It supports the work described above and does not replace it. A platform can enforce policy and produce records, but the agent inventory, the risk decisions and the statements made to regulators remain your organization’s responsibility, and assessors decide whether a control meets a requirement.

To learn more about governing AI access to sensitive content with audit-ready evidence, schedule a custom demo today.

Frequently Asked Questions

Earlier tools mostly produced recommendations that a person then acted on. Agents act, which means they hold credentials and take steps on their own. That moves the compliance question from whether the output was accurate to what the agent was allowed to access and whether you can show what it did. A practical start is the AI data governance guide, and you can compare it with how you treat other privileged identities.

Experts disagree, and that disagreement is the finding. Athenahealth says HIPAA is not applicable in its patient-authorized use case, and an Akerman attorney is quoted saying HIPAA generally falls away once records reach the patient. Another attorney points to Texas House Bill 300 and advises keeping psychotherapy notes and 42 CFR Part 2 records out. Review the HIPAA Security Rule obligations that apply to your own systems and get counsel’s view before sensitive data moves.

Assume you will need to build the record yourself. An MIT study found 62 percent of the top 1,000 AI companies did not discuss potential risks. Document how you assessed each provider, what you decided and what controls you applied, and store it with your third-party file. The zero trust for generative AI approach is a useful frame for those controls.

The enforcement director has said the agency will look at statements that may exaggerate AI capabilities and at failures to disclose AI use or risks in a core part of a business. Counsel’s advice is to define capabilities precisely and substantiate claims with records. Keep the evidence behind each outward statement, supported by an audit log of agent activity where relevant.

Apply least privilege. Google’s advice is to deny all permissions that are not explicitly required, including access to cloud model services. Inventory the keys and agents in use, scope each to the minimum, rotate credentials and monitor usage. See the zero trust AI data privacy guide for how to extend the same principle to data access.

Additional Resources