Multi-agent AI systems require strict AWS Cedar policies to prevent unchecked privilege escalation during automated delegation.
Software engineers deploying multi-agent AI architectures face a distinct authorisation vulnerability when autonomous agents delegate tasks through multi-hop chains. The OWASP Top 10 for Agentic Applications categorises this specific threat as ASI03: Identity & Privilege Abuse.
Without hard boundaries, an agent can execute commands beyond the scope originally authorised by the human user. Role-based access control policies fail to maintain context across automated handoffs because the acting entity switches from the human to the machine.
Addressing this requires deploying a three-layer policy model using the open-source Cedar authorisation language on Amazon Web Services. This architecture intercepts traffic, establishes absolute boundaries around each tool invocation, and halts execution before any unverified command reaches production data.
Establishing cryptographic token boundaries
Production deployments require a strict separation between identity establishment and policy evaluation.
A trusted identity provider, such as Amazon Cognito with Time-based One-Time Password multi-factor authentication, first verifies the originating user. The identity provider issues a signed JSON Web Token containing specific claims, including the user role, authentication methods, and session identifiers.
The human user passes this token and the task request to the initial AI agent. This Model Context Protocol (MCP) client embeds the originating user context directly within a metadata envelope before initiating downstream actions. Relying entirely on the identity provider ensures the system never trusts user assertions without cryptographic proof.
Security architects implement a sequential pipeline to process these requests before they reach the execution environment. The AI agent transmits the MCP request to AWS WAF, which applies filtering rules for common vulnerabilities, rate limiting, and body size constraints.
Amazon API Gateway intercepts the request next, using a Cognito authoriser to verify the token signature against public keys and reject expired credentials. Valid requests proceed to a protocol adapter Lambda function deployed within private subnets. This adapter applies Amazon Bedrock Guardrails for content filtering while mapping the verified token claims to specific Cedar context attributes, such as assigning the JSON Web Token role claim to the originating user role variable.
Preserving identity context across multiple hops relies on cryptographic signing. The protocol adapter computes an HMAC-SHA256 signature over the canonical user context using a key retrieved from AWS Secrets Manager. Downstream evaluators verify this signature to confirm the context remains untampered.
OAuth 2.0 Token Exchange further restricts the scope using the on-behalf-of pattern. When an orchestrator agent delegates a task to a downstream data-bot, it swaps the original token for a scoped alternative. This exchange limits the downstream agent to the exact scope of the delegated task rather than inheriting the full permissions of the original token. Both mechanisms operate in tandem to prevent context injection attacks during complex delegation chains.
Executing the three-layer Cedar evaluation pipeline
The enforcement mechanism resides entirely within the Cedar policy evaluator Lambda function. The function extracts the requested policies from Amazon Verified Permissions and sequentially evaluates three independent authorisation layers, halting execution on the first deny decision.
The initial layer restricts agent-to-tool invocations. The policy requires the invoking agent to possess a verified trust score, belong to the correct namespace, and operate within the production lifecycle stage. The evaluator retrieves these attributes directly from the Verified Permissions entity store rather than trusting self-reported metrics from the agent itself. An agent possessing a trust score of three can access medium-risk payment processing tools, while higher-risk data manipulation requires an elevated trust score of four.
The second layer governs agent-to-agent delegation depth and capability boundaries to contain runaway execution loops. An orchestrator agent requesting an action from a specialized data-bot must keep the delegation chain within predefined limits. The architecture enforces a hard system-wide cap of five hops, regardless of the individual agents involved in the transaction. The requested tasks must also match the exact registered capabilities of the target agent. Breaking either constraint results in an execution halt. This layer prevents an authorised initial request from cascading into unauthorised domains through unchecked machine-to-machine handoffs.
The final layer anchors the entire chain back to the originating user context against the target resource. The AI agent remains the acting principal, but the Cedar policy inspects the stored user attributes to validate the human who initiated the original request.
Invoking a high-risk tool, such as deleting database records, requires an admin role and verified multi-factor authentication. A support user initiating the same chain will receive a deny decision at this third layer, even if the agent possesses the technical capability to execute the command. A hard depth limit of two hops applies specifically to these high-risk deletions, ensuring maximum operational oversight.
A scenario testing a support-role user without multi-factor authentication requesting record deletion results in an explicit denial at the third layer. The system permits the agent-to-tool and agent-to-agent interactions, but blocks the final step due to insufficient human privileges. However, an administrative user with multi-factor authentication successfully executes the same chain. Testing the delegation depth limits reveals that even an authorised admin request fails at the second layer if the automated chain exceeds five hops.
Enforcing audit compliance and centralised governance
Platform teams maintain observability over the entire evaluation process through standardised, continuous audit events. The evaluator Lambda function emits an Open Cybersecurity Schema Framework 99001 event to Amazon CloudWatch Logs for every access decision.
Failed log emissions route directly to an Amazon Simple Queue Service dead-letter queue to guarantee no audit data loss occurs during traffic spikes. The event payload includes the request identifier, exact user identity, complete multi-hop delegation chain, per-layer decisions, and system latency metrics.
Organisations scale this pattern across multi-account environments by deploying the Cedar policy store in a central security account and using AWS Organizations service control policies to enforce centralised governance.
As multi-agent architectures scale, the risk of ASI03: Identity & Privilege Abuse during automated handoffs becomes a critical point of failure. Traditional role-based access controls simply cannot maintain authorisation context across complex machine-to-machine delegations.
By implementing a three-layer Cedar evaluation pipeline, security teams can establish the necessary cryptographic boundaries to contain execution loops and safely deploy autonomous agents in production environments.
See also: Microsoft finds costs multiply during some AI model upgrades
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.