Skip to content
Today
Sections

Security Also reported elsewhere2 publishers 2 min read Published Updated

Identity that survives the second hop: OBO token exchange from AgentCore Gateway to Artifactory

JFrog has documented an on-behalf-of exchange so agent calls reach Artifactory as the signed-in user. The price is the Gateway's cached tool search, which per-user discovery gives up.

The Watch · Security desk

Send a correction

What happened

  • JFrog has published an end-to-end, CLI-reproducible procedure for wiring Artifactory behind Amazon Bedrock AgentCore Gateway using on-behalf-of token exchange.
  • The Gateway puts one managed MCP endpoint in front of many backend tools, with targets registered centrally instead of per agent.
  • The integration forgoes the Gateway's cached tool search in favour of dynamic tool listing, so discovery runs under the user's token.

Why it matters

  • What it costs cost Per-user identity is paid for in discovery work: with cached search dropped, listing repeats for every distinct user token instead of being served once.
  • What it limits constraint Once the agent inherits the user's entitlements, the quality of Artifactory's per-user permission model becomes the ceiling on what agents can do, and any sloppiness there is now agent-visible.
  • Who has to decide decision Platform owners now pick explicitly: wire the exchange into the existing IdP, or accept that Artifactory's authorization model sits unused for agent traffic.
  • What it sets up precedent A vendor-published, reproducible procedure retires the argument that shared service accounts for agents are a limitation of the tooling rather than a choice.

Hop 1 was never the hard part. The user signs in with an identity provider, the agent presents that identity, and the Gateway validates the JWT on the way in [2][5]. The per-user security model for agent traffic therefore reduces to one leg of a two-leg path [17]: whichever credential the Gateway holds when it turns round and calls Artifactory [4].

JFrog is unusually direct about what a single shared credential costs at that boundary. Actions land in the log against one service account rather than the person who triggered them [c10a]. That credential normally carries broader access than any individual user, so the agent can act beyond the permissions of the person asking [c10b]. And one long-lived secret, once leaked, exposes everything the agent can reach [c10c].

What on-behalf-of exchange changes is where the permission decision gets made. AgentCore Identity, the managed broker and vault behind outbound auth, performs the exchange so the outbound call carries the user rather than a shared identity [3]. Artifactory then evaluates the request with its own authorization system against the signed-in person, and accountability for the operation stays with that person [16].

The alternatives listed alongside it are worth reading for where each one parks the trust. Header whitelisting forwards identity in a request header that the target must be set up to trust [15], which makes the guarantee a configuration promise on the receiving end rather than a signature the receiver can check. Three-legged OAuth is the other option named, and these are general Gateway mechanisms rather than anything JFrog-specific [14].

Two limits on the evidence. This is JFrog's own write-up of an integration with an AWS service [18], and it is a procedure rather than an assessment: it asserts the request reaches Artifactory as the user and hands over the CLI steps to reproduce it [9]. It also only covers traffic that actually goes through the Gateway, which is the single place targets are registered and outbound credentials are obtained [10][2]. Targets can be Lambda functions, OpenAPI or Smithy APIs, or other MCP servers [11], and the identity story holds for exactly as many of them as are registered there.

Agents already open pull requests, run queries, and publish artifacts into repositories [1], which means the question of who published a given build is going to be asked. A shared service account answers it with the name of a robot. This answers it with a person [16].

What to watch

  • Whether AWS or JFrog document OBO for target types beyond MCP servers, particularly OpenAPI and Smithy targets registered on the same Gateway.
  • Whether anyone outside JFrog reproduces the CLI procedure and reports what Artifactory's audit log actually records for an OBO-authenticated call.
  • Whether the loss of cached tool search shows up as measurable discovery latency once more than a handful of users share a Gateway.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence55
Adoption
Not scored
Hype gap+15
Incentives70
Confidence60
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    AI agents are becoming real users of internal systems: they open pull requests, run queries, and pull and publish artifacts in repositories like JFrog Artifactory.

    Reported SupportedView cited source
  2. [2]

    The Gateway validates the caller's token (a JWT from the identity provider) on the way in, and obtains the right credential for the target on the way out.

    Reported SupportedView cited source
  3. [3]

    AgentCore Identity is the managed broker and vault behind outbound auth; it stores the credential the Gateway uses to reach a target and can perform an OBO token exchange so the outbound call carries the user's identity rather than a shared one.

    Reported SupportedView cited source
  4. [4]

    Every agent-to-tool request travels at least two hops: user via agent to AgentCore Gateway (hop 1), then Gateway to JFrog Artifactory (hop 2).

    Reported SupportedView cited source
  5. [5]

    Hop 1 is well understood: the user signs in with an identity provider and the agent presents that identity to the Gateway. Hop 2 is trickier, because it is unclear what identity the Gateway uses when it calls Artifactory.

    Reported SupportedView cited source
  6. [6]

    With a single shared credential on hop 2 you lose audit fidelity: actions are recorded against one service account, not the person who triggered them.

    Reported SupportedView cited source
  7. [7]

    With a single shared credential on hop 2 you lose least privilege: that credential usually has broader access than any one user, so the agent can act beyond a user's permissions.

    Reported SupportedView cited source
  8. [8]

    With a single shared credential on hop 2 you lose containment: one leaked long-lived credential exposes everything the agent can reach.

    Reported SupportedView cited source
  9. [9]

    The JFrog post gives a complete, API-driven procedure for On-Behalf-Of (OBO) token exchange between Amazon Bedrock AgentCore Gateway and JFrog Artifactory, reproducible with CLI commands against the JFrog Platform.

    Reported SupportedView cited source
  10. [10]

    AgentCore Gateway gives an agent a single, managed MCP endpoint fronting many backend tools: targets are registered on the Gateway rather than each agent being taught how to reach each system.

    Reported SupportedView cited source
  11. [11]

    A Gateway target can be a Lambda function, an OpenAPI or Smithy API, or another MCP server.

    Reported SupportedView cited source
  12. [12]

    The Gateway offers cached tool search, but this integration uses dynamic tool listing instead, so tool discovery runs with the user's token.

    Reported SupportedView cited source
  13. [13]

    Under OBO the agent's reach at Artifactory equals the signed-in user's own entitlements, which is narrower than the typical shared credential's reach, so the per-user permission model becomes the ceiling on what the agent can do.

    Derived Supported
  14. [14]

    AgentCore Gateway supports three ways to propagate identity to a target - header whitelisting, three-legged OAuth, and on-behalf-of exchange - and these are general mechanisms, not JFrog-specific.

    Reported SupportedView cited source
  15. [15]

    Header whitelisting forwards identity in a request header that the target must be set up to trust.

    Reported SupportedView cited source
  16. [16]

    With OBO token exchange, each call reaching Artifactory authenticates as the signed-in user rather than a single shared credential, allowing JFrog's own authorization system to be used with the AgentCore Gateway and keeping the correct owner's accountability on agentic operations.

    Reported SupportedView cited source
  17. [17]

    Of the two hops in an agent-to-tool call, one is already settled by the inbound JWT, so per-user identity for the whole chain turns on a single remaining hop.

    Derived Supported
  18. [18]

    The account of the integration is published by JFrog on jfrog.com and describes an integration with Amazon Bedrock AgentCore Gateway.

    Reported SupportedView cited source
  19. [19]

    Because tool discovery runs under each user's token via dynamic listing instead of the Gateway's cached tool search, discovery work repeats per distinct user token rather than being served from one shared cache.

    Derived Insufficient

Sources

2 independent publishers whose own reporting we read for this story.

  1. helpnetsecurity.com

    1 article · August 20, 2026

    AWS limits AI agents’ data access, even when manipulated
  2. jfrog.com

    1 article · August 21, 2026

    Propagating User Identity From AI Agents to Your Tools: Amazon Bedrock AgentCore Gateway and JFrog Artifactory

Topics and entities

Topics

Entities