Notifications
Clear all
Topic starter
24/06/2026 7:30 pm
TL;DR: Access bottlenecks are slowing analytics and AI initiatives because traditional IAM tools were built for application access, not granular data governance, according to Collibra. The real issue is that manual, ticket-based controls cannot keep pace with governed self-service access for humans and AI agents.
NHIMG editorial — what this means for AI and NHI governance
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full announcement
Collibra's full blog post covers the operational detail this post intentionally leaves for the source:
- Preview-specific platform coverage for Snowflake, Databricks, and BigQuery access handling
- Implementation detail on the Edge connector, agent, and polling-based integration model
- Role-by-role examples showing how data governance leads, architects, and platform teams use the preview
- The product team's own explanation of how unified metadata and policy enforcement are packaged in the release
👉 Read Collibra's analysis of governed data access for AI and analytics →
Data access governance for AI agents: what IAM teams should change?
Explore further
25/06/2026 4:49 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Data access governance for AI agents needs data-level controls
