The Policy Moment Has Arrived
On March 6, 2026, the White House released a new National Cyber Strategy — seven pages that, in unusually direct language, mandate zero-trust architecture, post-quantum cryptography, and AI-powered security across federal networks. Thirteen days later, Microsoft published a new framework explicitly extending Zero Trust principles to AI systems themselves, with a Zero Trust Assessment for AI pillar arriving in summer 2026.
Two policy signals in two weeks. The message is unambiguous: the era of treating AI as an application that sits on top of your security architecture is over. Going forward, the AI stack is the security perimeter, and it needs to be defended accordingly.
For defense contractors, this convergence is not theoretical. It arrives as CMMC 2.0 enforcement ramps up, as FedRAMP is actively revising its High baseline to account for AI components, and as DoD acquisition guidance increasingly requires contractors to demonstrate AI governance as a condition of award. The organizations that get ahead of this will have a material competitive advantage. Those that treat it as a compliance checkbox will spend 2027 in remediation.
What the Strategy Actually Says
The 2026 National Cyber Strategy builds on its 2023 predecessor but is notably more prescriptive in three areas that directly affect defense contractors operating AI systems.
Zero Trust Architecture as a Requirement, Not a Recommendation
The 2023 strategy encouraged agencies to adopt ZTA. The 2026 version requires it — with specific reference to NIST SP 800-207 and the DoD Zero Trust Strategy 2.0 as the implementation baseline. For contractors, this means your Authorized Operating Environment (AoE) is increasingly expected to reflect the seven pillars of Zero Trust: User, Device, Network, Application, Data, Visibility & Analytics, and Automation & Orchestration.
What was novel in 2023 is table stakes in 2026.
Post-Quantum Cryptography Migration
The strategy establishes a federal migration deadline of 2030 for transitioning to NIST’s post-quantum cryptographic standards (FIPS 203, 204, and 205 — the recently finalized ML-KEM, ML-DSA, and SLH-DSA algorithms). For contractors with long-lived classified systems, this is a near-term engineering problem, not a distant one. Any system with a lifecycle extending past 2030 needs a crypto agility plan today.
AI-Powered Security and AI Security
The strategy makes a distinction that matters: it calls for both AI-powered security (using AI to defend systems) and security of AI (protecting AI systems from attack). This dual framing is the critical insight. Most organizations have explored the first. Almost none have seriously addressed the second.
Why Your Zero Trust Architecture Doesn’t Cover Your AI Systems
The Zero Trust model was designed around a specific threat model: untrusted users and devices trying to access trusted resources. The foundational assertion — “never trust, always verify” — assumes that the entity requesting access is a human or a managed device with a known identity.
AI systems break this model in ways that traditional ZT frameworks were not designed to address.
The Identity Problem
A Zero Trust architecture works because every entity has an identity that can be verified, a set of permissions that can be scoped, and a set of actions that can be logged and attributed. When an AI agent requests access to a production database, who is the identity? The model? The service account the agent uses? The human who triggered the pipeline that invoked the agent?
In most current implementations, the answer is the service account — which means the AI agent inherits the broadest permissions of any human who might use that account. This is not Zero Trust. This is the opposite of Zero Trust.
The Data Problem
Traditional ZT enforces data access on a need-to-know basis using labels, classification levels, and access controls. AI models present a unique challenge: they do not access data so much as they absorb it during training. A model trained on data at one classification level effectively embeds that data in its weights. The model itself becomes a data artifact that carries the sensitivity of everything it was trained on — but most classification and data handling frameworks have no mechanism to label, track, or control a set of floating-point weights.
The Verification Problem
In a Zero Trust network, you verify identity continuously, not just at login. You check whether the device posture has changed, whether the user’s behavior is anomalous, whether the access pattern matches historical norms.
AI agents are intrinsically non-deterministic. The same agent, with the same permissions, can produce radically different outputs on different invocations. Continuous verification built on behavioral baselines fails against a system whose behavior is, by design, variable. The standard trust signals simply do not apply.
Zero Trust for the AI Stack: A Framework
Extending Zero Trust to AI systems requires addressing five layers that traditional ZT frameworks do not cover. Microsoft’s March 2026 guidance organizes these well, and the DoD’s Zero Trust Reference Architecture provides the defense-specific overlay.
Layer 1: Model Provenance and Attestation
Before a model is allowed to operate in any production environment, its origin must be verifiable and its behavior must be documented. This means:
- Signed model artifacts — Every model version is cryptographically signed, with the signature chain traceable to a known training run. Unsigned models do not deploy.
- Model cards as compliance artifacts — The training data sources, evaluation results, known failure modes, and intended use cases are documented and version-controlled alongside the model weights.
- Red-team records — Adversarial testing results are maintained as auditable records, analogous to penetration test reports for traditional systems.
The tooling for this exists. MLflow, Weights & Biases, and the emerging AI Bill of Materials (AI-BOM) specification — analogous to the Software Bill of Materials (SBOM) that is already required for DoD software contracts — provide the infrastructure. The organizational decision to require it has been the missing piece. That decision is now being made at the policy level.
Layer 2: Agent Least Privilege
If you have read our post on AI agents in the CI/CD pipeline, the principle here is consistent: AI agents must operate under the strictest application of least privilege that the task permits.
In practice, this means:
# Example: Scoped service account for an AI coding agent
# Agent can read repositories and open pull requests.
# Agent cannot merge, deploy, or access secrets.
apiVersion: v1
kind: ServiceAccount
metadata:
name: ai-coding-agent
namespace: ci-agents
annotations:
zt-policy/max-permissions: "repo:read,pr:write"
zt-policy/no-secrets-access: "true"
zt-policy/human-approval-required: "merge,deploy"
The agent’s token is scoped to the specific repository it is working on, expires after the task completes, and is automatically revoked if the agent attempts an action outside its declared scope. Every action is logged with the agent identity, timestamp, and the human principal who authorized the task.
This is not how most AI agent deployments are configured today. Most inherit a developer’s personal access token or a broad service account created years ago for a different purpose. That configuration does not survive a ZT audit — and post-2026, it will not survive a CMMC assessment either.
Layer 3: Workload and Pipeline Integrity
The CI/CD pipeline is the boundary between AI-generated artifacts and production systems. As we covered in our Policy as Code post, every security policy that governs your infrastructure should be expressed as code and enforced automatically. For AI workloads, this means adding AI-specific policy gates:
# OPA policy: AI-generated infrastructure changes require human review
package ai_pipeline
deny[msg] {
input.commit.author_type == "ai-agent"
input.change.touches_security_controls == true
not input.review.human_approved
msg := sprintf(
"AI-authored change to security controls requires human approval. Commit: %v",
[input.commit.sha]
)
}
deny[msg] {
input.commit.author_type == "ai-agent"
input.change.new_dependencies_count > 0
not input.dependencies.lockfile_updated
msg := "AI-authored commits introducing new dependencies must update the lockfile"
}
These rules encode the organization’s Zero Trust posture for AI workloads in the same way that OPA policies encode infrastructure security rules — and they live in the same Git repository, subject to the same review and audit process.
Layer 4: Data Governance for AI
This is where most organizations have the largest gap. Traditional data governance frameworks — DLP, classification labels, access controls — were designed for structured data in defined locations. AI training data and model weights are neither.
The emerging standard, being formalized in both NIST AI RMF guidance and DoD AI policy updates, treats AI data governance as a four-part requirement:
- Data lineage — Every dataset used in training or fine-tuning is tracked: where it came from, how it was processed, and what classification level applies to each source.
- Model sensitivity labeling — The model artifact itself is labeled with the highest classification level of any training data it absorbed. A model fine-tuned on CUI data is a CUI artifact, regardless of the format of its weights.
- Output filtering — Inference outputs from models trained on sensitive data are subject to the same DLP controls as direct access to that data. The model cannot be used to launder classified information into an unclassified channel.
- Post-quantum encryption — Model weights, training data, and inference logs stored long-term are encrypted using NIST-approved post-quantum algorithms on the 2030 migration timeline. Given the sensitivity of defense AI systems, this deadline is effectively earlier.
What This Means for Your CMMC Assessment
CMMC 2.0 Level 2 maps directly to NIST SP 800-171, which does not yet explicitly address AI systems. However, CMMC assessors are increasingly applying existing controls — particularly around access control (AC), audit and accountability (AU), configuration management (CM), and media protection (MP) — to AI components when they process, store, or transmit CUI.
The practical implication: if your AI system touches CUI at any point in its lifecycle — training data, inference inputs, or outputs — it is in scope for your CMMC assessment boundary. If you have not mapped your AI components into your System Security Plan (SSP), you have an undocumented gap that an assessor will find.
The organizations getting ahead of this are doing three things now:
- Adding AI components to the SSP with explicit data flows showing what CUI the AI system touches and where
- Documenting model provenance as evidence for CM controls — the model is a software component and must be in your configuration baseline
- Implementing agent least privilege as the technical implementation of AC-6 (Least Privilege) for automated system components
The Connection to What You Have Already Built
If your organization has implemented GitOps practices, you already have the audit trail infrastructure that AI Zero Trust requires. Every change to every configuration is a Git commit, attributable to an identity, reviewed through a pull request, and deployable only through your pipeline. The extension to AI workloads is not a new architecture — it is applying the existing architecture consistently to a new class of system component.
If you have implemented Policy as Code, you have the mechanism to enforce Zero Trust policies for AI automatically. The OPA policies that govern your infrastructure can be extended to govern your AI pipeline: which models are allowed, which agents have which permissions, what data flows are permitted, and what actions require human approval.
The organizations that treated GitOps and Policy as Code as foundations — not just pipeline optimizations — are the ones for whom Zero Trust for AI is an extension of existing practice. The organizations that skipped those foundations will find Zero Trust for AI much harder to retrofit.
The Bottom Line
The 2026 National Cyber Strategy does not introduce new concepts. Zero Trust, post-quantum cryptography, and AI security have all been on the roadmap for years. What the strategy does is convert that roadmap into a timeline with enforcement teeth.
For defense contractors, the window to get ahead of this is measured in months, not years. The CMMC assessment cycle means that gaps in your AI security posture that are not addressed today will surface in audits that affect your ability to hold contracts.
The good news is that the framework is clear and the tooling is mature. Model provenance, agent least privilege, pipeline integrity gates, and data lineage tracking are all implementable today with existing tools — SLSA, OPA, MLflow, Sigstore, and the post-quantum TLS libraries that have been production-ready since the NIST standards finalized in 2024.
The question is not whether your AI systems need to comply with Zero Trust principles. The White House, DoD, and your assessors have answered that question. The question is whether you build that compliance in now, on your timeline, or in response to a finding, on someone else’s.
Is your organization already incorporating AI components into your CMMC boundary and SSP? What has been the hardest control to map? Share your experience in the comments.