The majority of enterprise employees are already using AI applications their IT organization has not approved. Your Identity pillar does not see them — the agent authenticates through a personal or unsanctioned service account. Your Network pillar does not flag them — AI API calls look like ordinary HTTPS. Your Data pillar does not catch the exposure — DLP rules were written for file exfiltration, not conversational data ingestion at scale. Five pillar teams, five telemetry blind spots, and a single AI application slipping through all of them simultaneously.

Structural gaps in AI security are best addressed by extending existing architectural controls rather than fragmented tuning. CISA's Zero Trust Maturity Model v2.0 provides the necessary ownership domains to govern AI assets. This document establishes the five-pillar baseline—the essential "enforcement" foundation for AI security. The architectural controls defined here in part 1 are the necessary prerequisite for the governance frameworks detailed in upcoming Part 2.

Section 1: The Baseline — ZTMM 2.0 Today

CISA ZTMM v2.0 (April 2023) organizes enterprise security maturity around five entity pillars and three cross-cutting capabilities. Each pillar owns a class of enterprise assets. Each maturity level — Traditional, Initial, Advanced, Optimal — describes progressively stronger controls for that asset class. The cross-cutting capabilities (Visibility & Analytics, Automation & Orchestration, Governance) apply horizontally across all pillars.

The framework is well-designed and battle-tested. The baseline below is what it covers before any AI-specific controls are layered in.

ZTMM v2.0 — Five Pillar Baseline

Cross-Cutting Capabilities

Source: CISA Zero Trust Maturity Model v2.0, April 2023 — https://www.cisa.gov/zero-trust-maturity-model

Section 2: How AI Maps to Each Existing Pillar

AI does not require a new framework. It requires each existing pillar team to expand their ownership definition to include a new class of assets and threats. The mapping is cleaner than most organizations assume — each pillar already owns the infrastructure and policy mechanisms that AI controls build on.

Identity owns non-human identities. AI agents, automated pipelines, and service accounts connecting to external AI providers are non-human identities. The Identity pillar already governs service accounts; AI agents are the same problem at greater scale and velocity. NHI audit, least-privilege enforcement, PAM integration for agent credentials, and conditional access policies applied to AI authentication events all belong here. The Identity pillar governs authentication — verifying the credential and enforcing session policy. The authorization boundary — what the authenticated agent is permitted to do operationally — is enforced at the application and data tiers, exactly as it already is for human identities.

Devices own AI compute infrastructure. AI inference servers, GPU nodes, and the endpoints running agent runtimes are managed hardware assets. The Devices pillar already governs servers and virtual assets; adding AI compute to compliance scope, configuration baselines, and supply chain risk assessments is a natural extension. AI software tools running on managed endpoints belong in the managed software inventory.

Networks own AI API traffic. AI API calls to LLM providers, agentic orchestration traffic, and RAG retrieval queries all traverse the network. The Networks pillar already owns TLS inspection, traffic categorization, and DLP at the network layer. Extending those controls to categorize AI API domains, inspect AI API payloads for sensitive data egress, and integrate AI-specific threat intelligence feeds is a direct extension of existing network security capabilities.

Applications & Workloads owns shadow AI and AI-integrated applications. Shadow AI — the unsanctioned AI applications your employees are already using — is an application governance problem. The Applications & Workloads pillar already governs shadow IT via CASB, enforces app access policies, and owns the CI/CD security pipeline. Adding AI application discovery tiers, prompt injection detection for custom AI-integrated workflows, and AI workload segmentation falls cleanly within that remit.

Data owns AI training data, RAG inputs, and AI outputs. AI systems consume and produce data. The Data pillar already owns classification, DLP, and access control for data assets. Extending that to AI training data and RAG knowledge base classification, upload DLP for AI API calls, retrieval-layer access controls for RAG systems, and AI output DLP uses the same classification framework and enforcement mechanisms already in place.

Section 3: Five-Pillar AI Coverage — Updated Maturity Tables

The table below is the primary reference: original ZTMM 2.0 controls with AI additions layered in per pillar at all four maturity levels. Use it as your target state for AI-aware Zero Trust.

ZTMM 2.0 + AI — Five Pillar Reference

Section 4: Cross-Cutting Capabilities — AI Extensions

The three cross-cutting capabilities span all five pillars. AI extends each one.

Visibility & Analytics

AI agent behavior — tool call chains, multi-step inference pipelines, LLM API interactions — generates telemetry that standard SIEM rules were not built to parse. V&A AI extensions bring that telemetry into the same centralized analytics infrastructure, not a separate silo.

Automation & Orchestration

AI agents operate at machine speed. Policy automation handles the expected path. Human-in-the-loop is reserved for decisions where the risk exceeds the agent’s authorized operational envelope.

Governance

Governance spans all five pillars as a horizontal capability. AI extends the Governance capability with AI-specific risk ownership, acceptable use policy, and regulatory alignment processes.

Section 5: Practitioner Roadmap

Phase 1 — Discover: Know Your AI Estate (Months 1–3)

You cannot govern what you have not inventoried. Activate AI application discovery on your existing CASB before deploying any controls — the inventory will surprise you. Most organizations find 200–400 distinct AI applications in active use; 15–25% require immediate governance action based on data risk.

In parallel, filter your IAM platform for non-human identity service accounts associated with AI agents and integrations. The majority will be over-privileged relative to their actual operational scope. Document every AI application, AI agent, and AI compute asset you find — this becomes the working register your pillar teams operate against.

Phase 2 — Strategize: Map to Pillars, Assign Ownership (Months 2–4)

Each AI asset you discovered has a natural home in one of the five pillars. Map it explicitly. AI agent service accounts go to the Identity team. AI inference servers go to the Devices team. AI API traffic policies go to the Networks team. Shadow AI governance goes to the Applications & Workloads team. AI training data classification goes to the Data team.

The most important output of this phase is not a control list — it is clear ownership. AI security fails most often not because the right controls don’t exist, but because no single team owns the end-to-end picture for a given AI asset. Establish a cross-pillar AI security working group with one lead per pillar and a single accountability owner for the overall program.

Sequence deployment by risk tier: high-risk AI assets get controls in the first 90 days; medium-risk within 6 months; low-risk productivity tools via acceptable use policy and CASB enforcement.

Phase 3 — Implement: Risk-Ordered Deployment (Months 4–18)

• Months 1–6: Shadow AI discovery enforcement (CASB policy activation, tiered governance by application risk); NHI audit and over-privilege remediation across all AI service accounts; AI API upload DLP active; AI data assets classified and added to automated inventory
• Months 6–12: TLS inspection for AI API traffic; AI payload DLP at network layer; AI-specific SIEM detection rules; AI inference servers in device compliance scope; NIST AI RMF gap assessment complete
• Months 12–18: Continuous NHI risk scoring; AI output DLP in production workflows; RAG retrieval access controls at the knowledge base layer; AI vendor risk assessment process operational; AI governance reporting integrated into enterprise GRC

Phase 4 — Measure: AI Maturity Assessment

Assess AI security maturity per domain, not as an aggregate score. An organization can be at Advanced on shadow AI governance and Traditional on AI data lineage simultaneously — that per-domain view is what drives prioritization. Score each domain quarterly and track direction of travel.

Section 6: Industry Alignment

The five-pillar AI extension approach aligns with how the industry is building AI security controls today:

• CSA AI Controls Matrix v1.0 (July 2025): 243 controls across 18 domains; cross-mapped to ISO 42001, NIST AI RMF, EU AI Act, and BSI AIC4. The majority of controls map cleanly to Identity, Devices, Networks, Applications, or Data ownership. Use the AICM as your gap assessment baseline.
• CSA Agentic Trust Framework (February 2026): Five Zero Trust questions applied to every AI agent — what is it, what can it access, what can it do, is its behavior expected, and is it compliant. Each question resolves to a pillar team’s accountability.
• OWASP LLM Top 10 v1.1: Prompt injection (Applications & Workloads), sensitive data exposure (Data), insecure plugin design (Applications & Workloads), overreliance (Governance), supply chain vulnerabilities (Devices) — the OWASP LLM risks distribute cleanly across the five existing pillars.
• NIST AI RMF 1.0 / ISO 42001:2023: Risk identification, measurement, and management practices from both frameworks map to existing pillar controls when AI assets are included in the scope of each pillar team.
• NIST SP 800-207: The foundational Zero Trust Architecture document — all seven tenets apply directly to AI agents as subject principals. No new framework required.

Section 7: What This Model Covers — and Where It Points Next

Extending the five pillars with AI-specific controls is not a compromise. It is the right starting point for most organizations and the right permanent home for the majority of AI security controls. The Identity team is the right owner for NHI governance. The Data team is the right owner for AI training data classification. The Networks team is the right owner for AI API traffic inspection. These controls do not need a new home — they need adoption.

That said, three patterns emerge as organizations mature their AI security posture within this model. They are worth naming, not because they undermine the five-pillar approach, but because they represent the natural next questions a maturing program will encounter.

The Authorization Boundary Question

The Identity pillar authenticates AI agents — it verifies the credential and enforces session policy. But as AI agents become more autonomous, the question of what an authenticated agent is permitted to do — invoke a payment API, write to a production database, compose and send communications on behalf of a user — does not map cleanly to any existing pillar’s enforcement mechanism. Identity enforces who can authenticate. Applications & Workloads enforces resource-level access. Neither owns the question of operational capability scope for an agent acting autonomously across multiple systems. Today, most organizations handle this with agent-by-agent configuration. As agent deployments scale, that approach becomes a governance liability.

The Model-as-Asset Question

AI inference servers belong in the Devices pillar. AI training data belongs in the Data pillar. But the AI model itself — the artifact that sits between the compute and the data, with its own version history, training data provenance, safety evaluation record, and deprecation lifecycle — does not belong cleanly to either. It is not hardware. It is not a traditional application. It is not a passive data asset. Organizations that deploy multiple models into production will find that no existing pillar team has a natural accountability claim for model lifecycle governance as a discipline.

The Compliance Evidence Question

NIST AI RMF, ISO 42001, and emerging regulatory requirements expect organizations to produce integrated, auditable governance records for AI systems — covering model risk classification, training data integrity, behavioral monitoring, and incident response in a unified form. When that evidence is distributed across five pillar teams, each with their own data systems and reporting cadence, assembling it for an audit or a regulator is a coordination challenge that grows with the scale of the AI estate.

These three patterns do not invalidate the five-pillar model. They describe where the five-pillar model transitions from sufficient to strained. Recognizing that transition point—and knowing what a structured response to it looks like—is the natural next step for any organization that has gotten the fundamentals right. We will explore how to bridge this governance gap in Part 2 of this series.

Closing

Zero Trust was designed for a world where the perimeter cannot be trusted. That principle applies to AI agents as directly as it applies to human users. Every AI agent should be authenticated. Every AI data access should be policy-governed. Every AI API call should be inspected. Every AI application in your environment should be known.

The five pillars give you the ownership structure to act on all of that today, without waiting for a new framework. Identity, Devices, Networks, Applications & Workloads, and Data — combined with the three cross-cutting capabilities — provide the full surface area to govern AI security.

Building this foundation is the crucial first step; it prepares your organization for the next, more advanced phase of AI security maturity, which we will address in the next part of this series.

References

[1] CISA. Zero Trust Maturity Model v2.0 (April 2023). https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf

[2] NIST. AI Risk Management Framework 1.0 (January 2023). https://airc.nist.gov/RMF

[3] ISO/IEC 42001:2023. https://www.iso.org/standard/81230.html

[4] EU AI Act (Regulation 2024/1689). https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689

[5] OMB M-24-10 (March 2024). https://www.whitehouse.gov/wp-content/uploads/2024/03/M-24-10-Advancing-Governance-Innovation-and-Risk-Management.pdf

[6] CSA. AI Controls Matrix v1.0 (July 2025). https://cloudsecurityalliance.org/artifacts/ai-controls-matrix

[7] CSA. Agentic Trust Framework (February 2026). https://cloudsecurityalliance.org/blog/2026/02/02/the-agentic-trust-framework-zero-trust-governance-for-ai-agents

[8] CSA. STAR for AI (October 2025). https://cloudsecurityalliance.org/press-releases/2025/10/23/cloud-security-alliance-launches-star-for-ai

[9] Microsoft. ZT4AI (March 2026). https://www.microsoft.com/en-us/security/blog/2026/03/19/new-tools-and-guidance-announcing-zero-trust-for-ai

[10] Cisco. Zero Trust for Agentic AI (2025). https://www.cisco.com/c/en/us/solutions/collateral/artificial-intelligence/security/zero-trust-agentic-ai-wp.html

[11] OWASP. LLM Top 10 v1.1. https://owasp.org/www-project-top-10-for-large-language-model-applications/

[12] NIST SP 800-207. Zero Trust Architecture (August 2020). https://doi.org/10.6028/NIST.SP.800-207