Home > Security and Compliance Blog > Cybersecurity Risk Management > AI Agent Governance Has Become an Evidence Problem

AI Agent Governance Has Become an Evidence Problem

by Patrick Spencer updated November 3, 2026 Cybersecurity Risk Management

Reading Time: 12 minutes

An AI agent that touches sensitive data must be governed like the employee who authorized it, and many organizations may not yet be able to prove that it is. The gap is not a shortage of policies. It is a shortage of evidence that the policies were enforced at the moment an agent read, moved or changed a record.

A survey from Foundry and Rubrik, reported in a Rubrik-sponsored CIO BrandPost published October 29, 2026, puts numbers on that gap. Of 200 IT and AI decision makers, 38 percent said agents had exfiltrated data or caused a sensitive data leak, and 42 percent named governance, guardrails and compliance as obstacles to implementing agents. Read the figures with care, because the source is sponsored and small, but notice how consistent they are with other research published over the past six months.

Table of Contents

For a CISO, a Chief Compliance Officer or a Data Protection Officer, the question is the one a regulator will ask. Who was the user, what authority did the agent act under, and where is the log? This post separates what the Foundry and Rubrik survey can and cannot support, sets it beside findings from EY and others, and lays out the evidence package that lets an organization govern agents and humans under one set of rules. It also explains where Kiteworks Compliant AI and the Kiteworks Control Plane fit when the data layer is where evidence must be produced.

Key Takeaways

1. The survey signal is real, but the source is a sponsor.

A Rubrik-sponsored survey of 200 decision makers reports that 38 percent confirmed an agent-caused leak, which is a reason to test your own controls and not a benchmark to quote as fact.

2. Autonomy is manageable, unattributed autonomy is not.

Agents are a second class of identity that must be governed alongside humans, with every action traceable to an accountable person.

3. Governance is the stated bottleneck.

Research from EY and others shows policies are common while operational control and ownership lag behind.

4. Existing data rules already reach agents.

HIPAA, GDPR and sector rules contain no exemption for automated access to regulated data, so the evidence standard for an agent is the standard for a human.

5. Evidence beats intent.

The organizations that can produce a unified, attributable record of agent data access in hours will answer inquiries that others cannot.

What the Foundry and Rubrik Survey Says

The BrandPost reports that agents are allowed to act with full autonomy (26 percent) or limited autonomy (35 percent). It reports that 42 percent cite governance, guardrails and compliance as obstacles to agent implementation, and that 24 percent name security and governance as the single biggest barrier to scaling agents. It reports that 38 percent confirmed an agent had exfiltrated data or caused a sensitive data leak, and that nearly half had dealt with an agent or chatbot conveying false or incorrect information.

Now the caveats. The piece is a BrandPost sponsored by Rubrik, a vendor that sells agent governance and recovery products, and the article does not state when the survey was fielded or how respondents were selected. A sample of 200 cannot support industry-wide claims. The 38 percent figure is respondents’ own account, and the article does not define what counts as a leak or how it was confirmed.

Those limits do not make the findings useless. They make them a hypothesis worth testing against your own environment. If nearly two in five respondents say they have already seen an agent leak data, the question for the rest is whether they would know. A leak that nobody detects is not recorded in any survey.

The more useful reading is structural. Respondents say they are giving agents real autonomy while naming governance as their main obstacle. Those two facts together describe a program that is expanding faster than its evidence base.

Autonomy Is Not the Problem, Attribution Is

It is tempting to read a figure like 26 percent full autonomy as a warning that agents are running loose. The better question is whether each autonomous action can be traced to an accountable human and a governing policy. An agent acting within delegated authority is a normal part of modern work. An agent acting with no recorded delegation is a compliance problem.

EY’s survey sharpens the point. In EY’s US AI Risk and Governance Survey, published September 15, 2026, 85 percent of agentic AI users said they run at least a handful of agentic systems that act without real-time human intervention. The survey covered senior AI decision makers at U.S. public companies with at least $1 billion in revenue, so it describes large enterprises and not the whole market. EY is also an assurance firm with an interest in the topic.

Real-time human intervention is the wrong test of control. Nobody reviews every database query a trusted employee runs either. What makes that acceptable is that the employee has a unique identity, a role, permissions that match the job and an audit trail that records what happened. The same architecture must apply to agents. An agent is a second class of identity alongside human identity, governed by the same policies, and the human who authorizes it remains accountable.

That framing changes the design requirement. The goal is not to slow agents down so a person can click approve. The goal is to ensure that an agent can never exceed the access of the user who authorized it, that every action is attributed to that user and that the record cannot be quietly altered. When those conditions hold, autonomy is a productivity feature. When they do not, it is an unlogged access path.

Governance Is the Stated Bottleneck, and the Audit Trail Is Where It Shows

The 42 percent who cite governance as an obstacle are describing something that EY’s data explains. The same EY survey found that 98 percent of respondents report formal AI governance policies and 69 percent report a fully unified policy, yet 47 percent say their organization has previously bypassed its AI governance process for urgent deployment. Among agentic AI users, 49 percent say their governance framework has not been specifically updated for agentic AI risk.

Put those numbers together and a pattern appears. Policies exist. Enforcement under deadline pressure is uneven. The framework was written for AI that produces outputs and has not caught up with AI that takes actions. This is the same distinction that a CISO sees between a policy document and a control that operates.

The evidence angle is where this becomes a compliance matter. An auditor does not ask whether you have an AI policy. An auditor asks you to show a sample of agent actions against sensitive data, the identity each ran under, the policy that permitted it and the log that proves it. If the answer takes weeks to assemble, the policy has not been operationalized in any way that matters to the audit.

The Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report measured that gap directly in a survey of 459 respondents across several regions. Only about a quarter (27 percent) could produce a complete AI audit record within one business day, and only 17 percent within one hour. Those figures are self-reported in a vendor survey with a mixed sample, so they are directional, but they match the shape of the EY finding. Policy is widespread, and proof on demand is not. Closing that gap is the heart of any serious AI data governance program.

Visibility and Rollback Are the Quiet Gaps

If governance is the headline obstacle, visibility and recovery are the quieter ones. Rubrik Zero Labs published a separate and larger study, The State of the Agent, on April 16, 2026, drawing on more than 1,600 IT and security leaders. It reports that 86 percent expect agents to outpace their security guardrails within a year, that 23 percent report full visibility into the agents in their environment, and that 88 percent say they cannot roll back agent actions without disrupting systems. The release itself says the visibility figure is probably an overestimate.

This is the same vendor as the sponsor of the CIO piece, so it is not independent corroboration of the Foundry and Rubrik numbers. It is a second look from one source, with a larger sample, though the release gives little methodology detail. Treat it as one vendor’s view and weigh it accordingly.

What the study does illustrate is the compliance angle of rollback. If an agent alters or exposes a record, the organization needs to know which records, which user authority and which time window. Recovery without attribution is a technical fix that leaves the legal question unanswered. Regulators ask what happened and to whom, not only whether the system was restored.

For the CCO the practical takeaway is that agent incidents need the same investigative record as human incidents. That means the audit trail must name the agent, the authorizing user, the data touched and the policy applied, and it must be retrievable in the same format as every other access record.

Sanctioned Agents and Unvetted Tools Open Two Doors to the Same Data

The Foundry and Rubrik survey describes agents an organization chose to deploy. A second exposure runs through tools it never chose. Compliance Week reported on October 29, 2026 that regulators and national authorities worry companies may be unwittingly exposing themselves to significant risk by adopting cheaper Chinese-made AI tools, or open-source software that relies on them. The visible text cites national security, cybersecurity and data protection concerns, says such tools may not meet stricter EU or US standards, and warns that data entered into them could be retained and used by Chinese authorities. The article is subscriber-only after its opening paragraphs, so this post relies only on what is visible and cites no figures from it.

The point for a compliance leader is not about any one vendor or country. It is that an organization can lose control of sensitive data through an AI tool that nobody approved, a pattern usually called shadow AI. A sanctioned agent that leaks data and an unvetted tool that retains it are two doors to the same room, and the question a regulator asks is identical. Which data left, through which tool, under whose authority, and where is the record?

A sponsored piece from SailPoint, reported by CIO as a BrandPost, gives the condition a name. It defines an AI trust deficit as what occurs when an organization deploys autonomous AI agents faster than it can prove they are acting within policy. It cites Omdia research that more than half of enterprises are already deploying agentic AI, and quotes SailPoint’s Mike Kiser saying that AI innovation has outpaced AI safety. SailPoint is an identity security vendor, and this is vendor content, so treat the framing as a perspective and not a finding. The definition is still useful because it ties the problem to proof, not to the existence of a policy.

Note the shape of the trust deficit. It is not a claim that agents are unsafe. It is a claim that the organization cannot demonstrate they are acting within policy. That is an evidence problem, which is exactly what an audit trail and a data-layer control exist to solve. Whether the door is a sanctioned agent or an unvetted tool, the remedy starts with the same discipline of knowing which data each tool can reach and recording every access.

Ownership Is Still Unsettled, and That Is the Real Risk

Ask three leaders in one organization who owns AI agent security and you may hear three different roles. That ambiguity is a risk in its own right, and EY’s data shows what it can cost. EY reports that 26 percent of agentic AI users say they cannot detect unauthorized AI agents operating inside their organization, and a function that cannot see an agent cannot be accountable for it.

An accountability vacuum is the worst possible condition for producing evidence, because evidence requires someone to own the question. If the CIO deploys the agent, the CISO secures the platform and the CCO answers the regulator, then nobody owns the record that connects them. When an inquiry arrives, the three leaders each hold a fragment.

The fix is organizational before it is technical. Name a single accountable owner for agent data access, give that owner authority over the audit record and make the CISO and the CCO consumers of the same record. The Chief AI Officer or CIO can own adoption and speed, but the evidence standard must be set by the people who answer to regulators, and a clear governance, risk and compliance structure keeps those roles from drifting apart.

Existing Data Rules Already Reach Agents

The enforcement environment does not treat an agent as a special category. HIPAA does not care whether a clinician or an AI agent read the record. GDPR’s security and accountability duties apply whether a person or a system accessed the data, and Article 22 adds limits on solely automated decisions. The question in every case is whether access to sensitive data was authorized, limited to what was necessary and recorded.

The Security Rule under HIPAA shows how this works in practice. 45 CFR 164.308(a)(1)(ii) requires covered entities to conduct an accurate and thorough risk analysis and to implement procedures to regularly review records of information system activity, and both specifications are labelled required. Neither mentions who or what does the reading. An agent that reads patient records triggers the same duties under the HIPAA Security Rule as any other user, so the risk analysis must include it and the activity review must be able to find it.

The same logic applies in financial services, where data protection and security rules apply regardless of whether a human or an agent touched the data, and in legal settings where privilege and client confidentiality attach to the information and not the tool. The common thread is that an AI agent is a new way to reach regulated data, not a new category of regulated activity.

This is the strongest argument for governing at the data layer. Model governance matters for accuracy and bias, but the compliance exposure sits where data is accessed, used and exchanged. If you can govern and log that layer for every identity, human or agent, the evidence follows.

Governing the Data Layer for Humans and Agents Together

Kiteworks Compliant AI is built on one premise, which is to govern the data layer and not the model. In practice that means the controls that protect sensitive content for human users also apply when an AI system reaches for that content. The Kiteworks Secure MCP Server connects AI clients to enterprise content under role-based and attribute-based access control inheritance, so an AI client cannot exceed the permissions of the user who authorized it. Authentication uses OAuth 2.0 with PKCE, and activity is logged to the user who authorized the agent.

Those actions land in the same unified audit log that records email, file sharing, SFTP, forms and managed file transfer activity, with feeds to a SIEM for correlation. The Data Policy Engine applies data policies consistently, and the CISO Dashboard gives security leaders a view across that activity. The Kiteworks Control Plane governs data access, use and exchange for people and agents under one set of policies, one identity model and one audit trail.

Two limits are worth stating plainly. A data-layer control does not replace the risk analysis, the AI governance committee or the accountable owner, which remain human responsibilities. And it governs the sensitive content that flows through Kiteworks secure data exchange, so agents with direct access to data stores outside that boundary need their own controls. The architecture reduces the number of places an evidence package must be assembled. It does not eliminate the need to know where all your data lives.

Build the Agent Evidence Package Now

Start by inventorying the agents. Given that 26 percent of respondents in EY’s survey cannot detect unauthorized agents, a registry is the first control to build, because nobody can govern what they cannot list. Record each agent, the user or team that authorized it, the data it can reach and the systems it connects to.

Next, define the policy in terms an auditor can test. For each agent, state which data classes it may read, which it may never read, and under what conditions. Express the rules as attribute-based policies that follow the data, not as guidance in a document. A rule that exists only in a policy PDF cannot be shown to have operated.

Third, prove attribution. Pick a sample of agent actions from the last month and trace each to an authorizing user, an applied policy and a log entry. If any link in the chain is missing, you have found the gap before an auditor does. Repeat the exercise quarterly and keep the output.

Fourth, test your response. Run a tabletop exercise in which an agent is found to have accessed data it should not have. Measure how long it takes to identify the records involved, the authorizing user and the policy gap, and compare that time with the deadlines you face under your own regulations.

Finally, brief the board with evidence, not assurances. A one-page summary of agents in production, data classes reachable, last attribution test and open exceptions will do more than a maturity score. The board’s question is whether the organization can show control, and the answer must come from records.

To learn more about governing AI agents and human users under one policy and one audit trail, schedule a custom demo today.

Frequently Asked Questions

Cite it only with its context. It comes from a Rubrik-sponsored BrandPost that reports a survey of 200 IT and AI decision makers, and the article gives no field dates or definition of a leak. It is a reasonable prompt to test your own controls, not an industry benchmark. Pair it with independent sources such as EY’s survey, and test the number against your own environment by asking how quickly you could detect an agent leak. If the honest answer is “we would not know,” that is the finding worth acting on. The AI risk guidance offers a starting point for that review.

A shared service account is the weakest option, because it breaks attribution. When an agent acts through a generic account, the log cannot show which person authorized the action or whether the access matched that person’s permissions. HIPAA’s unique user identification and audit requirements, and GDPR’s accountability principle, both point toward attributable access. The better pattern ties each agent action to the authorizing user through identity and access management controls, so that the record shows both the agent and the accountable human. Treat agents as a second identity class alongside people, governed by one policy set, instead of letting them borrow a shared credential nobody owns.

Expect requests for the same artifacts as for human access. That means the risk analysis that includes the agent, the policy that limited its access, the identity it ran under, and the audit log showing what it read or moved. Data protection and security rules already apply to agent access to regulated data, so the absence of an AI-specific rule does not reduce the burden. A unified audit trail across channels shortens the time needed to respond, because the evidence sits in one place instead of five. Build the package before the request arrives, and rehearse retrieving it.

Ownership is often split across the CIO, CISO and compliance functions, and that split is how evidence gaps form. The practical answer is to name one accountable owner for agent data access, give that person authority over the audit record, and make the CISO and Chief Compliance Officer consumers of the same record. The CIO and Chief AI Officer can own adoption and delivery speed. Document the assignment so that the answer to “who is accountable” does not depend on who is asked, and review it whenever a new agent goes into production. A data governance charter is a sensible place to record it.

Model governance addresses accuracy, bias and behavior of the model itself. A data-layer approach governs what content any identity can access, use and exchange, and records every action. Compliance exposure sits at the data layer, because laws attach to personal, health and financial data regardless of the tool that touched it. Kiteworks Compliant AI follows this approach, and the Secure MCP Server is one way AI clients connect under inherited permissions.

Additional Resources