Most arguments about what a platform is missing are really arguments about where you think it sits. Put AgentCore in the wrong place in your head — a client library you import, a framework that runs on the caller's machine — and you go looking for client-shaped features that were never its job. Put it in the right place and the same list of "gaps" reads differently.
So this is about placement first. I did not work it out from the docs. I worked it out by building the thing: an agent running inside AgentCore, invoked through a governed AWS endpoint, reaching a tool through a gateway, gated by a per-user policy, grounded through a managed connector. Once that was standing and I could invoke it, its position in the stack stopped being a claim and became something I could point at. Two things I had written down as gaps along the way then resolved on their own.
Where it sits: a governed server-side hub
Three facts fix AgentCore's position, and I have run all three rather than read them.
The agent runs inside AgentCore, not on the caller's machine. I deployed a two-tier support agent to Runtime and invoked it through InvokeAgentRuntime. The agent executed server-side — the caller sent a request to an AWS endpoint and got a result back; the model calls, the tool calls, the reasoning loop all happened inside the microVM, not in the client. Each invocation is its own isolated session: invoke twice with one session id and state is shared; invoke with a new id and it starts clean. The agent is a hosted endpoint, not a script on a laptop.
The front door is a browser, and the human already authenticated there. The production shape is not the browser calling AgentCore directly. It is the shape independent builders keep converging on: a web front end where the user signs in, a backend that authenticates that user, and the backend invoking AgentCore with its own IAM role — after which the Runtime execution role reaches Memory, Identity, and tools. The human is at a browser-backed app; the agent is behind it. That placement is the whole key to what follows.
It is a node in a governed fabric, not an open endpoint. The agent reaches tools over MCP through a Gateway, and the Gateway is where authorization happens. I proved this end to end: a refund tool behind a JWT gateway, gated by a Cedar policy, invoked by the deployed agent — a $450 call was permitted and ran, a $600 call was denied by default, and the decisions showed up as AllowDecisions and DenyDecisions in the policy engine's own metrics. The same agent also reached a managed search connector by signing as its own execution role. Two tools, two auth models, one agent, every call governed at the gateway. AgentCore is entered through IAM or a JWT authorizer, never by an arbitrary public client.
Hold that picture: a governed server-side hub, entered through a browser where the human already authenticated, reaching tools through a gateway that authorizes every call. With the service placed there, two things I had flagged while building it stopped looking like gaps.
The first: there is no OAuth device flow
AgentCore Identity's user-delegated authentication is an authorization-code redirect — the user is bounced to the identity provider, consents, and a callback completes the flow. There is no RFC 8628 device grant. I confirmed it against the API model: the outbound flow modes are USER_FEDERATION, M2M, and ON_BEHALF_OF_TOKEN_EXCHANGE. No device flow among them.
Device flow exists to solve one problem: the client device has no browser. A smart TV, an IoT sensor, a bare CLI — the user reads a code off one screen and authorizes on their phone. It is a workaround for a missing browser on the thing requesting access.
But the agent runs server-side, behind a front door where the human already is. The authorization-code redirect lands at that front door — the web app — not on the agent. The agent never had a browser and never needed one, because it was never the thing the user sits in front of. The genuinely headless cases are covered by the other two modes: an agent acting as itself uses M2M client credentials; an agent acting as a user without a fresh prompt exchanges the token the user already minted at the front door. Consent happens once, at the web app.
So "no device flow" is not a hole in AgentCore. Device flow answers a question this architecture does not raise, because the client is a server-side hub and the browser is the user's own front door. The narrow residue: a CLI or local agent with no web front end, needing a user's third-party token from a cold start, has no browserless grant. That is a real edge, and it is the honest remainder once the placement is right — not the flat limitation I started with.
The second: the on-behalf-of token exchange I could not complete
On-behalf-of (OBO) token exchange lets a server-side agent act as the user against a downstream resource without a second consent screen. It takes the token the user already presented and exchanges it for a new, scoped token carrying both identities — the user's and the agent's — so the downstream resource can decide at every hop.
Here is the full wiring, and the one place it can stall:
sequenceDiagram
participant U as User (front door)
participant AG as Agent / MCP server
participant AC as AgentCore Identity
participant IdP as IdP token endpoint
participant R as Downstream resource
U->>AG: call with inbound user JWT
AG->>AC: GetWorkloadAccessTokenForJWT(user JWT)
AC-->>AG: workload access token (carries user as subject)
AG->>AC: GetResourceOauth2Token(ON_BEHALF_OF_TOKEN_EXCHANGE)
Note over AC: builds RFC 8693 request
opt actorTokenContent = M2M
AC->>IdP: client_credentials grant (agent's own creds)
IdP-->>AC: actor_token (agent identity)
end
AC->>IdP: POST /oauth/token<br/>grant_type=token-exchange<br/>subject_token=user JWT<br/>actor_token=agent (optional)
Note over IdP: the seam — the IdP must (1) implement RFC 8693<br/>AND (2) allow a custom exchange profile on your tier
alt IdP accepts + profile bound
IdP-->>AC: scoped token (user + agent identity)
AC-->>AG: on-behalf-of access token
AG->>R: call as user, scoped
R-->>AG: result
else grant/profile refused
IdP-->>AC: error
AC-->>AG: exchange fails at IdP boundary
end
AgentCore's side is fully specified, and I confirmed it against the API model. TOKEN_EXCHANGE maps to grant_type=urn:ietf:params:oauth:grant-type:token-exchange; the inbound user JWT is sent as subject_token; under actorTokenContent=M2M, AgentCore first runs a client-credentials grant to mint the agent's own actor_token before sending the exchange. A second mode, JWT_AUTHORIZATION_GRANT, maps to the RFC 7523 JWT-bearer grant for providers that implement OBO that way. Either way, AgentCore builds the request and sends it.
The exchange then completes — or does not — at the identity provider. I pushed on that boundary against two providers and got two different refusals. Cognito does not implement RFC 8693 at all: the request reaches it and comes back a 400. A standards-compliant provider on a free tier advertised the token-exchange grant in its discovery document but refused to bind a custom validation profile: "custom_authentication" Token Exchange Profile is not allowed for the client — that profile is gated behind paid tiers.
Two providers, two refusals, both at the provider boundary. The plain statement of it: AgentCore emits a spec-compliant exchange request; whether the round-trip completes is decided by the identity provider, which must implement the grant and permit a custom exchange profile on your plan tier. In both cases AgentCore did its part correctly. What I did not do is complete a successful round-trip — I did not have a compliant provider on hand where I could bind the profile, so the final hop is unverified on my setup. That is the honest state: AgentCore's half is done and correct, and the other half hands off to a provider that has to be capable and appropriately licensed. The marked step in the diagram is not a hole in AgentCore. It is the seam where responsibility crosses to the identity provider.
The move underneath both
Both times, the same question sorted it: does this live in AgentCore's lane, or in a layer it hands off to?
| What it first looked like | Where it actually lives |
|---|---|
| "No device flow" | The client-has-no-browser problem — but the agent is server-side behind the user's browser front door, so the question does not arise here |
| "OBO exchange doesn't complete" | AgentCore builds a valid exchange; whether it completes depends on the identity provider's grant support and plan tier |
Neither was a gap. They were moments in the build where something looked missing, got written down honestly, and then resolved into "not AgentCore's lane" once the placement was clear. The same test also points at where a real gap would sit — in operating the hub, not in the client-shaped features I first reached for: region availability, the granularity of per-tool observability, Runtime cold-start behavior, the lifecycle tooling around Cedar policy sets. Those are in the right lane to be gaps. I have not pushed on them hard enough to name one.
So what
Place the service before judging it. AgentCore is a governed server-side hub, entered through a browser where the human already authenticated, reaching tools through a gateway that authorizes every call — and I know that because I built it and invoked it, not because a diagram told me. From that vantage, the client-shaped gaps I instinctively looked for were mostly the wrong lens. If there are real gaps here, they are about running the hub, and that is the next thing to push on.
Once the hub is placed, the interesting question stops being "what is missing" and becomes "what do you build on it." That is the next post: the use cases this harness actually unlocks, and the wiring behind each one.
Part of a series working through Amazon Bedrock AgentCore by building on it. Start with The AgentCore Map for the full picture, then the mechanics: AgentCore Runtime: Where an Agent Actually Runs, Two Ways to Authorize an Agent Tool, and Who May Call What.
Top comments (0)