--- title: "Propagating User Identity From AI Agents to Your Tools: Amazon Bedrock AgentCore Gateway and JFrog Artifactory" url: https://daily.dev/posts/propagating-user-identity-from-ai-agents-to-your-tools-amazon-bedrock-agentcore-gateway-and-jfrog-a-vptjksmq0 source_url: https://jfrog.com/blog/amazon-bedrock-agentcore-gateway-jfrog-artifactory type: article source: "JFrog" published: 2026-08-21T16:22:59.454Z updated: 2026-08-21T16:23:28.939Z tags: ["ai-agents", "mcp", "oauth"] reading_time: 18 upvotes: 2 comments: 1 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Propagating User Identity From AI Agents to Your Tools: Amazon Bedrock AgentCore Gateway and JFrog Artifactory **[JFrog](https://daily.dev/sources/jfrog)** · 18 min read · 2 upvotes · 1 comments ## Summary A detailed technical walkthrough explains how to propagate per-user identity from AI agents through Amazon Bedrock AgentCore Gateway to JFrog Artifactory using OAuth 2.0 on-behalf-of (OBO) token exchange (RFC 8693). It compares three identity propagation mechanisms - header whitelisting, three-legged OAuth, and on-behalf-of exchange - and explains why OBO is preferred: it preserves least privilege, audit fidelity, and avoids shared long-lived credentials. The post provides step-by-step CLI and API commands to configure the identity provider, JFrog OIDC integration and identity mapping, the AgentCore credential provider, gateway target with dynamic listing mode, and IAM permissions, plus a troubleshooting table for common failures like token type mismatches and stuck target synchronization. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I set up on-behalf-of token exchange between Amazon Bedrock AgentCore Gateway and JFrog Artifactory so agent calls carry the user's identity? Create an AgentCore CustomOauth2 credential provider with an onBehalfOfTokenExchangeConfig block using grantType TOKEN_EXCHANGE and actorTokenContent NONE, then add a gateway target pointing at JFrog's /mcp endpoint with listingMode DYNAMIC and a customParameter subject_token_type set to urn:ietf:params:oauth:token-type:id_token, matched against a JFrog OIDC integration and identity mapping keyed on a claim like preferred_username. _Track evolving AgentCore Gateway and JFrog integration patterns on daily.dev while wiring up secure agent-to-tool identity propagation._ ### Why does my AgentCore Gateway target fail with an internal error on every JFrog MCP tool call? The credential provider is missing the onBehalfOfTokenExchangeConfig block, which is required for the on-behalf-of exchange to run; omitting it is not caught at creation time but surfaces later as a generic internal error on every tool call, with the real ValidationException on GetResourceOauth2Token visible in CloudTrail and Gateway CloudWatch logs. Adding that config block to the credential provider resolves it. _Debugging agent-to-tool auth failures gets easier when daily.dev keeps you current on AgentCore Gateway integration gotchas._ ### Why does JFrog reject my AgentCore Gateway token exchange with 'Wrong token type was used'? AgentCore forwards the inbound user access token as the subject token but labels it as a JWT by default, and JFrog rejects that label. Setting the subject_token_type custom parameter on the gateway target to urn:ietf:params:oauth:token-type:id_token fixes only the label JFrog receives, not which token is actually sent, since JFrog still parses the underlying access token claims for its identity mapping. _Save time on token-exchange configuration errors by following AgentCore and JFrog integration guidance surfaced on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@kartiknvj** · 0 upvotes > Identity propagation is one of those things you do not notice until an agent calls a tool with the wrong scope. I ended up vetting each tool's auth surface before trusting it in a loop, since a broad token is exactly what a hijacked agent would exploit. I wrote up my process for that here: [https://dev.to/kartik-nvjk/how-i-vet-mcp-servers-before-trusting-them-in-my-agent-1ngh](https://dev.to/kartik-nvjk/how-i-vet-mcp-servers-before-trusting-them-in-my-agent-1ngh) — are you passing end-user identity all the way down, or re-authing at the tool boundary? ## Similar posts on daily.dev - [AI Agent Identity: How to Authenticate and Govern AI Agents](https://daily.dev/posts/ai-agent-identity-how-to-authenticate-and-govern-ai-agents-pii52p4wl) · Security Boulevard · 0 upvotes · 0 comments - [Securing Amazon Bedrock AgentCore with Auth0 for AI Agents](https://daily.dev/posts/securing-amazon-bedrock-agentcore-with-auth0-for-ai-agents-4vbphqldn) · Auth0 · 0 upvotes · 0 comments --- Tags: [#ai-agents](https://daily.dev/tags/ai-agents), [#mcp](https://daily.dev/tags/mcp), [#oauth](https://daily.dev/tags/oauth) [View this post on daily.dev](https://daily.dev/posts/propagating-user-identity-from-ai-agents-to-your-tools-amazon-bedrock-agentcore-gateway-and-jfrog-a-vptjksmq0)