Data access governance is becoming an identity problem

At a glance

What this is: This is a BigID analysis of why data access governance now spans human and non-human identities, with risk driven by identity, activity, ownership, sensitivity, and business context rather than permissions alone.

Why it matters: IAM, IGA, PAM, and data security teams need the same lens because AI agents, service accounts, APIs, and machine identities can all expand exposure to sensitive data.

Context

Data access governance is the practice of deciding not only who can reach data, but what that access means in context. The article argues that traditional permission-centric models fail once human users, service accounts, APIs, machine identities, and AI systems all touch the same sensitive information.

The governance gap is visibility without prioritisation. Teams can see entitlement lists, but they still need to know which identities are active, who owns them, what data they expose, and whether the resulting risk justifies remediation first.

For IAM and data security programmes, the problem is no longer just access administration. It is deciding which access paths materially increase exposure across hybrid environments, especially where AI workflows inherit permissions from underlying identities.

Key questions

Q: How should security teams govern AI agents that inherit authority from other identities?

A: Security teams should govern AI agents by tracking identity lineage, not just credentials. That means recording the originating identity, the delegated authority path, and the runtime context for each action. If an agent can inherit permissions from humans, services, or other agents, policy has to evaluate the full chain before access is granted or continued.

Q: Why does data access risk depend on more than permissions?

A: Permissions show what an identity could do, not whether the access is active, who owns it, what data it exposes, or how damaging misuse would be. Risk rises when the permission intersects with sensitive data, weak ownership, and unnecessary activity. Without that context, access reviews miss the exposures that matter most.

Q: Why do service accounts and machine identities matter under NIS2?

A: Service accounts and machine identities matter because they often carry the permissions that move data, trigger reports, and feed AI workflows. If those identities are over-privileged or left out of review cycles, the organisation cannot prove that access is proportionate or necessary. Under NIS2, that creates both security exposure and audit weakness.

Q: How do teams decide which access to remediate first in a data governance programme?

A: Start with access that combines sensitive data, active use, weak ownership, and broad permissions. That combination creates the highest exposure because it indicates both reach and current exploitation potential. The right sequence is to reduce the permissions that touch high-value data and are still being used.

Technical breakdown

Why permissions alone no longer explain data access risk

Permissions describe potential capability, not actual exposure. A role, group, service account, or agent may technically have access yet pose very different risk depending on whether it reaches regulated data, whether that access is used, and who owns the identity. The article’s core model combines identity, permissions, activity, data sensitivity, ownership, and business impact. That is closer to access intelligence than a classic entitlement review, because it explains why two identical permissions can create very different outcomes in practice.

Practical implication: prioritise governance decisions by data context and usage, not by entitlement counts alone.

How AI agents change data access governance

AI systems do not just consume data. They can inherit permissions, search across repositories, call APIs, trigger workflows, and modify records at machine speed. That breaks the assumption that access is static, human-paced, and easy to review through periodic certification. Once an AI workflow inherits access from users, applications, or service accounts, the access path becomes distributed across several identities and control planes. The governance challenge is therefore not merely visibility into the agent, but visibility into the inherited access chain behind it.

Practical implication: map every AI access path back to the underlying identities, permissions, and sensitive data it can reach.

What “data-aware least privilege” means in practice

Least privilege is not only about reducing access volume. It is about right-sizing access against business purpose and data sensitivity. Low-risk data and confidential or regulated data should not be governed as if they carry equal exposure. That makes ownership, activity, and data classification part of the authorisation decision, not just a downstream audit concern. In modern programmes, least privilege must be read as a control over both capability and context, especially where inherited access and non-human identities blur the original intent of a permission grant.

Practical implication: recast least privilege as a data-context decision, then remove excess access only where the exposure justifies it.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Data access governance has become an identity problem because access now travels with the identity, not just the login event. Human users, contractors, applications, service accounts, APIs, machine identities, copilots, and AI agents all inherit permissions differently, but they can converge on the same sensitive dataset. The discipline now has to govern the identity chain behind the access path, not simply the access request. Practitioners should treat access as an identity lifecycle issue tied to data exposure, ownership, and business context.

Permissions are no longer sufficient evidence of risk. A permission indicates possible action, but it does not explain whether the identity is active, whether the data is sensitive, or whether the access still serves a business purpose. This is why access intelligence is becoming central to governance programmes: it connects entitlement, usage, and data sensitivity into one decision frame. The implication is that entitlement reviews without data context will increasingly miss the highest-risk exposure.

AI makes access governance behave more like runtime control than periodic review. AI agents can inherit permissions, reach across repositories, and act at machine speed, which compresses the window in which a risky permission can be observed and remediated. That shifts the governance burden from after-the-fact certification to context-aware access decisioning. Practitioners should expect data access governance, IGA, and AI access governance to converge on the same operational question: what access is justified right now?

Continuous visibility is the new baseline for ownership, not the end state of governance. The article’s strongest contribution is the reminder that ownership, activity, and business impact are not optional enrichments; they are what turns access governance into a risk-reduction function. Without them, organisations can count permissions but cannot prioritise exposure. The practical takeaway is that governance programmes must define risk in the language of data context, not just identity inventory.

Identity blast radius: The article points to a broader governance truth: one identity can expose many data domains when permissions accumulate across cloud, SaaS, on-premises, and AI systems. That means the blast radius of a single service account or AI agent is defined less by its label and more by the sensitivity of the data it can reach. Practitioners should measure access risk by the reach and meaning of data exposure, not by the identity class alone.

From our research library:

• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: Top 10 NHI Issues

What this signals

Data-aware access governance is becoming the control plane for hybrid identity estates. Once service accounts, APIs, machine identities, and AI systems can all reach the same repositories, the old split between identity management and data security becomes operationally expensive. Security teams will need one view that connects privilege, data classification, and ownership before access reviews can drive real reduction in exposure.

Identity blast radius: The article points to a programme design shift, not just a reporting problem. The more identities inherit permissions across SaaS, cloud, and AI workflows, the more exposure has to be measured by what the identity can reach and use, not by what role it was granted at onboarding. That makes continuous enrichment of entitlement data a governance requirement, not a nice-to-have.

The practical implication for IGA and data security teams is that access governance must move closer to runtime evidence. If activity, sensitivity, and ownership are missing, remediation will continue to chase the wrong permissions while the most dangerous access remains untouched.

For practitioners

• Discover sensitive data first Classify the data that matters most before ranking access, so permissions are judged against actual exposure rather than abstract entitlement lists.
• Map identity-to-data access paths Trace how employees, service accounts, APIs, machine identities, and AI systems reach sensitive repositories, including inherited access through roles, groups, and workflows.
• Add activity context to entitlement reviews Use usage telemetry to separate active, stale, unusual, and unused access, then prioritise the identities that touch regulated or confidential data.
• Assign accountable owners for risky access Tie each high-risk permission set to a business or technical owner who can approve remediation and validate whether the access still serves a legitimate purpose.
• Treat AI access as a governed access path Document which applications, APIs, users, and machine identities give AI systems their permissions, then review those inherited entitlements as part of the same governance workflow.

Key takeaways

• Access governance is becoming a data-security problem because the same permission can be harmless or high risk depending on the data it reaches and who owns it.
• AI agents and machine identities compress the gap between privilege assignment and potential misuse, which makes inherited access and activity context more important than static entitlement lists.
• Practitioners should prioritise remediation by exposure, not by volume of permissions, and use data sensitivity, usage, and ownership to decide what to fix first.

Key terms

• Access intelligence: Access intelligence is a runtime authorization approach that combines identity, context, and policy before granting or continuing access. It reduces the value of stolen credentials by requiring the request to still look legitimate at the moment of use, not just at the moment of approval.
• Data Access Governance: Data access governance is the practice of deciding who or what should reach specific data based on sensitivity, business purpose, and observed access paths. It combines classification, entitlement analysis, and review workflows so access decisions reflect exposure, not just permission status.
• Inherited Access: Inherited access is permission a tool receives from a connected user, service account, or integration rather than from a purpose-built identity. It often hides privilege expansion because the tool appears lightweight while actually operating under broad, durable entitlements.
• Data-aware least privilege: A governance model that limits access based on both identity and the sensitivity of the data being accessed. In practice, the entitlement may be valid for one dataset but unjustified for another, so policy must evaluate context at runtime or during continuous review.

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.