Data access governance for AI agents needs data-level controls

At a glance

What this is: Collibra argues that modern data access governance needs finer-grained controls, masking, and policy enforcement across data platforms, not just application-level IAM.

Why it matters: For IAM, IGA, PAM, and NHI teams, this matters because governed access now spans data platforms, identity systems, and AI consumers, so access models must be faster without losing auditability.

By the numbers:

• 92% of data consumers at banks stated that the data they need is often unavailable or takes too long to be made available.

👉 Read Collibra's analysis of governed data access for AI and analytics

Context

Data access governance is the control plane for deciding who can use which data, under what conditions, and with what protections applied. The problem is that many IAM programmes still treat data access like application access, which leaves a gap between identity governance and the actual consumption layer.

As analytics and AI programmes expand, that gap becomes operational, not theoretical. Organisations need access patterns that support human users and AI agents without forcing teams back into spreadsheets, tickets, and manual enforcement that slow delivery and increase error rates.

Key questions

Q: How should security teams govern access to sensitive data across multiple platforms?

A: Security teams should define a single entitlement model that covers the data layer, not just the application layer. That means consistent rules for masking, approval, and audit across every platform, with exceptions documented centrally. If access is managed differently in each system, governance becomes fragmented and compliance evidence becomes unreliable.

Q: Why do traditional IAM tools struggle with data access governance?

A: Traditional IAM tools were designed primarily for application access, where the main decision is whether a user can sign in and reach a system. Data access requires finer control at the database, schema, table, and column level, plus masking and source-specific policy enforcement. Without those controls, teams fall back to manual workflows that do not scale.

Q: When should organisations automate data access instead of using tickets?

A: Organisations should automate access when the request is recurring, low-risk, and policy-driven, such as standard analyst access or repeat AI consumption patterns. Tickets should be reserved for exceptions, sensitive escalations, and unusual combinations of data. If routine access still needs manual handling, the governance model is too slow for the business.

Q: How do teams keep data access compliant when AI agents need fast access?

A: Teams should create explicit policy paths for AI consumers, with logging, scope limits, and approval logic that matches machine speed. The key is to avoid letting AI agents borrow human workflows by accident. If the access pattern is not designed for machine consumption, organisations will either block legitimate use or overgrant access.

How it works in practice

Why application IAM does not solve granular data access

Traditional IAM systems are good at authenticating users and granting broad application access, but they are not designed to enforce row-, column-, schema-, or database-level controls inside data platforms. That mismatch forces teams into manual approvals, duplicate views, and inconsistent policy application across Snowflake, Databricks, BigQuery, and similar environments. The control problem is not identity proofing. It is entitlement precision at the point where data is actually consumed.

Practical implication: identity teams should separate application access governance from data access enforcement and map the handoff between them.

How masking and policy enforcement change the access model

Data masking lets organisations expose the same dataset to different users while hiding sensitive fields based on policy, which reduces the need to clone views or maintain separate datasets. Policy enforcement adds consistency across sources so access rules are applied once and reflected everywhere relevant. This turns data access from a request workflow into a governed decision layer tied to identity, role, and context.

Practical implication: governance teams should define which data elements are maskable, which require full disclosure, and who owns policy exceptions.

Where AI agents complicate governed data access

AI agents raise the stakes because they often need rapid, machine-speed access to data while operating through delegated identity paths. If access governance is built around slow human ticketing cycles, AI workloads either stall or bypass controls through ad hoc exceptions. The technical risk is not only overexposure. It is uncontrolled acceleration of access decisions across data and identity systems.

Practical implication: teams should design explicit access paths for AI consumers instead of letting them inherit human approval workflows by default.

NHI Mgmt Group analysis

Data access governance is becoming an identity problem, not just a data problem. Once access decisions move from the application layer into the data layer, IAM and IGA controls have to account for finer-grained entitlements, masking, and source-level policy enforcement. That shifts governance from coarse user authorization to contextual data authorization. Practitioners should treat data access as a distinct control surface, not a side effect of application IAM.

Manual, ticket-based access workflows are now a scaling constraint. The article shows that even organisations with advanced AI maturity still hit access bottlenecks because the operating model remains human-paced. That is not merely inefficiency. It is a structural mismatch between business velocity and governance latency. Practitioners should re-evaluate where approvals, audits, and entitlements can be automated without losing accountability.

Masking is a governance control, not a convenience feature. In environments where users need the same dataset but not the same fields, masking reduces the need to duplicate views and fragment data ownership. That matters because duplicated datasets create their own governance drift over time. Practitioners should treat masking as part of the entitlement model, not an optional presentation layer.

Unified data access governance is now part of NHI and AI governance convergence. When AI agents, service identities, and human users all touch the same governed datasets, the organisation needs one policy logic across identity types. That does not mean the same access for all actors. It means one governance model that can distinguish between them without creating separate exceptions for every platform. Practitioners should align data governance with broader identity architecture rather than maintain parallel control stacks.

Policy inconsistency across platforms is where compliance risk accumulates. The article points to the operational reality of multiple data stores, identity providers, and manual interventions. In that environment, the issue is not whether policy exists. It is whether the same policy is enforced the same way everywhere. Practitioners should focus on cross-platform consistency and auditability before adding more access requests to the queue.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader view of how access, lifecycle, and governance failures compound across machine identities, see Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Data access governance is converging with identity governance. As platforms centralise access controls and masking, IAM teams will increasingly be asked to govern data entitlements as part of the same programme that handles users, service accounts, and automation. The practical signal is that access review processes need to expand beyond application entitlements and into data consumption paths, or they will miss where exposure actually happens.

With 27 days as the average time to remediate a leaked secret, per The State of Secrets in AppSec, speed alone is not enough. The more important signal is whether your organisation can prove which identities reached which data, through which policy, before the access changed. That is where auditability becomes operationally decisive.

Policy consistency across platforms will become a board-level control question. If analysts, engineers, and AI consumers are all drawing from the same governed data estate, then inconsistent rules across Snowflake, Databricks, BigQuery, and identity providers will surface as measurable risk. Teams should prepare for a world where data access governance is assessed like any other identity control domain, with evidence, exceptions, and lifecycle ownership.

For practitioners

• Map data access controls separately from application IAM Document where database, schema, table, and column decisions are made today, then identify which of those decisions are still being handled outside the identity programme. Close the gap between who authenticates to a system and who is allowed to consume the underlying data.
• Standardise masking rules for sensitive fields Define which fields must be masked by default, who can override masking, and how exceptions are approved and reviewed. Keep the rule set consistent across analytical platforms so the same data does not have different exposure depending on where it is queried.
• Replace ticket-driven provisioning for repeat access patterns Identify recurring access requests for analysts, data engineers, and AI consumers, then convert them into policy-based entitlements with audit trails. Reserve manual tickets for exceptions, not for routine access that should be governed as a standing pattern.
• Build a distinct access path for AI consumers Define how machine-initiated access is authorised, logged, and constrained so AI agents do not inherit human approval workflows by default. Make the path explicit in policy, because hidden delegation paths are where oversharing and audit gaps begin.
• Reconcile policy enforcement across data platforms Compare how access rules are applied in Snowflake, Databricks, BigQuery, and connected identity systems, then remove conflicting local exceptions. The goal is a single audit trail that shows the same entitlement logic across every source.

Key takeaways

• Traditional IAM alone does not govern data access well enough for modern analytics and AI use cases.
• Manual, ticket-based access workflows create delays, inconsistency, and governance drift across data platforms.
• Policy-based masking and centralised entitlement control are now baseline requirements for governed data consumption.

Key terms

• Data Access Governance: Data access governance is the set of policies, controls, and reviews that decide who can use data and how that use is constrained. It covers entitlement approval, masking, auditability, and cross-platform consistency so sensitive information is shared safely and in line with business and regulatory requirements.
• Column Masking: Column masking is a control that hides sensitive values in specific fields while still allowing the underlying dataset to be queried. It lets organisations share the same data model with different audiences without cloning views or exposing confidential values to users who do not need them.
• Entitlement Model: An entitlement model defines the rules for what an identity can access, at what scope, and under what conditions. In data environments, it must be precise enough to handle tables, schemas, fields, and masking rules, not just broad application permissions.
• Machine-Initiated Access: Machine-initiated access is data or system access requested and consumed by software rather than a human user. It requires explicit governance because machine speed, delegation chains, and automation can bypass the slower review patterns designed for people.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Collibra: Introducing Collibra Data Access and the case for governed access to data faster. Read the original.