Enterprises are adopting AI at a pace that has outstripped the existing Zero Trust Maturity Model (ZTMM). Current security pillars are designed to verify the authenticity of human and application entities, but they are not architecturally equipped to inspect the intent and scope of autonomous AI agents. The result is not merely an operational oversight; it is a structural gap where AI interactions bypass existing telemetry streams. This document defines the framework for bridging this gap by evolving CISA ZTMM 2.0 to include a dedicated 6th Pillar for AI & Autonomous Systems.
This 6th pillar is designed to own the governance and lifecycle of AI models and agents, distinguishing it from the existing five pillars (Identity, Devices, Networks, Applications & Workloads, and Data) which continue to act as "Enforcement Points" for AI security.
Executive Summary
- Problem: Current ZTMM 2.0 pillars are designed for known assets; they cannot interpret the autonomous intent of AI agents.
- Solution: We propose a hybrid model: the existing 5 pillars act as Enforcement Points, while a new 6th Pillar acts as the Policy Authority.
- Outcome: This bridges the regulatory gap (ISO 42001/EU AI Act) and centralizes AI risk without requiring a re-tooling of existing security stacks.
Why AI Exposes a Structural Gap in ZTMM 2.0
CISA ZTMM v2.0 (April 2023) defines five pillars - Identity, Devices, Networks, Applications & Workloads, Data plus three cross-cutting capabilities: Visibility & Analytics, Automation & Orchestration, and Governance. Each pillar has clean ownership, a four-level maturity progression (Traditional → Initial → Advanced → Optimal), and an established body of tooling.
The model works because every security concern in a traditional enterprise maps naturally to one of these five domains. AI does not map naturally. It cuts across all five pillars simultaneously and introduces governance concerns none of them were designed to own.
Think of it this way: a production AI agent authenticates using a service account (Identity), runs on compute infrastructure (Devices), communicates with external APIs (Networks), invokes application tools (Applications & Workloads), and reads and writes data (Data). Then it makes autonomous decisions about what to do next. The first five actions map to existing pillars. The sixth does not.
That autonomous decision layer - who authorized this agent to act, against what scope, with what accountability, under which regulatory framework, is the governance gap. You cannot close it by asking five separate pillar teams to each patch their corner. You close it by owning it.
Four problems define the gap:
- Shadow AI is invisible to all five pillar telemetry streams simultaneously. The majority of enterprise employees use AI applications IT has not approved and cannot control at higher data risk because AI apps are designed to ingest large volumes of content.
- Non-human AI Agent identities authenticate via NHI credential types the Identity pillar already governs but it does not govern the capability scope of those identities. The Identity pillar knows the agent is authenticated; it does not know whether the agent's decision to send an email on behalf of a VP falls within its authorized scope.
- Model lifecycle governance - versioning, training data provenance, safety evaluation gates, AI SBOM, deprecation has no natural home in any of the five pillars. ISO/IEC 42001:2023 formalizes these as a distinct governance discipline.
- AI regulatory compliance (ISO 42001, NIST AI RMF, EU AI Act, OMB M-24-10) requires producing unified, auditable governance documentation. Distributed across five pillar teams, that evidence will be fragmented and will not survive audit.
The Hybrid Architecture: Policy Authority vs. Enforcement Point
Effective AI security requires a hybrid architecture where the 6th Pillar functions as the 'Policy Authority,' while the existing five pillars act as 'Enforcement Points' that operationalize those policies. In this capacity, it generates the necessary risk postures, model classifications, and authorized capability scopes. The existing five pillars then serve as 'Enforcement Points,' integrating these high-level governance outputs into their native technical enforcement mechanisms to provide comprehensive security coverage.
The ZTMM 2.0 Baseline: Where We Start
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.
Before describing the extension, here is the five-pillar baseline that ZTMM v2.0 covers today across all four maturity levels, before AI controls are added.
ZTMM v2.0 - Five Pillar Baseline
This table outlines the standard ZTMM v2.0 maturity progression for the original five security pillars: Identity, Devices, Networks, Applications & Workloads, and Data.
| Pillar | Traditional | Initial | Advanced | Optimal |
| Identity | • Static passwords; siloed on-premises identity stores • Permanent access grants; periodic reviews only • Manual risk assessments | • MFA deployed more broadly • Combined self-managed and hosted identity stores; basic cloud integration • Access starts to expire with automated review • Manual risk assessments on static rules | • Phishing-resistant MFA (FIDO2/WebAuthn/PIV) • Identity store consolidation • Automated dynamic risk analysis • Need-based and session-based access tailored to specific actions | • Continuous identity validation with real-time behavioral insights • Fully integrated identity stores across partners and environments • JIT/JEA dynamically tailored to individual actions |
| Devices | • Manual device tracking; limited compliance visibility • No device criteria for resource access decisions • Manual threat protection deployment to some devices | • Track physical and some virtual assets • Basic compliance checks (often self-reported); some device characteristics as prerequisite for access • Automated threat protection deployment begins | • Verified device health insights on initial access • Automated compliance enforcement for most devices and virtual assets • Centralized threat protection • Supply chain risk assessments | • Continuous verification of device insights and compliance throughout lifecycle • Fully integrated device, software, configuration, and vulnerability management • Real-time device risk analytics for access decisions • Automated supply chain risk management • Fully automated provisioning, monitoring, isolating, and decommissioning |
| Networks | • Large perimeter or macro-segmentation; minimal internal restrictions • Minimal traffic encryption; ad-hoc key management • Manual network configuration | • Begin isolating critical workloads • Transition to service-specific interconnections • More formalized key management; more internal and external traffic encrypted • Basic application profiles and traffic management rules | • Ingress/egress micro-perimeters; service-specific interconnections • Risk-aware application assessments drive network configuration • Most traffic encrypted; key rotation managed; cryptographic agility starting • Network availability managed dynamically | • Extensive micro-segmentation based on dynamic application profiles • JIT/JEA connectivity for service-specific interconnections • Encryption enterprise-wide with full cryptographic agility • Holistic resilience and availability • Infrastructure-as-code with automated change management |
| Applications | • Access via local authorization and static attributes • Minimal threat protections integrated • Critical apps confined to private networks • Ad-hoc development and deployment; manual security testing before deployment | • Contextual access decisions (identity, device compliance) with expiration • Threat protections deployed in mission-critical workflows • Some apps available via brokered public connections • CI/CD pipelines with basic privilege controls; static and dynamic security testing | • Automated access decisions with expanded context and least privilege • Threat protections deployed in all workflows • Most mission-critical apps over public networks • Distinct DevSecOps teams; developers removed from production • Security testing integrated into development and deployment | • Continuous authorization with real-time risk analytics and usage patterns • Advanced content-aware threat protections in all workflows • All applicable apps over public networks • Immutable workloads; automated deployment with no admin access • Application security testing throughout the SDLC |
| Data | • Manual data inventory and categorization • Static access controls; minimal encryption • Ad-hoc key management; manually enforced lifecycle policies | • Automated data inventory for on-premises and cloud • Basic DLP protections; data categorization strategy with defined labels • Automated data access controls with least privilege elements • Formalized key management; encryption for data in transit and critical data at rest | • Automated tiered data categorization and labeling with regular review • DLP strategies based on static attributes and labels • Automated data access controls considering identity, device risk, and data category - with time limits • Broad encryption with cryptographic agility; rigorous key protection | • Continuous inventory of all applicable data • Dynamic DLP capable of blocking suspected exfiltration • Automated enterprise-wide categorization with granular formats • JIT/JEA data access controls with continuous review • Encryption with cryptographic agility including data-in-use • Unified dynamic data lifecycle and security policies |
Source: CISA ZTMM v2.0, April 2023. https://www.cisa.gov/zero-trust-maturity-model
Cross-Cutting Capabilities Baseline
This table details the maturity progression for the three essential cross-cutting capabilities defined in the original ZTMM v2.0 framework.
| Capability | Traditional | Initial | Advanced | Optimal |
| Visibility & | • Manual, limited log collection • Minimal analysis | • Automation for critical functions • Basic correlation | • Enterprise-wide automated collection including virtual environments • Centralized analysis correlating multiple sources | • Comprehensive dynamic monitoring across all pillars • Advanced behavioral and predictive analytics • Continuous security posture assessment |
| Automation & | • Static, manual processes • Limited automation | • Automation supporting critical mission functions • Basic response activities | • Enterprise-wide automation of orchestration and response • Contextual information from multiple sources | • Dynamically adapt to changing requirements • Infrastructure as code • Fully automated security workflows across the enterprise |
| Governance | • Ad-hoc policies • Manually enforced or via static technical mechanisms | • Enterprise-wide policies defined and implemented • Minimal automation; manual updates | • Tiered, tailored enterprise-wide policies • Automation for enforcement where possible • Contextual information incorporated into access policy decisions | • Dynamic enterprise-wide policies fully automated • Tailored local controls • Continuous enforcement and updates across the enterprise |
The Gap - Where AI Breaks the Coverage Model
The five pillars cover every class of enterprise asset that existed in 2023. AI introduced asset classes and behavioral patterns that do not cleanly map to any of them.
Non-human identities with autonomous decision scope. The Identity pillar governs authentication - verifying credentials, enforcing MFA, managing access expiration. It does not govern the capability scope of an authenticated agent: whether the agent's decision to invoke a payment API, write to a production database, or send an email on behalf of an executive is within its authorized operational boundary. Authentication and capability-scope authorization are distinct concerns. The Identity pillar handles the first. Nothing in ZTMM 2.0 handles the second.
AI models as unowned enterprise assets. AI models have a full lifecycle - model versions, training data provenance, safety evaluation gates before promotion, AI-specific software bill of materials, and a deprecation process when a model is retired or compromised. They are not devices (no hardware), not applications in the traditional sense, not data assets (not passive information). ISO/IEC 42001:2023 defines model lifecycle governance as a distinct discipline. No existing ZTMM pillar owns it.
AI regulatory compliance as a unified domain. ISO 42001, NIST AI RMF, EU AI Act, and OMB M-24-10 require integrated, auditable governance documentation for AI systems - spanning model risk classification, impact assessments, training data integrity, behavioral monitoring, and incident response. Distributed across five pillar teams, this evidence will be fragmented and will not hold up to regulatory scrutiny.
Shadow AI across all five telemetry streams. Because no pillar owns AI application governance end-to-end, shadow AI - the AI tools your employees are already using without IT approval - is simultaneously invisible to all five pillar telemetry streams. This is the operational consequence of the above gaps. No single team has the clear accountability to find it, classify it, and enforce policy on it.
The Hybrid Architecture: Extend Five, Add One for AI
The right response is not to redesign ZTMM. It is a hybrid: keep AI controls that map naturally to existing pillars where they belong, and create a 6th AI Pillar to own what genuinely belongs nowhere else.
The 6th AI Pillar is a governance construct, a defined ownership boundary with a maturity progression and an integration model. It produces policies, governance artifacts, and threat intelligence that the five existing pillars consume and enforce.
What stays in the existing five pillars:
- Identity: AI agent service account governance; NHI least-privilege; PAM for agent credentials; conditional access for AI agent auth events
- Devices: AI inference servers in device compliance; AI endpoint tool governance; GPU, NPU infrastructure posture management
- Networks: AI API domain categorization; TLS inspection for AI traffic; AI payload DLP; AI-specific IOC feeds
- Applications & Workloads: Shadow AI discovery and governance tiers; prompt injection detection in custom apps; AI workload segmentation
- Data: AI training data classification; AI API upload DLP; RAG retrieval access controls; AI output DLP
What the 6th AI Pillar owns - and why it cannot live in an existing pillar:
This table breaks down the core elements of the proposed 6th AI Pillar, defining the domain, governance scope, and justification for why these elements require dedicated AI-specific ownership.
| Element | What It Governs | Why It Needs the 6th Pillar |
| AI Identity & | • Agent registry and capability scopes • Tool authorization chains • Human-in-the-loop checkpoints | • Identity pillar governs authentication, not authorization scope for autonomous decision chains |
| Model Lifecycle | • Model registry; versioning; deprecation • Safety evaluation gates • AI SBOM and supply chain integrity | • No existing pillar owns AI models as managed assets with full lifecycle controls |
| AI Data Governance | • Training data provenance and lineage • RAG access control at retrieval layer • AI output audit logging | • Data pillar covers DLP; not designed to govern AI-specific data lineage or training data integrity |
| AI Behavior | • Agent behavior baselining • AI-specific attack pattern detection • IR for rogue agents; circuit breakers | • AI systems exhibit non-deterministic behavior that standard SIEM rules are not built to detect |
| Regulatory | • AI risk tiering and classification for models/agents; risk tolerance thresholds fed into policy • AI risk tolerance documentation • Audit evidence production | • Risk classification must happen at the model/agent level, closest to the asset - Governance owns the resulting audit trail and certification |
Cross-Cutting Capabilities Extended for AI
The three cross-cutting capabilities apply to the 6th AI Pillar exactly as they apply to the existing five but AI demands specific extensions to each.
Visibility & Analytics - See What AI Is Doing
Standard SIEM telemetry was built for human-initiated events. AI agent behavior such as tool calls, multi-step decision chains, inference API interactions, are higher in volume and categorically different in pattern.
This table maps the maturity progression for the Visibility & Analytics capability specifically as it pertains to AI and Agentic behaviors and telemetry.
| Level | AI Visibility Capability |
| Initial | • AI application usage logs centralized • AI API call logging active for sanctioned providers • Basic AI asset usage dashboard |
| Advanced | • Behavioral baseline per AI agent • Anomaly detection for prompt injection chains, unusual data volumes, model extraction probe signatures • AI telemetry correlated with identity and data events in SIEM |
| Optimal | • Real-time AI risk scoring fed into ZT policy engine • AI behavioral signals trigger conditional access changes • Full auditability of AI agent decision paths |
Automation & Orchestration - Enforce at Machine Speed
AI agents operate at machine speed. Human-in-the-loop governance cannot scale to cover every agent action. The answer is policy-driven automation for the normal path, with human judgment reserved for edge cases.
This table outlines the maturity model for AI-specific automation, focusing on policy-driven agent authorization and model lifecycle management.
| Level | AI Automation Capability |
| Initial | • AI service account provisioning automated with IaC • Basic response playbooks for AI alerts (shadow AI discovery, NHI over-privilege detection) |
| Advanced | • Policy-as-code for AI agent authorization • Model promotion gates in CI/CD (safety scan, SBOM generation, compliance check before production) • Automated agent suspension on policy violation |
| Optimal | • Anomalies trigger autonomous investigation and response • Compliance evidence generated continuously • Model deprecation automated on policy triggers |
Governance - Give AI Risk a Permanent Home
Without explicit governance, AI security is a project. With it, it is a program. The regulatory timeline is not abstract - EU AI Act compliance for high-risk AI systems phases in from 2026.
This table defines the maturity levels for AI governance, tracking the progression from basic acceptable use policies to fully automated compliance and continuous risk posture management.
| Level | AI Governance Capability |
| Initial | • AI risk owner designated • AI acceptable use policy published • AI impact assessment process for new AI systems • AI asset register maintained |
| Advanced | • Formal AI governance program established • ISO 42001 / NIST AI RMF gap assessment complete • AI policy board established • AI vendor risk assessment process |
| Optimal | • AI governance embedded in enterprise GRC • Automated compliance evidence generation • CSA STAR for AI certification • Continuous AI risk posture dashboard |
A Practitioner's Implementation Roadmap
Phase 1 - Define: Know Your AI Estate (Months 1–3)
- Enable AI application discovery to identify shadow software and determine which systems require policy governance. Expect to find many distinct AI apps; 15–25% will need immediate governance action.
- Filter your IAM platform for AI agent NHI accounts. Most will have broader permissions than their specific use case requires.
- Build a model registry: name, version, owner, deployment environment, training data classification, risk tier.
- Assess your regulatory exposure. Identify AI systems qualifying as high-risk under the EU AI Act - they have the shortest compliance runway.
Phase 2 - Strategize: Set Priorities, Establish Ownership (Months 2–4)
Designate an AI Risk owner before deploying any controls. Without it, AI security remains a coordination problem. Sequence controls by the risk tier of your asset inventory, not by pillar. Add the 6th AI Pillar explicitly to your ZTMM documentation to prevent the accountability vacuum where five teams each assume another owns a given concern.
Establish a RACI matrix (Responsible, Accountable, Consulted, Informed) for the handoffs between the Policy Authority and the Enforcement Points. The 6th Pillar defines the policy; the Enforcement Pillars (Identity/Data/etc.) own the uptime and efficacy of the control implementation.
Phase 3 - Implement: Risk-Ordered (Months 4–18)
- Months 1–6: Shadow AI discovery and enforcement (CASB policy activation); NHI audit and over-privilege remediation; AI API upload DLP; model registry populated
- Months 6–12: TLS inspection and AI payload DLP; agent authorization policies deployed; AI-specific SIEM detections; ISO 42001/NIST AI RMF gap assessment
- Months 12–18: Agentic authorization framework fully operational; AI SBOM for all production models; CSA STAR for AI Level 1 self-assessment; EU AI Act documentation for high-risk systems
Phase 4 - Measure: AI Maturity Scorecard
Score quarterly alongside your existing ZTMM assessment cycle.
This scorecard provides a quantifiable way to measure your organization's AI security maturity across eight domains, helping to identify gaps and track progress over time.
| Domain | Traditional (0) | Initial (1) | Advanced (2) | Optimal (3) |
| AI Asset Visibility | • No AI inventory | • Inventory exists; reviewed quarterly | • Real-time discovery; risk-tiered • Integrated with CMDB | • Continuous auto-discovery • New assets surfaced within 24h |
| NHI & Agent Identity | • No AI agent governance | • Service accounts audited • Least-privilege applied | • PAM for AI credentials • Capability-scoped permissions | • Zero standing AI privileges • Continuous NHI risk scoring |
| Shadow AI Governance | • AI apps invisible | • Discovery active • Usage data collected | • Tiered enforcement active • DLP on AI uploads | • Real-time app risk scoring • Automated policy response |
| AI Data Protection | • No AI DLP | • Classification extended to AI data • Basic upload DLP | • AI output DLP active • RAG access controls at retrieval layer | • Continuous data lineage • Training data provenance • AI output audit trail |
| Model Lifecycle | • No model registry | • Registry with name/version/owner/risk tier | • Safety gates in AI CI/CD • AI SBOM for production models | • Automated deprecation • Continuous model integrity monitoring |
| Agentic Authorization | • No agent policy | • Auth policy documented • Reviewed annually | • Tool permission authorization enforced • Human-in-the-loop checkpoints | • Dynamic capability adjustment • Circuit breakers operational |
| AI Regulatory Compliance | • No compliance program | • AUP published; risk owner designated • Impact assessment process exists | • ISO 42001/NIST AI RMF gap assessment done • Remediation underway | • Automated compliance evidence • CSA STAR for AI certified |
| AI Behavioral Monitoring | • No AI monitoring | • AI traffic and agent action logs centralized | • AI-specific SIEM detections active • Behavioral anomaly alerting | • Real-time AI risk scoring in ZT policy engine • Autonomous response |
Final View: ZTMM 2.0 with AI Coverage (Including 6th AI Pillar)
The unified reference table below shows original ZTMM 2.0 controls alongside AI additions for each pillar at all four maturity levels, plus the 6th AI Pillar and extended cross-cutting capabilities.
ZTMM 2.0 + AI Coverage - Unified Reference (All Four Maturity Levels)
This comprehensive table integrates original ZTMM 2.0 baseline controls with proposed AI-specific enhancements for each pillar, plus the 6th AI Pillar and extended capabilities across all maturity levels.
| Pillar | Traditional | Initial | Advanced | Optimal |
| Identity | Original: • Static passwords; siloed on-prem identity stores • Permanent access grants; periodic reviews only AI additions: • No NHI/AI agent governance in place • AI agent accounts exist but untracked | Original: • MFA deployed more broadly • Combined identity stores; basic cloud integration • Access expiration with automated review AI additions: • AI agent NHI audit and inventory • Least-privilege applied to AI service accounts | Original: • Phishing-resistant MFA (FIDO2/WebAuthn/PIV) • Identity store consolidation • Session-based access tailored to specific actions AI additions: • PAM integration for AI agent credentials • Capability-scoped agent permissions • JIT access for AI agents | Original: • Continuous validation with real-time behavioral insights • Fully integrated identity stores across partners/environments • JIT/JEA dynamically tailored to individual actions AI additions: • Continuous NHI risk scoring • Automated over-privilege remediation • Full agent session logging |
| Devices | Original: • Manual device tracking; limited compliance visibility • No device criteria for resource access decisions AI additions: • AI inference servers and GPU nodes untracked • No AI tool governance on endpoints | Original: • Track physical and some virtual assets • Basic compliance checks (often self-reported) • Automated threat protection deployment begins AI additions: • AI tools included in software inventory • AI inference servers added to device compliance | Original: • Verified device health insights on initial access • Automated compliance for most devices and VMs • Centralized threat protection; supply chain risk assessments AI additions: • GPU server configuration baselines • AI endpoint tool governance policy | Original: • Continuous verification throughout lifecycle • Fully integrated device/software/config/vulnerability management • Automated supply chain risk management AI additions: • Real-time AI hardware posture monitoring • Model weight integrity monitoring |
| Networks | Original: • Large perimeter or macro-segmentation; minimal internal restrictions • Minimal traffic encryption; ad-hoc key management AI additions: • AI API traffic uncategorized and unmonitored • No visibility into sanctioned vs. unsanctioned AI endpoints | Original: • Begin isolating critical workloads • Service-specific interconnections; formalized key management • More traffic encrypted; basic application profiles AI additions: • AI API domains categorized • AI traffic logged for sanctioned providers | Original: • Ingress/egress micro-perimeters; service-specific interconnections • Most traffic encrypted; key rotation; cryptographic agility starting AI additions: • TLS inspection for AI API traffic • AI payload DLP • AI-specific IOC feeds | Original: • Extensive micro-segmentation on dynamic application profiles • JIT/JEA connectivity; full cryptographic agility • Infrastructure-as-code with automated change management AI additions: • Automated prompt injection blocking • AI API rate limiting • Behavioral anomaly detection on AI traffic |
| Applications | Original: • Access via local authorization and static attributes • Minimal threat protections; apps confined to private networks AI additions: • Shadow AI in use; no discovery or governance • No AI acceptable use policy | Original: • Contextual access (identity/device) with expiration • Threat protections in mission-critical workflows • Some apps via brokered public connections; CI/CD with basic privilege controls AI additions: • Shadow AI discovery active (CASB) • AI acceptable use policy published | Original: • Automated access decisions with expanded context and least privilege • Threat protections in all workflows • Distinct DevSecOps teams; developers removed from production AI additions: • AI app governance tiers enforced • Prompt injection detection in custom apps • AI workload segmentation | Original: • Continuous authorization with real-time risk analytics • Content-aware threat protections in all workflows • Immutable workloads; automated deployment with no admin access AI additions: • Continuous shadow AI monitoring • Automated AI app risk scoring • AI output filtering |
| Data | Original: • Manual data inventory and categorization • Static access controls; minimal encryption; ad-hoc key management AI additions: • AI training and RAG data unclassified • No controls on AI API data uploads | Original: • Automated data inventory (on-prem and cloud) • Basic DLP; data categorization with defined labels • Automated access controls with least privilege; encryption for data in transit and at rest AI additions: • AI training/RAG data assets classified • AI API upload DLP active | Original: • Automated tiered categorization with regular review • DLP based on static attributes and labels • Time-limited access controls; broad encryption with cryptographic agility AI additions: • AI output DLP • RAG access controls at retrieval layer • AI data inventory in DSPM | Original: • Continuous inventory; dynamic DLP blocking suspected exfiltration • JIT/JEA data access with continuous review • Encryption including data-in-use; unified dynamic data lifecycle policies AI additions: • Continuous AI data lineage tracking • Automated training data classification • AI output audit trail |
| 6th: AI & Autonomous System (new) | • AI models unregistered; no lifecycle controls • No AI risk ownership | • AI asset inventory complete • Model registry live (name/version/owner/risk tier) • AI agent authorization policy documented | • Agent authorization framework deployed • AI SBOM for production models • Safety evaluation gates in AI CI/CD | • Real-time AI risk scoring • Automated compliance evidence • Automated model deprecation and integrity monitoring • Circuit breakers operational for rogue agents |
| V&A | Original: • Manual, limited log collection; minimal analysis AI additions: • AI traffic and agent events not logged • No AI-specific telemetry | Original: • Automation for critical functions; basic correlation AI additions: • AI app and agent action logs centralized • AI API call logging active for sanctioned providers | Original: • Enterprise-wide automated collection including virtual environments; centralized multi-source correlation AI additions: • AI-specific SIEM detection rules • Behavioral anomaly alerting for AI agents | Original: • Comprehensive dynamic monitoring; advanced behavioral and predictive analytics; continuous security posture assessment AI additions: • Real-time AI risk scoring in ZT policy engine • Full auditability of AI agent decision paths |
| A&O | Original: • Static, manual processes; limited automation AI additions: • AI provisioning fully manual • No automated response to AI events | Original: • Automation supporting critical mission functions; basic response activities AI additions: • AI service account provisioning automated with IaC • Response playbooks for shadow AI and NHI alerts | Original: • Enterprise-wide automation of orchestration and response; contextual info from multiple sources AI additions: • Policy-as-code for AI agent authorization • Model promotion gates in CI/CD | Original: • Dynamically adapt to changing requirements; infrastructure as code; fully automated security workflows AI additions: • Automated model deprecation • Autonomous response to AI behavioral anomalies |
| Governance | Original: • Ad-hoc policies; manually enforced or via static technical mechanisms AI additions: • No AI risk owner • No AI acceptable use policy in place | Original: • Enterprise-wide policies defined and implemented; minimal automation; manual updates AI additions: • AI risk owner designated • AI acceptable use policy (AUP) published • AI impact assessment process for new AI systems | Original: • Tiered, tailored enterprise-wide policies; automation for enforcement; contextual info in access policy decisions AI additions: • ISO 42001/NIST AI RMF gap assessment • AI policy board established • AI vendor risk assessment process in place | Original: • Dynamic enterprise-wide policies fully automated; tailored local controls; continuous enforcement and updates AI additions: • Automated AI compliance evidence generation in place • CSA STAR for AI certification achieved • Continuous AI risk posture dashboard |
Industry Alignment
This is not a theoretical construct. The 6th AI Pillar model is where the industry has independently converged:
- Microsoft ZT4AI (March 2026): Explicit 6th AI Pillar added to ZTMM workshop materials with 700+ controls
- Cisco Zero Trust for Agentic AI (2025): Know every agent / Authorize every action / Adapt to risk - maps directly to the 6th Pillar structure
- CSA Agentic Trust Framework (February 2026): Five ZT questions applied to every AI agent - vendor-neutral implementation of the agent authorization element
- CSA AI Controls Matrix v1.0 (July 2025): 243 controls across 18 domains; maps simultaneously to ISO 42001, NIST AI RMF, EU AI Act, and BSI AIC4
- CSA STAR for AI (October 2025): Level 1 self-assessment and Level 2 third-party certification - the first standardized AI governance assurance program
- NIST AI RMF 1.0 / ISO 42001:2023 / EU AI Act: All require governance structures that align to the 6th Pillar rather than the existing five
Closing Thought
Zero Trust transformations rarely fail because of technology-they fail due to ambiguous ownership. ZTMM 2.0 succeeded by codifying clear boundaries and measurable progression. AI demands that the same discipline applied to a new governance domain. The five existing pillars manage the mechanics-how AI authenticates, communicates, and accesses data. A 6th AI Pillar is required to govern the intent: what AI decides and who is accountable for those actions at scale. By formalizing this governance layer, you move AI security from an ad-hoc coordination challenge to a mature, instrumented program. Build it deliberately, integrate it into your existing controls, and ensure your Zero Trust architecture remains complete as the threat landscape evolves.
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
[13] California SB 53 (2025). https://leginfo.legislature.ca.gov
