Notifications
Clear all
Topic starter
07/06/2026 8:52 pm
TL;DR: AI agents can now reach sensitive enterprise data through governed data platforms, but policy-based controls alone do not solve agent identity, authorization, or audit gaps, according to WorkOS. The real issue is that access governance built for data platforms does not fully cover autonomous or semi-autonomous access paths.
NHIMG editorial — based on content published by WorkOS: Immuta for AI Agent Security, features, pricing, and alternatives
By the numbers:
- The company has raised over $127 million in funding and serves major enterprise customers including JB Hunt, Swedbank, Thomson Reuters, Booking.com, GM, and Roche.
Questions worth separating out
Q: How should security teams govern AI agents that access sensitive data?
A: Security teams should split the problem into three layers: agent identity, authorization, and data access.
Q: What breaks when data governance is used as a substitute for AI agent identity controls?
A: What breaks is accountability.
Q: How do security teams know if AI agent access controls are actually working?
A: Look for evidence across three signals: denied retrievals for restricted fragments, complete logs that link agent identity to each request, and no unexplained access outside intended data domains.
Practitioner guidance
- Separate agent identity from data access policy Define which controls prove the agent is authenticated, which controls constrain retrieval, and which controls audit behaviour across the application stack.
- Map retrieval boundaries at chunk level Test whether sensitive fragments remain protected when they are retrieved through RAG workflows, not just when full datasets are queried.
- Extend audit coverage beyond the data platform Capture agent requests, upstream identity, downstream tool use, and final data exposure in one audit trail.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- How Immuta's policy entitlement engine translates natural-language rules into enforcement across specific data platforms.
- How its RAG security features classify chunks and enforce access at retrieval time in Snowflake and Databricks.
- What the platform includes for unified audit, monitoring, and alerts across connected environments.
- How WorkOS positions authentication, SSO, directory sync, and fine-grained authorization as the adjacent identity layer.
👉 Read WorkOS's analysis of Immuta and AI agent data governance →
AI agent data governance: what IAM teams are missing?
Explore further
08/06/2026 8:35 am
AI agent data governance is not the same thing as agent identity governance. The article shows a common market mistake: assuming that policy enforcement inside a data platform can stand in for the full access model around an AI agent. That works for query boundary control, but not for proving who the agent is, what it can initiate, or how its privileges change over time. Practitioners should treat the data layer as necessary but incomplete.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, according to the same AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who is accountable when an AI agent surfaces restricted data?
A: Accountability should sit with the team that owns the agent identity and its delegated permissions, not only with the data platform team. If the agent can retrieve regulated content through a valid identity path, the failure spans IAM, data governance, and application ownership together.
👉 Read our full editorial: AI agent data governance exposes gaps in enterprise access control
