Got the operator's laptop authenticated to PayCargo's AI-sandbox AWS account, using the most secure path AWS offers.
Every action that builds the AI infrastructure has to be done as some identity. The choice of which identity (PayCargo Identity Center SSO, a one-off IAM user, or root) shapes the security posture of the platform from the very first action. Identity Center with MFA and short-lived tokens was chosen, which means the credential cannot be stolen and reused for more than a few hours, and can be centrally revoked the instant the operator leaves. This is also the path every future engineer onboarding to AI-sandbox will use.
If skipped: No way to deploy any AI-sandbox infrastructure. This step is the first credential gate; nothing downstream can run without it.
Every other block in the AI-sandbox build (bootstrap, identity, network, data, observability, and so on) is applied by either a human from a laptop or by CI from a GitHub Actions workflow. Bootstrap creates the CI identity (a deploy role assumable via OIDC federation). Nothing in the codebase creates the human identity, because nothing can create an identity inside an AWS account it has not yet entered.
Bootstrap is the first Terraform apply. Step 0 is what has to happen before Terraform can run at all. A human with administrator privileges in the AI-sandbox account must surface those credentials to the local AWS CLI before terraform apply can authenticate.
Bootstrap creates a deploy role for GitHub Actions to assume via OIDC. That role is a machine identity, intended for CI workflows running inside GitHub. It is not assumable by a human laptop, and it requires bootstrap to have already run successfully. So bootstrap depends on a human identity being present, and the human identity must therefore exist first.
Configure the local AWS CLI so that it can authenticate to the AI-sandbox AWS account as a named human with administrator privileges, using credentials that are short-lived, MFA-protected, and centrally revocable.
PayCargo operates an AWS IAM Identity Center instance for the organization. Identity Center is AWS's native single-sign-on service: it manages users (or syncs them from an external IdP), assigns them permission sets on specific AWS accounts, issues short-lived federated credentials when those users log in, and tracks every authentication and authorization decision in CloudTrail.
This step bound the local AWS CLI to that Identity Center instance and authenticated into the AI-sandbox account with the AdministratorAccess permission set.
Two files on the local machine changed:
~/.aws/config — added [profile ai-sandbox] bound to [sso-session paycargo] with the PayCargo portal URL.~/.aws/sso/cache/ — populated with a short-lived (12-hour) access token from the SSO login. This is the only credential material on disk; it expires automatically and re-issuing requires a fresh MFA-protected browser login.No file was created in ~/.aws/credentials. There are no static access keys associated with this identity.
This is the steady-state onboarding path for any future engineer joining the AI-sandbox build. Three prerequisites must be met by the PayCargo admin first; the engineer then runs five commands locally.
AdministratorAccess permission set on the AI-sandbox account (or a narrower permission set if appropriate to their role — admin is required only for bootstrap-level changes).https://d-90676daaf9.awsapps.com/start.# Always pass an explicit --profile name to avoid silently overwriting
# an existing profile (see Gotcha 1).
aws configure sso --profile ai-sandbox
# Answer the prompts:
# SSO session name: paycargo
# SSO start URL: https://d-90676daaf9.awsapps.com/start
# SSO region: us-east-1
# SSO registration scopes: (press Enter to accept the default)
#
# Browser opens to authenticate. Pick:
# Account: AI-Sandbox (959228203854)
# Permission set: AdministratorAccess
#
# Continue answering:
# CLI default Region: us-east-1
# CLI default output format: json
# CLI profile name: ai-sandbox (must match the --profile above)
# Log in and confirm
aws sso login --profile ai-sandbox
aws sts get-caller-identity --profile ai-sandbox
# Set as the active profile for the shell session
export AWS_PROFILE=ai-sandboxSubsequent sessions only need aws sso login --profile ai-sandbox (browser opens for re-auth, takes ~10 seconds). The SSO token caches for 12 hours by default.
The choice of Identity Center as the human-access path (rather than IAM users with access keys, or the AWS account's root user) is consequential. The properties it secures:
| Property | Identity Center (this path) | IAM users w/ keys | Root user |
|---|---|---|---|
| No long-lived credentials on disk | Yes — SSO tokens expire in 12 hours | No — access keys persist until rotated | No — root keys persist forever |
| MFA enforced on every credential issuance | Yes — via Identity Center MFA policy | Optional, requires explicit IAM policy | Not enforced for programmatic use |
| Centrally revocable | Yes — disable user in Identity Center, all sessions invalidate | Per-key, per-account rotation needed | Account closure or manual key deletion |
| Audit trail attributable to a named human | Yes — ARN includes the user's email | Only by IAM user name; mapping to human is fragile | No human attribution at all |
| Permission boundary survives the credential | Yes — permission set is independent of session | Policy attached to user; deletion of user takes policy with it | Root is not constrained by any boundary |
| Scales cleanly to multiple engineers | Yes — one click in Identity Center per new user | Per-account IAM user creation, key distribution, rotation | Cannot share root |
$0/month. AWS IAM Identity Center is free at the AWS layer. There is no per-user, per-session, or per-permission-set charge. If PayCargo wires Identity Center to an external IdP (Okta, Google Workspace, Azure AD) via SCIM, the external IdP may have its own per-user cost; that is independent of AWS and is unaffected by this step.
Permanent. Identity Center is the steady-state human-access path for the AI-sandbox account (and, by extension, every other PayCargo AWS account that uses the same Identity Center instance). There is no follow-on deletion, rotation, or migration required. SSO tokens auto-expire and auto-renew per session; no manual operator intervention is required for normal operation.
The local CLI profile ([profile ai-sandbox] in ~/.aws/config) and the SSO session ([sso-session paycargo]) persist on the engineer's laptop. If the laptop is lost or replaced, the config can be regenerated by re-running the aws configure sso sequence in Section 3.
The single command that confirms Step 0 succeeded:
$ aws sts get-caller-identity --profile ai-sandbox
{
"UserId": "AROA56VTU2NHFJN5IF4EE:mtang@paycargo.com",
"Account": "959228203854",
"Arn": "arn:aws:sts::959228203854:assumed-role/AWSReservedSSO_AdministratorAccess_1f350a57e8032361/mtang@paycargo.com"
}Three things must be true in the output for the step to be considered closed:
Account equals 959228203854 — the AI-sandbox account, not the PayCargo management account, not a sibling sub-account.Arn starts with arn:aws:sts::<account>:assumed-role/AWSReservedSSO_ — confirming this is a federated SSO identity, not an IAM user.AdministratorAccess — required for bootstrap, since bootstrap creates IAM, KMS, and Organizations-touching resources.If any of the three is wrong, do not proceed to Block 1. Diagnose and fix the CLI configuration first.
The work product of this step is mostly invisible at the AWS Console (it's a credential path, not a deployed resource). But three places confirm what's set up.
| What to see | Where to look | What confirms success |
|---|---|---|
| SSO portal accepts your login | Browser → https://d-90676daaf9.awsapps.com/start → log in with PayCargo email + MFA |
You see a list of AWS accounts. The AI-Sandbox (959228203854) tile appears and offers the AdministratorAccess role. |
| You're in the right account | Click AI-Sandbox → AdministratorAccess → "Management console" link | AWS Console opens. Top right: account dropdown reads AI-Sandbox (959228203854) and the federated user line reads AWSReservedSSO_AdministratorAccess_1f350a57e8032361/mtang@paycargo.com. |
| Your local CLI is bound to the same identity | Terminal: aws sts get-caller-identity --profile ai-sandbox |
Returns Account: 959228203854 and the same AWSReservedSSO_AdministratorAccess_ ARN as the console. |
The match between the browser console identity and the CLI identity is the verification that Step 0 succeeded. They are the same federated session viewed two different ways. If they diverge (different accounts, different ARN shapes), the CLI is talking to the wrong place — do not proceed to Step 1.
Two CLI-level issues surfaced during this step. Documented here so the next engineer does not lose time to the same things.
aws configure sso silently reuses the previous profile nameThe CLI does not always explicitly prompt for a profile name at the end of aws configure sso. If a previous SSO profile exists on the laptop, the CLI defaults the new SSO binding to that profile name and writes it without confirmation, silently overwriting the previous profile's config.
On this laptop, a profile named nvisionx existed (from an unrelated consulting client). After running aws configure sso for PayCargo without an explicit profile name, the [profile nvisionx] block in ~/.aws/config was rewritten to point at the PayCargo Identity Center and AI-sandbox account, breaking the nvisionx CLI binding.
Fix applied: manually renamed the mislabeled profile in ~/.aws/config to ai-sandbox. The nvisionx access still worked because a sibling profile bound to the same SSO session existed; without that, full nvisionx reconfiguration would have been required.
Prevention for future engineers: always pass an explicit --profile <name> flag:
aws configure sso --profile ai-sandboxThis forces the CLI to write under the named profile regardless of any defaults.
The engineer told the assistant they had SSO to AWS. This was taken to mean either federated SSO via an external IdP or Identity Center, without verification. The conversation looped for a long time trying to diagnose whether Identity Center existed for PayCargo, whether the engineer had been provisioned into it, and whether the existing paycargo-ocr IAM-user profile was the only credential path.
The resolution was a single screenshot: the AWS console account dropdown, showing the federated user string AWSReservedSSO_AdministratorAccess_1f350a57e8032361/mtang@paycargo.com. The AWSReservedSSO_ prefix is unambiguous evidence of Identity Center. The conversation could have ended an hour earlier with that screenshot up front.
Prevention for future engineers: when surfacing AWS access for a new account, the fastest disambiguation is to log into the AWS console in a browser and screenshot (or paste the text of) the federated user string from the account dropdown. The presence or absence of AWSReservedSSO_ answers in two seconds what abstract questions take much longer to chase down.
How Step 0 is handled tells future engineers what the security culture of this platform is. Three doctrine principles trace directly back to this choice.
The AI-sandbox doctrine assumes credentials are either time-bounded (SSO tokens, OIDC web identity tokens, STS-issued temporary credentials) or do not exist at all (the deploy role created by bootstrap has no static keys). The permission boundary deployed in bootstrap blocks IAM user creation precisely to enforce this. Step 0 using Identity Center reinforces the doctrine from the very first credential the platform ever sees.
CloudTrail logs the identity of every API call. The federated SSO role ARN includes the user's email address, making the link from log entry to human intrinsic and self-documenting. With an IAM user named mike-bootstrap, the link from log to human depends on someone remembering who that user was, which decays over time.
Whoever can authenticate as the bootstrap operator can do anything inside the account during the bootstrap window. There is no permission boundary yet; bootstrap is the thing that deploys it. This is the only window of unrestricted access in the lifetime of the platform. The credential used for that window is short-lived (12-hour SSO token), MFA-protected (Identity Center MFA on issuance), and centrally revocable (one click in Identity Center invalidates every session). This is the most defensible posture available without changing the AWS API surface.
Step 0 looks like plumbing. It is actually the most consequential identity decision in the build — the credential that does bootstrap has unconstrained access to the AI-sandbox account for the duration of that apply. Using Identity Center for it is the difference between "the platform's first credential exemplifies the doctrine" and "the platform's first credential is the first exception to the doctrine." The doctrine is more credible when it has no exceptions.
Step 0 is complete the moment aws sts get-caller-identity returns the AI-sandbox account ID with a federated SSO admin ARN (see Section 6). Immediately proceed to Block 1 — bootstrap apply.
Block 1 will:
After Block 1 succeeds, every subsequent module (identity, network, data, observability, and so on) is applied via CI, not from a laptop. The human credential established in Step 0 stays in place for break-glass and for re-applying bootstrap itself, but day-to-day operations move off the laptop entirely.