The Zero Trust Blind Spot: Why Your Security Stack Can’t See AI

Zero Trust has become the default architecture for healthcare cybersecurity, and for good reason. The model CISA (Cybersecurity and Infrastructure Security Agency) published for federal agencies, and that most enterprise security programs now follow in some form, organizes Zero Trust into five pillars: Identity, Devices, Networks, Applications and Workloads and Data. Each pillar answers a specific question about what’s allowed to access what and under what conditions.

It’s a sound, industry accepted model built over years of real-world hardening. It’s also missing something CISA itself admits it doesn’t cover: AI.

The Gap Is Documented, Not Hypothetical

Buried in the federal government’s own Zero Trust Maturity Model is a direct admission: the model does not address how to incorporate machine learning and AI capabilities into Zero Trust solutions. That’s not a criticism of the framework. It’s an honest acknowledgment that the five pillars were built to govern users, devices, network traffic, applications and data, and AI doesn’t sit neatly inside any of them.

Walk through the five pillars and the pattern repeats.

Identity governs who or what is allowed to act and what they’re allowed to do. An AI agent making autonomous decisions inside a clinical workflow isn’t a user with a login. It doesn’t authenticate the way a person does and most identity systems have no concept of “AI as an entity” worth verifying.

Devices governs the hardware accessing your network: is it known, is it compliant, is it compromised. A device can be fully verified and still be running an AI model nobody approved. The device can be secure. What’s running on top of it can be invisible.

Networks governs traffic: where it’s going, whether it’s segmented, whether it’s encrypted. An API call to a large language model looks like ordinary outbound traffic to most network tooling. It doesn’t get flagged as “AI usage” because most network tools were never built to recognize what AI traffic looks like.

Applications and Workloads govern what software is allowed to run and how. Vendor platforms increasingly ship with embedded AI baked into the product. Most app governance processes were not designed to ask “does this application contain a model making autonomous decisions,” only “is this application authorized to run.”

Data governs who can access what information and how it’s protected. AI tools, especially public ones, can ingest sensitive data without it ever being logged as a data access event in the traditional sense. The data pillar assumes a person or system is requesting access; it doesn’t assume a model is quietly learning from what it’s been shown.

Five pillars, five blind spots, one common thread: each pillar was built to verify users, devices, and traffic, not to discover or govern AI itself.

A Strong Foundation, Pointed at a Different Problem

This isn’t unique to health system security programs. It shows up in the architecture of even the most sophisticated infrastructure security environments.

There are many solutions from leading infrastructure and hardware leaders that have strong engineering within the Devices pillar: hardware-rooted protections that operate below the operating system, paired with AI-assisted threat detection that profiles and flags malicious behavior using CPU telemetry and machine learning. Defense architecture spanning hardware, firmware, hypervisor, OS and applications, hardening endpoints against ransomware, firmware tampering and fileless attacks that software-only tools tend to miss.

That’s real security value and it answers the Devices pillar’s core question well: is this hardware compromised.

It does not answer a different question: what AI is running on top of that hardware, what data it’s touching or whether anyone approved it. A hospital can have every endpoint hardened, every below-the-OS protection active, and still have no visibility into the AI agents and models running on that secured device. The Devices pillar can be fully mature while AI itself remains completely ungoverned.

Closing the Gap on the Same Hardware

This is the gap Cognome’s AI Sniffer™ is built to close. AI Sniffer discovers AI activity across all five Zero Trust pillars at once: sanctioned tools and shadow AI usage, third-party vendor models embedded in applications, internally built models, and autonomous agents, surfacing what’s actually running rather than what was supposed to be deployed. It treats AI discovery and governance as the layer the existing five-pillar model never had a mechanism to address, not a replacement for Zero Trust, but the missing piece that lets every pillar account for AI the way it already accounts for users, devices and traffic.

Run alongside hardware-rooted protections, the combination is straightforward: the Devices pillar stays defended below the OS and the AI running on top of it stops being invisible. The five pillars get the AI layer CISA’s own model admits it doesn’t yet cover.

Watch this video to learn more about the Cognome platform including AI Sniffer™, ExplainerAI™ and our clinically-aware Risk Intelligence Layer.