The AI Security Alphabet Soup, Decoded

It's 11:04 p.m. on a Friday. A nurse on the step-down unit at a regional health system in Texas is charting at a workstation in the hallway outside room 412. The overhead lights have cycled to night mode. Her monitor is the brightest thing on the floor. She has five patients. One of them (sepsis, two comorbidities, a family that wants answers in the morning) has a note that isn't close to done.

She doesn't have time to write the kind of note she knows she should write. So she opens ChatGPT, pastes the patient's history, and asks it to help her organize her thoughts.

She's not malicious. She's exhausted. She's been doing this for six weeks.

Three floors up, no one knows. The CISO left at six. On his desk: a contract renewal for the DLP tool they deployed eight months ago. The quarterly report showed 17,000 blocked events. The numbers looked right.

On Tuesday morning, the inbox has three new pitches...

AI DLP. AIDR. AI MDR. AISPM. SSPM. AI TRiSM. MCP. OWASP LLM Top 10. CASB. SASE. DSPM. The pitches read the same. "AI is the new attack surface." "Your employees are leaking PHI into ChatGPT." "Your AI agents will be jailbroken." Three slides in, the deck looks like the deck from last week. Different logo, same words.

The vendors are not making it up. The risks are real. But the categories are different shapes of work, sold to different buyers, solving different problems. A tool that blocks staff from pasting patient data into ChatGPT does not protect a patient portal chatbot from a jailbreak. A managed detection service that watches for AI-generated phishing does not tell a compliance officer what staff are doing with Copilot at 11 p.m. on a Friday.

The reason this is hard is that the market is young and the language has not settled. Vendors borrow each other's terms. Analysts add new acronyms faster than buyers can absorb them. Some of these categories did not exist a year ago. One of them, AI MDR for LLM threats, technically still does not exist as a buying motion.

Ten vendor calls in, and most CISOs are less certain than when they started. This guide fixes that.

By the time you finish it, you should be able to pick up any AI security pitch and answer four questions in the first three slides: which category is this, what does it actually do, what does it miss, and do I need it. No vendor recommendations. Plain language. Healthcare examples from the kinds of situations your teams are actually in.

If you're a CISO at a health system, a CIO who has to translate this for the board, or a compliance lead who keeps hearing "agentic" and doesn't know what to do with it, you're in the right place.

Start with the map.

The landscape at a glance

Seven categories of AI security tools matter to a healthcare CISO right now. They sort cleanly into three lenses, defined by what they protect.

Lens 1: tools that govern your employees using AI. Four categories live here. AI-Native DLP, SSE/SASE with AI Module, Legacy DLP with AI Extension, and Shadow AI Discovery. These are the tools you buy when your concern is what staff are sending to ChatGPT, Copilot, Gemini, or any of the free AI tools that show up on a clinician's browser.

Lens 2: tools that protect AI you build. One category sits here. AIDR (AI Detection & Response), also called LLM Runtime Security or AI firewalls. These tools protect AI applications and agents your organization is shipping. If you have a patient portal chatbot, an in-house clinical documentation pilot, or an agentic workflow that takes actions in your EHR, this is the layer that defends those apps at runtime.

Lens 3: tools that defend against AI-driven attacks. Two categories sit here. AI MDR / AI-Augmented SOC and AI Governance Platforms. These tools watch for AI-generated phishing, model-abuse pathways, and identity attacks against your cloud, and they handle the assurance work for any models your team builds.

Some categories sit on more than one lens. Shadow AI Discovery often overlaps with AI-Native DLP. AI Governance Platforms sometimes describe themselves as covering both employee governance and model governance. We will flag the overlaps where they apply.

Each of these answers a different question. Here is what each category actually does, what it misses, who it is for, and why you might need it.

AI-Native DLP

The billing analyst didn't think of it as a security event. She had a 200-row payer denial spreadsheet and a deadline. The free AI tool cleaned it up in forty seconds. What she didn't register and what no one flagged until three weeks later was that the spreadsheet included 340 patient names, claim numbers, and diagnosis codes. An auditor found it during a routine review. The disclosure process took four months.

AI-Native DLP is purpose-built to catch that moment before it becomes a disclosure event. These tools inspect data flowing into AI applications and block sensitive content before it reaches ChatGPT, Copilot, Gemini, or any other generative AI tool. Usually deployed as a browser extension, a network-layer proxy, or an API integration into specific AI tools.

What it does well

Catches the most common AI exposure event. An employee pasting patient data into ChatGPT to draft a discharge summary. A billing analyst dropping a payer denial spreadsheet into a free AI tool to "make it readable." A clinician copying a chart note into Gemini for a second opinion. Best-of-breed vendors do this with high fidelity and low false-positive rates, and most have healthcare-specific data classifiers for PHI, PII, and HIPAA-identifier detection built in.

What the sales rep won't put in the deck

AI-Native DLP is a prevention layer, not a governance layer. It tells you what was blocked. It does not tell you whether your acceptable use policy is defensible to an auditor, whether your staff has been trained on what they are allowed to use, or whether the shadow AI tools your security team does not know about are still running anyway. It is also a point solution. Most of these vendors do not address AI features now embedded inside SaaS tools you already own: Slack AI, Salesforce Einstein, Notion AI.

Who it's for

Security teams at organizations that have standardized on a specific AI tool stack and need a focused prevention layer for it. Healthcare orgs with a recent Office for Civil Rights inquiry tend to land here first because they need a fast, auditable block on the most obvious leak path.

Why you might need it

A breach or near-miss event where staff exposed regulated data through a sanctioned AI tool. A SOC 2 or HITRUST auditor adding AI scope. A compliance officer asking how you would know if someone sent a patient roster to ChatGPT, and you not having an answer.

Representative vendors

• Nightfall AI. Cloud DLP API with deep ChatGPT and Copilot integrations. Strong PHI, PII, and secrets detection.
• Cyberhaven. Data lineage approach. Tracks data flow from source to AI tool. Unified DLP, DSPM, and insider risk.
• Harmonic Security. Browser-based real-time prompt inspection. Strong shadow AI discovery across free-tier AI tools.
• Prompt Security. Integrated into SentinelOne's Wayfinder Threat Detection & Response stack as the prompt-level DLP layer. First AI DLP vendor to land inside an MDR-class platform.
• Polymer. AI DLP for SaaS and generative AI. Identifies and redacts sensitive data in prompts and outputs.
• Mind.io. Autonomous DLP and insider risk for human, non-human, and agentic AI activity.

SSE/SASE with AI Module

A large IDN in the Midwest deployed Zscaler in 2021. When the AI conversation started internally, the CISO pulled up the contract. The AI module was already bundled. Ninety days later the policy was live, the block list was configured, and the quarterly board report showed 23,000 blocked AI upload events. The numbers looked right.

What the report didn't show: the blocked events dropped 40% in month four. Not because staff stopped trying. Because they found a workaround. Personal phones. Browser profiles on clinic computers. A transcription app that wasn't on the block list yet. The SSE had done exactly what it was designed to do. It had also stopped being the thing staff tried to get around.

The big secure-edge platforms that most large enterprises already own (SSE and SASE) combine CASB, SWG, ZTNA, and DLP into a single cloud-delivered platform. The AI module is a feature inside that broader stack, not a standalone product.

What it does well

If you already run Netskope or Zscaler, the AI module gives you a same-pane-of-glass view of AI traffic alongside the rest of your egress monitoring. Policies, identity, and the existing CASB inventory carry over. You do not have to deploy another agent or stand up another console. For a 5,000-employee health system already invested in an SSE stack, this is the lowest-friction starting point.

What the sales rep won't put in the deck

Blocking is not the same as solving. When the SSE tells the nurse at 11 p.m. that ChatGPT is off-limits, she doesn't stop. She switches to her personal phone. She uses a browser profile you can't see. She finds the free transcription tool that isn't on the block list yet. The SSE logs a prevention event and calls it a win. The PHI is still moving. You just can't see it anymore.

SSE AI modules also tend to lag standalone vendors on AI-specific signal, because AI traffic inspection is one of fifty features the vendor is shipping at once.

Who it's for

CISOs at organizations that already own an SSE or SASE platform and want to add AI coverage without a new procurement cycle. Common pattern at large IDNs and academic medical centers that consolidated on Zscaler or Netskope between 2020 and 2024.

Why you might need it

You bought SSE three years ago, and the AI module is bundled into your existing contract. You want to start somewhere. This is the path of least resistance.

Representative vendors

• Netskope SkopeAI. AI traffic inspection through Netskope's CASB and SWG layers. Strong DSPM integration.
• Zscaler AI Data Protection. Zero Trust Exchange with AI DSPM and AI posture controls. Inline inspection through the existing SSE architecture.
• Cato Networks. SASE with XDR and AI-specific threat detection. AI protection inside the broader secure-edge offering.
• Cisco Umbrella. DNS-layer AI service detection. Lighter-weight than full SSE. Useful as a discovery layer.

Legacy DLP with AI Extension

The Proofpoint contract came up for renewal in April. The account rep mentioned, almost in passing, that the AI extension was now included. The compliance team added it to the renewal summary as a line item. "AI coverage: included." Technically accurate. What it meant in practice was that the email DLP layer now flagged some AI-adjacent data patterns, slowly, inconsistently, and not at all for browser-based activity. The audit committee saw the line item. The clinician on the fourth floor still had an undetected workaround.

The DLP vendors that most healthcare shops standardized on a decade ago are now retrofitted with AI coverage. The AI module is bolted onto existing email DLP, endpoint DLP, and cloud DLP products.

What it does well

If your organization already runs Proofpoint for email or Symantec on the endpoint, the AI extension is often a cheap upgrade. Policies, classifiers, and incident workflows carry over. For shops that view DLP as a compliance checkbox and want to keep it that way, this is the lowest-cost path to "we have an AI control in place."

What the sales rep won't put in the deck

Legacy DLP architectures were built for email exfiltration and file movement. They were not built for browser-based, real-time, conversational data flow into a chat interface. The AI extensions are doing their best to match modern AI traffic patterns, but they tend to miss free-tier AI tools, browser extensions, and the kind of paste-into-prompt behavior that AI-native DLP catches by design. Healthcare orgs running this category as their primary AI control should expect blind spots, especially on personal-device and clinician-mobile workflows.

Who it's for

Healthcare shops with a deeply embedded legacy DLP vendor, a procurement preference for incumbent extensions over new vendors, and a compliance-first rather than risk-first posture on AI.

Why you might need it

You are not ready to add another vendor, and your existing DLP vendor can produce a quarterly report that satisfies the audit committee. You know the coverage is partial. You are buying time.

Representative vendors

• Proofpoint. Email and cloud DLP with AI/ML extension for generative AI data classification.
• Forcepoint. DLP with AI Mesh for generative AI risk. Inspection of prompts alongside traditional email and cloud DLP.
• Symantec (Broadcom). Enterprise DLP with AI policies for content going to generative AI services.

AI Governance Platforms

The data science team had built the readmission model eighteen months earlier. It lived in a shared drive, was retrained occasionally when someone remembered, and had never been formally documented. When the compliance committee asked whether the model was biased against patients with certain zip codes, no one could answer confidently. The documentation didn't exist. The audit trail didn't exist. The model had been running on 4,200 discharge decisions in the meantime.

That is the problem AI Governance Platforms exist to solve, and it is a completely different problem from what the nurse at 11 p.m. is doing with ChatGPT.

These tools are focused on model risk, bias, policy, and audit assurance for the AI models and ML pipelines an organization builds. This is a different layer from prompt-level DLP. It is concerned with how a model behaves over time, whether it drifts, whether it is biased against a protected class, and whether the documentation around it will hold up under a regulator's review.

What it does well

If your organization is building or operating its own machine learning models (clinical decision support, denial prediction, risk stratification, readmission scoring), an AI Governance Platform gives you the model registry, the audit trail, the bias monitoring, and the policy mapping that ISO 42001, NIST AI RMF, and the EU AI Act all increasingly require. For organizations under federal contract or state AI accountability rules, these tools turn governance from a one-time documentation exercise into an ongoing control.

What the sales rep won't put in the deck

These platforms govern models. They do not govern employees. A Credo AI deployment does not tell you what your billing team is pasting into ChatGPT. It tells you whether the in-house readmission model is drifting. Buyers often confuse the two and end up with a model governance tool when the actual problem is shadow AI usage. The reverse mistake happens too: orgs buy a prompt DLP tool and discover at audit time they also need model governance, because the data science team built a homegrown sepsis predictor two years ago that no one is tracking.

Who it's for

Organizations building or operating their own ML models. Health systems with internal data science teams. Payers with risk-prediction models. Anyone whose AI strategy includes "we built it" rather than only "we bought it."

Why you might need it

A regulator asked how you monitor a model for bias. A board member read about the EU AI Act and asked what your equivalent program looks like. A clinical leader wants to deploy a homegrown sepsis-prediction model and your compliance committee asked who is accountable for it.

Representative vendors

• Credo AI. Model risk, compliance mapping, and policy enforcement. Enterprise-focused.
• Vectice. Data science and ML workflow governance. Model lineage and compliance documentation.
• Fairly AI. Bias detection, model monitoring, regulatory compliance.
• Monitaur. AI assurance and governance. Auditability and compliance reporting.
• Arthur AI. Performance and governance monitoring. Drift, bias, and explainability.
• Robust Intelligence. AI firewall and validation. Pre-deployment model testing and runtime protection. Crosses into AIDR for some use cases.

AI MDR / AI-Augmented SOC

The CFO's executive assistant got a voicemail. It sounded like the CFO, same cadence, same slight accent, same way of trailing off at the end of a sentence. It asked her to initiate a wire transfer to a new vendor account before end of day. She was 80% sure it was real. She made the call.

It wasn't real. It was a voice clone, generated in under four minutes from publicly available earnings call recordings. The attack was caught, barely, by a second-factor approval process that almost didn't exist. The MDR provider flagged the anomaly seventeen minutes after the wire was initiated. Close enough to matter. Not close enough to prevent it.

AI MDR / AI-Augmented SOC covers this territory. These are Managed Detection and Response services that either use AI internally to augment analyst workflows or extend detection coverage to AI-driven attacker techniques. As of mid-2026, no MDR provider sells "MDR for LLM threats" as a dedicated SKU. The category is consolidating. Expect the term to mean something more specific in 12 to 18 months.

What it does well

If you already buy MDR, the AI-augmented version extends the same service to detect AI-generated phishing, identity attacks against Microsoft 365 and Azure, agentic-attack patterns against your cloud, and the model-abuse pathways where attackers use AI to scale lateral movement. For health systems where the SOC is the most expensive line item in security and the team is short three analysts, the productivity gain of AI-augmented triage is real and measurable.

What the sales rep won't put in the deck

AI MDR covers attackers. It does not cover employees. The MDR provider watches for the threat actor running an AI-generated impersonation campaign. It does not watch the clinician using Doximity Ask to draft a chart note. Two different problems, two different buys. Healthcare CISOs who assume their MDR contract covers AI risk often discover during an incident that the scope was narrower than they thought. Read the statement of work.

Who it's for

CISOs already buying MDR who want their provider to add AI-attack coverage. The fastest-moving segment is the one where MDR vendors are acquiring AI security companies to bundle prompt-level coverage into the managed service. SentinelOne's integration of Prompt Security into the Wayfinder stack is the first cross-category bundle in the market. Expect CrowdStrike, Sophos, and Rapid7 to follow.

Why you might need it

Your SOC is short-staffed. Your board asked what you are doing about AI-generated phishing. An incident response retrospective surfaced that the attacker used AI tooling and your MDR did not flag it cleanly.

Representative vendors

• AirMDR. AI-native MDR with generative AI virtual analysts. Triage built on AI agents.
• Vectra AI. Behavioral AI for hybrid attack detection across network, cloud, identity, and endpoint.
• Sophos. Largest pure-play MDR. Agentic SOC model. 24/7 managed threat response.
• CrowdStrike. Falcon Complete Next-Gen MDR with AI-powered detection. Dedicated AI security services for agentic AI systems.
• SentinelOne. Wayfinder Threat Detection & Response with human and AI defense. Integrated Prompt Security into the Wayfinder stack to add prompt-level DLP.
• eSentire. Atlas Platform for AI-driven security operations. 24/7 managed detection.

AIDR / LLM Runtime Security

The patient portal chatbot had been live for four months when the security researcher found it. She wasn't trying to do harm. She was curious. She spent twenty minutes crafting a prompt that got the chatbot to ignore its system instructions and respond as if it were a general-purpose medical assistant with no restrictions. Then she asked it about another patient's discharge medications. It answered.

The chatbot had passed a standard penetration test before launch. The pen test hadn't included adversarial prompt scenarios. No one had thought to check.

AIDR (AI Detection & Response, also called LLM Runtime Security, AI firewalls, LLM guards, or AI agent runtime protection) exists to catch exactly that. These tools defend the AI applications, agents, and pipelines your organization builds and ships, not the AI tools your employees use. This is a different buyer entirely: app security teams, ML engineering teams, whoever inside the organization is shipping AI into production.

What it does well

Catches prompt injection, jailbreaks, sensitive-data leakage, and agentic-action abuse at runtime. If you have a patient portal chatbot, an in-house clinical documentation assistant, or an agent that takes actions inside your EHR or scheduling system, AIDR is what prevents that agent from being tricked into giving medical advice, exposing data from a different patient's record, or executing an action it should not be authorized to take. The category maps cleanly to the OWASP LLM Top 10 risks and is the first place CISOs land when their compliance team asks about adversarial AI testing.

What the sales rep won't put in the deck

AIDR does nothing about the employee using ChatGPT or Copilot. It defends apps, not users. The disambiguating question is one sentence: are you protecting an AI app you built, or governing AI tools your employees use? The answer tells you which vendor you're even talking to. The other miss: most AIDR vendors are early-stage and assume the customer has a meaningful internal AI engineering capability. Health systems without a dedicated AI engineering team often find this category overshoots their actual risk surface.

Who it's for

Organizations building or deploying their own AI applications. Health systems with patient-facing chatbots, agentic workflows in revenue cycle or scheduling, or in-house clinical AI pilots. Payers with claims-processing agents. Anyone whose AI footprint includes "we shipped it" not just "we use it."

Why you might need it

You launched a patient portal AI assistant and someone on the security team asked how it would handle a jailbreak. A red team report found a way to make your chatbot reveal another patient's data. You are about to ship an agentic workflow that touches PHI and the compliance committee asked what runtime controls are in place.

Representative vendors

• Zenity. AIDR and AI-SPM. Monitors AI agent runtime behavior, intent, and execution paths.
• Lakera. Lakera Guard blocks prompt injection, jailbreaks, and data leakage in real time for production AI apps.
• Lasso Security. Enterprise LLM interaction monitoring for data leakage and malicious prompts.
• Mindgard. AI security testing and protection for LLM and GenAI vulnerabilities.
• PromptGuard. Production AI firewall with multi-layer defense against prompt injection and data leaks.

Shadow AI Discovery Specialists

The CISO asked the question in a staff meeting: "What AI tools are running in our environment right now?" The room was quiet for a moment. The IT director said Copilot and the Epic AI features they'd approved. The security lead said ChatGPT, probably, but they'd blocked it at the SSE layer. Someone in the back mentioned Doximity Ask. Someone else mentioned that the dev team had been using Cursor for six months. The CISO asked if that had been approved. No one was sure.

That inventory, incomplete, inconsistent, assembled from memory in a conference room, is the starting condition for most health systems. Shadow AI Discovery tools exist to replace guesswork with a real list.

These tools find unsanctioned AI usage across SaaS, devices, OAuth permissions, and developer environments. They are often the first deliverable in a broader AI governance program, because no other category produces a useful answer to the question every CISO is eventually asked: what AI is actually running in our environment right now?

What it does well

Surfaces the AI footprint. The free-tier AI tools running on clinician devices that do not show up in standard network scans. The Doximity Ask installs on physician phones. The OAuth grants where someone connected ChatGPT to the company Google Workspace and forgot. The personal Claude accounts that show up in browser history. The Cursor and GitHub Copilot installs in the dev team that no one approved. Discovery tools turn an unknown into an inventory.

What the sales rep won't put in the deck

Discovery is a starting line, not a destination. It tells you what is there. It does not tell you what to do about it. Once you know your nursing staff is using ChatGPT, your residents are using Doximity Ask, and the revenue cycle team is using a free transcription tool, the question becomes governance, training, and a sanctioned alternative. None of the discovery tools provide that next step. They report and they alert.

Who it's for

Organizations early in the AI governance journey. Health systems that have never done an AI inventory. Compliance leads about to walk into a board meeting and needing a clear answer to "what AI is in our environment." This is also the most common lead-in to a broader DLP or governance buy, because once leadership sees the inventory the next conversation is "now what."

Why you might need it

A board member asked the question. A compliance officer wants a baseline before drafting an AI usage policy. You are about to publish an acceptable use policy and want to know what you are about to govern.

Representative vendors

• Knostic AI. Shadow AI detection across the AI agent and coding-assistant supply chain (Cursor, Claude Code, GitHub Copilot, MCP servers, IDE extensions, and rules).
• Reco. Identity-centric SaaS security with shadow AI discovery. Maps AI usage to user and non-human identities.
• Teramind. Insider risk and DLP with a dedicated shadow AI detection module.
• BetterCloud. SaaS management with shadow AI detection via OAuth and API monitoring.
• Auvik. SaaS management with AI app discovery across the organization.

The governance gap

Six weeks after the DLP deployment, the CISO pulled up the quarterly report. Seventeen thousand blocked prompts. Three escalations. Zero incidents disclosed. The numbers looked exactly right.

That same week, a compliance officer doing a routine floor walk overheard a resident telling an attending that the workaround everyone used was to type notes into a personal Gmail draft first, no PHI, just shorthand codes the unit had developed, then paste it somewhere else and clean it up with a free tool that wasn't on the block list. It had started as a one-person hack. It had spread to eleven people on the floor in three months.

The DLP had worked exactly as designed. It had also accomplished nothing.

Step back. The pattern across all seven categories is the same. They detect, they block, they report. The AI-Native DLP catches the prompt. The SSE blocks the upload. The Discovery tool finds the OAuth grant. The MDR flags the attack. The AIDR catches the jailbreak. The Governance Platform documents the model.

What none of them do is help your nurses, your clinicians, your billing staff, your case managers, and your residents actually do their jobs with AI in a sanctioned way. They tell you what to stop. They do not tell you what to start.

That gap has a name, even if no analyst firm has agreed on it yet. Call it governed enablement. It is the work of policy, training, audit-ready operations, and a sanctioned AI platform staff can use without going around the controls. It is the work of converting "we blocked Free Tool X" into "we approved Sanctioned Tool Y, trained the team on it, documented the BAA, and gave compliance a quarterly report they can defend."

It is also where most healthcare AI strategies break down. The detection layer is mature. The enablement layer is improvisational.

This is the work AuthenTech AI does. We frame it as the missing layer rather than as a category because the truth is, most of the seven categories above are starting to add governance language to their pitches. Several now offer policy modules, training content, or "responsible AI" framing. The work is real even when the labels overlap. Some organizations solve this internally, with a strong compliance officer, a determined CIO, and a friendly IT operations team. Others bring in a partner. There is no traditional security category that sells you this end-to-end. It is a different shape of work, often delivered as engagement plus platform plus operations rather than as a single SKU.

The reason to call it out separately is not to sell. It is to make the map honest. If a CISO reads the seven categories above, picks one or two, deploys them, and stops there, the org will have controls and an audit trail. It will still not have a sanctioned path for the nurse who is pasting chart notes into a free tool because she has no other option at 11 p.m. on a Friday.

That is the gap. Name it before you buy.

What to do next

A decision framework for the morning after this article lands in your inbox.

• If your concern is "what AI is actually running in my org right now?" start with Shadow AI Discovery. Get the inventory before you write the policy.
• If your concern is "what are staff sending to AI tools?" look at AI-Native DLP. If you already own SSE, check what the bundled module catches before you buy a new vendor.
• If your concern is "we are building AI features and worried they could be tricked" that is AIDR territory. Different buyer in your org. Likely engineering, not security.
• If your concern is "attackers are using AI to target us" that is AI MDR. If you already have MDR, check the scope of your contract before adding a new vendor.
• If your concern is "auditors will ask about AI and I cannot answer" that is AI Governance Platforms for models you build, and governed-enablement work for models you use.
• If your concern is all of the above you do not need another product. You need a coordinator.

The nurse at 11 p.m. on a Friday is still out there. She's in every health system. She has a real problem and no sanctioned path to solve it, so she will find an unsanctioned one. The tools in this guide will help you see her. Some of them will help you stop her. None of them will give her a better option.

That is the work that comes after the buying.

If you want to know what is actually running in your environment before you buy anything, start with the SAFE AI Assessment. It maps your specific exposure across four layers: not a category list, but the actual shape of the problem in your org.