Security2 publishers2 min readPublished 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
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend 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.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- 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.
- 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.
- 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.
- 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.