A buyer's guide to AI security tooling

where buyers go wrong

A quick boundary first. AI governance and the EU AI Act deal with policy, classification, and regulatory obligation, and they have their own home. Everything here stays on the security side: AI as a data-egress and attack surface, and the tooling that controls it.

Two mistakes show up across companies of every size, from a 30-person studio to a 5,000-person group. The first is trying to ban AI. Block the domains, add a line to the policy, hope the problem goes away. It does not. The tools are too useful and too easy to reach. A ban pushes usage onto personal accounts and personal devices, where you have no view at all. The goal is enablement with guardrails, so people can use AI in a way you can see and shape.

The second mistake is subtler and more expensive. You buy a control that only sees managed use. It inspects traffic on company-issued laptops, through the corporate network, on accounts in your directory. It produces clean reports. And it misses the actual exposure, which is someone pasting a customer list into a consumer AI tool like ChatGPT from a personal account on a phone during a commute. That activity leaves no trace in your identity provider. The control you paid for cannot see it, and the demo never showed you that gap. The mistake scales: a large enterprise with a dozen security tools can still be blind to a department running consumer AI on personal logins. The blind spot is widely shared: 68% of organizations say they lack identity security controls for AI (CyberArk, 2025), and high levels of shadow AI add an average of USD 670,000 to the cost of a breach (IBM, 2025).

before you evaluate: see what you have

Do not buy before you can see your current state. You cannot judge a control until you know what it needs to control. So the first move is an inventory of the AI actually running in your company and what it can reach. Three sources get you most of the way, and none cost anything to look at.

• OAuth grants in your identity provider. Microsoft Entra, Okta, and Google Workspace all let you list which third-party apps hold access to company email, files, and calendars. Filter for AI tools. This surfaces a large share of connected AI, including grants nobody on the IT team approved.
• DNS or proxy logs. Known AI domains in your network logs catch browser-based use that left no OAuth footprint.
• Browser extensions on managed devices. If you manage endpoints, pull the extension inventory. AI extensions can read open tabs and intercept typed text, and most are never reviewed.

What you build from this is a list: which tools, used by whom, with what access to company data, and how sensitive that data is. That inventory is the input to every buying decision below. While you are at it, work out which size and maturity tier you sit in, because the right answer changes a lot across them. Lean or small (under ~50 people): one IT generalist or none, mostly browser-based AI use. Growing mid-market (~50 to 500): a small IT team, an IdP that is half-deployed, AI use spreading faster than policy. Larger or multi-entity (~500 to 2,000): multiple business units, an existing SaaS security or data-loss tool, real audit pressure. Enterprise or regulated (2,000+, or any size under heavy regulation): a security team, a tool stack, and obligations that make documented control a requirement.

One honest finding from almost every inventory, regardless of tier: the riskiest use sits on personal accounts, and it stays invisible until you go looking. If a vendor's tool cannot see that category, the inventory will tell you so before you sign.

the category in depth

This market is young and fragmented. Several of these controls are features of tools you may already run, sold separately under new names. Five layers matter.

AI and LLM gateways and proxies

A control point that AI traffic routes through, where policy can be applied and prompts inspected before they reach the model. It solves the case of a single chokepoint for AI you build or operate: internal AI apps, API calls to model providers, and the prompts your own software sends. You need it when you build with AI or run internal AI applications and want one place to apply policy, log usage, and control cost. You do not need it when your exposure is employees using third-party AI in a browser, because a gateway never sees the contractor on a personal laptop. Some API security and developer-platform tools already offer gateway features.

AI data-loss controls and data classification

Stops sensitive data from going into AI tools, and classifies what counts as sensitive so the rule can be precise. It solves the core data-egress risk: a customer record, source code, or contract heading into an AI prompt. You need it when you handle regulated or confidential data and want to block or redact at the moment it heads into an AI tool. You do not need it when you have not yet checked whether your existing data-loss tooling already covers this. This is the layer most likely to be a feature you already own, often one configuration change away.

browser-based and endpoint controls

Sees and controls AI use where it actually happens, in the browser tab and on the device, including on unmanaged or personal accounts in some configurations. It solves the exposure the other layers miss, because AI use is overwhelmingly a browser activity. You need it when your inventory shows the real risk is personal-account and off-network use, which it usually is. This is the layer most likely to reach the exposure that matters. You do not need it when your AI use is entirely through APIs you operate. It is also the layer that touches user privacy most directly, so scope it carefully and tell people what it sees.

AI security posture (AI-SPM and SSPM coverage)

Maps the posture and risk of your AI integrations and connected AI apps, including the OAuth grants to AI tools that accumulate in your IdP. It solves the slow build-up of AI integrations holding standing access, including grants whose creators have since moved on. You need it when connected AI apps and OAuth grants are a meaningful part of your exposure and you want continuous watch. You do not need it when you already run a SaaS security posture tool, which may already cover connected AI apps and their grants. Check before buying a separate AI-SPM product. The overlap here is heavy.

prompt-injection and agent guardrails

Controls at the tool and API layer for agentic AI that acts on its own: what an agent can reach, what it does with delegated permissions, and whether it can be manipulated through injected content. It solves the new attack surface that comes with delegated authority. Once you deploy AI agents that act, this becomes real. If you are not running agents yet, this is buying ahead of the need. Parts of this sit close to non-human identity governance, since an agent is a non-human identity with permissions.

The pattern across all five layers: check what you own before you buy a dedicated layer. Your IdP shows OAuth grants. Your SaaS security tool may cover AI apps. Your data-loss tooling may extend to AI domains. The fastest path to a wasted purchase is buying a category you already have a seat for, and the overlap does not shrink with scale, it grows.

what is right for your size and situation

• Lean or small · Typical starting point: Enterprise tier of one or two sanctioned AI tools, a short usage policy, basic browser and endpoint hygiene · Add when the gap appears: A browser or endpoint control once personal-account use becomes the real risk · Skip for now: Gateways, AI-SPM, agent guardrails, full platforms
• Growing mid-market · Typical starting point: Finish deploying your IdP, turn on existing data-loss rules for AI domains, run the OAuth inventory · Add when the gap appears: A browser and endpoint layer for unmanaged use; AI-SPM only if your SSPM does not cover it · Skip for now: A unified platform bought ahead of need
• Larger or multi-entity · Typical starting point: Extend existing SaaS posture and data-loss tooling to AI; consolidate visibility across units · Add when the gap appears: A gateway if you build with AI; agent guardrails as agents arrive · Skip for now: Duplicate point tools that overlap what you own
• Enterprise or regulated · Typical starting point: A documented, layered approach: browser and endpoint, data-loss, posture, and gateway where you build · Add when the gap appears: Agent guardrails and prompt-injection controls as agentic AI deploys · Skip for now: Nothing structural, but resist buying capability with no operator

A few special cases cut across the tiers. Heavily regulated data (finance under DORA, health data, anything where a leak is a reportable event) moves data classification and data-loss controls up the priority list, and observe-only is a weaker starting point because you may need to block from day one. High AI adoption makes visibility the bottleneck, not policy, so the browser and endpoint layer that sees unmanaged use is the first real purchase. Teams deploying agentic AI need prompt-injection and agent guardrails once agents act on their own, because an agent with delegated permissions is a new kind of insider. For the lean and small tier, the honest answer is usually that you do not buy a dedicated AI security product yet. You buy the enterprise tier of the AI tools your people already use, which keeps your data out of training and gives you an admin view, write a one-page usage policy, and keep your browsers and endpoints in decent shape.

sourcing models

There are four ways to get the control you need, and most companies use more than one.

Use what you already own. The OAuth view in your IdP is free. Data-loss rules in your existing endpoint suite may extend to AI domains. An enterprise browser you already license may cover part of the unmanaged-use problem. This is the cheapest and often the most durable option. Most early wins at every size live here.

A point AI control. A single tool aimed at one gap: a browser and endpoint layer for unmanaged use, or an AI-SPM for connected-app posture. The right choice when your inventory reveals one clear gap and you do not want a platform's worth of capability you will not configure.

A platform. A unified product that gates prompts, classifies data, scores integrations, and guards agents. Fits larger and enterprise tiers that genuinely span all those needs and have the team to run them. For a smaller company, most of a platform is capability you will never configure.

A managed service. Someone else runs the inventory, tunes the controls, and keeps them current. The right choice when you do not have the time or the in-house skill, and when learning a fragmented market by trial and error would cost you a quarter.

decision criteria in depth

When you compare tools, these are the questions that separate them. The marketing will not lead with most of them. Score each candidate honestly. A tool can be excellent and still be the wrong layer for your exposure.

• Sees unmanaged and personal use · What strong looks like: Surfaces a personal-account, off-network use you can verify · The trap: Only covers managed devices and directory accounts
• Coverage layer · What strong looks like: Clear about endpoint vs network vs API and what each misses · The trap: Implies it sees everything
• Block vs observe · What strong looks like: Both available; moving between them is a setting · The trap: Observe-only sold as protection, or block gated behind a tier
• Supports enablement · What strong looks like: Can allow an enterprise tier while blocking the consumer one · The trap: Only verb is "block," which drives use underground
• Covers agentic AI · What strong looks like: Sees agent actions and delegated permissions, not just prompts · The trap: Claims agent coverage but only inspects prompts
• Data residency and EU · What strong looks like: EU processing option, clear data processing agreement · The trap: Vague on where your prompts are processed and stored
• Pricing model · What strong looks like: Transparent on what drives the number · The trap: Needed capability gated above the quoted tier
• Admin overhead · What strong looks like: A small team can run it without a specialist · The trap: Assumes a project team and ongoing tuning capacity
• Vendor viability · What strong looks like: Funded, growing, credible roadmap in a young market · The trap: A thin product likely to be acquired or abandoned

The personal-use criterion is the single most important one. A tool that only covers managed devices and directory accounts has solved the visible problem and left the real one. Ask specifically how it handles a personal account on an unmanaged device. And vendor viability matters more here than in mature markets: this category is young, products are thin, and consolidation is coming. Weight roadmap and funding alongside today's features.

how it is priced and the true total cost

Pricing follows the layer, and the sticker is rarely the real cost. Browser and data-loss layers tend to price per user, and the capability you actually need is sometimes gated above the quoted tier. Gateways price per gateway or by throughput, so cost tracks how much you build with AI. Platforms price in tiers, with the useful capabilities bundled into higher ones, and the quoted entry tier often excludes the feature that made you look in the first place.

The hidden costs are where total cost of ownership gets decided. Endpoint deployment is a real project, not a download, for a distributed or partly unmanaged fleet. Coverage of unmanaged use is often the most expensive part and the part the entry tier leaves out, so confirm it is in the tier you are pricing. Tuning is continuous staff time, or the control either breaks workflows or misses the data it was bought to catch. And some products are cheap to license and expensive to deploy, with a professional-services line that can dwarf the subscription. Ask for that estimate before you anchor on the license price.

how to run the evaluation

A disciplined evaluation in this category looks like any other, with one adjustment: weight viability and roadmap heavily, because the market is young. Let your inventory pick the category and your tier pick the sourcing model, and shortlist two or three tools that fit the gap you named, not the broadest platforms on the market.

Take the criteria table into the room. The sharpest RFP questions: show me an employee using a consumer AI tool from a personal account on an unmanaged device, and what you can do about it; which layer do you operate at, and what does that layer not see; can you allow the enterprise version of a tool while blocking the free version; do you only observe, or can you block, and is moving between those modes a setting or a separate purchase; where is our data processed and stored when your tool inspects it; what do you cover that our identity provider and our SaaS security tool do not already cover; and for agentic AI, can you see the actions an agent takes or only the prompts. That comparison question is the one vendors least want to answer and the one most likely to save you a redundant purchase.

Run a short pilot with a clear pass condition you set in advance. The best test is concrete: plant a personal-account AI use, a colleague pasting sample data into a consumer tool from a personal login on an unmanaged device, and see whether the tool surfaces it. If it cannot, it has failed the test that matters most. Then check references with a customer of similar size and maturity, ideally one in your region with similar data sensitivity, and ask what the rollout actually cost in time, what the tool misses, and whether they would buy it again.

traps and red flags

The demo runs on managed devices, with sanctioned accounts, on the corporate network. That is the environment where every tool looks good. The gaps live outside it.

• A tool that only sees managed traffic. The exposure that does not touch your managed estate is the exposure the demo cannot stage. If a tool cannot show you unmanaged and personal use, it has not addressed your hardest problem.
• Block-everything modes. A control whose only verb is "block" pushes teams back onto personal accounts, which recreates the exposure you bought it to close.
• "Secure AI" claims that cover one channel. Many tools secure one layer, a gateway, an endpoint, or an API, and market it as securing AI. No single layer covers everything.
• The endpoint-agent rollout cost. Coverage that degrades off-network, or a rollout that stalls at 60% of the fleet, leaves holes exactly where the risk concentrates. Ask what coverage looks like off the corporate network.
• Static OAuth coverage. Some posture tools enumerate AI integrations once and stop watching. Grants accumulate continuously. Ask whether discovery is live or a one-time scan.

where this maps to regulation

Security and governance are related but distinct, and buyers conflate them at their cost. The EU AI Act is mostly a governance instrument: it concerns risk classification, transparency, human oversight, and documentation for AI systems you deploy or build. Security supports those obligations without being them. A data-loss control that keeps regulated data out of a consumer AI tool helps you meet a governance duty, but it is not the duty itself. Buy security tooling to control your data and attack surface, not to satisfy the AI Act, and you will not be disappointed when the auditor asks for a policy rather than a dashboard.

NIS2 treats AI use as part of your wider risk management and supply-chain duty for essential and important entities. The connected AI integrations holding access to your systems are part of the attack surface NIS2 expects you to manage, which is another reason the OAuth and posture view matters. The clean way to hold both in mind: governance asks what AI you allow and on what terms, security asks where the data goes and what AI can reach. Buy security tooling against the second question.

a sequenced path

You do not need everything at once. The order matters more than the speed.

Crawl. See your current state. Run the OAuth, DNS, and extension inventory. Name your tier. Turn on what you already own: existing data-loss rules for AI domains, your IdP's grant view, an enterprise browser if you have one. Write a short usage policy that enables a sanctioned path. No new purchase yet. A meaningful share of the exposure typically closes here for free.

Walk. Buy against the one gap the inventory named, and only that gap. For most companies that is the browser and endpoint layer that sees unmanaged and personal use. Start in observe mode to learn your real usage before you risk breaking a workflow, then move to block where the data is sensitive enough to justify it.

Run. As you build with AI, add a gateway. As you deploy agents, add prompt-injection and agent guardrails. As you grow across units, consolidate visibility. At each step the trigger is a gap you can name, not a tier a vendor offered. The platform, if you ever need one, is the last decision, after you know exactly which layers you actually use.

AI is good for your business, and the job is to enable it with guardrails rather than wall it off. The hardest part of that job is seeing the use you do not manage, because it leaves no trace in your directory and never reaches your network. So the order holds at every size: see your current state first, let what you find decide what you buy, and start with the tools you already pay for.