Uchi Uchibeke

· Security

AWS Just Dropped Its Agent Authorization Playbook: Here's What Cedar Gets Right (And Wrong)

Bedrock AgentCore puts Cedar policies outside the agent's reasoning loop. That works for one hop. Multi-agent delegation chains are still unsolved.

Three security posts from AWS, published within a week of each other. A new AI Security Framework. Bedrock AgentCore with Cedar-based policies. A detailed technical post on why they chose an open-source policy engine for agent authorization.

Amazon is building the control plane for enterprise AI agents. On one hand, this is the most serious treatment of agent authorization I've seen from a major cloud provider. On the other, if you know what to look for, the gaps are right there in the architecture.

TL;DR

  • AWS says treat the LLM as an untrusted actor, correct first principle
  • Bedrock AgentCore Gateway uses Cedar to enforce tool-call authorization outside the agent's reasoning loop
  • This handles static permission models well (user A can call tool B with params C)
  • It doesn't handle delegated authority (when Agent A acts for User B who asked Agent C to delegate)
  • If your agent ecosystem has more than one hop of delegation, Cedar alone isn't enough
  • You need agent-level identity that travels with the request. Tool-level policies alone will not carry it.

Pause for a second and think. If an agent calls a tool, who is actually asking? The user who started the session? The model that generated the plan? The orchestrator that routed the call? The answer matters because the tool's access policy needs to know whose authority to check.

AWS's answer is the AgentCore Gateway with Cedar policies. Let me show you how it works, what it gets right, and where the architecture stops short.

What AWS shipped, and why it matters

AWS AI Security Framework (May 15): A three-use-case model covering chat agents, RAG applications, and autonomous agents. Each use case builds on the previous one, and controls stack across three layers (infrastructure, identity/data, and AI application). The kicker: Phase 1 explicitly calls out "establish agentic identity and fine-grained access on day 1."

Bedrock AgentCore (May 18): A platform to build, connect, and secure agents. The key architectural component is the Gateway, a policy enforcement point that sits between the agent and every remote tool it calls.

Why AgentCore Chose Cedar (May 20): A detailed technical post explaining why AWS's own Cedar policy engine is the right tool for agent authorization. The argument: LLMs are non-deterministic, susceptible to prompt injection, and can't be trusted to enforce their own constraints. Authorization must sit outside the model's reasoning loop.

This is the right diagnosis. AWS is saying what I've been saying for months. The LLM is the untrusted actor, and you need a deterministic enforcement layer outside it.

How the Gateway works

The AgentCore Gateway intercepts every tool call before it reaches the remote API. Default behavior is deny-all. Policies selectively open the boundary by specifying which tool invocations are allowed and under what conditions.

Policies are written in natural language, which AgentCore converts to Cedar. Here's a simplified example:

permit (
    principal is AgentCore::Agent,
    action is AgentCore::ToolCall,
    resource is AgentCore::Tool
) when {
    resource.name == "get_order_status" &&
    context.requesting_user_id == resource.owner_id
};

This says: an agent can call get_order_status, but only if the requesting user owns the order. The LLM can't reason around this. The Gateway enforces it outside the agent's plan.

Cedar Analysis performs holistic checks on the policy set (detecting conflicts, redundancies, and unintended authorization outcomes). This is the same Cedar used by AWS Verified Permissions and Amazon Verified Permissions. It's battle-tested for authorization at cloud scale.

The blog's language is worth quoting:

"Treat the LLM as an untrusted actor. The insight is that the LLM can't affect the external world directly: it has to go through an orchestrator that invokes tools based on the LLM's output."

This is exactly right. And it's the first time a major cloud provider has made this architectural position explicit.

What Cedar handles well

Static authorization models. If your authorization model can be expressed as: principal X can perform action Y on resource Z when condition C, Cedar handles it. That covers most tool-call authorization in single-hop architectures (a customer service agent calling order lookup, a finance agent checking transaction status).

Default-deny by design. The Gateway blocks everything by default, then opens specific paths. This is the opposite of most agent frameworks, where tool access is all-or-nothing until you add manual checks.

Policy-as-code auditing. Cedar policies are deterministic and auditable. You version them, review them in pull requests, and enforce them at runtime. No prompt can override a Gateway policy.

Separation of concerns. Security teams own the policies, and agent developers do not. This is the governance model every enterprise needs.

Where the architecture stops short

Here's what happens when your agent ecosystem has more than one hop.

Three agents. Alice asks the travel agent to book a trip. The travel agent calls the payment agent to process billing. The payment agent calls the invoice tool. The invoice tool receives a Cedar-style policy check. The principal is "PaymentAgent." The resource is "invoice:12345." The policy says "PaymentAgent can call invoice for owned_by matching the requesting user."

But whose authority is being checked? Alice's? The travel agent's? The payment agent's?

The request arrives at the Gateway with PaymentAgent as the principal. The policy evaluates PaymentAgent's permissions. But Alice never authorized PaymentAgent directly. She authorized the travel agent, which delegated to PaymentAgent. Somewhere in that chain, authority needs to travel with the request.

This is the delegated authority problem. It's not theoretical. It's the default architecture of multi-agent systems. MCP servers, A2A protocol, LangGraph, CrewAI. Every framework that chains agents creates this pattern.

Cedar handles principal-in-context at a single hop. It knows about requesting_user_id. But when the requesting chain is three levels deep, and each level carries its own context, the policy engine needs more than a flat principal-resource pair. It needs:

  1. An identity that travels with the agent across services, untied to any one cloud account
  2. A chain of authority: who authorized what delegation, verifiable at each hop
  3. A provenance trail: which model made the plan, which orchestrator routed the call, which policy allowed it

Amazon's framework calls this "agentic identity" but doesn't ship the protocol for it. The Identity component of AgentCore handles agent-level authN (this agent exists, this agent is allowed to make calls). It doesn't propagate the originating user's authority through delegation chains.

Here's the difference:

Single hop? Cedar works. Principal = user, resource = tool, condition = user owns data. Done.

Multi-hop? Cedar needs agent-level identity with delegation context. The Gateway doesn't know that TravelAgent was acting on Alice's behalf when it called PaymentAgent, which called the invoice tool. The invoice tool gets a principal it can evaluate, without the full authority chain.

How this connects to everything I've been writing

I spent a month tracking every major AI security announcement. Anthropic's four fixes that failed four attacks. Microsoft's Agent Governance Toolkit. Cisco's DefenseClaw. Cloudflare's MCP Access Proxy. The NSA's MCP security guidance. Every single one handles single-hop authorization. None handle delegated authority across agent chains.

This is the missing layer of the OWASP Agentic Top 10. It reaches past IM-01 (Improper Input Validation) and AG-01 (Agent-to-Agent Authorization). The authority chain itself is the problem: who delegated to whom, and are those delegations valid at every step.

AWS is the first major player to acknowledge the problem architecturally. The AWS AI Security Framework says "establish agentic identity and fine-grained access on day 1." The AgentCore Gateway is the enforcement point. Cedar is the policy language.

But the protocol for propagating identity and authority through agent delegation chains: that's what's missing.

The gap is a protocol problem

The reason no vendor ships this yet is that it's not a product problem. It's a protocol problem.

You can't build delegated authority for agents inside a single cloud boundary. It has to work across providers, across frameworks, across protocols. An agent running on Bedrock calls an MCP server on Cloudflare, which calls an API on Azure, which needs to verify that Alice (the human who started the chain) is authorized.

This is the use case that drove the OAP (Open Agent Passport) specification. The idea: agents carry a signed identity that includes their authority chain, and each service in the path verifies the delegation before allowing the action. The passport encodes who the agent is, who delegated to it, what it's authorized to do, and who can revoke it.

Cedar handles the per-call authorization decision. OAP handles the identity and delegation propagation. They're complementary.

What I'd tell a builder today

If you're deploying agents on AWS, use AgentCore Gateway. Cedar policies are the right answer for single-hop tool authorization. Default-deny, policy-as-code, auditable: it's the best enforcement point in the cloud market right now.

But if your architecture chains agents (even two levels), start thinking about delegated authority now. Model the authority flow before you ship. Ask: which identity reaches the final tool? Is the originating user's authorization intact at every hop? Can you audit who delegated what to whom?

Because the attack surface doesn't care about architectural boundaries. An agent that inherits too much authority through unchecked delegation is just a long prompt injection chain waiting to happen.