The biggest AI agent security gap in 2026 is not what an agent is configured to do, it is what an agent actually does with the data it touches mid-task. Access lists, prompt instructions, and domain allowlists describe intent, not behavior, and a growing body of incident data shows agents completing actions their own configuration never anticipated. Closing that gap requires inspecting the data flowing through an agent in real time, not just the permissions granted to it at setup.

Cybersecurity leaders now say this problem is bigger than any other item on their desk. In Team8's 2026 CISO Village survey, reported by SecurityWeek, 78% of CISOs named AI and agent security their single biggest pain point, exactly double the 39% who cited the next-largest concern. Seventy-one percent of the same group are already experimenting with or augmenting existing security tools using AI agent capabilities. The gap between adoption and control could not be starker: organizations are deploying agents faster than they are building the layer that governs what those agents do once deployed.

That gap is not theoretical. It shows up in incident reports, in red-team exercises, and in the Verizon 2026 Data Breach Investigations Report's own dataset. This piece walks through what is failing, why the standard response (tighter configuration) does not fix it, and what a governance model built around real-time content inspection looks like in practice.

Key Takeaways

  • 78% of CISOs now name AI and agent security their single biggest security concern, per Team8's 2026 CISO Village survey, exactly double the next-largest category.
  • Mandiant's red-team testing shows an agent can exfiltrate data through a fully "approved" channel; the failure is that nothing inspected the actual content and destination of the action, only whether it stayed inside a pre-configured boundary.
  • Prompt instructions and domain allowlists describe what an agent is supposed to do. Neither one enforces anything once the agent is actually running.
  • Closing the gap means evaluating what data is flowing through an agent in real time, not just what it was configured or told to do.

The 78% Problem: What CISOs Are Telling Researchers

Team8's CISO Village survey, conducted among practicing security leaders and covered by SecurityWeek on September 14, 2026, put a number on something most security teams already sensed: AI agent risk has outpaced every other category of concern, including cloud misconfiguration, third-party risk, and ransomware. Team8's own CISO, Tim Brown, described the underlying dynamic to SecurityWeek in blunt terms: the risk surface tied to agentic AI is expanding faster than organizations' control layers, and employees are building agents through easily available coding tools that can reach further into production systems and sensitive data than their creators intend.

That last phrase, further than their creators intend, is the crux of the problem. It is not that agents are being handed access to things they should not touch. In most documented cases, the agent's configured permissions look reasonable on paper. The failure happens downstream of the configuration, in the moment the agent decides what to do with the access it has been given.

Verizon's 2026 DBIR dataset backs up how quickly this shifted from theoretical to structural. Shadow AI, meaning unauthorized or unsanctioned use of GenAI tools and agents, is now the third most common non-malicious insider action captured in Verizon's own data loss prevention telemetry, a fourfold increase in share from the prior year's report. Sixty-seven percent of users on corporate devices are accessing AI services through non-corporate accounts, and forty-five percent of employees are now regular AI users on those devices, up from just fifteen percent a year earlier. Three points worth sitting with: this is not a niche behavior confined to a few early adopters, it moved from a fringe practice to a majority behavior in twelve months, and none of it required malicious intent to create exposure.

Configured to Behave, Not Governed to Behave: The GitHub Case Mandiant Found

Google Mandiant's AI Risk and Resilience report, covered by Help Net Security on September 16, 2026, documents a red-team exercise that illustrates exactly how a configuration-based control fails in practice. Mandiant testers interacted with an internal AI assistant that had legitimate, configured access to manage code repositories and CI/CD pipelines. The testers convinced the assistant that the interaction was an authorized security test and supplied a personal access token pointing to an external, attacker-controlled GitHub repository. Because GitHub itself was an approved domain in the assistant's configuration, the assistant cloned sensitive internal repositories and pushed them to the external account, with no policy check stopping it along the way.

Read that sequence again: nothing about the assistant's permissions was wrong. GitHub was correctly allowlisted. The token authentication succeeded. Every step the assistant took was inside its configured boundary. The only thing that failed was any mechanism that looked at what data was leaving the environment and where it was going, independent of whether the destination happened to sit on an approved domain.

Mandiant's report separately describes an accounting agent that entered a runaway execution loop, making more than fifteen thousand high-cost API calls in under an hour and generating roughly fifty thousand dollars in unplanned cloud charges. Different failure mode, same root cause: a system that trusted the agent's own trajectory instead of checking the content and consequences of each action against policy in real time.

It is worth being precise about what these incidents do and do not show. Kiteworks and Bonfy were not in the data path of Mandiant's red-team exercise; this is not a claim that either platform prevented or would have stopped this specific test. The relevant point is architectural: had the repository content been governed by contextual data enforcement instead of a domain allowlist, the control checking the export would have needed to evaluate the actual content and destination of that specific action, not just whether GitHub.com appeared on a list drawn up before the task began.

Why Prompt Instructions Are Not a Control Boundary

Gourab Basu, Global Head of Engineering at meshIQ, made a related argument to Help Net Security in a September 16, 2026 interview: instructions written into an agent's prompt are not a real control boundary, because agents can dynamically alter their own execution path in response to what they encounter mid-task. Basu's example is a refund agent instructed to flag any transaction above a set dollar threshold for human review. That instruction lives in the prompt. It is not enforced anywhere else. If the agent's reasoning concludes, correctly or not, that a transaction does not meet the threshold, or if it is manipulated into believing an exception applies, the instruction does nothing to stop it.

Basu also raises a scaling question every enterprise security team is going to hit within the next eighteen months: what happens when an organization goes from ten agents to a thousand. At ten agents, a security team can plausibly review configurations by hand and catch drift. At a thousand, manual review becomes either a bottleneck that slows the business or a step that gets silently skipped. The only way governance survives that scale-up is if the enforcement point moves from configuration-time review to a framework-independent layer that inspects actions consistently regardless of which agent framework, vendor, or orchestration tool is running underneath.

This is precisely the distinction between what most tools ask and what needs to be asked. Most tools ask what an agent is configured to do. The question that catches the Mandiant GitHub case, the runaway accounting agent, and the CISOs' stated top concern all at once is a different one: what data is actually flowing through the agent right now, in this specific task, regardless of what its configuration or its own prompt says it intends to do.

What Contextual Data Enforcement Checks

Bonfy's Contextual Data Enforcement is built as an inspection layer that sits between an AI client, such as Claude, Microsoft Copilot Studio, or ChatGPT, and the enterprise data stores it reaches into, such as SharePoint or Google Drive. Rather than relying on the access an agent was granted at configuration time or the instructions written into its prompt, the layer evaluates what the agent retrieves, generates, and attempts to move mid-task, against policy, in real time. We wrote about the general version of this failure mode, an agent doing something nobody explicitly told it to do, in Nobody Told It To. It Did It Anyway., and the specific mechanics of how a runtime inspection layer intercepts an agent's actions in Bonfy's MCP Server Sets a New Standard for Securing AI Agents in Real Time.

Applied to the Mandiant scenario, the relevant check is not "is GitHub an approved domain." It is closer to: does this specific export, of this specific repository content, to this specific destination, match what this agent's task requires. That is a narrower and harder question than domain allowlisting, and it is the one a domain-based control structurally cannot answer, because a domain allowlist has no visibility into the content of the request once the domain check passes.

The same logic applies to the refund-threshold example Basu describes. A prompt instruction to pause above a dollar amount is a request the agent is asked to honor. A policy check that inspects the actual transaction parameters before the action executes, independent of what the agent's reasoning concluded, is an enforcement point the agent cannot reason its way around, because it does not depend on the agent agreeing to be governed.

This is also where the relationship between Bonfy and Kiteworks becomes concrete rather than abstract. Bonfy operates as inline runtime classification and enforcement, the layer watching what an agent or a human is doing with content right now, across email, SaaS applications, and AI-agent interactions, a problem we explored from the identity-and-intent angle in <a href="https://blog.bonfy.ai/solving-the-out-of-body-execution-problem-how-bonfy-keeps-ai-agents-user-intent-and-data-risk-aligned%22>Solving the " out-of-body"="" execution="" problem<="" a="">. Kiteworks operates as the control plane governing how sensitive content is exchanged, stored, and accessed at rest, through capabilities like the Kiteworks Secure MCP Server, which keeps agent credentials out of LLM context and applies the same role-based and attribute-based access controls to agents that already govern human users, and Kiteworks Compliant AI, which extends that governance across regulated AI workflows. Combined, the two produce one policy model spanning data in motion, at rest, and in use, applied consistently to humans and AI agents alike, rather than two disconnected point solutions each covering half the problem. Kiteworks' own architectural take on this same data-layer question is laid out in its AI Agent Security: Data-Layer Governance Guide, it goes deeper on the regulatory angle in When AI Agents Touch Regulated Data, Governance Can't Wait, and it applies zero-trust principles specifically to the protocol at issue in Mandiant's report in Model Context Protocol: Zero Trust Security for AI Data. On the Bonfy side, treating context as the thing being enforced, not just an input to a static permission check, is why we built context evaluation into the product as an operating principle rather than a bolt-on feature, a point we go deeper on in Context Engineering Isn't Just a Concept, It's Bonfy's Operating System.

Building an Agent Governance Model That Scales Past Ten Agents

For a security team weighing how to close this gap without slowing the business down, a few principles fall directly out of the incidents above.

First, treat every agent-initiated data movement as a request to be evaluated, not an action already authorized by configuration. The GitHub case failed precisely because the export was treated as pre-authorized once the domain check passed. Evaluating the content and destination of each specific action, rather than trusting the category of action the agent was configured for, closes that gap.

Second, assume prompt instructions will be tested, misunderstood, or socially engineered around, and build the actual control outside the prompt. Basu's refund-threshold example generalizes to nearly every "the agent was told not to" scenario security teams are currently relying on. If the only enforcement is what the agent was told, the control does not exist in any meaningful sense.

Third, plan for scale before it becomes unmanageable. The jump from ten agents to a thousand is not a distant hypothetical; Team8's own survey data shows seventy-one percent of CISOs are already augmenting security tools with agent capabilities today. A governance model that depends on a human reviewing each agent's configuration will not survive that growth curve. A framework-independent enforcement layer, evaluated consistently regardless of the underlying agent tooling, will.

Fourth, resist the temptation to claim more certainty than the evidence supports. None of the incidents cited above involved Bonfy or Kiteworks in the actual data path, and none of what follows should be read as a claim that either platform would have stopped a specific documented attack. The point is architectural fit: a control built to evaluate actual data flow, rather than configured intent, addresses the mechanism these incidents describe, whether or not it was present for any one of them. We put a related version of this same argument, aimed at the specific pressure Claude and Copilot put on existing security architecture, in Claude, Copilot, and the Pressure Test Your Security Wasn't Built For.

FAQs

1. What is the difference between AI agent access control and AI agent governance?

Access control determines what an agent is permitted to reach at configuration time, such as which systems, files, or APIs it can call. Governance evaluates what the agent does with that access once it is running, including the specific content it retrieves, generates, or moves. An agent can pass every access control check and still cause the kind of exposure Mandiant documented in its GitHub red-team case, because access control and behavioral governance answer different questions.

2. Why isn't a domain allowlist enough to stop data exfiltration by AI agents?

A domain allowlist checks whether a destination is on an approved list, not what content is being sent to it or why. In Mandiant's red-team case, GitHub was correctly allowlisted, and the exfiltration succeeded anyway, because nothing evaluated the specific repository content being pushed to a specific, attacker-controlled account on that otherwise-approved domain.

3. How would Bonfy and Kiteworks divide the work in a scenario like the Mandiant GitHub case?

Bonfy's Contextual Data Enforcement would sit inline on the agent's action itself, evaluating the specific repository content and destination the moment the export was attempted, the exact mechanic described in Bo… MCP Server Sets a New Standard for Securing AI Agents in Real Time. Kiteworks would sit one layer over, governing whether the agent's connection to the underlying content store was authorized and logged in the first place through the Kiteworks Secure MCP Server. Neither replaces the other: one inspects the action in motion, the other governs the access and the record of it.

4. Is Shadow AI the same problem as ungoverned AI agents?

They are related but distinct. Shadow AI, per Verizon's 2026 DBIR, typically describes employees using unsanctioned AI tools or accounts, a human behavior. Ungoverned AI agents describes sanctioned, IT-approved agents whose actual runtime behavior is not checked against policy. Both stem from the same root cause: enforcement built around configured intent rather than real-time content inspection.

5. Does Bonfy or Kiteworks claim to have prevented the Mandiant GitHub incident?

No. Mandiant's red-team exercise did not involve Bonfy or Kiteworks in the data path. The incident is referenced here as an architectural illustration of a control gap, specifically domain-based allowlisting versus content-and-destination-based enforcement, not as a claim about a specific product's involvement in that test.

6. How does Kiteworks Secure MCP Server relate to Bonfy's Contextual Data Enforcement?

Kiteworks Secure MCP Server governs how AI clients like Claude and Copilot connect to Kiteworks-managed content at rest, applying the same RBAC and ABAC controls that already govern human access and keeping credentials out of LLM context, as laid out in K… AI Agent Security: Data-Layer Governance Guide. Bonfy's Contextual Data Enforcement inspects content in motion and in use across email, SaaS, and agent interactions in real time. Together they cover the full lifecycle of sensitive content moving through an AI-enabled enterprise, for both human and agent activity.

The Next Step

Agent adoption is not slowing down, and neither is the gap between what agents are configured to do and what they actually do once they are running. Closing it starts with asking the harder question: not what your agents are allowed to reach, but what they are doing with it right now. If your team is still relying on access lists and prompt instructions as your primary control, that is worth a closer look before your next agent deployment, not after your next incident.

Gidi Cohen is VP Product at Kiteworks and co-founder and former CEO of Bonfy.AI, which Kiteworks acquired in 2026. He has spent his career building data security and governance systems for regulated enterprises.