Currently, the proxy creates a single boto3.Session at startup in create_transport_with_sigv4() (utils.py) and reuses it for the lifetime of the process. While session.get_credentials() is called on every request in _sign_request_hook(), botocore caches the resolved credentials in the Session object after the first read from ~/.aws/credentials.
This means that if a user switches to a different AWS account/role locally (e.g., by changing AWS_PROFILE, updating ~/.aws/credentials, running aws sso login with a different profile, or modifying environment variables), the proxy continues to use the stale credentials from the original session. The only workaround is to fully restart the proxy process.
Use Case
When working with multiple AWS accounts (e.g., dev, staging, production), developers frequently switch between different IAM roles or SSO profiles during a single session. Common approaches include:
- Switching named profiles with
role_arn in ~/.aws/config (via AWS_PROFILE)
- Using AWS SSO / IAM Identity Center with different profiles (
aws sso login --profile <profile>)
- Using
aws login and switching profiles
- Updating environment variables (
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)
In all of these cases, the proxy does not pick up the new credentials because the boto3.Session was created at startup and its credential provider cache is never invalidated.
This forces users to restart the MCP proxy (and in some MCP clients, restart the entire chat session) every time they switch accounts. This is disruptive to workflow, especially during development sessions where cross-account access is needed frequently.
Proposed Solution
[Might be other better ways] Auto-detect the local change of creds, and then tear down the old connection between the proxy and the remote mcp server, and then re-establish a connection.
Other Information
No response
Acknowledgements
Describe the feature (Security related? please follow https://github.com/aws/mcp-proxy-for-aws/security/policy to report them to AWS Security directly.)
Currently, the proxy creates a single
boto3.Sessionat startup increate_transport_with_sigv4()(utils.py) and reuses it for the lifetime of the process. Whilesession.get_credentials()is called on every request in_sign_request_hook(), botocore caches the resolved credentials in the Session object after the first read from~/.aws/credentials.This means that if a user switches to a different AWS account/role locally (e.g., by changing
AWS_PROFILE, updating~/.aws/credentials, runningaws sso loginwith a different profile, or modifying environment variables), the proxy continues to use the stale credentials from the original session. The only workaround is to fully restart the proxy process.Use Case
When working with multiple AWS accounts (e.g., dev, staging, production), developers frequently switch between different IAM roles or SSO profiles during a single session. Common approaches include:
role_arnin~/.aws/config(viaAWS_PROFILE)aws sso login --profile <profile>)aws loginand switching profilesAWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,AWS_SESSION_TOKEN)In all of these cases, the proxy does not pick up the new credentials because the
boto3.Sessionwas created at startup and its credential provider cache is never invalidated.This forces users to restart the MCP proxy (and in some MCP clients, restart the entire chat session) every time they switch accounts. This is disruptive to workflow, especially during development sessions where cross-account access is needed frequently.
Proposed Solution
[Might be other better ways] Auto-detect the local change of creds, and then tear down the old connection between the proxy and the remote mcp server, and then re-establish a connection.
Other Information
No response
Acknowledgements