Data-centric zero trust for government AI needs stronger governance

At a glance

What this is: This is a Cyera analysis of why government AI programmes need data-centric zero trust, with the key finding that perimeter-first trust models do not give AI secure real-time access to the data it depends on.

Why it matters: It matters because IAM, NHI, and human access programmes all have to govern who and what can reach sensitive data, and AI makes data access the control plane rather than a side issue.

By the numbers:

• AI use across the federal government more than doubled from 2023 to 2024.

👉 Read Cyera's analysis of data-first zero trust for secure government AI

Context

Government AI programmes are running into a familiar identity problem in a new form: access has to be decision-time accurate, not just perimeter-approved. If the system cannot determine what data exists, where it lives, and how it is used, then access control becomes guesswork and AI output inherits that uncertainty.

The article argues that zero trust in federal environments cannot stop at devices, users, and networks. For IAM teams, that shifts the control conversation toward data-centric governance, where visibility, classification, and access context determine whether AI can be trusted to operate safely.

Key questions

Q: How should security teams govern AI access to sensitive government data?

A: Security teams should govern AI access through data context, not just identity context. That means classifying the data, defining who or what may consume it, and enforcing policy at the dataset level so AI systems only reach information that matches the mission use case and sensitivity profile.

Q: Why do perimeter-based zero trust models fall short for AI programmes?

A: Perimeter-based zero trust falls short because AI risk sits in the data pipeline, not only in the device or network. AI systems can consume, combine, and reuse data continuously, so the control point has to move to what the data is, where it comes from, and how it may be used.

Q: What breaks when AI systems can access data without context-aware controls?

A: What breaks is the governance model. Teams lose the ability to explain why a system reached a dataset, to limit downstream reuse, or to prove that access matched the mission purpose. The result is broader exposure, weaker auditability, and higher risk of unintended inference.

Q: Who is accountable when AI access to government data is poorly governed?

A: Accountability sits with the programme owners who approve the access model, the identity teams that enforce entitlements, and the data owners who define sensitivity and permitted use. If those responsibilities are split, the AI programme can move faster than governance can prove control.

Technical breakdown

Data-centric zero trust and AI access control

Data-centric zero trust moves the control point from the network edge to the data itself. Instead of assuming a trusted zone, the model asks whether a user, workload, or AI system should access a specific dataset in a specific context. That depends on data discovery, classification, policy enforcement, and continuous validation. In AI workflows, the problem is sharper because models and agents can consume data at machine speed and at scale. If data context is missing, access decisions become coarse and downstream AI behaviour becomes harder to explain or constrain.

Practical implication: build policies around data sensitivity and usage context, not only around device or user trust.

Real-time access for AI systems in government

AI systems need current, authoritative access to the right data to support mission decisions. In practice, that means access must be fast enough for runtime use but still bounded by governance rules. The architectural challenge is not just entitlement management, but maintaining enough data context to decide whether a request is appropriate in the moment. This is especially important when AI is consuming multiple datasets, because the risk is often created by combination, not by a single source. Without runtime context, governance becomes static and too slow for AI operations.

Practical implication: pair data discovery with runtime policy checks so AI access decisions remain current and auditable.

Why perimeter zero trust is not enough for AI

Perimeter-oriented zero trust treats devices, users, and networks as the primary objects of control. That model still matters, but it is incomplete when the main risk sits in the data pipeline. AI changes the blast radius because the same dataset can be reused across models, prompts, automation, and downstream analytics. A data-first design forces teams to ask what the system is allowed to learn, infer, or propagate, not just what it can connect to. That is a governance shift as much as a technical one.

Practical implication: extend zero trust reviews to include data lineage, downstream reuse, and policy enforcement at the dataset level.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Data-first zero trust is now the governing model for AI-era access. The article is right to move the control discussion from perimeter objects to data context, because AI value is created at the point of use, not at the point of login. Traditional IAM can verify a subject and a session, but it does not automatically answer whether the underlying data is suitable for machine consumption. Practitioners should treat data visibility and access context as the control surface that now matters most.

Perimeter-shaped zero trust fails when the workload is the consumer. Devices, users, and networks remain relevant, but they are no longer sufficient as the primary trust boundary when AI systems can request, combine, and reuse data continuously. This is a governance gap, not just a tooling gap, because the programme assumption is still human-paced access review against stable objects. Security teams should re-evaluate which trust signals actually govern AI use cases.

Data context becomes the named concept that determines AI readiness. In this model, data context means knowing what data exists, where it lives, what it is for, and how it is used before AI touches it. Without that context, access controls degrade into broad allowance patterns that are difficult to justify or audit. The implication is that AI governance starts with classification, lineage, and policy scope, not with model tuning.

NHI and human identity programmes converge at the data layer. AI initiatives often look like a new category problem, but the practical challenge is shared: entitlements, approvals, and accountability all depend on accurate data context. Service accounts, human users, and AI-driven workloads all create risk when they can reach data whose sensitivity is not known or enforced. Practitioners should align identity governance and data governance rather than running them as parallel tracks.

Responsible AI in government is an access discipline before it is a model discipline. The strongest part of the article is its insistence that secure AI requires secure access to the right data, not merely secure model deployment. That shifts the centre of gravity to governance processes that can keep pace with mission operations. Teams that keep zero trust focused on infrastructure will miss the actual control plane AI depends on.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirming one and 26% suspecting one.
• For lifecycle governance context, see Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs for a practical view of provisioning, rotation, and offboarding.

What this signals

Data-first zero trust will become the default test for AI readiness in regulated environments. As agencies and enterprises widen AI use, the question is no longer whether access is granted, but whether the data being consumed is classified, contextual, and governable in real time. That shift makes data governance a prerequisite for identity governance, not a downstream dependency.

Runtime data context is the named concept practitioners should watch. If your programme cannot answer what a dataset is for, who may use it, and how it may be reused, then AI access decisions will be too broad for assurance and too static for operations. The governance signal to watch is whether identity and data teams are making decisions from the same control plane, supported by the NIST Cybersecurity Framework 2.0.

With more than 1 in 5 non-human identities believed to be insufficiently secured, according to our research on NHI governance maturity, AI programmes that ignore machine access patterns will compound existing control debt rather than reduce it.

For practitioners

• Map AI data dependencies before expanding access Inventory the datasets, repositories, and downstream systems each AI use case consumes, then classify them by sensitivity and mission criticality. Use that map to determine which access paths need stricter policy checks and which can remain broad.
• Move zero trust controls to the dataset level Apply policy enforcement to the data itself, including classification, usage constraints, and lineage-aware access decisions. Review whether current controls only validate devices and users, or whether they also gate the data an AI system can actually reach.
• Align IAM and data governance workflows Create a shared review process for identity entitlements, data sensitivity, and mission usage so AI access decisions are not made in separate silos. This is especially important where service accounts or automated workflows request data on behalf of applications.
• Test AI use cases against real-time access assumptions Challenge each approved AI workflow with the question of whether it still functions if the underlying data context changes mid-execution. If the answer is no, the governance model is too static for operational AI.

Key takeaways

• AI programmes in government fail fastest when data access is treated as a by-product of identity control rather than the primary control surface.
• The evidence points to a widening governance gap, with federal AI usage rising sharply while perimeter-shaped zero trust still leaves data context under-controlled.
• Practitioners should move policy, visibility, and accountability to the dataset level if they want AI to remain auditable and mission-aligned.

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.
• Runtime data context: The live information used to decide whether a data request should be allowed in the moment. It includes classification, purpose, lineage, and usage constraints, and it matters because AI systems can consume information too quickly for static approval models to stay effective.
• Mission data access: Authorised access to data that supports a government or enterprise objective. In AI programmes, mission data access must account for both who requested the data and how the system may reuse it, because downstream inference can widen exposure beyond the original request.

Deepen your knowledge

Data-centric zero trust and AI access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme for AI-driven data use, it is worth exploring.

This post draws on content published by Cyera: From Risk to Readiness, enabling secure, responsible AI in government. Read the original.