Session Security: X-Amzn-Bedrock-AgentCore-Runtime-Session-Id #161
Replies: 1 comment
-
|
AgentCore Runtime only doesn't enforce session-to-user mappings, so you you have two ways to handle this: Option 1: Build your own validation Maintain a mapping (DynamoDB, ValKey, whatever) of userId → sessionIds and check it on every request. Reject the request if the user doesn't own that session. Option 2: Use AgentCore Identity with JWT Configure JWT-based auth (Cognito, etc.) and AgentCore will bind sessions to users automatically. The JWT validation enforces ownership without you needing to maintain a separate registry. How it works:
Docs: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-sessions.html and https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-oauth.html |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm trying to figure out how to best protect sessions.
As far as I can tell, users can access unauthorised sessions by manipulating X-Amzn-Bedrock-AgentCore-Runtime-Session-Id if the endpoints does not check ownership of sessions.
For example, 02-use-cases/customer-support-assistant-vpc does not check the ownership of sessions. If I manage to obtain someone else's session id, all I need is to change the request header value for accessing conversation turns.
Are apps expected to check if a caller owns a given session or not, say using ValKey/DynamoDB, for each request in the AgentCore endpoint?
If so, are we expected to front the AgentCore endpoint by something like API Gateway so that we can check session ownership before request hit the AgentCore endpoint.
One attack I can think of is DDOS with random session ids - this will start new micro VMs and will damage us financially if AgentCore endpoints are not protected.
Beta Was this translation helpful? Give feedback.
All reactions