Zero Trust has become the organizing principle for a significant share of enterprise security investment over the past several years. The core idea is well-grounded: treat every connection attempt as untrusted until verified, regardless of whether it originates inside or outside a traditional network perimeter. But there is a gap in how most Zero Trust implementations handle data.
Network segmentation and identity provider policies address the question of whether a principal can reach a service. They do not, by themselves, address the question of what sensitive data that service exposes to authenticated principals and whether that access is justified. Those are related but distinct questions, and the gap between them is where a lot of actual data risk lives.
What Zero Trust gets right, and where the blind spot starts
A well-implemented Zero Trust architecture enforces least-privilege at the network and identity layers: mTLS between services, device posture checks before granting access, short-lived credentials, identity-aware proxies in front of internal applications. These controls meaningfully reduce the blast radius of credential compromise and lateral movement.
The blind spot is this: Zero Trust controls operate on the question of authentication and authorization at the service or API level. They answer "can this identity access this endpoint?" They do not automatically answer "what does this endpoint expose, what sensitivity does that data carry, and does this identity actually need access to data of that sensitivity?"
Consider a straightforward example. A data analyst has authenticated successfully through an identity provider, passes device posture checks, and presents a valid short-lived credential to connect to a Redshift cluster. Zero Trust says: allowed. But the Redshift cluster contains tables spanning three different sensitivity levels: public product data, operational metrics, and a table of customer PII including email addresses and purchase history. The analyst's job requires the operational metrics. The PII table access is a byproduct of being granted cluster-level read access at some point in the past, and nobody reviewed whether it should persist.
This is not a Zero Trust failure in the conventional sense. The identity policies worked exactly as configured. The gap is that the configured access was broader than the justified access, and nobody had visibility into that discrepancy because the connection between "who has access" and "what sensitive data does that access expose" was never made explicit.
The access graph as a data-layer construct
An access graph for data security is a representation of the relationships between identities (human users, service accounts, IAM roles) and data assets (tables, buckets, schemas, datasets), weighted by the sensitivity of the data being reached.
This is different from what an identity governance platform shows you. Identity governance shows you role assignments and group memberships. An access graph shows you which sensitive data is reachable as a consequence of those role assignments, taking into account the actual content of the data stores involved.
The distinction matters in practice. A service account with an IAM role that grants s3:GetObject on a particular bucket prefix looks like a routine infrastructure permission in identity governance. If that S3 prefix contains 200GB of customer financial records, the access graph shows the service account as a high-risk node regardless of how routine the IAM permission looks in isolation.
Building this graph requires two inputs that most security tooling keeps separate: the access policy layer (IAM, database grants, SaaS permissions) and the data classification layer (what type of data lives at each storage location). When you join these, overly permissive access becomes visible in terms of data risk rather than just policy configuration.
Where identity policies create structural access gaps
Several patterns consistently produce access graph exposure that Zero Trust network controls miss entirely.
Group-based grants and membership drift
Most organizations grant data access through group memberships: an AD group or IdP group is given database access, and users gain access by joining the group. Groups are practical for administration but create a specific risk: users join groups for legitimate reasons, and group membership is rarely reviewed once granted. Over time, the effective population of a group diverges from the intended population.
The access graph surfaces this as: identity in group X, group X has read on table Y, table Y contains PII category Z. The question for the security team is whether each member of group X actually has a current business need for table Y. Without the data classification layer, you cannot assess that risk because you do not know what group membership translates to in terms of sensitive data exposure.
Service account over-permissioning
Service accounts accumulate permissions faster than they lose them. An integration built two years ago needed broad read access to a database to do initial data validation. The integration was replaced with something narrower, but the original service account was not deprovisioned because "it might be needed." The service account persists, its credentials are somewhere in a secrets manager, and it has direct access to production tables containing financial records.
Network controls do not help here: the service account authenticates correctly and the connection is allowed. The exposure is visible only when you can see that the service account's grants touch sensitive data and that the account has not been used in activity logs for eight months.
Data warehouse roles and column-level sensitivity
Modern data warehouses support row-level and column-level security, but these controls require the security team to know which columns are sensitive before they can configure the controls. In large data warehouse environments with hundreds of tables and thousands of columns, maintaining accurate column-level sensitivity labels manually is not sustainable.
A common outcome: warehouse roles are granted at the schema or table level rather than the column level because fine-grained classification was not available. Users who need one column of a table can read all columns. The access they have is technically authorized; the access they actually need is a subset of that.
What "verify explicitly" means for data access
NIST SP 800-207 (the Zero Trust Architecture standard) frames the core principle as "verify explicitly": authenticate and authorize based on all available data points. For network and identity, "all available data points" includes device posture, user behavior, and identity attributes. For data access, the analogous principle means incorporating data sensitivity into the authorization decision.
We are not saying that every data access should require a separate sensitivity-based authorization flow. That would be operationally unworkable. The practical implementation is different: use data classification to inform which access grants require active review, and use access graph analysis to identify the grants that are carrying the most unexplained sensitive data risk.
The output of that analysis is a prioritized list: these ten service accounts have access to highly sensitive data and show no recent activity; these fifteen users have access to PII tables that their current roles don't require; these three IAM roles have wildcard grants on S3 prefixes that contain financial records. That is an actionable list that the access review process can work through systematically.
Connecting access graph to Zero Trust enforcement
The access graph is an analysis and prioritization tool, not a replacement for policy enforcement. The enforcement still happens in identity providers, database grant systems, and IAM policies. What the access graph adds is the feedback loop: after enforcement actions are taken, you can verify that the sensitive data exposure was actually reduced, not just that the policy change was applied.
This feedback loop is something that identity governance tools without data classification cannot provide. A policy change that removes a user from a group looks like a successful access reduction regardless of whether that group had any sensitive data access to begin with. When you can see the sensitive data layer, you can confirm that a remediation actually moved the access graph risk metric, not just the policy configuration metric.
Zero Trust as an architecture is sound. The gap is not in the framework but in how most implementations define the scope of "access." Network perimeter and authentication are necessary. They are not sufficient for the question of who can reach sensitive data and whether that reach is currently justified.