The AI Security Market Map
The AI security landscape, organized by use case.
AI security now describes three things: securing the AI systems your organization uses and
builds, putting AI to work inside your security program, and defending what you already run against attacks that
use AI. Most maps plot vendor logos onto a grid, leaving you to figure out
what technologies and products fit your specific security needs. This map organizes 14 distinct buying decisions
by the problem each solves.
Updated September 2026.
The map
Start with the groups that best match what your organization is doing with AI today. The numbers aren't a ranking: in Security of AI they follow where AI gets attacked, which is roughly the order teams find the gaps; in AI for Security, how much authority you hand the AI; Security from AI holds one category so far. Every category also names the ones it gets confused with, so follow those links before you draw up a shortlist.
Security of AI
Protects the AI your organization uses and builds: the copilots your employees paste data into, the LLM apps your developers ship, the agents that now hold credentials and take actions, and the data all of them touch.
If your employees use AI
If you build AI applications
- 3AI security posture management
- 4AI component and supply-chain security
- 5AI runtime security
- 6AI red teaming
If you deploy agents
If AI can reach sensitive data
AI for Security
Puts AI to work inside your own program: triaging alerts, investigating incidents, responding on its own, attacking your environment before someone else does.
If AI runs in your SOC
If AI tests your environment
Security from AI
Defends what you already run against attacks that use AI. Most AI-enabled attacks land in domains you own already.
If attackers use AI against your people
Security of AI
The AI your organization runs, and the AI it builds, can be attacked in four places: where people use it, where developers build it, where agents act, and where the data lives. The nine categories below follow that order, and most organizations discover the gaps in the same order too.
If your employees use AI
Security of AI · If your employees use AI
1 AI access and usage security
Who's using which AI services, and what do we allow?
Your employees are already using AI: the sanctioned copilot, the unsanctioned chatbot, and the AI feature that appeared inside a SaaS app. A browser agent working on their behalf is the newest of these and the hardest to see, because it reads pages nobody opened. Sensitive data flows into all of it and you can see almost none of it. This category gives you the inventory and the control.
Not to be confused with:AI data security (#9). Access policy decides which services are allowed; data security decides which information may leave. The same product can do both, but discovering an AI service doesn't mean you control every interaction with it.
Maybe not. If you run Zscaler, Netskope, or Palo Alto for SSE, you already inspect AI traffic at the proxy. The specialists earn their keep on embedded AI features and browser-level control a proxy can't see.
- Harmonic
- Lasso
- WitnessAI
- Quilr
- Prompt Security (now SentinelOne)
- Aim Security (now Cato)
- Aurascape
- Knostic
- Cyberhaven
Ask the vendor to show you:Show which browser, desktop and API routes are covered, and exactly what happens on a route that isn't.
Measure after 90 days:The share of AI traffic you can attribute to a named user and a sanctioned service, and the count of AI services you discovered that nobody had told you about.
Security of AI · If your employees use AI
2 AI governance and assurance
Who owns each AI use case, who approved it, and where's the evidence?
Your board wants to know what AI is running, how risky it is, and what you'll show a regulator. The EU AI Act is enforcing, ISO 42001 audits have started, and a spreadsheet won't survive either. This category is the system of record: use-case inventory, risk rating, approval, and the evidence behind each decision. Most of what you end up inventorying won't be yours. The AI arrived inside software you already bought, and the questionnaire your vendor risk team sent last year never asked about training data, model changes, or where the inference runs.
Not to be confused with:The technical categories that execute policy decisions. Governance records and coordinates them, and reaches beyond security into reliability, privacy and fairness, which is why it often sits with legal rather than the CISO. An approved use case still needs proof that its required controls are running. This map covers governance only where it produces a security control or the evidence for one. Model quality, fairness auditing, content moderation, and ethical-use review are adjacent disciplines with their own tooling, and buying an AI GRC platform does not make them your problem.
Usually, for now. GRC suites are adding AI modules; dedicated platforms still lead on inventory and regulatory mapping. For the third-party side specifically, the TPRM platform you already run is extending to cover it, and that is not a separate AI purchase.
Ask the vendor to show you:Follow one use case from approval through a material change, including who owns it, which controls it required, and whether the evidence updated.
Measure after 90 days:Every AI use case in production has a named owner and a completed risk assessment, and answering “what AI are we running” takes a day rather than three weeks. Judge this over two quarters; ninety days only gets the inventory started.
If you build AI applications
Security of AI · If you build AI applications
3 AI security posture management
Which AI assets and configurations are exposing us right now?
You have more AI assets than you think: models, endpoints, notebooks, services, and the identities and data attached to them. Some are public. Some have permissions nobody meant to grant. This category finds them, checks their configuration, and tells you which exposures matter.
Not to be confused with:Governance (#2), which decides who owns an asset, or supply-chain security (#4), which checks what came in the door. Posture management examines deployed assets and their technical condition, and an inventory becomes posture management the moment it starts naming actionable problems.
Increasingly not. Wiz, Palo Alto, and Microsoft have folded AI-SPM into cloud security. Standalone vendors compete on depth and on environments the platforms don't see.
Ask the vendor to show you:Trace one exposure from an AI asset to the data or system it puts at risk, identify the owner, and show the fix verified.
Measure after 90 days:The count of publicly reachable AI endpoints and over-permissioned AI identities, trending down, and the time between an asset appearing and an owner being assigned to it.
Back to the map ↑Next: 4 AI component and supply-chain security →
Security of AI · If you build AI applications
4 AI component and supply-chain security
Can we trust the models, tools, and data our AI systems depend on?
An AI system is assembled from parts that came from somewhere, and "somewhere" is often a public hub with no provenance. Model weights can carry executable code. Training, tuning, and evaluation data can be poisoned upstream. Embedding models, vector stores, orchestration frameworks, MCP servers, and the tool descriptions an agent reads are all components you did not write and mostly cannot see. This category establishes that every part is what it claims to be, and that it has not been modified. A fraud or underwriting model retrained on data you never inspected is the same problem as an LLM pulled from a public hub. The machinery between counts too: the training and fine-tuning pipeline, the model registry, and the promotion step that puts a model into production. Who can push a model to prod, and what signed it, are supply-chain questions. The clusters and secrets underneath belong to cloud and platform security, which already owns them.
Not to be confused with:Red teaming (#6), which examines the behavior of the running system while this examines the artifact. A clean scan of a model file proves nothing about how that model reacts to a prompt injection. Also not AI data security (#9): this category owns integrity, whether a component or corpus is trustworthy and unmodified, while #9 owns access, who can reach or disclose data through AI. Poisoning is an integrity problem and belongs here.
Partly covered. Application security and cloud platforms are adding model scanning; specialists lead on model-format depth, hub coverage, and the newer component types nobody scanned a year ago, such as MCP servers and agent skills.
Ask the vendor to show you:Name every component type covered, not just model files, and show a failed check on an MCP server or a tool description actually blocking a deployment.
Measure after 90 days:The share of models and components reaching production through a scanned path, and the number of unscanned artifacts still running when you check.
Security of AI · If you build AI applications
5 AI runtime security
How do we catch and stop an attack in the middle of an AI interaction?
Someone will try to make your LLM app ignore its instructions, leak its context, or say something that ends up in a screenshot. This category sits between the user and the model and stops it. Blocking is the easy half. The harder question is what happens after: whether the attempt reaches your SOC as an alert, and whether an investigator can reconstruct the prompts, retrievals, and model version that produced it.
The same choke point is where model theft shows up. An attacker who cannot copy your weights will settle for querying the model until they can approximate it, which looks like ordinary traffic until someone counts it. If the model is the intellectual property, ask about query-rate anomaly detection here rather than assuming the API gateway handles it.
Not to be confused with:Agent runtime control (#8). Runtime security protects a single model interaction; once the AI starts doing things with tools, you've crossed into #8.
Partly covered. AWS, Azure, and Google ship baseline guardrails with their model services. Security vendors add attack detection, cross-model policy, and evidence you can hand to an auditor.
- Lakera (now Check Point)
- Prompt Security (now SentinelOne)
- Pillar Security
- Lasso
- CalypsoAI (now F5)
- NeuralTrust
- Straiker
- TrojAI
Ask the vendor to show you:Run an indirect prompt injection through retrieved content, then show detection, enforcement, the false-positive rate, and the latency it added. Then show the alert it sends to your SIEM and the session record an analyst would open to investigate it.
Measure after 90 days:Injection attempts blocked against false positives on your own traffic, plus the latency the control added at p95. One number without the other two proves nothing.
Security of AI · If you build AI applications
6 AI red teaming
How can our AI be manipulated, and do our defenses hold?
You won't know how your models and agents break until someone breaks them. This category does it on your schedule instead of an attacker's, and does it again every time a prompt, tool, or data connection changes. It is not only an LLM exercise: evasion testing against a fraud, underwriting, or image-classification model in production is the same discipline, and in regulated industries it is the one an auditor asks about first.
Not to be confused with:AI-assisted offensive security (#13), which attacks your infrastructure using AI; this attacks model behavior. Similar name, different problem. And a general evaluation that scores accuracy is not a security test; a security test has to produce a security failure or validate a defense against a defined threat.
Rarely as a standalone. Most runtime and posture vendors bundle testing; buy it separately when you need independent evidence.
- Gray Swan
- Mindgard
- Enkrypt AI
- HiddenLayer
- Lakera (now Check Point)
- SplxAI
- Virtue AI
- Haize Labs
- Patronus AI
Ask the vendor to show you:Reproduce a failure in our application, not a demo app, and confirm the fix closes it.
Measure after 90 days:The share of findings that closed and stayed closed on the following run. Measure per test cycle rather than per quarter; a single ninety-day window usually covers one cycle.
Back to the map ↑Next: 7 AI agent identity and authorization →
If you deploy agents
Security of AI · If you deploy agents
7 AI agent identity and authorization
Who does this agent act for, and what is it allowed to do?
Every agent your teams deploy is a new identity with credentials and permissions, most of them created outside IAM and never reviewed. Agents accumulate standing access the way service accounts did a decade ago, only faster, and they act on someone's behalf without anyone writing down whose. The coding agent on a developer's laptop is usually the worst case: it holds repository credentials, cloud tokens, and MCP connections that never passed through provisioning.
Not to be confused with:Agent runtime control (#8), which watches what an agent actually does. This category establishes who an agent is, whom it represents, and what it may do. A valid credential is not permission for every action reachable through it.
Moving faster than any other line on the map. The specialists are being bought out from under you: Astrix went to Cisco, Entro to SailPoint, and Cyera has signed for Oasis, while CyberArk itself became part of Palo Alto Networks and relaunched as Idira. The remaining independents still win on discovering agents nobody registered and on the secrets they run on. If you're building customer-facing agents, that's a different buy again.
- Astrix Security (now Cisco)
- Aembit
- Oasis Security (acquisition by Cyera announced)
- Entro Security (now SailPoint)
- Linx Security
- Token Security
- Clutch Security
- P0 Security
- Okta
- Microsoft Entra
- Idira, formerly CyberArk (now Palo Alto Networks)
- SailPoint
- Veza (now ServiceNow)
Ask the vendor to show you:Show an agent permitted to read a record but blocked from modifying it, with the decision enforced before execution, not logged after.
Measure after 90 days:The share of agents with a named owner, a scoped credential, and an expiry date, and the amount of standing access you removed without breaking a workflow.
Security of AI · If you deploy agents
8 AI agent runtime control
What is this agent actually doing, and can we stop it mid-action?
Agents act. They call tools, move data, and trigger workflows, and a compromised or confused agent does all of that at machine speed. This category watches every tool call, blocks the dangerous ones, and keeps a person in the loop where it matters. The densest concentration of this sits on the developer endpoint, where coding agents install packages, call MCP servers, and commit on their own. Prevention is only half the job. Assume an agent acted before anything stopped it, and ask what you can undo: the action itself, the credentials it used, and the stored memory that told it to.
The harder version arrives when agents start calling other agents. A spoofed message between two of them, a failure that propagates down a chain, an agent that talks a person into approving something. OWASP named all three as top-ten agentic risks this year. Nothing on this list handles them well yet. Two other surfaces are moving as fast. Persistent agent memory is somewhere an attacker can leave something for the next session. And a browser agent reads pages nobody opened, which makes every page it visits an injection surface.
Not to be confused with:Runtime security (#5), which watches the conversation; this watches the actions that follow. You'll also hear "MCP gateway," which is a place, not a category. And "agentic code security," which is two problems wearing one label: the insecure code an agent writes is an application security problem you already have a budget for, while the agent doing the writing, and the credentials and tool calls it uses to do it, belongs here and in agent identity (#7).
Yes, for now. This is the least consolidated category on the map and the platforms haven't caught up. Expect that to change within four quarters.
Ask the vendor to show you:Trigger an agent action that violates policy mid-task and show it stopped, with the audit trail linking prompt, session, and action. Then let one through on purpose and show the containment path: revoking the agent's credentials, reversing what it did, and clearing the memory that caused it. If you run more than one agent, make them prove the same thing across a chain.
Measure after 90 days:The share of agent tool calls actually inspected, and how many policy violations were stopped before execution rather than found in a log afterward.
If AI can reach sensitive data
Security of AI · If AI can reach sensitive data
9 AI data security
What sensitive data can AI reach, retrieve, or leak?
AI reads, indexes, and reproduces data at a scale that breaks the classification and access controls you built for humans. A copilot with over-permissioned access will surface the HR folder to anyone who asks nicely.
In regulated and sovereign environments the question moves one step further back: not who inside your organization can reach the data, but whether the model host can see it at all. Confidential computing, enclaves, and in-region inference answer that, and they are a platform decision as much as a security one. No box on this map covers it yet; watch it.
Not to be confused with:Runtime security (#5) or usage policy (#1). This follows the information and its permissions, regardless of which AI is asking. A prompt filter does not fix an over-shared document repository, and no amount of usage policy does either. Nor is it supply chain (#4): this category owns access, who can reach or disclose data through AI, while whether a corpus has been tampered with is an integrity problem and sits in #4.
Probably not. This has become a feature of the data security platforms you're likely already evaluating.
Ask the vendor to show you:Have an AI assistant try to retrieve a sensitive document the requesting user is not entitled to see. Then watch what happens.
Measure after 90 days:The count of sensitive documents an over-permissioned assistant can still retrieve, trending down, and the time it takes to revoke access once you find one.
AI for Security
AI enters the security program at two ends: in the SOC, where it reads alerts, decides what matters, and increasingly acts on its own; and in testing, where it attacks your environment before someone else does. The four categories below run in order of authority, from recommending to executing, and authority is the axis to buy on. An assistant that suggests a response needs different controls from an agent that can disable accounts. The vendors know this, which is why the demo always shows the recommendation and the pricing assumes the automation.
If AI runs in your SOC
AI for Security · If AI runs in your SOC
10 AI-driven detection
Can behavioral models catch what our rules miss?
Behavioral models that catch what rules miss. This is the oldest use of AI in security and, by now, a platform feature rather than a purchase.
Not to be confused with:The rest of this map. It's here because "AI security" pitches often mean this, and it's worth recognizing when a vendor is selling you last decade's ML with this year's label.
No. Buy it inside EDR, NDR, email, or identity platforms.
Ask the vendor to show you:Show detections from the last quarter that no rule would have caught, and the false-positive rate that came with them.
Measure after 90 days:Detections no existing rule would have produced, and the false-positive rate that arrived with them.
Back to the map ↑Next: 11 AI SOC: triage and investigation →
AI for Security · If AI runs in your SOC
11 AI SOC: triage and investigation
Can AI do the first pass on alerts so analysts handle what's real?
Your SOC gets more alerts than it has people to read them. This category puts AI on the first pass so analysts handle what's real.
Not to be confused with:Autonomous response (#12). Triage decides; response acts. Vendors blur this line on purpose.
Partly covered. Every SIEM and XDR vendor now ships a copilot. The standalone AI SOC vendors argue they investigate deeper and reach across more tools. Test that against your own alert queue before believing it. Then plan for the failure nobody demos: analysts who stop checking. Sample the closures on a schedule and keep a path back to manual review.
Ask the vendor to show you:Feed it a week of your real alerts and show the verdicts, the evidence behind each, and the ones it got wrong.
Measure after 90 days:The share of alerts closed without a human touching them, and the false-negative rate on a sampled audit of those closures.
AI for Security · If AI runs in your SOC
12 Autonomous response
Can containment run on its own inside the policy we set?
A correct triage decision is worth nothing if containment takes four hours. This category lets response run on its own within the policy you set.
Not to be confused with:Triage (#11). Triage decides; this executes.
Partly covered. SOAR incumbents are adding agents; the newer platforms were rebuilt around them and it shows.
Ask the vendor to show you:Show an automated containment, the policy that authorized it, and the path to reverse it when it's wrong.
Measure after 90 days:Time to containment on the actions you authorized, and how often a response had to be reversed.
If AI tests your environment
AI for Security · If AI tests your environment
13 AI-assisted offensive security
Can AI attack our environment continuously so we find it first?
Annual pentests describe your environment as it was. AI-driven attack simulation describes it as it is, continuously.
Not to be confused with:AI red teaming (#6), which attacks your models; this attacks your environment.
Partly covered. Breach-and-attack-simulation vendors are adding AI agents; the AI-native entrants are ahead on autonomy.
Ask the vendor to show you:Point it at a real subnet with a known weakness and see whether it finds it, and what else it finds that you didn't know about.
Measure after 90 days:Exploitable paths found and fixed per cycle, and how many of them come back.
Back to the map ↑Next: 14 Deepfake and synthetic media detection →
Security from AI
Attackers reach for AI the same way you do, and most of what they build with it lands in domains you already defend: AI-generated phishing in email security, AI-assisted malware on the endpoint, automated reconnaissance in exposure management, insecure AI-written code in application security. None of those creates a purchase you haven't already made, so none earns a category here. Except for one. A market has formed around the case your existing controls were never built for: when the attacker's AI impersonates a person, and the voice or face on the other end is the thing that needs verifying.
If attackers use AI against your people
Security from AI · If attackers use AI against your people
14 Deepfake and synthetic media detection
Is the person on this call, or in this ticket, actually who they claim to be?
A voice cloned from a conference talk and a face lifted from a webinar are now cheap enough to use on a daily basis. They arrive at your help desk during a credential reset, on a video call approving a payment, and in a remote interview for a role with production access. Your identity stack authenticates accounts and devices; this category checks the human.
This category faces inward, at what arrives. The mirror problem faces out: proving that your own executives, announcements, and recordings are authentic, through signing and provenance standards rather than detection. Same market, opposite direction, and it has not formed into a purchase yet.
Not to be confused with:AI red teaming (#6) and AI-assisted offensive security (#13), which point AI at systems you own. This points at your people, and the attacker supplies the AI. It is also not consumer KYC: onboarding tools verify customers at signup, while this covers workforce moments such as help-desk resets, executive impersonation, and candidate screening.
Yes, and this is the newest line on the map. Identity platforms verify credentials and devices, not the voice and face in a live conversation. Nothing you already own closes this. Gartner ran its first Emerging Market Quadrant on the category in 2026, which is usually the signal that the buying decision has arrived ahead of the platforms.
Ask the vendor to show you:Run a cloned voice through your own help-desk verification flow and show where detection fires, how long it takes, and exactly what the agent on the call sees.
Measure after 90 days:The share of high-risk workflows that now run through a verification step, starting with credential resets, MFA enrollment, and payment approvals, and the false-positive rate against real employees doing their jobs.
Where programs actually break
The exposure in most AI security programs isn't a missing category or tool. It's two tools that don't talk to each other. Usage policy allows an AI service that data security never assessed. An agent gets an identity but nothing watches what it does with it. Red teaming finds a failure and runtime security never learns about it.
Shadow AI is the clearest example. Usage discovery (#1) finds the unsanctioned chatbot, posture management (#3) finds the model endpoint nobody registered, and agent identity (#7) finds the agent running on a developer's laptop. Buy only the first and you have inventoried a third of your exposure while believing you covered all of it.
Before you add another tool, take one attack and walk it across the map: a prompt injection that arrives inside a retrieved document, say. Which control sees it, which one stops it, and who finds out afterward. If the answer involves three vendors and no shared alert, you've found the gap.
Analyst's note, September 2026
Three of these fourteen categories won't exist as purchases by 2028. AI security posture management is already folding into cloud security, AI data security into DSPM, and AI-driven detection went into EDR years ago. Three are moving the other way: agent identity, agent runtime control, and deepfake detection are the categories where standalone vendors still lead, and where the next acquisitions will happen. Deepfake detection is the newest and the one to watch; if attacker-side AI keeps producing purchases the platforms don't cover, Security from AI will hold more than one category by this time next year. Buy those carefully and buy the rest as features.
Three things we are watching that have no box yet. Multi-agent security, where OWASP has named three top-ten risks and no product answers them well. Confidential inference, which regulated and sovereign buyers are purchasing today under a platform budget rather than a security one. And content provenance, the outbound mirror of deepfake detection. Any of the three could earn a number by the Q1 2027 benchmark.
What earns a box
Category names in this market change faster than the products do, which is why a capability earns a category here only when AI creates a distinct security problem with its own buying decision. In our model, categories are defined by the problem they solve, not by where the control runs: browsers, gateways, and APIs are places controls operate, so they sit inside categories rather than becoming categories.
AI also changes problems that already have a market. AI-generated phishing is still an email security problem and AI-assisted malware is still an endpoint problem, which doesn't put either outside AI security. They appear on the map as cross-cutting threats rather than categories, because neither creates a purchase you haven't already made. Deepfake detection did, which is why it has a category now.
The rule has one deliberate exception. AI-driven detection (#10) is a platform feature, not a separate purchase. It keeps a dedicated category because "AI security" pitches often mean this, and a buyer needs somewhere to put that pitch when it arrives. It is the only entry on the map we would tell you not to buy on its own.
"AI" here means all of it. The generative and agentic categories move fastest and take up the most room, but the same rules apply to predictive models, computer vision, and the fraud, underwriting, and recommendation systems that were in production long before anyone shipped a copilot. Where a category applies to both, the definition says so.
Vendor listings are selective and unranked, the inclusion criteria are below, and the map is revised quarterly.
How this map is built
Each category carries a market status showing how settled it is as a purchase: established platform capability (buy it inside something you already own), converging into platforms (standalone vendors still lead but the platforms are closing), mixed specialist/platform market (both are real buys today), and emerging standalone category (no platform covers it yet). Market status is re-assessed every quarter, and the categories that move are the ones worth watching. The typical owner names the team that usually holds the budget and the decision, which is often not the CISO.
Categories are named by the problem they solve; the market names them by the product it sells. Both taxonomies are on every page, and when buyers adopt a market name, so do we. Definitions come from editorial review against Cybersecurity Insiders practitioner survey data and public standards (OWASP LLM and Agentic Top 10, NIST AI RMF, EU AI Act).
Vendors are listed as representative, not ranked or endorsed. A vendor appears when it has a generally available product for the stated problem, at least one named enterprise customer or public case study, and public documentation that lets us verify the claim. In this standalone edition vendor names link to vendor sites; on the published map each links to a profile, and each profile to the documentation that qualified it. Listings are selective and unranked; a listing does not mean full category coverage or independent testing by Cybersecurity Insiders. Sponsorship of Cybersecurity Insiders research has no bearing on inclusion, placement, or order.
"(now Vendor)" means acquired and integrating. Ownership is re-verified every quarter; it's the field on this page most likely to be out of date, and we'd rather say so than pretend otherwise.
Submit evidence or a correction
Corrections are reviewed editorially. Send the product name, the category, the capability, and a link to public documentation.
Related research
2026
AI Risk and Readiness Report · Cybersecurity
Insiders research library · AI security coverage