What Is Data Access Governance?

A company can know that a dataset exists and still not really know who can use it. Knowing where data lives is a different problem from knowing every identity with access to it, why that access exists, whether it's still required, which applications can retrieve it, which AI systems can use it, whether it can leave the organisation, and which policies should apply to it.

That gap is what data access governance addresses.

What is data access governance?

Data access governance is the discipline of understanding, managing and controlling who and what can access enterprise data, what they are permitted to do with it, and under which policies and conditions that access should be allowed.

The “who and what” here is deliberately broad. Modern enterprise data can be accessed by:

• Employees
• Contractors
• Administrators
• Service accounts
• Applications
• APIs
• Third-party services
• AI systems
• Autonomous agents

AI systems and agents are one category on that list — a genuinely important one, and a growing one — but the discipline itself is broader than AI. Most of the access an enterprise needs to understand today is still held by people, applications and services doing ordinary, non-AI work.

Data governance vs data access governance

Data governance covers the broader lifecycle of enterprise data: discovery, classification, ownership, quality, lineage, access, policy, retention and audit.

Data access governance is the part of that discipline that focuses specifically on who or what can access data, what permissions they hold, why those permissions exist, and whether that access remains appropriate. It's one pillar of the wider governance problem, not a replacement for it — a dataset can be well classified and still be governed poorly if nobody understands who can reach it.

Access is no longer just about people

Traditional access models grew up around human identity — usernames, roles, directory groups. That foundation still matters, and it isn't going away. But it was never the whole picture, and the gap between it and reality is widening. Modern enterprise data is also read, moved and acted on by services, applications, automation, APIs, analytics systems, models and AI agents.

Every actor capable of retrieving, changing, moving or exposing data needs to be understood in the access model — not just the people who log in with a username and password.

The anatomy of a data access decision

Underneath any access question — should this be allowed? — is a consistent set of things worth establishing before answering it:

This is architectural framing for what an access decision needs to be capable of evaluating — not a claim that Sentinel, or any product, currently performs every one of these actions in production today.

Identity is only the beginning

Knowing who someone is doesn't answer whether their access is appropriate. Two employees might authenticate the exact same way and legitimately need very different access — one in finance, one in product design, each with data needs the other has no reason to share. Two services might use similar credentials and still warrant very different permissions, depending on what each one actually does with the data it touches.

Answering whether access is appropriate usually needs more context than identity alone provides:

• Role
• Business purpose
• Data classification
• Requested action
• Environment
• Destination
• Risk
• Approval state

Least privilege, applied to data

Least privilege is a familiar security principle, but it becomes concrete once it's applied to specific data and specific actions rather than stated abstractly. A customer-support application, for example, may genuinely need to read customer contact details and order history to do its job. That doesn't mean it needs to export the entire customer database, or modify payment credentials, or delete customer records. Each of those is a different action, on different data, with a different risk profile — and least privilege means granting only the ones the application actually requires.

Permissions accumulate

Access tends to be granted deliberately and removed only reluctantly, if at all. Employees change roles and keep the access from the last one. Projects end, but the shared drive access they needed doesn't get revisited. Contractors leave without an offboarding step catching every system they touched. Services get replaced, but the old integration's credentials are never formally retired. Experiments become permanent fixtures nobody scoped for the long term. AI pilots get abandoned, and the data access they were given quietly outlives the pilot itself.

None of this is unusual or careless — it's just what happens when access is easy to grant and easy to forget about. It's why access review needs to be both periodic — a regular pass across existing permissions — and event-driven — triggered by role changes, offboarding, project closure or system retirement, rather than waiting for the next scheduled review.

Sensitive data requires context

Not all data warrants the same access requirements. What's appropriate for one dataset can be far too permissive for another, depending on how sensitive it is — categories like:

• Public
• Internal
• Confidential
• Personal
• Financial
• Health
• Credentials
• Commercially sensitive

(These are illustrative categories, not a universal classification standard — organisations define their own, shaped by their own data, industry and regulatory context.) The more sensitive the data, the more an access decision needs to weigh who's asking, why, and under what conditions — rather than treating every request the same way.

From static permissions to contextual control

Most access models still reduce to a binary: a given identity either has access or doesn't. That binary is easy to reason about, but it flattens a lot of real distinctions. It doesn't say anything about why the access exists, whether it's still needed, what the actor is actually allowed to do with the data once inside, or whether the current context — a risky destination, an unusual time, an atypical volume — should change the answer.

A more useful model evaluates access along several dimensions at once: who or what is asking, why, where the request is coming from or the data would go, which policy applies, and whether approval is required before it proceeds.

That's a direction, not a claim that every access decision must happen dynamically, or that Sentinel currently provides universal real-time enforcement across every system it connects to. Some access decisions are, and should remain, periodic and deliberate. The point is that the closer a governance system can get to evaluating access in context, the more it can catch than a static permissions list alone would.

Real-time visibility into data access

Static permission reports answer “who currently has access, according to the system of record.” They're slower to answer questions that matter just as much:

• Who is accessing customer data right now?
• Which applications accessed payroll data today?
• Which AI systems can retrieve personal data?
• Which external services received sensitive data?
• Which users gained access to this dataset recently?
• Which dormant permissions still exist?
• Which sensitive datasets have unusually broad access?

Actual latency and coverage here depend on which systems are actually connected and how quickly they surface activity — this isn't a promise of universal, instantaneous visibility across every system an enterprise runs. The underlying idea holds regardless of how far any particular deployment gets toward it: the closer access visibility is to actual data use, the faster organisations can understand and respond to risk. We go deeper on what that looks like across data governance more broadly in real-time data governance.

Data access and movement are connected

Permission to read a piece of data is a different thing from permission to copy it, export it, share it, send it externally, modify it or delete it. A mature access model needs to understand the action actually being taken, not just whether the underlying resource can be opened at all — an actor with legitimate read access to a dataset doesn't automatically have a legitimate reason to export the whole thing to an external destination. Where data can move, and under what permission, is closely tied to how it's accessed in the first place — a connection worth exploring further as we cover data movement and lineage in future pieces.

AI changes the access-governance problem

AI systems don't remove the access-governance problem — they add a new layer to it. AI systems and agents may retrieve large amounts of enterprise data, combine information from multiple systems, infer new information from what they retrieve, send context to external model providers, generate outputs that contain sensitive information, act through tools, and operate under service credentials rather than a named person's own login.

That extends the questions access governance already needs to answer:

• Which AI systems can access this data?
• Under whose authority?
• For what purpose?
• What can they do with it?
• Where can it go?

We cover the agent-specific side of this in more depth in AI agent security and shadow AI. Here, the point is narrower: AI is one more — increasingly significant — actor that an access model needs to account for. Data access is still the subject.

Access governance and policy enforcement

Put together, a workable access-governance process tends to follow a consistent progression, from first establishing who has access through to removing it once it's no longer justified:

What should an access record contain?

For a given grant of access, a useful record needs real structure behind it — illustrative, not an industry standard:

A practical data access governance checklist

• Inventory important data.
• Classify sensitive data.
• Identify data owners.
• Identify human access.
• Identify machine/application access.
• Identify AI access.
• Map permissions.
• Map permitted actions.
• Apply least privilege.
• Record why access exists.
• Review dormant permissions.
• Review role changes.
• Review third-party access.
• Monitor sensitive-data access.
• Understand external destinations.
• Require approval for high-risk actions.
• Maintain audit history.
• Revoke unnecessary access.
• Review continuously.

From access lists to data control

Organisations tend to move through a consistent progression as their access governance matures:

The objective isn't simply to produce a better permissions report. It's to give organisations practical control over how their data is used — the ability to move from a list of who has access to an understanding of whether they should, and the means to act on that when they shouldn't.

Where Sentinel fits

Data access governance is central to the problem Porthos Labs is exploring with Sentinel. Sentinel is being designed to help organisations understand where enterprise data lives, who and what can access it, how it is being used, and which policies apply.

The longer-term direction is to make that information easier to query and act upon — allowing authorised teams to move from discovering an access problem to reviewing, restricting or revoking access through governed workflows with appropriate approval and auditability. AI systems and agents are included because they are increasingly important actors on enterprise data, not because Sentinel is limited to AI governance.

Closing

Knowing that data exists is only the beginning. Organisations also need to know who and what can use it, whether that access is appropriate, and what they can do when it is not.

Visibility tells you who has access. Governance tells you who should. Control lets you do something about it.