Ditching IAM Users in AI-Driven DevelopmentHow to set up AWS access management with SSO + AssumeRole

1. Why Access Keys Are Risky in AI-Driven Development

At MOOBON, we increasingly hand both development and operations work over to AI. AI agents like Claude Code are incredibly useful, but if long-term keys live in that same environment, the list of things you need to watch out for suddenly grows. Specifically, there are two:

The SSO + AssumeRole approach changes those assumptions at the root.

• No long-term secrets on the PC in the first place = there's no "permanent key" that could be handed to AI.
• You use temporary credentials that expire automatically within hours = even if they leak, the blast radius is orders of magnitude smaller.
• MFA is required at the entry point = an agent can't reauthenticate on its own.

2. Access Keys vs. SSO + AssumeRole

So what's actually different between the old access keys (long-term keys) and the new SSO + switch role? Laying them out side by side makes the differences clear.

Side by side, it becomes clear that every weakness of the old approach stems from "permanent keys scattered across people's PCs." In exchange for convenience, the blast radius of a leak is large, and it's hard to notice. SSO + switch role removes that premise altogether. We'll look at how it works in the next section.

3. How SSO + AssumeRole Is Structured

The idea is simple. You log in to MOOBON's SSO just once to establish your identity, and from there you AssumeRole (switch) into each client's account to do your work.

You (MOOBON SSO account, MFA required)
        │  aws sso login (about once a day)
        ▼
[ MOOBON account <MOOBON_ACCOUNT_ID> ]
        │  AssumeRole (switch)
        ├──────────────► [ Client A ]  role: MoobonAdmin
        ├──────────────► [ Client B ]  role: MoobonAdmin
        └──────────────► [ Client C ]  role: MoobonAdmin

• Each client account gets a single role named MoobonAdmin that trusts MOOBON.
• That role has a trust setting saying "anyone from the MOOBON account may assume it," so no key handoff is needed.
• Client accounts remain independent (each company keeps its own billing). They are not brought into MOOBON's organization.

The credentials you get are temporary credentials that expire automatically within a few hours at most. No static keys are left on the PC; you obtain short-lived credentials on the spot only when you need them. That's the big picture.

Three design pillars: temporary credentials / MFA / trust policy

4. Prerequisites: SSO Login with Organizations and Identity Center

MOOBON set up SSO login several years ago, so we'll skip the detailed setup steps here, but the overall flow looks like this:

1. Enable AWS Organizations: the foundation for grouping multiple accounts. If you already have an organization, you can use it as is.
2. Enable IAM Identity Center (formerly AWS SSO): choose the region you normally use, ap-northeast-1 in our case (be careful, as it's hard to change later).
3. Choose an identity source: for a minimal setup, the Identity Center built-in directory is enough. If you already use Google Workspace, Microsoft Entra ID, or similar, you can choose an external IdP.
4. Create users (and groups if needed): register everyone who needs access.
5. Require MFA: in the Identity Center settings, set it to "require MFA on every sign-in." This is where the security of this whole approach comes from, so making it mandatory is non-negotiable.
6. Create a Permission Set: a bundle of permissions to grant. Start with one AdministratorAccess Permission Set (you can narrow it down as needed).
7. Assign it to accounts: link the Permission Set you created to "which people can use it in which accounts" (this is called an assignment). Now your team can sign in to the MOOBON account. Note that the name of the assigned Permission Set (e.g., AdministratorAccess) becomes the value of sso_role_name in ~/.aws/config in the next section.
8. Note down the start URL: the access portal URL shown on the Identity Center dashboard (https://d-xxxxxxxxxx.awsapps.com/start/). You'll use it for sso_start_url in the next section.

At this point, you can sign in to the AWS console with Administrator permissions from the start URL (https://d-xxxxxxxxxx.awsapps.com/start/), going through two-factor authentication (MFA). But that only covers the AWS side (the console). To let AI use the AWS CLI, you'll do the local setup in the next section.

5. Local Setup: Consolidating Everything in ~/.aws/config

The initial setup only needs to be done once. First, install AWS CLI v2.

# macOS
brew install awscli
aws --version   # should be aws-cli/2.x

All configuration goes into ~/.aws/config. Since there are no long-term keys, nothing goes into ~/.aws/credentials anymore.

# ~/.aws/config

[sso-session moobon-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start/
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

# MOOBON itself (your identity)
[profile moobon]
sso_session = moobon-sso
sso_account_id = <MOOBON_ACCOUNT_ID>
sso_role_name = AdministratorAccess
region = ap-northeast-1

With this, you can operate your own account through the moobon profile. Profiles for client (third-party) accounts will be added in Section 7, where we cover AssumeRole.

6. Daily Use: sso login and Profiles

Log in to SSO from the terminal (also when the token expires)

aws sso login --profile moobon

When you run the command in the terminal, a browser opens, and you sign in with the account you created in IAM Identity Center. One login stays valid for several hours up to a day. When it expires, just run it again.

Check that the AWS CLI works with the logged-in profile

Add the profile name to a command and see whether it actually goes through. Start with your own account (moobon) and confirm the command returns a result.

aws s3 ls --profile moobon
aws ec2 describe-instances --profile moobon

7. Managing Clients with AssumeRole: A Win-Win for Both Sides

From here on, we cover managing other companies' (clients') accounts. One option is to have each client set up Organizations and Identity Center and create an SSO user for MOOBON there. But asking every client to build and run that isn't realistic, and on our side we'd end up juggling a separate login for every client. That's where AssumeRole (switch role) comes in. It has the following advantages:

• Minimal effort for the client: no need to build Identity Center. They just need to add one "role that trusts MOOBON."
• You keep a single identity: you simply switch on the spot from your already-logged-in MOOBON identity. No separate login per client.

This setup not only keeps the burden on clients small, it also makes our own day-to-day operations much easier. We no longer need to manage a username × password × two-factor authentication for every client as we did before, and with everything consolidated into a single entry point, both using the AWS CLI and signing in to the AWS console become much simpler and easier to handle.

Now, let's move on to the configuration.

① Create a dedicated role on the client side

With the client's consent, create a MoobonAdmin role in their account. The key is the trust policy. By stating "allow the role to be assumed (sts:AssumeRole) from the MOOBON account," you can switch into it without handing over any keys. Save the following as trust-policy.json.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<MOOBON_ACCOUNT_ID>:root" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create the role with this policy and grant it permissions (AdministratorAccess in this example). Run this just once in the client's account, using temporary admin permissions.

# run once in the client's account (with temporary admin permissions)
aws iam create-role \
  --role-name MoobonAdmin \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name MoobonAdmin \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Specifying the MOOBON account's root as the Principal means trusting "anyone in the MOOBON account" and delegating the decision of who can actually assume the role to MOOBON's own permission settings (the SSO Permission Set). As long as the Permission Set from the prerequisites allows sts:AssumeRole, the switch will go through.

② Add client profiles to ~/.aws/config

Add the ARN of the role you created to the ~/.aws/config from Section 5 as a switch-target profile.

# append to ~/.aws/config
# one per client (switch target). the number in role_arn is that client's account ID.
[profile clienta]
role_arn = arn:aws:iam::<CLIENT_ACCOUNT_ID>:role/MoobonAdmin
source_profile = moobon
region = ap-northeast-1

# [profile clientb] ... add your other clients the same way

The key is source_profile = moobon. This means "switch using the MOOBON identity." To add more clients, just add the same block.

③ Switch and operate

From there, just add the client's profile name to your CLI commands. The temporary credentials for the target account are used automatically.

aws s3 ls --profile clienta
aws ec2 describe-instances --profile clienta

8. Signing In to the AWS Console with AssumeRole

Beyond the AWS CLI, there are times when you want to open a client's console in the browser. AssumeRole doesn't make the client part of your organization, so the client's AWS account won't appear as an option on the SSO login page. It's easy to assume you simply can't sign in to their console, but in fact you can switch and open the console right from your MOOBON SSO session. It's handy to set up a helper that generates a sign-in URL from the temporary credentials obtained by switching. Save the following as ~/bin/aws-console.

#!/usr/bin/env bash
# usage: aws-console <profile-name>   e.g. aws-console clienta
set -euo pipefail
PROFILE="${1:?specify a profile name}"

# prompt for SSO login if the token has expired
aws sts get-caller-identity --profile "$PROFILE" >/dev/null 2>&1 \
  || aws sso login --profile moobon

# extract the target's temporary credentials and build the session JSON for federation
# (--format process outputs JSON; a single python3 call parses it and URL-encodes it)
CREDS=$(aws configure export-credentials --profile "$PROFILE" --format process)
SESSION=$(echo "$CREDS" | python3 -c '
import sys, json, urllib.parse
d = json.load(sys.stdin)
print(urllib.parse.quote(json.dumps({
    "sessionId": d["AccessKeyId"],
    "sessionKey": d["SecretAccessKey"],
    "sessionToken": d["SessionToken"]
})))
')

# get a federation sign-in token -> build the login URL and open it
TOKEN=$(curl -s "https://signin.aws.amazon.com/federation?Action=getSigninToken&Session=$SESSION" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["SigninToken"])')
DEST=$(python3 -c "import urllib.parse;print(urllib.parse.quote('https://ap-northeast-1.console.aws.amazon.com/'))")
URL="https://signin.aws.amazon.com/federation?Action=login&Issuer=moobon&Destination=$DEST&SigninToken=$TOKEN"
echo "$URL"; open "$URL" 2>/dev/null || true

chmod +x ~/bin/aws-console
aws-console clienta     # -> opens Client A's console in the browser (valid for about an hour)