Data-Centric Access Control restricts access at the data layer rather than relying only on coarse system permissions. It uses sensitivity, task scope, and observed risk to decide what an AI agent may read, write, or propagate, which helps prevent overexposure even when identity controls appear correct.
Expanded Definition
Data-Centric Access Control is a decision model that treats the data object, not just the user or workload, as the unit of enforcement. It evaluates sensitivity, purpose, context, and sometimes live risk signals before allowing an action such as read, copy, transform, export, or share. In practice, that means the same identity may receive different outcomes depending on which record, field, document, or embedding is in scope.
This matters most in AI-enabled environments, where an agent can hold valid credentials yet still need tightly bounded access to prevent accidental propagation of secrets, personal data, or regulated content. The concept overlaps with fine-grained authorization, attribute-based access control, and information-centric security, but it is not identical to any one of them. Definitions vary across vendors when they describe it as policy at the data layer, classification-driven enforcement, or runtime context-aware control. NIST control language in NIST SP 800-53 Rev 5 Security and Privacy Controls is often used to anchor the governance requirements behind this model.
The most common misapplication is treating it as a labels-only exercise, which occurs when organisations classify data but fail to enforce policy at the point of access.
Examples and Use Cases
Implementing Data-Centric Access Control rigorously often introduces policy complexity and latency, requiring organisations to weigh precision against operational friction.
- An AI agent can read a customer support ticket but is blocked from copying payment details into a summary, because the policy permits analysis while denying propagation of sensitive fields.
- A finance workflow allows a contractor to view an invoice total but masks bank account numbers unless the request is made from an approved task context and device posture.
- A data platform permits a model to retrieve research notes for retrieval-augmented generation, while preventing export of source documents that contain personal or regulated information.
- An analyst can open a clinical record only after context checks confirm role, case assignment, and purpose, aligning with access governance expectations reflected in ISO/IEC 27001:2022 Information Security Management.
- A cloud application applies field-level redaction to API responses so an automation script receives only the minimum data needed, reducing exposure even when the service account is valid.
For environments handling cardholder data, the same approach supports tighter scoping and data minimisation expectations in PCI DSS v4.0. Where non-human identities are involved, the OWASP Non-Human Identity Top 10 is a useful companion reference because it highlights how machine credentials and excessive access amplify data-layer risk.
Why It Matters for Security Teams
Security teams need Data-Centric Access Control because identity correctness alone does not prevent data leakage. If a user, service account, or AI agent is authenticated and authorised at a coarse level, that still leaves room for oversharing through exports, prompts, logs, retrieval pipelines, and downstream automation. The control objective is to narrow what can be read or propagated based on the data itself, not just the holder of the credential. That becomes especially important where NHI sprawl, delegated access, and agentic workflows make static permission reviews unreliable.
This term also matters for governance because it connects policy, classification, and runtime enforcement. Controls from NIST SP 800-53 Rev 5 Security and Privacy Controls and implementation guidance inspired by CIS Controls v8 both support the broader discipline of limiting access to what is necessary and monitoring misuse. Organisations typically encounter the real cost of weak data-centric controls only after a sensitive dataset has been copied, summarised, or exfiltrated by an identity that still appeared legitimate, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Covers non-human identity risks that often drive data-layer overexposure. | |
| NIST CSF 2.0 | PR.AC | Access control governance supports restricting data use by context and need. |
| NIST SP 800-53 Rev 5 | AC-3 | Defines access enforcement controls that underpin data-centric authorization. |
| ISO/IEC 27001:2022 | A.5.12 | Information classification and handling rules support data-layer access decisions. |
| PCI DSS v4.0 | Req. 7 | Limits access to cardholder data to only what business processes require. |
Classify data consistently and attach handling rules that systems can enforce at runtime.
Related resources from NHI Mgmt Group
- What is the difference between encryption and access control in AWS data protection?
- 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?
- What is the difference between access control and data-flow control for agents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
