AWS Security ChangesHomeSearch

AWS bedrock-agentcore medium security documentation change

Service: bedrock-agentcore · 2026-05-07 · Security-related medium

File: bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.md

Summary

Revised explanation of token exchange flow: removed mention of caching tokens and updated Microsoft provider description.

Security assessment

Removal of 'caches the scoped downstream token(s) in the Token Vault' suggests a security design change to avoid token storage. Updated MicrosoftOauth2 description explicitly calls out security standards (RFC 7523) and secure delegation. This documents security feature improvements.

Diff

diff --git a/bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.md b/bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.md
index bbc8aa5fd..975ddda45 100644
--- a//bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.md
+++ b//bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.md
@@ -15 +15 @@ Amazon Bedrock AgentCore Identity supports On-Behalf-Of (OBO) token exchange, en
-On-behalf-of token exchange is built into the existing OAuth Credential Provider. When an agent requests a downstream token, AgentCore Identity automatically takes the inbound access token—representing the upstream caller—along with the client credentials already stored in the credential provider, and brokers the token exchange request with the customer’s IdP or OAuth authorization server. It submits the request, parses the response, caches the scoped downstream token(s) in the Token Vault, and returns it to the agent. Agent developers never need to handle the inbound token or manage client secrets directly. The authorization server makes the final authorization decision, including whether to grant the requested scopes and whether to permit the delegation.
+On-behalf-of token exchange is built into the existing OAuth Credential Provider. When an agent requests a downstream token, AgentCore Identity automatically takes the inbound access token—representing the upstream caller—along with the client credentials already stored in the credential provider, and brokers the token exchange request with the customer’s IdP or OAuth authorization server. It submits the request, parses the response, and returns it to the agent. Agent developers never need to handle the inbound token or manage client secrets directly. The authorization server makes the final authorization decision, including whether to grant the requested scopes and whether to permit the delegation.
@@ -81 +81 @@ Provider Name | Grant Type Mode | Note | Related Documentation
-MicrosoftOauth2 |  JWT_AUTHORIZATION_GRANT |  `requested_token_use=on_behalf_of` is automatically added to the request unless overridden. |  [Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow)  
+`MicrosoftOauth2` |  `JWT_AUTHORIZATION_GRANT` * Microsoft’s On-Behalf-Of flow is a proprietary delegation pattern built upon the RFC 7523 standard, using the JWT-bearer grant type to facilitate secure token exchange between tiered services. |  `requested_token_use=on_behalf_of` is automatically added to the request unless overridden. |  [Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow)