Because the same dataset may be reachable by users, service accounts, and AI agents through different control paths. If identity and access decisions are not centralised, a person can be restricted in one engine but effectively privileged in another. That turns identity governance into a cross-platform consistency problem, not just an entitlement review.
Why This Matters for Security Teams
Apache Iceberg-style sharing changes the governance problem because access is no longer limited to one application or one identity store. The same data can be exposed through catalogs, query engines, pipelines, notebooks, and AI-facing workflows, each with different enforcement points. That creates a control mismatch: a user may be denied in one layer while a service account, token, or agent still reaches the same data elsewhere.
For identity teams, the risk is not just excessive privilege. It is fragmented accountability. When access decisions are distributed across platforms, it becomes difficult to prove who can reach what, under which policy, and through which path. That complicates review, incident response, and audit evidence, especially where data access is delegated to engineering teams or embedded in automation. The NIST Cybersecurity Framework 2.0 remains useful here because it ties governance, access control, and monitoring into one operating model rather than treating them as separate tasks.
In practice, many security teams discover the mismatch only after a sharing configuration, service credential, or downstream integration has already expanded access beyond the intended identity boundary.
How It Works in Practice
Iceberg-style sharing is typically implemented through a table format, catalog, or sharing layer that exposes governed data across multiple consumers. That means entitlement decisions may sit in the identity provider, the data platform, the query engine, or the sharing service itself. If those controls are not harmonised, governance breaks down as soon as identities are translated from one system to another.
The practical issue is that identity governance must follow the data path, not just the login path. A person may authenticate through SSO, but the effective access could be granted by a warehouse role, a storage policy, an API token, or an AI agent using delegated credentials. This is why role design, token lifecycle, and policy inheritance matter as much as directory groups. NIST control families in NIST SP 800-53 Rev 5 Security and Privacy Controls are especially relevant for access enforcement, audit logging, and configuration management.
- Map every sharing path to an accountable identity type, including human, service, and agentic access.
- Centralise policy decisions where possible, then enforce them consistently across catalog, engine, and storage layers.
- Reconcile effective permissions, not just assigned roles, because cross-platform inheritance often changes the real access picture.
- Log data reads and sharing events in a way that preserves the identity, workload, and approval context.
Where this guidance tends to break down is in multi-cloud environments with custom connectors and locally managed service credentials, because policy translation and logging often diverge between systems.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance consistent access control against the speed that data teams expect from shared analytics platforms. That tradeoff becomes more visible when the same Iceberg table is consumed by BI tools, ETL jobs, and AI assistants.
Some environments use shared service identities to simplify operations, but that can obscure who actually initiated access. Others rely on fine-grained table permissions, which helps at the platform layer but still leaves gaps if export, replication, or downstream materialisation is not governed. Best practice is evolving for AI-mediated access, because there is no universal standard yet for how an AI agent should inherit, justify, or time-limit data permissions. That makes identity review more than a periodic entitlement check; it becomes a continuous validation problem.
For organisations handling regulated data, governance should also reflect revocation speed, traceability, and evidence quality. The right question is not only whether access was approved, but whether the effective path can be reconstructed after a policy change, credential rotation, or incident. In those cases, identity teams should treat sharing as a living control surface rather than a static permission set.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Shared data paths demand consistent identity and access governance across platforms. |
| NIST SP 800-53 Rev 5 | AC-3 | Enforcing least privilege across table sharing depends on access authorization controls. |
Define and enforce access rules centrally, then verify the same policy applies in every consuming system.
