Security & Threat Intelligence

What Enterprises Are Really Saying About AI Security

The AI security conversation has changed. Here’s what buyers are actually saying.

A year ago, enterprise security conversations about AI were theoretical. Should we allow it? Should we block it? Are we even an “AI company”?

That phase is over.

Over the past six months, Versa’s sales teams have been in active conversations with security and networking executives across industries about AI — specifically about how they’re thinking about risk, governance, and operational control as AI moves from pilot to production. What follows is a distillation of those conversations: the patterns that showed up repeatedly, the language buyers actually used, and what the aggregate picture tells us about where the market’s head is right now.

This isn’t a survey. It isn’t a research report. It’s field intelligence — and the point of sharing it is straightforward. If you’re a network or security executive trying to figure out what your peers are prioritizing around AI, and where to focus your own attention, this is what the conversation looks like from where we sit.

1. “We don’t want employees feeding sensitive data into public AI tools”

This is the clearest and most consistent pattern in the conversations we’ve had. The concern isn’t abstract — it’s specific. A product roadmap. A financial model. Customer records that belong in a controlled system, not in the training corpus of a public model that nobody in IT approved.

The language we heard: “employees can inadvertently submit sensitive data to external AI platforms” and “would it be able to prevent those prompts from being sent?”

What these executives are actually asking for is governance at the point of use — browser-level enforcement, DLP that understands AI sessions, and auditability after the fact. Not “block ChatGPT” as a blanket policy. Policy with teeth, applied at the prompt level, with a record of what happened and when.

The exposure vector here isn’t a misconfigured server or a phishing link. It’s an employee doing their job, reaching for the fastest tool available, and not thinking about what they’re typing. That’s not a training problem. That’s an infrastructure problem — and it has to be solved in the infrastructure.

What makes this pattern interesting is how the conversation evolves once you get past the initial concern. Before you can govern AI usage, you have to see it. Shadow AI — the tools employees are using that IT didn’t approve and often doesn’t know about — is a genuine blind spot for most organizations. The conversation usually starts with “we think our people are using AI tools” and ends with “we need to know what they’re actually submitting before we can do anything about it.”

That sequencing matters. A year ago, the AI security conversation was about policy: what do we allow, what do we block. Today it’s about discovery first, then policy, then enforcement. You can’t protect data you don’t know is moving — and most organizations are still in the discovery phase, even if they don’t realize it.

If you’re benchmarking your own posture against your peers: the executives who are ahead of this problem have already mapped their AI usage surface. Most haven’t. Starting there — understanding what’s actually in use across the organization, before writing policy — is probably the highest-leverage first step available to most teams right now.

2. “Keyword filtering isn’t enough — we need intent-based detection”

A smaller but increasingly important segment of the buyers we spoke with has moved past generic AI governance. They’re asking whether security controls can understand what a prompt is actually trying to do — not just whether it contains flagged terms.

The field language: “what LLM-based detection will do — it will identify the intent of that prompt, and based on the intent, it will block.”

The problem with keyword filtering is that it fails in both directions simultaneously. It blocks legitimate queries that happen to contain sensitive-looking terms, and it misses sophisticated exfiltration attempts that are phrased carefully enough to avoid the watchlist. Intent-based detection changes the question from “does this prompt contain a flagged word” to “what is this prompt trying to accomplish, and does that create risk.”

More significant: several of the buyers in this segment aren’t just asking about controlling access to third-party AI tools. They’re building their own models. “We are also creating our own models” — and they want to know whether security controls extend to that environment. Can you protect the prompt interface to an internal model? Can you secure the pipeline between an AI agent and the tools it’s authorized to use? Can you apply policy to AI traffic that never touches the public internet?

This is where the market starts to bifurcate in a way that’s worth understanding if you’re trying to calibrate your own roadmap against your peers.

Mainstream buyers — the majority of the organizations we’re talking to — want AI governance and data protection: visibility into what’s going out, controls at the session and prompt level, and audit trails for compliance. That’s a meaningful and tractable problem, and most security teams are somewhere in the middle of solving it.

Advanced buyers — concentrated in financial services, healthcare, and defense-adjacent environments — are asking a different set of questions. Can you protect custom models? Can you secure on-premises AI deployments? Can you handle the traffic that flows between AI agents, not just between users and AI tools? That last question — about agent-to-agent and agent-to-tool communications — is where the conversation gets genuinely new. Legacy SASE architectures were built around user-to-application traffic. Agentic AI creates fundamentally different traffic patterns: east-west, machine-initiated, often high-velocity, and largely invisible to tools that weren’t designed with it in mind.

The advanced buyer group is still smaller than the mainstream. But in our experience, that group tends to be about six to twelve months ahead of where the broader market lands. If the questions they’re asking today aren’t on your radar yet, it’s worth understanding them — because they’ll be standard procurement criteria before most organizations’ next major platform refresh.

3. “The AI can recommend. I’ll decide when it touches production.” — Human in the loop as a design requirement

This pattern surprised some of our sales teams when it first came up. Buyers who were genuinely enthusiastic about AI-assisted operations were also the ones most explicitly asking for approval workflows and fail-safes. It seemed like a contradiction. It isn’t.

The field language: “anytime you put an action in the chat, it’s always gonna ask to approve” and “I want the chatbot to say — do you want me to push this? — and let them push it.”

What these executives are describing is a specific trust architecture, not a rejection of automation. The AI does the hard cognitive work — correlating signals across the environment, identifying probable cause, surfacing the relevant runbook, recommending the remediation path. The human retains authorization over execution. Not for every action — low-risk, well-understood operations can run with more autonomy over time. But anything that touches production configuration, anything with potential blast radius, anything in a regulated environment: that gets an explicit approval step.

The regulatory dimension makes this concrete. In financial services, healthcare, and critical infrastructure, change management is audited. The question of who authorized a configuration change isn’t abstract — it’s a compliance requirement. An AI that can act autonomously on production infrastructure creates a gap in the audit trail, regardless of whether the action it took was technically correct. For executives in those environments, human-in-the-loop isn’t a preference. It’s a requirement that predates AI entirely and doesn’t go away because the recommendation came from a model rather than a person.

There’s also a trust-building dimension that the more thoughtful executives are articulating clearly. Autonomy, in their framing, is something AI earns incrementally. You start with the AI making recommendations that your team evaluates and approves. Over time, as the system builds a track record and the team develops confidence in its judgment, you expand the scope of what runs without explicit sign-off. That’s a reasonable model — it’s roughly how you’d onboard a new analyst, and it applies the same logic to AI-assisted operations.

What this means for how the industry should be talking about AI operations: the value proposition isn’t “the AI will handle it.” It’s “the AI will surface the right answer faster than any human analyst, and your team will make better decisions with less cognitive load.” For most of the executives we spoke with, that framing lands. The autonomy story lands later — after the trust has been established.

If you’re evaluating AI operations capabilities for your own environment, the question worth asking any vendor is: what does the approval workflow actually look like, and where are the boundaries between what the system can do autonomously and what requires human sign-off? The vendors who have thought this through will answer it specifically. The ones who haven’t will tell you the AI is very smart and very safe.

4. “Will this reach the environments where our most sensitive or sovereign workloads actually run?”

This is the least common pattern in the conversations we summarized — but the stakes when it surfaces are categorically different from the others. When coverage gaps come up, they tend to be disqualifying rather than a factor to weigh.

The field language: “ensuring that it works across all clouds and classification levels” and “they don’t always account for these specific higher-classification endpoints.” One of the more direct statements from a prospect: “on-premises model is also not supported” — stated flatly, as a blocker if its not available.

The underlying issue is that cloud-native AI security tools are built around an assumption that the infrastructure they’re protecting is also cloud-native. For the majority of enterprise environments, that assumption holds closely enough. For government agencies, defense contractors, regulated financial institutions, critical infrastructure operators, and enterprises with data residency requirements — it doesn’t.

These environments need AI security controls that extend to on-premises model deployments, air-gapped networks, sovereign cloud environments, and classified systems that cloud-delivered services cannot reach by design. Most vendor comparison frameworks don’t surface this as a distinct criterion because most buyers don’t have the requirement. For the ones who do, it tends to be the first question asked and the last one answered satisfactorily — if it’s answered at all.

The broader principle here applies even outside the sovereign and air-gap use case. Security coverage is only as comprehensive as its actual reach. A policy framework that applies everywhere except the most sensitive 15% of your environment isn’t a unified security posture — it’s a unified security posture with an asterisk. The executives in our conversations who had run into this problem described it as a hard lesson: they’d built what looked like comprehensive AI governance, and then discovered it had no visibility into the environments where the highest-value data actually lived.

If your organization operates in any environment with classification, residency, or air-gap requirements — or if you’re evaluating vendors for environments that include those constraints — the coverage question should come first, before the feature comparison. A platform that doesn’t reach your most sensitive environments isn’t a platform for your organization. It’s a platform for the less sensitive part of it.

What the pattern looks like in aggregate

Across all four of these themes, there’s a common thread: security and network executives want AI enablement with tight control. Not suppression. Not a blanket block-list. Visibility into what’s actually moving, policy enforcement at the point of use, detection that understands intent rather than just surface content, human-authorized execution for anything consequential, and coverage that reaches the full environment.

The executives who are ahead of this problem — the ones whose conversations reflect the more advanced patterns in sections two and four — got there by treating AI security as an architectural question rather than a product category. They’re not asking “which tool should we add to address the AI risk surface.” They’re asking “does our security infrastructure extend to cover the new traffic patterns, deployment models, and data flows that AI creates” — and then working backward to close the gaps.

For executives earlier in that journey, the most useful benchmark from these conversations isn’t where the advanced buyers are. It’s where the mainstream is, because that’s the realistic comparison set for most organizations. And the mainstream is currently somewhere between discovery and policy: understanding what AI tools are actually in use, mapping the data exposure surface, and beginning to put enforcement in place at the prompt and session level.

If you haven’t started with discovery — mapping your actual AI usage surface, not the tools you’ve approved but the ones your people are using — that’s the gap most likely to produce an unpleasant surprise. Everything else builds from there.

We’re obviously partial to how Versa has approached this. But whatever platform you’re evaluating or running today, the four questions this field intelligence surfaces are worth putting directly to it: Can you govern AI usage at the point of use? Can you detect intent, not just keywords? Can you enforce human-in-the-loop workflows for AI-assisted operations? And does your coverage actually reach the environments where your most sensitive workloads run? If the answers are specific and demonstrable, you’re in good shape. If they’re not, you have a clearer sense of where to focus.

Frequently asked questions

Q: We’ve already deployed a CASB and we have acceptable use policies in place for AI tools. Isn’t that sufficient?

Probably not — and the gap is worth understanding specifically. CASB tools were built to govern access to sanctioned applications, and acceptable use policies tell employees what they’re supposed to do. Neither addresses what actually happens at the prompt level when an employee is using an AI tool that IT approved, or one they found on their own. The exposure vector that’s showing up most consistently in field conversations isn’t unauthorized tool usage — it’s authorized usage with unauthorized content. An employee pasting a sensitive document into a ChatGPT session they’re allowed to use isn’t violating your acceptable use policy in any obvious way. They’re just doing their job badly. Closing that gap requires enforcement at the session and prompt level, not access control at the application level.

Q: How are other organizations handling the shadow AI problem — tools IT didn’t approve and doesn’t know about?

The honest answer is that most are still in the discovery phase, which means they’re handling it incompletely. The pattern we see most often is organizations believing their AI exposure is limited to the tools they’ve sanctioned, and then discovering — through a DLP scan, a security audit, or occasionally an incident — that the actual usage surface is significantly broader. The executives who are ahead of this problem started with visibility: mapping what AI tools are actually running across the environment before writing policy or deploying enforcement. That sequencing matters. Policy applied to a usage surface you haven’t fully mapped tends to create a false sense of coverage. Discovery first, then policy, then enforcement is the order that actually closes gaps rather than just documents them.

Q: Our Network Operations team is interested in AI-assisted operations, but there’s real concern about an AI making autonomous changes to production infrastructure. How are peer organizations managing that tension?

By treating human-in-the-loop not as a limitation on AI capability, but as a design requirement — at least to start. The pattern across the network operations teams we’re talking to is a staged trust model: the AI handles the work that’s genuinely hard to scale — correlating performance signals across thousands of sites, identifying probable root cause, recommending the remediation path or surfacing the relevant runbook. Network engineers authorize anything that touches production configuration or carries meaningful blast radius. The approval step isn’t friction; it’s the point where institutional knowledge and operational judgment get applied to a recommendation the AI generated faster than any human analyst could.

The concern we hear most from NOC leads and network operations managers isn’t that the AI will be wrong — it’s that a well-intentioned automated change will cascade in ways that are hard to predict and harder to unwind at 2am. That’s a reasonable concern, and the organizations handling this well are addressing it structurally: clear boundaries between what the system can act on autonomously and what requires explicit sign-off, with low-risk actions gradually expanding in scope as the system demonstrates accuracy over time.

There’s also a practical change management dimension. Most network operations teams already have formal processes governing who can push configuration changes to production infrastructure, and under what circumstances. An AI-assisted operations layer that bypasses those processes — even when it’s technically correct — creates organizational and audit problems that the technology ROI doesn’t offset. The implementations that are working treat the AI as a highly capable member of the operations workflow, not a replacement for it. Autonomy follows from trust, and trust is built through a track record of good recommendations before it’s extended to autonomous execution.

Q: The AI agent-to-agent traffic question came up in this piece — is that a real concern today, or something to plan for later?

Both, depending on your environment. For most enterprise organizations today, the primary AI security exposure is still at the user-to-AI boundary: employees using AI tools and potentially exposing sensitive data through prompts. That’s the problem most security teams are working on right now, and it’s the right place to start. But agentic AI — systems where AI models take actions, use tools, and interact with other AI models autonomously — is moving from early adoption into production faster than most security roadmaps anticipated. If your organization is building or deploying AI agents, or if your vendors are embedding agentic capabilities into tools you already use, the question of how you govern that traffic becomes current quickly. The organizations we’d describe as six to twelve months ahead of the mainstream are already asking about agent-to-agent and agent-to-tool security. If it’s not on your radar yet, it’s worth at least understanding the architecture before it arrives as an operational problem.

Q: We operate in a regulated industry with data residency requirements. Most of the AI security tools we’ve evaluated are cloud-delivered. Is that actually a problem, or is it solvable with configuration?

It’s a structural issue, not a configuration issue — and it’s worth being direct about that distinction because vendors will often suggest otherwise. Cloud-delivered security services process traffic by routing it through the vendor’s infrastructure. In environments with strict data residency requirements, classification constraints, or air-gapped network segments, that architecture is the problem: the data can’t leave the environment to be inspected, which means the cloud-delivered service either can’t reach those environments at all, or requires exceptions that effectively create ungoverned zones. The organizations we’ve spoken to who’ve run into this problem describe it as a hard lesson — they built what looked like comprehensive AI governance and then discovered it had no visibility into the environments where their most sensitive workloads ran. If your environment includes any segment with residency, classification, or air-gap requirements, the coverage question should come before the feature comparison. A platform that doesn’t reach your full environment isn’t a platform for your full environment.