🔥Teaching Agentic Strands Agents to assume Cross-Account IAM Roles and Read AWS Resources🔥

aka, which VMs are running hot on CPU? Or out of disk space?

This blog series focuses on presenting complex DevOps projects as simple and approachable via plain language and lots of pictures. You can do it!

These articles are supported by readers, please consider subscribing to support me writing more of these articles <3 :)

Hey all!

In this blog post, we’re going to integrate the AWS Labs CLI MCP server with a Strands-powered AI agent running in Lambda, with support for querying resources across multiple AWS accounts using profile-based role assumption.

The specific challenge: we need our AI assistant to query AWS resources across many different accounts (dev, staging, prod, ops, etc.)… with an MCP server that appears built to support a single authentication profile, in a single account.

The Multi-Account Challenge

When you ask an AI agent “List the EKS clusters in the Prod account,” the agent needs to:

1. Determine which AWS account “Prod” refers to

2. Assume a role in that account with read permissions

3. Execute the AWS API call with the assumed credentials

4. Return the results

The obvious approach is to use `aws sts assume-role` to get temporary credentials, then use those credentials in subsequent commands. This doesn’t work with the AWS CLI MCP server because it’s stateless - each command execution creates a fresh boto3 session. The MCP server can’t “remember” credentials from a previous assume-role call.

Bummer

Another approach would be creating a separate MCP client instance, one per account we might need to speak to, each configured with a different AWS profile. This creates tool sprawl and of course doesn’t scale well.

Double bummer

What we need is profile-based role assumption where the bot includes `--profile oak` in its AWS CLI commands, and the profile configuration automatically handles assuming the correct role using the Lambda execution role as the base credential source.

Why This Is Complicated

The AWS CLI MCP server uses boto3, not shell commands. When you pass `aws eks list-clusters --profile oak`, the MCP server:

1. Parses the command string to extract the profile name

2. Creates a boto3 Session with that profile

3. Loads profile configuration from the AWS config file

4. Resolves credentials according to the profile’s settings

5. Executes the API call

Each of these steps has failure modes that produce silent errors - boto3 just fails without helpful error messages. We’ll cover the debugging later.

The key insight: the `--profile` flag does work in the AWS CLI MCP server. It extracts the profile from the parsed command and passes it to `boto3.Session(profile_name=...)`. We just need to configure profiles correctly.

Lets do it!