The walkthrough builds a task agent on Amazon Bedrock AgentCore runtime that acts for signed-in users through Okta Cross App Access (XAA) and AgentCore Identity. Okta is the governance layer, deciding which agent can reach which resource, while AgentCore Identity holds the agent's credentials and redeems Okta's grant without exposing the client secret to agent code. The authors say AgentCore Identity added about 0.6 seconds to a request that took about 30 seconds end to end.
Each request carries three tokens: an ID token for the user, an ID-JAG that records Okta's decision, and the access token the resource accepts. The ID-JAG is single-use and expires in 5 minutes, and tokens already issued stay valid until they expire. Deleting the agent's resource connection took effect immediately in the tests, while deactivating the agent waited 86 minutes in a queue in the test org.
The MCP servers accept only tokens obtained by a registered agent, and they allow writes only when the user's group and the xaa:write scope are both present. AWS reports that plain RFC 8693 token exchange carried the user's identity but not the user's authority, and it issued a token even after the user was unassigned.
Why it matters if you build agents
Developers can enforce per-user authority for agents through Okta and groups claims, without relying on shared service accounts. Revoking a user's assignment or deleting a resource connection cuts off new requests quickly, but tokens already issued can still work for up to 5 minutes. Tool code should check the agent's client ID and the groups claim, because the runtime authorizer alone accepts tokens issued to other agents unless allowedClients is set.
Get stories like this every weekday
One short email with the day's agent tooling news.