Okta publishes two ways to keep a user's identity attached to AgentCore agent tool calls

Okta has published a technical blog post, dated 2 October 2026, describing how to make tool calls from agents on Amazon Bedrock AgentCore carry the identity of the person who started the work. The post is co-authored by Okta staff and an AWS partner solutions architect.

Okta describes AgentCore as a platform for building, deploying and operating AI agents that works with any framework and model. Its core claim is a gap between inbound and outbound identity. According to Okta, AgentCore validates inbound user authentication but defaults outbound tool calls to the agent's own principal, so the user's authority does not automatically reach the tools the agent calls. Okta also says that simply forwarding the user's original OpenID Connect token is not a fix, because that token was issued for the web application, not for a separate resource server.

Okta's proposed answer combines its Cross-App Access (XAA) with the Identity Assertion Authorization Grant (ID-JAG), an IETF draft. In Okta's description, the user's token is exchanged for a short-lived ID-JAG token, which is then exchanged at the target authorization server for a scoped OAuth 2.0 access token naming both the user and the agent. Okta contrasts this delegation with impersonation, saying a delegated agent appears in audit trails alongside the user.

The new detail beyond the concept is two deployment patterns. In Pattern A, the agent itself runs the exchange using the Okta SDK, which Okta calls the simplest topology. In Pattern B, a Lambda interceptor at AgentCore Gateway reads the user's token from an allowlisted header and performs the exchange on the agent's behalf, which Okta says keeps credentials out of the agent container and puts exchange policy in one place. Okta also states that AgentCore Runtime does not perform the Okta token exchange; that remains application code's job.

What is confirmed and what is not: the post is Okta's own account of Okta's product and of how AWS's service behaves. We found no independent report or AWS documentation confirming the described AgentCore defaults or the interceptor wiring, and no customer deployment or test results are cited. This is effectively a single-source item.

It matters because enterprises moving agents into production must answer whose authority a tool call used. Okta's post offers one concrete design for that, but readers should treat its claims as vendor guidance until verified against AWS documentation.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. Correction: the earlier version said the source excerpt does not provide further implementation steps. The source says there are two implementation patterns: running the token exchange inside the agent with the Okta SDK, or having an AWS Lambda interceptor at AgentCore Gateway perform it. The earlier version remains available as revision 1.