Bedrock Credentials are inherited by child processes and override user's ~/.aws/ Credentials

Resolved 💬 3 comments Opened Mar 1, 2026 by ori-n Closed Mar 4, 2026

Preflight Checklist

  • [x] I have searched existing issues for similar behavior reports
  • [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

When Bedrock credentials are defined in ~/.claude/settings.json, they are injected into the environment and inherited by all child processes, including shell commands and MCP servers.

As a result, the AWS CLI uses these injected credentials instead of the user’s expected configuration from ~/.aws/config and ~/.aws/credentials.

This creates confusion and unexpected behavior when developers assume their default AWS profile is in use.

What Claude Actually Did

  • Credentials from ~/.claude/settings.json are loaded into environment variables
  • All child processes inherit these credentials
  • aws CLI uses the inherited credentials instead of the user’s ~/.aws configuration
  • Users encounter authentication errors or make API calls with unintended credentials

Expected Behavior

  • Shell commands should use the user’s configured ~/.aws credentials (or none, if not configured)
  • Clear separation between Claude Code’s internal permissions (Bedrock access) and the user’s shell and CLI permissions

Files Affected

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

Reproduction Scenario – ~/.claude Overrides ~/.aws

Configure ~/.aws/credentials with Account A and verify aws sts get-caller-identity returns Account A. Then add different Bedrock credentials (Account B) to ~/.claude/settings.json and launch Claude Code.

From within Claude, run aws sts get-caller-identity again. It will return Account B instead of Account A because the credentials from ~/.claude/settings.json are injected as environment variables and override the ~/.aws configuration for child shell processes.

Reproduction Scenario – Bedrock-Only Credentials Escalate to S3 Access

Install Claude Code and create an IAM user (my-claude-code-user) with only AmazonBedrockLimitedAccess, storing its credentials in ~/.claude/settings.json. In a clean terminal with no AWS credentials configured, verify aws sts get-caller-identity fails, then start Claude Code and request: “List my S3 buckets.” The command is denied by IAM, but it authenticates successfully as my-claude-code-user, proving credentials from settings.json are injected into the shell environment.

Next, attach AmazonS3ReadOnlyAccess to the same IAM user. Without restarting Claude Code, repeat: “List my S3 buckets.” This time all buckets are listed successfully. This demonstrates that credentials intended only for Bedrock are inherited by shell commands, and any permission added to the IAM user immediately expands AWS CLI access inside Claude Code, with no additional restriction applied by the tool itself.

Finally, detach the policies, delete the IAM user, and remove the local ~/.claude/settings.json configuration.

Claude Model

Haiku

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.63 (Claude Code)

Platform

AWS Bedrock

Additional Context

Impact

  • Uncertainty about which AWS identity is active
  • Accidental API calls to unintended AWS accounts or resources
  • Debugging complexity due to credential precedence
  • Expanded attack surface (e.g., prompt injection leading to unintended AWS operations)

Recommendations

Credential Isolation
Credentials defined in ~/.claude/settings.json should be restricted to Claude Code’s internal Bedrock API calls only.

Persistent Visibility
Display a banner indicating the active AWS identity and permission scope.

Documentation Guidance
Recommend using Bedrock-specific credentials (e.g., AWS_BEARER_TOKEN_BEDROCK) instead of global AWS environment variables.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗