92.9% of security leaders acknowledge at least one blind spot in their AI security. But none of the leading security controls are built to find or manage them.
Most organizations have deployed some control to govern workforce AI activity, but deployment and coverage aren't the same thing. In Neon Cyber’s research, the most commonly deployed control and the most commonly named blind spots describe almost entirely different surfaces – and that’s the gap where AI risk lives.
What controls are organizations using to govern AI activity?
Security and IT leaders employed a range of traditional security controls to try and govern AI activity across their organizations. Only two are cutting-edge:
- URL filtering / secure web gateway (SWG): 43.8%
- Enterprise browser / browser security: 37.3%
- DLP (network, endpoint, or SaaS): 24.3%
- CASB / SSPM: 20.7%
- Custom proxies / AI-aware gateways: 18.9%
- EDR / XDR: 14.8%
URL filtering leads by a wide margin, and it's worth highlighting what that control actually does: it can block or flag a destination — confirming an employee visited an AI site — but it has no visibility into what that employee typed, pasted, or uploaded once they got there. It also can't keep pace with new AI tools entering the market faster than any blocklist can be updated. URL filtering and SWGs are an example of legacy controls that are too slow to truly find and manage shadow AI.
Where do security leaders believe they have AI blind spots?
There were a range of areas where security leaders admitted to flying blind:
- Personal browser profiles used for work: 37.9%
- Unsanctioned AI or SaaS tools: 34.3%
- Personal accounts used for work: 26.0%
- Browser extensions: 21.3%
- File uploads and copy-paste into AI: 16.6%
- Session hijacking / account takeover: 10.7%
Line these blind spots against the control list above and the picture is pretty clear. The controls below browser security all sit under 25%. That tracks with what Neon Cyber has seen across our customers and with the blind spots leaders named — personal browser profiles, unsanctioned tools, file uploads and pastes. None of those controls were designed for this surface. The deployment numbers reflect what the tools were built for, not what the risk has become.
The 37.3% who have already deployed enterprise browser or browser security are the exception — and the blind-spot data suggests why that number is moving. Browser security applies controls directly inside the browser session — where a user's keystrokes, pastes, uploads, and clicks actually occur. That's distinct from network-perimeter controls like URL filtering or SWGs, which observe traffic to and from the browser but not the content or actions within it.
Ownership of browser security is fragmented, and that’s a real problem for managing AI risk
13.0% of leaders say their organization has no clear owner of AI security risk at all. Where an owner does exist, ownership splits by domain and may not always include security:
- 34.4% name IT/Infrastructure as the owner of browser security and configuration.
- 33.6% name a joint Security/IT arrangement as the owner of SaaS application security.
- 29.6% name business units as the owner of SaaS-related data-loss prevention.
- 28.8% name Risk/Compliance as the owner of AI-related data-loss prevention.
For browser security specifically —the most exposed surface to AI risk — the security team ranks fifth among named owners, behind Risk/Compliance and joint Security/IT arrangements. This is another data point that highlights the mismatch in security controls to AI blind spots, but it also underscores how pervasive shadow AI is across an organization.
The tools deployed to govern AI activity don't live in the browser session, and neither does the team that owns them. But fragmented ownership creates a problem beyond slow response: it creates the conditions for incidents to fall between teams entirely. Security gets the EDR alert. IT owns the browser configuration. Risk/Compliance holds the data-loss policy. When an AI-related incident surfaces, each team can point to the part they didn't own as the reason for the event. But this is exactly where shadow AI operates and why the risk is growing. Ownership fragmentation doesn't just slow the response. It removes the accountability that would have caught it earlier.
Visibility IT can deploy. Alerts Security can act on.
Reducing AI risk and illuminating shadow AI inside an enterprise means being inside the browser session itself. It’s the one surface every named blind spot in this data has in common.
This requires both IT and Security in the room: IT to deploy and configure, Security to monitor and respond. Neon Cyber is built for that handoff. It deploys through existing MDM or GPO without a new agent, a new proxy, or a change to which browser employees use — which means IT can stand it up without an infrastructure overhaul — and it gives Security the session-level visibility to actually act on what IT put in place. The ownership question doesn't go away. But a shared data layer makes it answerable.
FAQs
If we already have DLP deployed, does that cover the blind spots this report names?
Not for most of them. DLP was built to catch data leaving through file transfers, email attachments, and known egress points — not a paste action inside a browser tab. An employee copying a revenue figure from a spreadsheet into an AI prompt doesn't trigger a file-transfer rule, because nothing moved as a file. Neon Cyber's research found DLP deployed at 24.3% of surveyed organizations as an AI-related control, and even where deployed, it has no visibility into session content — only into transfers it was originally designed to intercept.
Who should own browser security if our organization is split across IT, Security, and Risk/Compliance?
The data doesn't point to one right answer, but the incidents that fall through in this research fall through because each team assumed the other had it covered. A practical starting point: name IT/Infrastructure as the deployment and configuration owner (where they already sit at 34.4%) and Security as the alert-response and policy owner. Both functions need to be explicitly assigned — joint ownership without defined roles produces the same accountability gap as no owner at all.
Our CASB already monitors SaaS application access. Does that give us visibility into what employees are doing inside those applications?
At the access level, yes — a CASB can log that an employee authenticated into a SaaS tool. Inside the session, after authentication, no. Once an employee is logged in, what they type, paste, or upload into that application sits outside what CASB was built to observe. The same limit applies to AI tools accessed through a CASB-monitored SSO: the login is visible, the prompt content isn't. That's the authenticated-versus-session-content distinction the blind-spot data keeps surfacing — and it's why 20.7% CASB deployment doesn't translate to coverage of the blind spots this finding names.