[Part 3 of the Demystifying Data Governance Series]

In the previous article, we built the foundation: knowing what data we have, where it lives, how sensitive it is, and who owns it. The next question is where most governance conversations stall: who gets access to the data, and how do we ensure it stays safe?

This sounds like a security question. It is not – or at least, not entirely. The confusion between security and governance is common, and it has real consequences. This article starts by drawing a clear line, then covers the mechanics of access control, the trade-off between safety and speed, the governance gap that AI agents have opened, and how compliance becomes a byproduct rather than the goal.

Table of Contents

The Scope: Two Different Problems

The common assumption is: if the security team does its job, the data is safe. Everyone who gets through the front door can access whatever is inside. This is inaccurate, and it is worth being precise about why.

The security team’s job is perimeter defense: network access control, workstation hardening, vulnerability management, intrusion detection, and software scanning. They prevent unauthorized actors from entering the system. When they do their job well, the perimeter holds. What they do not control is what happens among people already inside — people already authorized to be in the system. Most data incidents happen inside the perimeter.

Data governance owns the interior problem.

A dataset gets shared with a team that should not have it, because the sharer did not know the dataset was classified.
A machine gets compromised. The attacker now has access to everything the account can reach.
A pipeline runs with overly broad permissions on the service accounts and dumps sensitive fields into an analytics table that everyone can query.
A deletion request cannot be completed because no one can trace where the data propagated.

None of these are perimeter failures. They are governance failures — permission scope, classification coverage, lineage gaps, and the absence of audit trails.

How Data Class Drives Protection

In the previous [article](LINK), we established classification – the process of attaching a sensitivity label to a dataset, column, or field – as the hinge between knowing the data and governing it. Here is where that hinge does its work.

A data class is a sensitivity label (or tag) attached to a dataset, a column, or a field that determines how it must be treated. The class is the unit of policy. Once the classes are established, every downstream governance decision – who can access, how it is encrypted, how long it is retained, what audit trail is required – is derived from the class rather than from a specific table.

This hierarchy matters because it makes governance decisions deterministic rather than negotiated. When a new table is created and classified as restricted, the access approach, masking requirements, and audit obligations apply immediately — without anyone having to make a case-by-case decision. When a classification changes, the control stack updates accordingly.

The Core Tradeoff: Safety vs. Speed

Every access control decision is a tradeoff between enabling work and preventing harm. The tradeoff cannot be eliminated. It can only be made deliberately. There are two philosophically different approaches that sit at opposite ends of the spectrum: Preventive and Detective.

The Preventive Approach

The preventive approach blocks access by default and requires explicit grants. Only approved users can access a dataset. New tables inherit the most restrictive applicable class until explicitly downgraded. Changes require a review step before they take effect.

The downside: preventive controls create bottlenecks when approval processes are slow, undocumented, or dependent on other persons. Teams under pressure route around preventive controls by copying data to ungoverned environments. That outcome is worse than the friction the control was trying to eliminate.

The Detective Approach

The detective approach grants access by default and monitors for anomalies. Alerts fire when usage deviates from expected patterns – unusual volume, access outside normal hours, data leaving a system it normally stays in. Investigation happens after the fact rather than before.

The downside: by the time an anomaly is detected, the data has already been accessed or shared.

Most of the time, we need both, and which approach carries more weight depends on the organization’s risk tolerance.

Evaluating the Trade-Off

Both approaches have real costs. The question is not “which approach is safer” – it is which approach has lower total cost for a given data class.

Preventive approach. Every access request is reviewed before approval. The dominant costs:

Approval overhead – time spent by the approver, time spent by the requester waiting. Measurable in hours per request.
Productivity loss – work that does not happen, or is delayed, while the request is pending. Measurable in delayed decisions, missed deadlines, or revenue impact.
Residual breach risk – preventive controls reduce but do not eliminate the probability of unauthorized access. Misconfigurations, social engineering, and approval mistakes still happen. Lower than the detective approach, but not zero.

The cost of the preventive approach can be evaluated by the following equation.

C_{\text{prev}} = N * \left( t_{\text{approval}} * w + t_{\text{delay}} * w_{\text{delay}} \right) + P_{\text{breach}}^{\text{prev}} * C_{\text{breach}}

Where:

$N$ = number of access requests in the period
$t_{\text{approval}}$ = average hours per request consumed by approval overhead (requester + approver time)
$t_{\text{delay}}$ = average delay per request before access is granted (in hours)
$w$ = hourly cost of the people involved
$w_{\text{delay}}$ = hourly cost of delayed work (often higher than $w$ — a senior analyst blocked on a query costs the business more than the analyst’s hourly rate)
$P_{\text{breach}}^{\text{prev}}$ = probability of unauthorized access under the preventive approach
$C_{\text{breach}}$ = cost of a single breach (fines, notification, remediation, reputational damage)

Detective approach. Access is granted by default; monitoring catches misuse afterward. The dominant costs:

Monitoring infrastructure – the systems, alerts, and on-call ownership required to detect anomalies. Fixed cost, scales sub-linearly with access volume.
Investigation cost – when an alert fires, someone investigates. Most alerts are false alarms, but every one consumes time.
Breach cost when detection fails or detects late – the data is already accessed by the time the alert fires. The blast radius is whatever happens between access and detection.

The cost of the detective approach can be evaluated by the following equation.

C_{\text{det}} = C_{\text{monitor}} + N_{\text{alerts}} * t_{\text{investigate}} * w + P_{\text{breach}}^{\text{det}} * C_{\text{breach}}

Where:

$C_{\text{monitor}}$ = fixed cost of monitoring infrastructure and on-call ownership per period
$N_{\text{alerts}}$ = number of alerts triggered in the period
$t_{\text{investigate}}$ = average hours per alert investigation
$P_{\text{breach}}^{\text{det}}$ = probability of unauthorized access under the detective approach (higher than $P_{\text{breach}}^{\text{prev}}$, because access happens before review)
$C_{\text{breach}}$ = cost of a single breach, same as above

The decision rule is to choose the approach with the lower total cost for the data class.

\text{Choose preventive if } C_{\text{prev}} < C_{\text{det}}

This rearranges into something more useful. The preventive approach is cheaper when:

N \cdot \left( t_{\text{approval}} \cdot w + t_{\text{delay}} \cdot w_{\text{delay}} \right) – C_{\text{monitor}} – N_{\text{alerts}} \cdot t_{\text{investigate}} \cdot w < \left( P_{\text{breach}}^{\text{det}} – P_{\text{breach}}^{\text{prev}} \right) \cdot C_{\text{breach}}

The left side is the friction premium of going preventive. The right side is the risk reduction of going preventive, valued at the breach cost.

Preventive wins when the breach cost is high enough—or the breach-probability gap is wide enough—to justify the friction premium. Detective wins when the cost of delay exceeds the breach cost. Usually, it happens when the data is low enough in sensitivity that the friction premium exceeds the marginal risk reduction.

A few things are worth mentioning about the evaluation.

Preventive or detective approaches are not mutually exclusive. We can choose either method or both, as appropriate. For example, we can use a monitor, even if the approach is preventive; the cost of a monitor is lower than that of the detective method.
It quantifies friction. Most programs treat preventive overhead as invisible because no one bills for it. The equation forces the question: how many hours per request, how many requests per period, at what hourly cost? The answer is usually larger than expected and often exceeds the monitoring cost it was meant to replace. Besides, the number indicates how much we can save by improving our approval process.
It treats breach probability as a variable, not a binary. Preventive controls do not make breach probability zero. They lower it. Detective controls do not make breach probability one. They lower it differently: preventive reduces the probability that unauthorized access occurs at all; detective reduces the time to detect once it does. Both contribute to the expected cost of the breach.
It exposes the crossover. For every data class, there is a breach cost at which the two approaches are equal. Above it, preventive wins. Below it, the detective wins. The classification system implicitly encodes this — Restricted data is on the preventive side, Internal data is on the detective side — but most organizations have never written down the math. Writing it down makes the policy defensible.

The implication: classification is not just a label. It is the input that selects which cost equation governs which dataset. Without it, the decision between preventive and detective is made by tradition or by whoever shouts loudest. With it, the decision becomes a calculation. The classification work in the previous article is what makes the math in this section operate.

Least Privilege Principle: Easy to State, Hard to Operate

The Least Privilege Principle means every principal – human or automated system – has access to exactly what they need to do their job, and nothing more. This is structurally difficult to maintain at scale.

The operational challenge has a name: role explosion. In a large organization, the number of distinct access patterns grows faster than the number of roles anyone is willing to maintain. If every team, every environment, and every data class combination requires a separate role, we end up with hundreds or thousands of roles — many unused, some incorrect, none reliably up to date.

Attribute-based access control (ABAC) is the pragmatic response. Instead of managing roles directly, access decisions are expressed as policies over attributes: the requester’s team, job function, and purpose; the data’s class and owner; the environment (production vs. staging). A policy might read: “data analysts in the finance team may read Financial-class data in production if their stated purpose is reporting.”

When a new analyst joins finance, they receive the finance team attribute. Access is granted without a separate role grant. When they leave, removing the attribute revokes the access. The maintenance burden shifts from “keep roles current” to “keep attributes current” — a smaller, more tractable problem.

Regardless of the access control mechanism, two operational disciplines determine whether least privilege is real or aspirational:

Access reviews. At a defined cadence, the dataset owner reviews every access grant. Access not used longer than a certain number of days (e.g., 90 days) is revoked unless actively re-approved. The review is not a compliance checkbox. It is the mechanism by which access drift is caught and corrected.

Offboarding automation. When someone leaves or changes teams, their access should be revoked the same day. This requires the identity system and the data access system to be connected, which they often are not. The manual alternative reliably fails.

Access and Visibility

The most fundamental access governance question: who has access to what, right now? Can we produce that list on demand?

The question may seem obvious, but most organizations cannot provide the list, at least without considerable effort. Access is distributed across cloud IAM, data warehouse roles, application-level permissions, and data-sharing agreements. No single system has a full picture.

The catalog – an inventory of every dataset with its metadata, classification, ownership, and lineage, introduced in “What Do We Have and What Does It Mean” – is where access visibility should reside. Every dataset in the catalog should carry the following information: who has access, how they got it, the stated purpose, and when the grant was last reviewed. This is not documentation for its own sake — it is the input to the access review process, and the first query an incident response team runs.

Authentication, authorization, and audit — the three A’s — each play a distinct role:

Authentication answers “who are you?” Multi-factor authentication for access to production data is a baseline. Service accounts should authenticate with short-lived credentials, not long-lived API keys that persist after the person who created them has left.

Authorization answers “what are you allowed to do?” Policies that reference data classes rather than specific tables are more durable. A policy referencing a class applies automatically to new tables in that class; a policy referencing a table must be manually updated whenever the estate changes.

Audit answers “what did you do?” An immutable audit log of all access to sensitive data is the governance primitive that enables post-incident investigation. Without it, “what happened” cannot be answered with confidence, and regulatory notification windows pass while the investigation is still incomplete.

The three are frequently treated as independent systems. In practice, they form a pipeline: authentication gates access, authorization constrains it, and audit records it. A gap in any one degrades the value of the others.

Monitoring and Audit

An audit log that nobody reads is a storage cost. Monitoring is what makes the audit log useful before an incident, not just during one.

Effective monitoring watches for:

Anomalous access patterns. Volume spikes on a sensitive table. Access outside normal working hours. A service account querying tables it has never accessed before. These signals are not definitive — each has a legitimate explanation — but they are worth routing to the dataset owner for review.

Permission drift. The gap between what access policies state and what access logs show. A user listed as read-only who appears in write operation logs is a discrepancy worth investigating, not one to be explained away.

Sensitive data leaving expected environments. Exports from production tables to personal cloud storage. Data flowing to external endpoints not listed in any sharing agreement. These detective controls do not prevent the movement, but they surface it quickly enough to act.

Encryption coverage. Sensitive data should be encrypted at rest wherever it lives — including backups, archives, and analytics copies. It should also be encrypted in transit between all services that handle it. The hard part is not encryption itself; it is key management: who holds the keys, how often they are rotated, and whether key access is audited. A table encrypted with a key accessible to several people is not meaningfully protected.

A monitoring system is only as useful as its alert routing. An alert sent to a shared inbox with no owner is indistinguishable from no alert. Every alert path must resolve to a named owner, which is why catalog ownership records are not optional. They serve as the routing table for the monitoring system.

Regulation and Compliance as a Byproduct

GDPR, CCPA, HIPAA. Most governance discussions treat regulations as the reason to build governance. They are better understood as evidence that a governance program is working.

What these regulations actually require, stripped of the legal language:

Know what personal data you hold and where it lives. → This is the “Know the Data” pillar.
Protect it with appropriate controls. → This is the “Secure the Data” pillar.
Use it only for the purposes to which the data subject consented. → This is the “Use Data Properly” pillar.
Delete it when requested, and prove you did. → This requires lineage coverage — the recorded path of every dataset from origin through transformations to consumption, as introduced in the previous article — sufficient to trace every propagation of the data, including derived tables, backups, and model training sets.
Report breaches within 72 hours. → This requires an audit trail and a blast-radius analysis tool that can answer “what was affected” in minutes, not days.

Every one of these requirements is a byproduct of a governance program functioning for operational reasons — not a compliance program built to satisfy auditors.

The practical difference is that a compliance program built to check regulatory boxes produces documentation and reports, whereas a governance program built to operate the data estate produces classification coverage, lineage graphs, access logs, and deletion workflows — all of which satisfy auditors as a side effect. The first degrades the moment auditors leave. The second persists because the organization depends on it.

Treating compliance as a floor rather than a ceiling — building governance that exceeds the minimum regulatory requirements — produces better systems and creates headroom. When regulations tighten or a new one applies, a program that already exceeds the old floor does not scramble to rebuild from scratch.

AI Agents Are Not Exempt

AI agents — systems that use language models to execute multi-step tasks by calling tools, querying data sources, and taking actions — are now present in most enterprise data environments. They appear as internal automation tools, as customer-facing assistants, and as engineering infrastructure. They have the same access control requirements as any other principal in the system. However, most governance programs treat them as an afterthought.

The governance problem with agents is structural. By default, an AI agent inherits the permissions of whoever built it or is running it. A data engineer with read access to the analytics warehouse builds an agent to automate a reporting task. The agent now has read access to the analytics warehouse. If the engineer also has access to a PII table irrelevant to the reporting task, the agent has that access too.

This is not hypothetical. It is the default behavior of every MCP server integration, every function-calling setup, and every tool-enabled LLM deployment that does not explicitly scope permissions. The agent inherits a blast radius determined by the credential under which it runs, not by the task it was built for.

The least privilege principle applies to agents exactly as it applies to humans:

Agents need their own identity. An agent should not run under a human’s credentials. It should have its own service account with permissions scoped to the specific task it performs.

Agent permissions should be task-scoped. An agent that summarizes support tickets should have read access only to the support ticket table—nothing else—not read access to the financial tables that happen to be accessible via the same warehouse role.

Agent actions should be audited. Every query an agent executes, every tool it calls, every data source it accesses should be logged with the same rigor as human access. Without this, the audit trail for agent behavior is empty. An agent that exfiltrates data leaves no trace in an ungoverned system.

Agent sessions should be time-bounded. An agent running a long-horizon task should not keep open connections to sensitive data sources for the duration of the task. Permissions should be acquired just-in-time and released after use.

RAG systems require retrieval-time access control. When an LLM retrieves from an internal knowledge base using semantic similarity, it can surface content that the querying user cannot access via a direct query — because retrieval prioritizes relevance over permissions. A user who asks “what were the Q3 financials?” receives a semantically relevant response that may draw on documents to which they do not have explicit access.

The access control layer for RAG must operate at retrieval time, not at the LLM level. Every retrieved chunk should be filtered against the querying user’s access rights before it enters the context window. This requires the retrieval system to know the data class and access policy for every document in the index, which in turn requires the catalog and classification infrastructure from Article 2 to be operational before RAG is deployed, not after.

Two Kinds of Blast Radius: Exposure and Cost Exposure

There is a second dimension of agent blast radius that most governance discussions miss entirely: cost.

Until recently, an un-scoped service account was a data risk. The worst case was that a compromised credential or a misconfigured query exposed records that should not have been exposed. The financial impact was a function of the data — fines, breach notification, and remediation. The credential itself did not generate cost; it consumed compute that was already paid for.

That assumption no longer holds. SaaS pricing has been restructuring around AI usage in two distinct patterns: AI seat surcharges layered on top of existing seats, and true consumption pricing that charges per action or outcome. Both attach a real dollar cost to AI activity:

AI seat surcharges — flat per-user fees added on top of existing seat licensing:

Microsoft Copilot charges $30 per user per month for the enterprise tier and \$18–\$21 per user per month for the business tier, on top of qualifying Microsoft 365 licenses (Microsoft pricing page, verified May 2026). This is a 40–60% increase in per-user Microsoft 365 cost depending on the base license tier.

True consumption pricing — costs that scale with actions, tokens, or outcomes:

Salesforce Agentforce launched at $2 per conversation in 2024 and added Flex Credits at \$0.10 per action in May 2025 (Salesforce press release, May 2025). A widely reported real-world scenario showed five support agents handling 70 conversations per day, each incurring roughly \$900 in daily Agentforce spend — a figure that landed badly enough with customers to prompt a pricing redesign.
Box AI uses a consumption model: AI Units are included in enterprise tiers and billable at \$10 per 1,000 AI Units beyond the included allocation (Box pricing page, verified May 2026). The transition from the original “20 credits per user” launch model to consumption-based AI Units happened in late 2025.
Intercom Fin charges $0.99 per outcome — billed only when Fin resolves a customer conversation or successfully executes a configured handoff (Intercom Fin pricing page, verified May 2026). The cleanest outcome-based example in the market.
Snowflake prices per credit consumed for compute (billed per second), plus per-terabyte storage (Snowflake docs, verified May 2026). AWS, Twilio, and OpenAI follow the same pattern — pay for what runs. Anthropic prices per million tokens for API access, with input and output billed separately (Anthropic pricing docs, verified May 2026).

The macro trend is consistent. Bain’s analysis of 30+ SaaS vendors introducing AI capabilities found that roughly 35% have simply raised per-seat prices to bundle AI in, while the remainder have moved to hybrid, consumption, or outcome-based models (Bain & Company, October 2025). Gartner predicts that by 2027, 70% of top SaaS vendors will offer consumption-based pricing for at least part of their portfolio (Gartner forecast cited in Zylo SaaS Statistics, 2026).

The governance implications differ by pricing pattern. AI seat surcharges create a fixed-budget exposure that scales with the number of deployed seats — predictable, but expensive. True consumption pricing creates a variable budget exposure that scales with agent behavior, unpredictable, and the dimension where unscoped agents do the most damage. The remainder of this section focuses on true consumption pricing, because that is where governance controls have the most leverage.

The implication for governance is direct. An agent now has two blast radius dimensions, not one:

Data blast radius — the records and systems an agent can reach if compromised or misconfigured. This is the dimension we have already covered.

Cost blast radius — the dollar amount an agent can spend if it loops, retries, fans out across tools, or gets stuck in a recursive call pattern. An unscoped agent can drain a budget just as it can leak data.

The governance discipline that prevents data exposure is the same discipline that bounds cost exposure. The controls do not differ:

Scoped identity — an agent acts under its own service account, not a human’s. Permissions are limited to the specific task. This prevents the agent from accessing data it should not touch, and from invoking SaaS actions that consume budget it does not own.
Time-bounded sessions — agent permissions are acquired just-in-time and released after use. Compromised credentials have a short useful lifespan. Stuck or recursive agents stop consuming when their session expires.
Audit trails — every action is logged: what data was accessed, what tools were called, what cost was incurred. The same audit log that supports incident investigation supports cost attribution and anomaly detection.
Anomaly monitoring — unusual volume on a sensitive dataset is a data anomaly. Unusual API call volume from one agent is a cost anomaly. Both surface in the same monitoring layer, route to the same owner, and require the same kind of investigation.

The framing matters. Treating agent governance as only a data security problem misses half the failure surface. An unscoped agent that runs up a five-figure SaaS bill over a weekend has caused a real incident — even if no sensitive data ever moved. Explicitly naming the cost dimension makes the governance controls fundable because it gives the leadership a reason to care that does not depend on a hypothetical breach.

We translate this dimension into business value in the next article.

Summary

The controls described in this article — classification-driven policies, least privilege, access reviews, audit trails, agent-scoped permissions, and retrieval-time enforcement for RAG — answer “who gets access and how do we keep it safe?” They are not a project you complete. They are a posture you maintain.

The speed-versus-safety tradeoff does not disappear. It becomes explicit and managed rather than implicit and accidental. Access decisions are made based on data class, not on a case-by-case basis. Anomalies are surfaced to owners before incidents. Agents operate with the same discipline as humans.

The next question is whether any of this survives in the long term: how do we know it is working? How do we measure it, detect drift, and translate it into terms that the people funding it recognize?

Next in the series: How Do We Know It’s Working?

Self-evaluation: Do We Really Know Our Data? — a checklist for the Secure the Data Pillar.

All external sources cited in this article were verified as of May 2026. Pricing pages and vendor documentation referenced as “verified May 2026” are evergreen pages that may have been updated since publication. Dated citations (press releases, analyst reports) reference the original publication date.

Demystifying Data Governance – Who Gets Access and How Do We Keep It Safe?