AWS Shows How to Separate an Agent’s Permissions From Its User’s Authority

An enterprise agent can be allowed to use a task manager without being allowed to create tasks for every employee. AWS’s two-part Okta Cross App Access and Amazon Bedrock AgentCore walkthrough makes that distinction concrete: identify the agent, identify the person it represents, then enforce both sets of permissions before a tool changes anything.

For developers and identity teams connecting agents to business applications, the useful contribution is a tested delegation architecture and its failure cases. This is practical workflow analysis, rather than evidence of a newly launched service. The examples show why issuing a valid token is only one part of deciding whether a particular action should succeed.

Carry two identities to the tool

In Part 1 of AWS’s walkthrough, an administrator registers an agent in Okta, assigns users and connects the agent to a resource authorization server with approved scopes. The signed-in user’s ID token is exchanged for an Identity Assertion JWT Authorization Grant, or ID-JAG. Okta checks the agent, user assignment and resource connection when issuing that grant.

AgentCore Identity then redeems the grant for a short-lived access token. That token identifies both the user and the acting agent, and carries the user’s groups. The credential provider holds the client secret, keeping it out of agent code. The runtime’s inbound authorizer also pins the grant to the intended agent through its allowedClients configuration.

The decisive detail is downstream authorization. In AWS’s example, all three test users received the same read and write scopes through one agent’s resource connection. Their groups supplied the distinction between who could create a task and who could not. The task manager therefore required both the write scope and membership in the writers group.

AWS reports that an earlier implementation accepted a user without a groups claim and allowed that user to create tasks. Another missing check allowed a plain token-exchange token without the expected acting-agent claim. Those findings support a specific implementation rule: validate the delegation identity and the user’s authority at the resource, rather than treating a broad scope as sufficient.

Move credential exchange behind a gateway

Part 2 moves token exchange to AgentCore Gateway. The agent forwards its ID-JAG to the gateway, whose role performs the exchange. The agent’s execution role consequently loses its token-exchange and secret-reading permissions.

Cedar policies at the gateway bind tools to the agent and its delegated scopes, using default-deny behavior. Resource servers still check the user’s groups and scope. These are complementary decisions: the gateway limits what this agent may attempt, while the resource decides whether this person may perform the action.

AWS demonstrates the distinction with a second, read-only reporting agent running on Amazon EKS. Bob could create a task through the task agent, but the reporting agent’s gateway hid write tools and refused a direct write call. Changing the agent changed the available authority even though the person stayed the same. In this design, each Okta agent needs its own gateway and credential provider.

Revocation has more than one clock

The operational lesson is to measure new grants separately from existing tokens. AWS’s Part 1 tests found that removing a user assignment blocked new requests within about one second, while deleting the resource connection blocked them immediately. Already issued access tokens continued working until expiry, up to five minutes.

An ID-JAG minted before a user’s removal could also still be redeemed afterward. Deactivating the agent proved slower in AWS’s test organization: the operation queued for 86 minutes. These are reported observations from that configuration, not universal revocation guarantees. Teams adopting the pattern should test the resource-connection control and outstanding-token behavior explicitly.

Part 2 also shows why the same policy cannot be assumed for every application. XAA requires a target authorization server that accepts its grant. In AWS’s separate GitHub consent example, suspending a user in Okta blocked a new sign-in but an earlier inbound token still worked, and the stored OAuth grant remained until disconnected.

Centralization needs explicit resource controls

AWS’s separate Fargate MCP data-lake architecture illustrates the broader benefit of separating agents from shared tools: datasets become discoverable through metadata, while Athena tools reject writes before execution. It does not establish equivalent per-user delegation or finished column-level permissions; finer-grained column controls are described as future work.

For a pilot, select one resource and test four cases: a permitted writer, a reader attempting a write, the same writer through a read-only agent, and a revoked user with outstanding tokens. Preserve the user, agent and authorization decision in resource traces alongside identity-provider events. Our existing analysis of the agent gateway as an enterprise control plane provides the architectural context. AWS’s walkthrough adds concrete evidence about where that control must be enforced—and where access can persist after an administrator acts.