Discover AWS profile, region, and identity before deployment
Discovers AWS profile, region, account, and caller identity before deployment work, surfacing SSO limitations that prevent IAM role creation.
Why it matters
Automatically read and validate the user's local AWS configuration to establish the active profile, region, account ID, and caller identity before any AWS work begins, preventing deployment failures caused by missing credentials, expired SSO sessions, or incorrect region assumptions.
Outcomes
What it gets done
Resolve the active AWS profile from environment variables or config files without guessing
Determine the effective region using the correct precedence order and validate it exists
Verify credentials are valid and retrieve account ID and caller ARN via STS
Detect SSO-based authentication and warn about IAM role creation limitations upfront
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-hf-cloud-aws-context-discovery | bash Overview
AWS Context Discovery
This skill runs AWS CLI commands to discover your active profile, region, account ID, and caller identity without exposing credentials. It validates your authentication and identifies whether you're an IAM user, SSO assumed-role, or regular assumed-role - warning you upfront if SSO limitations will prevent IAM role creation during deployment. Run this at the start of any AWS workflow to establish verified context before attempting SageMaker deployments or other AWS operations. It's especially valuable for diagnosing expired SSO sessions, missing profiles, or understanding why you might need to use existing IAM roles instead of creating new ones.
What it does
AWS Context Discovery inspects masked AWS CLI metadata to establish the effective profile, region, account ID, and caller identity before any AWS deployment work begins. It validates credentials via aws sts get-caller-identity and identifies whether the caller is an IAM user, SSO assumed-role, or regular assumed-role - surfacing SSO limitations that prevent IAM role creation before deployment fails.
When to use - and when NOT to
Use this skill at the start of any AWS workflow to establish verified context for SageMaker planning, deployment, or other AWS operations. Run it to diagnose expired SSO sessions, missing profiles, or configuration overrides before attempting resource creation.
Do NOT use this skill if you need to inspect credential values directly - it deliberately masks secrets and never opens ~/.aws/credentials, credential-process output, or SSO token caches.
Inputs and outputs
You provide an optional profile name; the skill uses AWS CLI commands to discover the rest. If no profile is named, it identifies the active profile from masked metadata.
You receive a one or two-line summary like: "Working with profile my-profile in eu-west-1, account 123456789012. You're authenticated via SSO, so we'll need to use an existing IAM role rather than create one." If credentials are expired or the profile is missing, you receive a specific error before any deployment attempt.
The skill resolves region by checking: region explicitly named by the user in conversation, region reported by aws configure list --profile "$profile", region reported by aws configure get region --profile "$profile", and only asks the user after these methods fail. It never falls back to hardcoded defaults like us-east-1.
Credentials and identity are validated with:
aws sts get-caller-identity --profile "$profile" --region "$region"
This single call confirms credentials are valid, returns the account ID for ARN construction, and returns the caller ARN that reveals principal type.
Integrations
Integrates with AWS CLI for profile and region discovery via aws configure list-profiles, aws configure list, and aws configure get region. Uses AWS STS for identity validation. Provides verified context to downstream SageMaker planning and deployment skills.
Who it's for
Built for developers and data scientists working with AWS SageMaker or other AWS services who authenticate via SSO and need to understand their effective permissions before deployment. The skill's highest-leverage feature is identifying SSO assumed-role principals (ARN pattern arn:aws:sts::<acct>:assumed-role/AWSReservedSSO_<...>/<email>) and surfacing that these principals typically cannot create IAM roles - turning a confusing mid-deployment iam:CreateRole failure into a five-second conversation about using existing roles instead.
Source README
AWS Context Discovery
Before doing any AWS work, inspect only masked AWS CLI metadata. Don't guess the region, and don't ask the user for things the CLI already answers. Never open or print ~/.aws/credentials, credential-process output, secret environment variables, access keys, session tokens, or SSO token caches.
When to Use
- Establish the effective AWS profile, region, account, and caller before AWS work.
- Diagnose expired SSO sessions, missing profiles, or configuration overrides.
- Provide verified context to later SageMaker planning and deployment skills.
What to discover
Run these at the start of the AWS work and remember the results for the rest of the session.
1. Active profile
Use a profile the user explicitly named, otherwise use the profile identified by masked AWS CLI metadata. If the named profile is absent from aws configure list-profiles, surface that clearly.
2. Region
Resolution order - stop at the first one that produces a value:
- Region the user explicitly named in this conversation
- Region reported by
aws configure list --profile "$profile" - Region reported by
aws configure get region --profile "$profile" - Ask the user - but only after the first four have failed
Do not fall back to us-east-1 or any other hardcoded default.
3. Credentials, account ID, caller ARN
aws sts get-caller-identity --profile "$profile" --region "$region"
Three purposes in one call: confirms credentials are valid (stop if not), returns the Account ID (needed for ARN construction), returns the Arn of the caller.
4. Identify SSO / assumed-role principals
The Arn field tells you what kind of principal this is. The pattern matters because it determines what IAM operations the caller can do.
| ARN pattern | Type | IAM write capability |
|---|---|---|
arn:aws:iam::<acct>:user/<name> |
IAM user | Depends on attached policies |
arn:aws:sts::<acct>:assumed-role/AWSReservedSSO_<...>/<email> |
SSO assumed-role | Typically none - can't create/modify IAM roles |
arn:aws:sts::<acct>:assumed-role/<role>/<session> |
Regular assumed-role | Depends on the role |
If the caller is SSO, surface this immediately before later skills hit iam:CreateRole and fail:
Heads up: you're authenticated via SSO (
AWSReservedSSO_<PermissionSet>_...). SSO principals usually can't create IAM roles directly. If we need a SageMaker execution role, I'll look for an existing one first - if none exists, you'll need to ask whoever manages your AWS access to create one.
This is the highest-leverage thing this skill does. Surfacing it now turns a confusing mid-deployment error into a five-second conversation.
Commands to run
### Profiles and masked effective metadata; never read credential files directly
aws configure list-profiles
aws configure list --profile "$profile"
aws configure get region --profile "$profile"
### Validate credentials and get identity
aws sts get-caller-identity --profile "$profile" --region "$region"
aws configure list masks credential values and identifies their source. Use these metadata commands instead of parsing AWS files or inspecting secret-bearing environment variables. If the CLI cannot resolve a profile or region without exposing credentials, stop and ask the user for the non-secret profile or region value.
What to report back
One or two lines, not a wall of text:
Working with profile
my-profileineu-west-1, account123456789012. You're authenticated via SSO, so we'll need to use an existing IAM role rather than create one.
Don't ask the user to confirm the region you just read from their config - they configured it; that is the confirmation.
If something is wrong (credentials expired, profile doesn't exist, no region anywhere), stop and surface the specific error before continuing.
Limitations
- Discovery may reveal account IDs, role ARNs, or profile names; report only what the task needs and never expose secrets or session tokens.
- STS identity checks require network access and valid credentials.
- A valid identity does not imply permission to change resources.
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.