Repository navigation
Support for assumed IAM role (chained credentials) in MCP proxy #176
Description
Describe the feature (Security related? please follow https://github.com/aws/mcp-proxy-for-aws/security/policy to report them to AWS Security directly.)
When configuring the MCP proxy with an AWS profile that uses an assumed IAM role (chained credentials), the connection fails with a timeout error.
Logs (Assumed Role Profile):
2026-02-12 16:07:44.808 [info] [eks-mcp] Configuration changed for MCP server, reconnecting
2026-02-12 16:07:44.809 [info] [eks-mcp] Registering MCP server and starting connection
2026-02-12 16:08:44.977 [info] [eks-mcp] MCP connection closed successfully
2026-02-12 16:08:44.978 [error] [eks-mcp] Error connecting to MCP server: MCP error -32001: Request timed out
However, when using an AWS profile backed by a direct IAM user (static credentials, no role assumption), the connection succeeds.
Logs (IAM User Profile):
2026-02-13 20:01:46.900 [info] [eks-mcp] MCP server is already connecting
2026-02-13 20:01:56.266 [info] [eks-mcp] Connected to server with transport type: Stdio
2026-02-13 20:01:58.092 [info] [eks-mcp] Successfully connected and synced tools and resources for MCP server
Expected Behavior:
The MCP proxy should support AWS profiles that use assumed IAM roles (including chained credentials), similar to how the AWS CLI and SDKs handle them.
Questions:
- Are assumed-role profiles officially supported?
- If not, is this a known limitation for security reasons?
- Would supporting MFA-authenticated role sessions resolve security concerns?
- Is there any additional configuration required for chained role profiles?
Use Case
I’m interested in using the fully managed EKS MCP server provided by AWS. In our organization, access to EKS and related resources is granted exclusively through assumed IAM roles.
I expect this is a common setup across many organizations, where IAM roles (rather than long-lived IAM user credentials) are required for interacting with AWS services. Enabling support for assumed-role profiles in the MCP proxy would therefore benefit a broader segment of the AWS community that relies on role-based access controls.
Proposed Solution
No response
Other Information
No response
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
Activity
vinodkumar-wagh commentedon Feb 13, 2026
This will be much required feature to get going with EKS MCP server setup in our organization. MCP must support role assumption (or even MFA authentication) for that matter.
nix-tkobayashi commentedon May 8, 2026
Root Cause Analysis
I investigated this issue and found the root cause in
sigv4_helper.py._sign_request_hookis anasynchttpx event hook, but it calls two synchronous methods that can trigger blocking STS calls:session_holder.refresh_if_needed()— callscreate_aws_session()which may involve STSsession_holder.session.get_credentials()— triggers a blocking STSAssumeRolecall for profiles with chained credentials (role assumption)Since these run directly on the asyncio event loop (not in a thread), the entire event loop is blocked for the duration of the STS call, causing the ~60 second timeout.
Workaround (for anyone blocked on this)
Pre-resolve the AssumeRole credentials and pass them explicitly to
boto3.Session:Fix
I submitted #270 which adds
asyncio.to_thread()wrappers for both blocking calls, keeping the event loop responsive.arnewouters commentedon May 19, 2026
I have not been able to reproduce this, my setup with chained credentials works. If this is still an issue, can you share your MCP configuration and what MCP client you are using? Do you have MFA enabled?
fix: resolve AWS credentials off the event loop