When The Gateway Swaps Tokens, User Identity Stops Travelling
AWS's four-account AgentCore reference architecture puts Cedar authorization at the gateway hop, which means the one config flag the sample leaves off is the one holding the whole boundary up.
The moment a gateway exchanges a user's token for a machine token, user identity stops being enforceable downstream. That's the structural fact sitting underneath Amazon's new multi-account agent pattern, and AWS states it plainly: "Because the outbound call uses M2M, user-level authorization is enforced here at the Gateway."
The shape is hub-and-spoke. Line-of-business accounts wrap their DynamoDB tables and Bedrock Knowledge Bases as MCP servers on AgentCore Runtime, each with a custom JWT authorizer pointed at Okta's OIDC discovery endpoint. A platform account runs the Strands agent and a single AgentCore Gateway that registers every LOB server as a target. The agent forwards the end user's JWT to the Gateway. Policy in AgentCore evaluates the claims against Cedar rules in ENFORCE mode, default-deny, and permits or denies each tool call.
Then the Gateway pulls OAuth 2.0 client-credentials tokens from AgentCore Identity and makes the outbound call as itself. The LOB server validates that token and sees a machine, not a person. So `get_balance` for all authenticated users and `transfer_funds` for one role are decisions that exist in exactly one place.
Which makes the perimeter question the whole question. The LOB Runtime will accept any valid Okta token with the right audience unless you set `allowedWorkloadConfiguration` to the Gateway's ARN, and the sample doesn't — AWS's own text says it "relies on OAuth audience validation as its primary access control." An M2M credential leaking, or a second target registered against the same authorization server, routes straight past Cedar. AgentCore Identity does support on-behalf-of exchange, which would carry both identities downstream; the walkthrough skips it because the Okta developer account used for the sample doesn't support the flow.
The genuinely new capability here is the federation itself: one `tools/list` call, semantic tool discovery across accounts, and onboarding a new LOB by adding a Gateway target. Data stays put, results flow out.
If you clone the repo, treat the default network mode and the missing workload restriction as demo scaffolding. Set the ARN before anything touches real balances.