Shadow AI Incidents Hit One in Five Organizations
Your AI governance policy does not matter if an employee can grant an AI tool access to Microsoft 365 before IT ever hears about it. That is the uncomfortable center of new research from DNSFilter, which reports that 20.1 percent of surveyed organizations have already had a security incident traced to an unapproved AI connection. The finding sits beside a second number that is harder to explain away. More than half of those same organizations say they run AI governance or monitoring controls.
DNSFilter published the findings on November 3, 2026, in The Cost of Shadow AI, part of its 2026 Visibility Deficit survey series. The company surveyed 400 IT and cybersecurity professionals at manager level and above, at companies with 150 to 5,000 employees across the US and Canada, from June 15 to 26, 2026, in partnership with the research firm Censuswide. These are self-reported answers collected by a vendor that sells DNS filtering, so they describe what respondents say, not what an audit would find. Treat them as a strong directional signal about North American mid-market organizations, and nothing broader.
For a CISO or Chief Compliance Officer, the signal is blunt. The control that regulators and assessors will ask about is not the policy document. It is the proof that every AI system touching sensitive content was authorized, constrained, and logged, and that you can produce that proof in days. Kiteworks secure data exchange is built around that evidence problem, and the rest of this post explains why the DNSFilter numbers make it urgent.
Key Takeaways
1. One in five organizations has already had a shadow AI incident.
DNSFilter’s survey found 20.1 percent of respondents tied a security incident to an unapproved AI connection.
2. Governance controls and unapproved connections coexist.
Of respondents, 54.0 percent use AI governance or monitoring controls, yet 46.1 percent had an employee connect an unapproved AI tool to Google Workspace, Microsoft 365, or single sign-on.
3. Notification after the fact is the dominant approval model.
DNSFilter found 43 percent of organizations learn of AI access only after it is granted, or never.
4. Agent sprawl is the next version of the same problem.
Morgan Stanley’s advisors made nearly 50,000 attempts at building AI agents, and agents nobody adopted are not comprehensively reviewed.
5. Evidence beats policy.
Regulators regulate data, not models, so the defensible position is a record showing who or what accessed which content, under which policy, with what result.
What the DNSFilter Survey Actually Measured
The headline is the 20.1 percent. About one in five respondents said an unapproved AI connection had already led to a security incident. The release does not say how respondents defined “incident,” so the figure should not be read as a breach rate. It is a rate of respondents who experienced something their organization classed as a security incident.
The second figure explains how those incidents happen. In the survey, 46.1 percent of organizations had an employee connect an unapproved AI tool to Google Workspace, Microsoft 365, or their single sign-on provider. Those three platforms are where sensitive business content lives, which means an unapproved AI connection there is not a marginal browser experiment. It is a new party holding an OAuth grant against the systems that carry contracts, customer records, and regulated data.
Consider what that grant means in practice. An employee clicks “Allow” on a consent screen. The AI tool now reads mail, files, or calendar data under that employee’s identity, indefinitely, until someone revokes it. No ticket was filed, and no security review took place. The access is legitimate from the identity provider’s point of view, because the user authorized it.
That is the authorization gap, and it is why permissions do not determine what AI should be allowed to use. Identity systems answer the question “did this user approve this app?” They do not answer “should this app, acting for this user, be reading this content?” The distance between those two questions is where shadow AI lives.
You Trust Your Organization is Secure. But Can You Verify It?
Why Policies Fail at the Consent Screen
DNSFilter’s data on approval workflows is the most useful part of the release. Of organizations whose employees use AI tools for work, 36.8 percent of organizations whose employees use AI tools for work let employees grant OAuth or API access and notify IT after the fact. Another 6.5 percent send no notification at all. Combined, the survey puts the share that learn of AI access only after it is granted, or never, at 43 percent.
Read those numbers as an architecture, not a lapse in discipline. An organization that lets employees self-approve and tell IT later has chosen speed over review, usually for good business reasons. The trouble is that the notification model produces a record of the grant, not a decision about the content the grant exposes.
The other half of the puzzle is the control count. With 54.0 percent of respondents running AI governance or monitoring controls, you would expect unapproved connections to be rare. Nearly half still report one. The honest reading is that monitoring tells you a connection exists, while governance would decide what the connection may touch. Most organizations have invested in the first. That is the gap between detection and control that few programs have closed.
That distinction matters for audit exposure. An assessor does not ask whether you can see AI traffic. An assessor asks whether you can show that access to a regulated record was authorized, that the authorization was enforced at the moment of access, and that a tamper-resistant log captured it. A dashboard that counts connected AI tools does not answer any of those questions.
The Visibility Gap Is Wider Than Leaders Believe
DNSFilter’s CEO, Ken Carnesi, made a claim worth pausing on. Roughly one in seven organizations on DNSFilter’s network sees more than 10 AI tools in use, he said, while fewer than one in 100 IT leaders believe that happens in their environment. The full report puts numbers behind both halves. Its network data covers 3.4 billion requests to generative AI tools from more than 43,000 North American organizations in August 2026. Counting distinct AI vendors on a standard business day, the median organization sees five, and 15.2 percent see more than 10. In the survey, only 0.5 percent of IT professionals said their employees use more than 10 AI tools, which makes the network figure 30 times the self-reported one.
Note what the network figure measures. It counts distinct AI vendors appearing in DNS traffic, so it shows use, not necessarily an approved or authorized integration. Both halves also come from DNSFilter, whose network data is drawn from its own customers and whose report closes with an invitation to try its product. Neither half is independent. Still, the direction matches what practitioners report elsewhere, which is the reason the point deserves attention instead of dismissal.
The control side looks thin in the same report. Across that traffic, only 0.75 percent of generative AI requests were blocked, and DNSFilter reads that as most organizations not exercising the control their governance spending was meant to buy. Separately, 61.5 percent of survey respondents cannot say every security tool in their environment is properly configured, and 61.8 percent cannot say every one is actively monitored. Allowing AI is a legitimate policy choice. Allowing it by default, without a decision, is a different thing.
Verizon’s 2026 Data Breach Investigations Report gives a sturdier lens on the same behavior. Drawing on data loss prevention records rather than a survey, it found that 67 percent of users access AI services through non-corporate accounts on corporate devices, and that 45 percent of employees are now regular AI users on corporate devices, up from 15 percent the year before. Shadow AI became the third most common non-malicious insider action in the dataset, a fourfold increase.
Put the two sources side by side and a pattern appears. The use of AI at work is no longer an edge case, and a large share of it runs through accounts the organization cannot see or govern, a drift security teams now describe as shadow AI moving into the browser. The Verizon figures describe the dataset window of October 2024 through November 2025, and they come from incident and DLP data that contributors chose to share, so they are not a census. They are, however, a different method reaching a compatible conclusion.
The practical consequence for a Chief Compliance Officer is that “we have an AI policy” and “we know where AI touches regulated data” are two separate claims. Only the second one survives a regulator’s follow-up question.
Agent Sprawl at Morgan Stanley Is the Preview
Shadow AI is not only about employees pasting text into a chatbot. The next layer is employees building agents. American Banker reported on November 2, 2026 that Morgan Stanley advisors have made nearly 50,000 attempts at building AI agents through natural-language prompts, mostly to automate routine tasks.
The detail that matters is in what happens next. Koren Maranca, head of AI for the firm’s wealth management division, told the publication, “Sometimes people build an agent, they use it twice, and then they never touch it again.” Agents that an advisor’s team adopts go through review and approval after use, according to the article, while orphaned agents are not comprehensively reviewed.
Morgan Stanley is a well-resourced, heavily regulated firm, and it describes its controls as in place. It also runs a large review effort, with more than 1,000 people reviewing model outputs before the firm moved to production, and it reports that roughly half of advisor inquiries are now first handled by an AI agent. This is a company doing the work seriously. Even so, the review-after-use model leaves a population of abandoned agents whose access was granted and never revisited.
Notice the parallel to the DNSFilter finding. In both cases, access is granted first and reviewed second. In both cases, the thing that lingers is a standing permission attached to a human identity. A forgotten agent holds credentials just as a forgotten OAuth grant does.
That is why agents must be governed alongside the humans who create them, under the same policy engine and the same audit record. An agent is not a separate species of risk that needs a separate program. It acts on behalf of a person, inherits that person’s reach, and should be constrained to that person’s authorization and no further. The underlying issue is delegated authority in AI workflows, and it needs a named owner. Any approach that treats agents as ungoverned until a new tool arrives misdescribes the problem, because the underlying access controls already exist and must simply apply.
Practitioners See It, and Policy Alone Does Not Fix It
A fourth source adds a practitioner’s angle. O’Reilly’s survey of 209 security professionals, fielded in September 2026, found that 49 percent named employees leaking sensitive data through commercial AI tools as a top concern, tied with overreliance on unverified AI output. The sample is small and self-selected, with no stated margin of error, so it supports direction and not precision.
Within that sample, shadow AI was reported as widespread by 17 percent of respondents whose organizations had a comprehensive AI policy, compared with 35 percent where the policy was basic and 37 percent where there was none. The subgroups are small and their sizes are not disclosed, and the relationship is an association, not proof that policy causes less shadow AI. Even so, the gap hints that policy quality matters, and that a thin policy performs about as poorly as no policy.
Agents show up in the same survey. When asked for the single most concerning agent risk, 28 percent chose excessive permissions or unclear ownership, the largest share of any option. Unclear ownership is the accountability vacuum that Morgan Stanley’s orphaned agents illustrate. Someone built the agent, nobody owns it, and its permissions remain.
A cautionary note belongs here, in the spirit of reading vendor data carefully. Vorlon’s 2026 CISO Report, a vendor-sponsored survey of 500 U.S. CISOs fielded in January and February 2026, found 30.4 percent had experienced suspicious AI agent activity in 2025, and 86.8 percent said they cannot see what data AI tools exchange with SaaS applications. The sample is U.S.-only and the vendor sells in this category. The consistency across four different samples, methods, and sponsors is more persuasive than any single figure.
Money Is Moving Toward Governance, and Evidence Is the Test
Budgets confirm that leaders feel the pressure. DNSFilter reports that 74.5 percent of respondents have a larger cybersecurity budget than 12 months ago, 18.8 percent grew theirs by more than 10 percent, and 40.3 percent named AI security and governance as the destination of the next incremental security dollar, against 25.5 percent for cloud security. Intent to spend is not the same as effective spending, and the survey cannot tell us which purchases will close the gap.
Spending on AI inside compliance functions is rising too. Compliance Week reported on S-RM’s research that 78 percent of 225 compliance professionals expect spending on AI-enabled compliance and due diligence tools to rise by about 24 percent over the next one to two years, from roughly $337,000 to $416,000. The full article sits behind a subscriber wall, so only the opening figures are cited here, and they measure expectations, not outcomes.
Put those two budget signals together and the picture is clear. Security leaders will fund AI governance, and compliance teams will put more sensitive documents in front of AI systems. Both movements increase the number of times AI touches regulated content, which raises the value of proof that each touch was authorized.
Here is the test to apply to any investment. Suppose a regulator, an assessor, or opposing counsel asks how an AI system accessed a specific record on a specific day. Could you show, within days, the identity that requested it, the policy that permitted it, the content returned, and the log entry that captured it? If the answer takes weeks of correlating logs from separate tools, the money went to visibility, not governance.
Regulators regulate data, not models. HIPAA does not care whether a human or an AI agent read the record, and neither do the other frameworks that govern financial, defense, and privacy data. The obligation to control and evidence access follows the data wherever AI takes it.
Governing the Data Layer, Not Just the AI Tool
If the problem is the distance between “the user approved this app” and “this app should read this content,” the fix belongs where content is accessed. That means policy enforcement at the data layer, applied to every request in line with zero trust security principles, whether the requester is a person, an assistant working for a person, or an agent a person built.
This is the design principle behind Kiteworks Compliant AI and the Secure MCP Server. The MCP Server lets AI assistants such as Claude and Copilot work with content in Kiteworks through the Model Context Protocol. Authentication uses OAuth 2.0, and each operation is evaluated against role-based and attribute-based access policies in the Kiteworks Data Policy Engine, so an AI inherits the permissions of the user it acts for and cannot exceed them. Every access lands in a unified audit log, which is the record an assessor asks for.
Two features of that design answer the DNSFilter findings directly. First, authorization is checked per request, not once at connection time, so a standing OAuth grant does not become a standing entitlement to everything the user can reach. Second, the audit entry attributes the access to a specific AI system acting for a specific user, which removes the “the AI accessed it” ambiguity that makes incident response and regulatory inquiries slow. Governance depends on that record, because you cannot govern what you cannot attribute.
Kiteworks was not in the data path of any survey or company discussed in this post, and the architecture does not replace discovery tools that find unsanctioned connections. Detection of shadow AI and enforcement at the content layer are different jobs. Organizations need both, and the second one produces the evidence that regulators ask for.
For readers building a program, the architecture rests on a few concrete practices, which can be worked through in order.
- Inventory the OAuth and API grants that already exist against Google Workspace, Microsoft 365, and your identity provider, and revoke any that no business owner will claim.
- Replace notify-after-the-fact with approve-before-access for AI integrations that can reach regulated content, and time-box the approvals.
- Assign a named owner to every AI agent, and expire agents that have not been used within a set period, so orphaned agents lose their permissions.
- Enforce content-level policy on AI requests as part of AI data protection, so that access depends on the data’s classification and the user’s attributes, not on the app’s consent.
- Test the evidence. Pick an AI access event at random and time how long it takes to produce the identity, policy, content, and log for it.
Learn more about zero trust data protection for background on why every request, not only the initial connection, must be verified.
What to Do Before the Next Audit Request
The DNSFilter findings are best read as a prompt to measure your own organization. Do not assume you sit in the 80 percent without an incident, and a short review of AI risk in your own estate is the fastest way to find out. About one in five respondents in this survey did not know it either until something happened.
Start with the number that is cheapest to learn. Count the third-party AI applications holding OAuth grants against your productivity suite. Identity platforms typically list them in an admin console, so the number is quick to get.
Next, decide who is accountable. Ownership of AI security is unsettled across the industry, with CIOs, CTOs, and CISOs each claiming the seat depending on who ran the survey. That ambiguity is the problem to solve, not a fact to accept. Name one accountable executive for AI data access under your data governance program, and give the Chief Compliance Officer and your GRC team a standing report on the evidence record.
Then close the loop with legal and privacy leadership. A Data Protection Officer or General Counsel will want to know, before an inquiry arrives, which AI systems processed which regulated records. Building that audit trail now costs far less than reconstructing it under a regulator’s deadline.
Finally, revisit the assumption behind self-service AI. Speed is a legitimate goal, and banning AI only drives it further into the shadows. The workable path is governed enablement, where employees get approved tools quickly and the approval is enforced by policy at the data layer, not left to a consent screen. Teams exploring AI data governance can use that principle as the starting point for their program.
To learn more about producing audit-ready evidence for AI access to sensitive content, schedule a custom demo today.
Frequently Asked Questions
No. DNSFilter reports that 20.1 percent of respondents said an unapproved AI connection led to a security incident, but it is a vendor’s self-reported survey of 400 North American IT and cybersecurity professionals at companies with 150 to 5,000 employees. “Incident” reflects each respondent’s own classification, which can range from a policy violation to a confirmed data loss. Use it to justify measuring your own exposure and not as a breach rate. A structured AI risk assessment can translate the signal into your own environment.
An assessor generally wants to see that access was authorized, that the authorization was enforced when the access occurred, and that a log captured the identity, content, time, and outcome. For AI, that includes which AI system acted and on whose behalf. A count of connected AI tools does not satisfy this expectation. The Kiteworks audit log approach consolidates this record across channels, including AI requests, so one query can answer the question.
Blocking tends to push usage into personal accounts, which is exactly the pattern Verizon’s 2026 DBIR describes, where 67 percent of users reach AI services through non-corporate accounts on corporate devices. A better default is governed enablement, meaning a short list of approved tools, approval before access for anything that can reach regulated content, and policy enforcement at the data layer. Resources on governing generative AI with zero trust principles describe how that works in practice.
Accountability for AI security is unsettled, with different surveys putting CIOs, CTOs, and CISOs in the owner’s seat. Treat that ambiguity as a gap to fix. Assign each agent a human owner, give the agent only that owner’s authorization, and require the audit record to attribute each access to the agent and the owner together. The Morgan Stanley example shows why orphaned agents need an expiry rule. Read more about compliant AI and how attribution is handled.
Monitoring observes connections and flags anomalies. Data-layer governance decides, per request, whether the requester may see the content, and records the decision. DNSFilter’s results illustrate the difference, since more than half of respondents run governance or monitoring controls while 46.1 percent still had an unapproved AI tool connected to a core platform. Organizations need both, because detection finds the connection and enforcement limits what it can touch. The Secure MCP Server is one example of enforcement at the content layer.
Additional Resources
- Blog Post
Zero‑Trust Strategies for Affordable AI Privacy Protection - Blog Post
How 77% of Organizations Are Failing at AI Data Security - eBook
AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025 - Blog Post
There’s No “–dangerously-skip-permissions” for Your Data - Blog Post
Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.