AI Agents Now Touch Twice the Data Anyone Approved

Three independent studies on AI agent governance published within days of each other this quarter. Kiteworks’ own primary research had already measured the same gap.

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

Developers already know their agents are overreaching

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

Read that again.

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

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

CISOs confirm it from the boardroom down

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

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

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

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

The vulnerability that passes every safety check

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

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

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

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

The architectural question nobody’s tooling answers

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

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

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

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

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

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

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

What to do Monday morning

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

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

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

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

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

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