Bedrock Data and AI agent governance: identity controls fall short

At a glance

What this is: This is a WorkOS analysis comparing Bedrock Data’s metadata-led approach to AI agent governance with production identity and authorization controls, and it concludes that visibility alone does not secure agent access.

Why it matters: IAM teams need to separate data governance from enforceable identity control, because AI agent programmes can look governed while still lacking real authorization boundaries, revocation, and auditability.

By the numbers:

• WorkOS provides SSO with 70+ identity providers for enterprise applications.
• Bedrock Data was backed by $10 million from Greylock Partners.
• The platform includes a Metadata Lake with over 50 metadata elements for data governance.
• Bedrock says its platform claims 100x faster scanning and 25x lower infrastructure costs.

👉 Read WorkOS's analysis of Bedrock Data and AI agent security

Context

AI agent governance fails when teams confuse data visibility with access control. Bedrock Data’s approach centres on metadata intelligence, but identity programmes still need enforceable authentication, authorization, and revocation before an agent can act safely across enterprise systems.

In practical IAM terms, this is a question of whether governance happens by advice or by enforcement. For AI agents, the distinction matters because runtime access decisions, audit trails, and session termination are identity problems, not just data catalog problems.

Key questions

Q: How should security teams govern AI agents that can access sensitive data across multiple systems?

A: Security teams should govern AI agents with enforced identity controls, not only data classification. That means binding each agent to authenticated identity, least privilege, real-time authorization, session control, and audit logs. Metadata and lineage improve visibility, but they do not stop action unless the access layer can deny the request.

Q: Why do metadata-based controls fall short for production AI agent security?

A: Metadata-based controls fall short when they depend on the agent to cooperate. They can describe sensitivity, policy, and lineage, but they cannot guarantee that a request will be blocked if the agent bypasses the guidance or interprets it incorrectly. Production security needs an external control point that can enforce denial.

Q: What breaks when AI agent governance is built only on runtime policy hints?

A: What breaks is enforceability. Runtime policy hints can inform an agent, but they do not create a binding control if the agent can ignore the hint, call another tool, or chain actions without a separate authorization decision. That leaves auditability and revocation weaker than many teams assume.

Q: Should organisations rely on data governance tools instead of IAM for AI agents?

A: No. Data governance tools help teams discover and classify sensitive information, but IAM defines who or what may access it and under what conditions. For AI agents, that includes authentication, authorization, session management, and revocation. Without those controls, the agent may know the policy and still bypass the boundary.

Technical breakdown

Metadata-only governance versus enforced authorization

A metadata-led model classifies data, tracks lineage, and exposes policy context to the agent at runtime. That can improve visibility, but it does not itself stop an agent from acting outside policy unless the agent voluntarily follows the guidance. Enforced authorization sits lower in the stack, at the point where the system decides whether a requested action is allowed. In production AI systems, that distinction determines whether governance is advisory or binding.

Practical implication: keep metadata governance separate from the policy enforcement layer that actually permits or denies agent actions.

MCP servers and agent self-governance

The Model Context Protocol lets an AI agent query external tools and data sources, which makes it useful for context retrieval and policy lookups. But once governance logic is pushed into the agent’s runtime, the security model depends on the agent choosing to ask, interpret, and obey. That is not the same as centralized authorization, because the system assumes compliant behaviour rather than guaranteeing it. This matters most when agents are composable or can chain actions across tools.

Practical implication: treat MCP-based context as a control input, not as a substitute for authoritative access checks.

Why data governance cannot replace identity governance

Data security posture management is designed to discover sensitive data, classify it, and help teams understand exposure. Identity governance answers a different question: who or what is allowed to do what, under which conditions, and with what revocation path. AI agents need both, but only identity controls can enforce session management, auditability, and access termination. Without those controls, data governance can describe the risk while leaving the execution path open.

Practical implication: map AI agent access to identity policies, not only to data classification or lineage records.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Metadata visibility is not the same thing as control. Bedrock Data’s model improves insight into where sensitive data lives and how it moves, but insight alone does not establish authority over an AI agent’s runtime actions. In identity terms, the system can know more about the data and still fail to stop the wrong access path. Practitioners should treat that as a governance boundary, not a feature gap.

Agent self-governance only works when the agent is trustworthy by design. Once the security model depends on the agent asking for guidance and then honouring it, the programme has shifted from enforcement to cooperation. That is fragile in environments with third-party agents, uncooperative integrations, or rapidly composed workflows. The implication is that production AI programmes need binding authorization, not policy suggestions.

Identity infrastructure remains the control plane for production AI. SSO, directory sync, session management, fine-grained authorization, and audit logs are not interchangeable with metadata intelligence. Bedrock-like approaches can complement governance, but they do not replace the mechanics that define access, revoke it, and prove what happened. The practitioner conclusion is simple: if the agent can act, identity must be the authority.

Runtime authorization is the named concept that separates visibility from enforcement. In this pattern, governance context is available at the moment of decision, but the decision still has to be made by an access-control layer, not by the agent itself. That distinction becomes decisive when enterprises scale AI workflows across multiple systems and identities. Teams should test every AI agent control against the question of whether it can actually deny action.

From our research:

• AI LLM hijack breach analysis shows how stolen AWS access keys can turn model access into a compromise path, according to AI LLM hijack breach.
• Our research on the Moltbook AI agent keys breach shows that 1.5 million AI agent keys were exposed in one incident.
• For teams moving from visibility to enforcement, the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs covers the provisioning, rotation, and offboarding controls that metadata alone cannot replace.

What this signals

Runtime authorization is the line enterprises will increasingly be judged on. AI programmes that can explain data sensitivity but cannot deny a risky action will struggle to defend their control model under audit or incident review. For teams building production agents, the question is no longer whether data is visible, but whether the identity layer can still stop execution when the context turns unsafe.

With 92% of organisations saying AI agent governance is critical but only 44% having implemented policies, per AI Agents: The New Attack Surface report, the market signal is clear: governance intent is outrunning control maturity. That gap will push more programmes toward enforceable identity, not advisory metadata.

Metadata confidence debt: when a programme can see more but enforce less, it accumulates a false sense of control that shows up only when an agent bypasses the intended workflow. Teams should pressure-test whether their AI controls survive a non-cooperative actor, not just a compliant one.

For practitioners

• Separate data governance from authorization enforcement Use metadata catalogs and classification for discovery, but enforce access at the identity layer where the system can approve or deny each agent action in real time.
• Require revocation paths for every AI agent identity Verify that each agent has session termination, directory-based provisioning, and auditable deprovisioning so access can be removed without relying on voluntary compliance.
• Test uncooperative-agent scenarios Validate what happens when an agent ignores governance guidance, skips the metadata query, or attempts a direct API call outside the intended workflow.
• Map AI agent access to the same control expectations as service accounts Treat the agent as a non-human identity for entitlement review, audit logging, and least-privilege scoping, while also checking whether it can compound decisions across tools.

Key takeaways

• AI agent security cannot stop at data visibility, because classification and lineage do not enforce access decisions.
• The evidence in the article points to a gap between governance intent and production-grade enforcement, especially when agents are expected to cooperate.
• Teams should anchor AI agent governance in identity, session control, and authorization if they want controls that hold under real operational pressure.

Key terms

• Metadata lake: A metadata lake is a centralized layer that collects and organizes data about enterprise data assets rather than the data content itself. In AI governance, it can improve visibility into sensitivity, lineage, access patterns, and residency, but it does not by itself enforce whether an agent may act on that information.
• Runtime authorization: Runtime authorization is the act of deciding whether a request is allowed at the moment the action is attempted. For AI agents, it matters because access must be enforced after identity is established and before the action completes, especially when the system can call tools or chain requests autonomously.
• Model Context Protocol server: An MCP server exposes context, tools, or data sources to an AI agent through a standard interface. In governance terms, it can help an agent ask for policy or sensitivity context, but the server is not automatically the enforcement point unless the access decision is made outside the agent itself.
• Fine-grained authorization: Fine-grained authorization evaluates access at a detailed level, such as specific records, actions, or workflow steps. For AI agents, that means permissioning the exact operation rather than the whole application, which is essential when the same agent can retrieve, transform, and trigger multiple downstream systems.

Deepen your knowledge

AI agent authentication and authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a production AI governance programme from an identity-first starting point, it is worth exploring.

This post draws on content published by WorkOS: Bedrock Data for AI Agent Security: Features, Pricing, and Alternatives. Read the original.