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.
Why data-centric access control matters in government AI programmes
Government AI systems do not fail or succeed only on who can log in. They succeed or fail on which records, repositories, prompts, search indexes, and output channels the system can reach. Data-centric access control makes access decisions around the data itself, so the programme can distinguish between lawful use, over-broad retrieval, and disclosure that would be inappropriate for the mission or the sensitivity of the information.
That matters because AI often works by combining many sources into a new answer. If the control plane stops at the user or workload boundary, it can miss the more important question: should this dataset, document class, or field be exposed to this workflow at all?
How data-centric control changes the access decision
Traditional access control asks whether an identity is allowed into a system. Data-centric control adds a second check: whether the specific data object is permitted for that purpose, context, and classification. In government settings, that distinction is essential because the same AI service may handle public material, internal drafts, protected operational records, and highly sensitive casework.
This is also why Authorisation Models Guide is useful here, it explains why role-only access is too coarse when decisions need attributes, relationships, or policy rules tied to the data being requested. The control question becomes not just "who are you?", but "what data may this workflow see, combine, and return right now?"
For government AI, that shift is especially important when retrieval is dynamic. Search, retrieval-augmented generation, summarisation, and agentic workflows can all surface data that a human requester never directly opened. Data-centric policy reduces the chance that an otherwise legitimate session becomes a route to accidental oversharing.
Why the risk is bigger in government AI than in ordinary applications
Government programmes usually operate across multiple classifications, departments, contractors, and missions. That creates a bigger blast radius if an AI system can retrieve the wrong corpus or blend restricted data with lower-sensitivity content. The control problem is not only confidentiality, it is mission integrity, because the wrong dataset can also distort advice, prioritisation, or case handling.
AI retrieval layers are particularly sensitive to privilege creep and hidden inherited access. A service account, connector, or index that is over-permissive can expose data far beyond the intended audience. The programme may appear properly governed at the user layer while the AI backend quietly broadens access.
Permission-Aware RAG Guide shows the practical version of this problem: retrieval must honour the underlying permissions of the source data, not just the permissions of the person asking the question. That same principle becomes even more important in public-sector environments where sensitivity classes and disclosure rules are stricter.
What good design looks like for government AI programmes
Good design starts with classifying data before it enters the AI path, then enforcing policy at retrieval, indexing, and output time. The control should know whether a record is public, internal, confidential, operationally sensitive, or restricted by law or mission policy, and it should preserve that context as the data moves through search, summarisation, and generation.
That often means combining data labels with policy rules, request context, and downstream auditing. If a workflow can retrieve a document, it should also be able to explain why that document was eligible, who approved the policy, and what happened to the output. In practice, the better programmes treat retrieval permissions as part of the data architecture, not as an afterthought in the AI layer.
IAM and IGA Basics helps frame the governance side, because permissions, entitlements, and access reviews still matter even when the AI is data-centric. The difference is that the review must extend to the data sources, not only the human accounts and application roles.
Risk and Threat Considerations
When government AI is not data-centric, the most common failure is silent oversharing: the model retrieves or recombines information that was never meant to be jointly exposed. That can create privacy harm, operational leakage, policy errors, and in some cases legal or national-security consequences.
Failure mechanism: A broadly entitled connector, index, or service account pulls data from a repository whose sensitivity is higher than the requesting workflow should see, then the AI surfaces or synthesises that material without a direct human open on each source record.
Impact: Sensitive records can leak into answers, summaries, prompts, logs, caches, or downstream workflows, and the programme may not detect the issue until after the data has already been redistributed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST AI RMF and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Data-centric AI access depends on enforcing permissions on the underlying data objects. |
| AC-6 — Least Privilege | Government AI connectors and service paths must be constrained to the minimum data needed. | |
| AU-2 — Event Logging | Data-centric access control needs traceability for which data sources were used and surfaced. | |
| Recommendation — Enforce access decisions at the data layer so AI retrieval cannot exceed mission-approved permissions. Limit AI retrieval and connector permissions to the minimum datasets required for the mission. Log source-data access and retrieval decisions so sensitive exposures can be reviewed and investigated. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control policy must extend to the data objects AI systems retrieve and expose. |
| A.5.12 — Classification of information | Data-centric control depends on sensitivity classes that drive AI retrieval decisions. | |
| Recommendation — Define and enforce access rules for data used by AI systems, not only for users and applications. Classify information so AI retrieval policies can respect sensitivity and mission boundaries. | ||
| NIST AI RMF | Govern, Map, Measure, and Manage | AI risk governance must cover data access paths, retrieval behaviour, and downstream exposure. |
| Recommendation — Map AI data flows and govern retrieval controls so access decisions match intended use. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | AI programmes need disciplined account and access management for data retrieval pathways. |
| Recommendation — Restrict and review access to data sources used by AI systems, especially privileged connectors. | ||
Practitioner Guidance
What to prioritise: Start with the datasets and retrieval paths that can create the largest disclosure or decision-impact blast radius, not with the model itself. If a source system mixes public and restricted records, it deserves the first control review.
What to verify: Check that access policy is enforced at the data object, field, or corpus level wherever the AI can retrieve content, and confirm that inherited permissions do not exceed the mission need. Also verify that logging captures the data source used, not only the user who asked.
Common mistake: Treating model access as the control boundary. In reality, the risky boundary is often the retrieval layer, the index, or the connector, because that is where overbroad exposure becomes possible.
Practitioner takeaway: If the AI can combine data, then access control must decide which data combinations are acceptable, or the programme will end up governing users while leaving the real exposure path open.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- What is the difference between control-plane and data-plane access in AI governance?
- What is the difference between access control and data governance in AI environments?
- Why do AI security programmes need to connect access, data, and behaviour?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org