The Challenge
Multi-agent AI systems pose a privilege escalation risk that traditional Role-Based Access Control (RBAC) can't catch. When an orchestrator agent delegates a task to a downstream agent, which then delegates to another, the authorization scope can expand beyond what the originating user authorized. The OWASP Top 10 for Agentic Applications classifies this as ASI03: Identity & Privilege Abuse.
Consider this: your finance agent can process payments. It delegates a query to your data agent, which can delete records. Without proper controls, that data agent could delete records on behalf of a finance operation, even though the originating user never authorized deletion. The finance agent's legitimate delegation becomes a vector for unauthorized action.
This isn't theoretical. Every delegation hop creates an opportunity for scope drift. By the third or fourth hop, you've lost track of what the human user actually permitted.
The Environment and Constraints
The reference implementation runs on AWS and addresses three distinct authorization layers that traditional RBAC ignores:
Layer 1 (agent-to-tool): Can this specific agent invoke this specific tool? The finance agent shouldn't touch data deletion tools, even if another agent asks it to.
Layer 2 (agent-to-agent delegation): Can this agent delegate this task to that agent? The orchestrator can delegate to the finance agent and data bot, but the finance agent can't sub-delegate to the data bot.
Layer 3 (originating user authorization): Does the human who started this chain have the role and authentication strength to authorize this action?
The architecture separates authentication from authorization. Amazon Cognito handles authentication and issues signed JWTs containing claims like role, multi-factor authentication status, and session ID. Cedar handles authorization by evaluating policies against those verified claims.
Two critical constraints shaped the design:
First, context integrity across hops. When the orchestrator delegates to the data bot, the data bot must verify that the originating user context hasn't been tampered with. The solution uses HMAC-SHA256 signatures computed over the user context (user_id, role, mfa_verified, authentication_method, session_id) using a key from AWS Secrets Manager. Every downstream evaluator verifies this signature before trusting the context.
Second, delegation scope control. The implementation uses OAuth 2.0 Token Exchange (RFC 8693) with the on-behalf-of pattern. When delegating, the orchestrator exchanges the original token for a scoped token that records who's acting on behalf of whom and limits the downstream agent to only the delegated task's scope.
The Approach Taken
The Cedar evaluator Lambda function evaluates three independent policy layers sequentially, halting on the first deny. This short-circuit behavior is crucial: if Layer 1 denies the agent-to-tool invocation, Cedar never evaluates Layers 2 or 3. You get fast denies and clear audit trails.
Layer 1 policies check agent attributes retrieved from the Verified Permissions entity store. The finance agent can invoke process_payment only when its trust score is at least 3, it belongs to the payments namespace, and it's deployed in production. These attributes aren't self-reported. The evaluator retrieves them using the agent_id as a lookup key.
The trust_level attribute uses a 1-5 scale. High-risk tools require higher trust scores. The delete_records tool requires trust_level >= 4. The query_records tool only requires trust_level >= 2. This creates a graduated authorization model where agents earn access to riskier operations.
Layer 2 policies enforce delegation limits. The orchestrator can delegate to the finance agent and data bot. The finance agent can't sub-delegate. The policy checks whether the delegation hop count stays within the hard limit of five and whether the requested tasks match the target agent's registered capabilities.
Here's the Layer 2 policy that permits orchestrator-to-finance-agent delegation:
permit (
principal == AgentAuthz::Agent::"orchestrator",
action == AgentAuthz::Action::"delegate_task",
resource == AgentAuthz::Agent::"finance-agent"
)
when {
context.delegation_hop_count < 5 &&
context.requested_tasks.isSubset(resource.registered_capabilities)
};
Layer 3 policies verify the originating user's authorization. The adapter extracts verified claims from the JWT and maps them to Cedar context attributes. The JWT role claim becomes context.originating_user.role. If the JWT amr claim includes an MFA method, context.originating_user.mfa_verified is set to true.
High-risk operations require both admin role and completed MFA. The policy for invoking delete_records checks both:
permit (
principal,
action == AgentAuthz::Action::"invoke_tool",
resource == AgentAuthz::Tool::"delete_records"
)
when {
context.originating_user.role == "admin" &&
context.originating_user.mfa_verified == true
};
Results and Metrics
The evaluator emits Open Cybersecurity Schema Framework (OCSF) 99001 audit events to CloudWatch Logs. Failed emissions fall back to an SQS dead-letter queue. CloudWatch dashboards monitor evaluation latency, deny rates, and DLQ depth.
The three-layer model creates clear failure modes. When an agent attempts an unauthorized action, the audit event shows exactly which layer denied it. Layer 1 denies mean the agent lacks sufficient trust or namespace permissions. Layer 2 denies mean the delegation chain violated hop limits or capability boundaries. Layer 3 denies mean the originating user lacks the required role or MFA.
The reference implementation uses AWS WAF in front of API Gateway, applying CommonRuleSet, SQLiRuleSet, rate limiting, and body size constraints. API Gateway's Cognito authorizer verifies JWT signatures against the user pool's public keys and rejects invalid or expired tokens before the request reaches the MCP protocol adapter.
What They Would Do Differently
The reference implementation accepts agent attributes (trust_level, namespace, lifecycle_stage) from the request payload for simplicity. Production deployments must validate these attributes against an authoritative source to prevent a compromised agent from escalating its own trust.
The current design uses a single HMAC key from Secrets Manager. High-security environments should implement key rotation and use separate keys per agent namespace.
The hard limit of five delegation hops is arbitrary. Your team needs to profile your actual agent topologies and set limits based on legitimate delegation patterns. Too restrictive and you'll block valid workflows. Too permissive and you'll allow scope creep.
Takeaways for Your Team
Separate authentication from authorization. Your identity provider establishes who the user is. Cedar evaluates what they're allowed to do. Don't conflate these concerns.
Verify context integrity at every hop. Use HMAC signatures over the originating user context. Every downstream evaluator must verify the signature before trusting role claims or MFA status.
Implement graduated trust levels. Not all agents should have equal access to tools. Use numeric trust scores and require higher scores for higher-risk operations.
Enforce delegation depth limits. Multi-hop chains create audit complexity and scope drift risk. Set hard limits based on your actual agent topologies.
Audit every authorization decision. Emit structured events that show which layer denied the request and why. You can't investigate incidents without this trail.
Don't self-report agent attributes. Retrieve trust_level, namespace, and lifecycle_stage from an authoritative entity store. A compromised agent shouldn't be able to escalate its own privileges by lying about its attributes.
The OWASP ASI03 risk is real. Your multi-agent systems need authorization controls that understand delegation chains, not just static role assignments. Cedar's policy language and AWS Verified Permissions give you the tools to build those controls. The challenge is designing the policy layers that match your actual agent topology and risk tolerance.
