Data-centric zero trust for government AI needs stronger governance

At a glance

What this is: This article argues that government AI needs data-centric zero trust, because perimeter-focused controls do not govern the data AI systems consume and act on.

Why it matters: IAM, NHI, and governance teams should treat data context and access policy as core control surfaces for AI, not as downstream security detail.

Context

The core governance gap is simple: zero trust programmes can be strong on users, devices, and networks while still being weak on the data layer that AI relies on. In government environments, that gap matters because AI is increasingly embedded in mission workflows and its outputs are only as trustworthy as the data access behind them.

Data-centric zero trust means applying access, classification, and usage controls to the information itself, not just to the session or endpoint that requests it. For practitioners, the question is no longer whether identity is authenticated at the edge, but whether the right data is visible, usable, and governable for the AI workload that needs it.

Key questions

Q: What fails when zero trust stops at devices, users, and networks for AI?

A: The model fails to govern the data layer that AI actually consumes. Authentication may still be strong, but mission risk remains if sensitive records, documents, or knowledge stores are exposed to AI systems without data-centric entitlement controls. That leaves practitioners with perimeter-shaped security that does not match AI-driven decisioning.

Q: Why do government AI programmes need data-centric access control?

A: Because AI value depends on what data it can retrieve, combine, and surface. If access decisions only cover the user or workload, they miss whether the dataset is appropriate for the mission, the sensitivity class, or the downstream decision impact. Data-centric control closes that governance gap.

Q: How can teams tell whether zero trust is actually helping against AI-driven attacks?

A: Look for continuous verification across identities, not just successful logins. If authentication is secure but privilege use, lateral movement, and cross-system access remain opaque, then zero trust is incomplete in practice and AI-assisted misuse can still blend into normal traffic.

Q: How do IAM and data security teams align on AI governance?

A: They should align around the same control objective: explainable access to sensitive data. IAM teams own entitlements and identity review, while data teams own classification and lineage, but AI risk emerges where those controls overlap. The best programmes treat access path visibility as a shared requirement.

Technical breakdown

Why perimeter-shaped zero trust breaks for AI data access

Traditional zero trust implementations often verify the user, device, and network path, then assume the data layer can be handled later. That model works poorly when AI systems need broad, dynamic access to documents, records, and knowledge stores across multiple repositories. The control problem shifts from authenticating a person or workload to governing what data an AI system can ingest, retain, and surface. In practice, data context becomes the policy input, not the by-product, because the same dataset can be low risk for one use and highly sensitive for another.

Practical implication: extend zero trust policy to data classification, usage context, and retrieval scope before AI reaches production.

How data-centric access control changes the identity model

In a data-centric model, access is not just about who or what logged in. It also depends on why the data is needed, where it resides, how sensitive it is, and whether the AI workflow is authorised to consume it at all. That pushes identity teams toward policy decisions that bind user identity, workload identity, and data entitlement together. For government programmes, the hard part is not proving that the actor is authenticated. It is proving that the actor is entitled to the specific information class that will shape an AI-generated decision or recommendation.

Practical implication: align IAM, data governance, and AI workflow approvals so entitlement decisions include the dataset itself.

Why visibility and DLP alone are not enough

The article points to visibility and posture management as enabling controls, but visibility on its own does not enforce policy. Data loss prevention can block some exfiltration paths, yet it does not fully solve overbroad access, unsafe retrieval, or model usage outside intended mission boundaries. For AI programmes, the governance requirement is tighter: teams need to know what data exists, where it lives, what it is for, and how it is being used. Without that chain of context, compliance checks become after-the-fact reporting instead of operational control.

Practical implication: use visibility tooling to drive policy enforcement, not just reporting, for AI data access and retrieval.

NHI Mgmt Group analysis

Data-centric zero trust is now the missing layer in government AI governance: device, user, and network controls do not answer the most important question, which is whether the AI system should see the data at all. The article correctly reframes the control problem around data context, because AI value comes from retrieval and correlation, not from authentication alone. Practitioners should treat data entitlement as the core trust decision, not a follow-on review.

Identity assurance without data entitlement is incomplete: verifying the actor is necessary, but it does not establish that the actor is authorised for the dataset that will shape an AI output. In government settings, that creates a governance mismatch between identity controls and mission outcomes. The implication is that IAM programmes must coordinate with data governance so access scope reflects both actor and information sensitivity.

Data visibility is a control input, not a control outcome: teams that stop at discovery and classification will improve reporting but not necessarily reduce risk. The value of visibility is in turning it into enforceable policy for retrieval, sharing, and downstream use. For AI in government, that means data posture and access governance need to operate as one control plane.

Mission AI changes the trust boundary from session to substance: the article shows that what matters is not only who connected, but what data the model was allowed to consume. That shifts governance away from perimeter logic and toward substance-based authorization, where the sensitivity and purpose of the data determine access. Practitioners should re-evaluate whether their current zero trust model actually governs mission data or only the path to it.

What this signals

Government AI programmes will keep exposing a control gap until zero trust is applied to data as rigorously as it is applied to identities and devices. The practical shift is toward entitlement decisions that follow the dataset, not just the session.

Data-centric trust boundary: this is the control model that separates authenticated access from authorised AI consumption. Practitioners should expect more convergence between IAM, data governance, and AI oversight as agencies move from perimeter enforcement to substance-based authorization.

For practitioners

• Map AI workflows to data sensitivity tiers Inventory which datasets feed each AI use case, then classify them by mission sensitivity, regulatory exposure, and operational criticality before allowing production use.
• Bind entitlement reviews to the data itself Require access approvals to cover the dataset, repository, or data domain, not just the user, workload, or endpoint requesting it.
• Turn visibility into enforcement Use data discovery and posture findings to drive actual policy actions such as access restriction, retrieval scoping, and conditional exposure.
• Re-test zero trust boundaries for AI consumption Validate whether your current zero trust design governs what AI can consume, not just who can connect, and close any gap at the data layer.

Key takeaways

• The article argues that government AI cannot be governed safely with perimeter-only zero trust because the data layer is where the real trust decision happens.
• The main evidence is structural rather than numerical: AI use is rising in federal government, while many zero trust programmes still focus on users, devices, and networks instead of the data AI consumes.
• Practitioners should align identity, data classification, and AI workflow controls so access decisions cover the dataset as well as the actor.

Key terms

• Data-centric zero trust: A zero trust model that treats the data itself as the primary control boundary. Rather than relying mainly on network location or device trust, it asks whether a subject, workload, or AI system should access specific data for a specific purpose under current policy.
• Substance-based authorization: An access model that decides based on the content, sensitivity, and intended use of the information, not just the identity of the requester. In AI environments, this means the authorization question is whether the model or workflow should consume this dataset at all.
• Data entitlement: The specific right to retrieve, use, or share a dataset under defined conditions. For AI governance, entitlement is more than a login permission because it must account for the mission purpose, the data class, and the downstream effect of exposing that information to machine processing.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.