hermes - 💡(How to fix) Fix [Bug]: auth_type="aws_sdk" never feeds into subprocess credential blocklist; AWS env vars leak to terminal/execute_code [1 pull requests]

Bug Description

When the built-in bedrock provider uses auth_type="aws_sdk" (the default), AWS credential environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, etc.) are not registered in PROVIDER_REGISTRY.api_key_env_vars and therefore are never added to _HERMES_PROVIDER_ENV_BLOCKLIST. As a result, all agent-spawned terminal and code-execution subprocesses inherit AWS credentials that the agent did not intend to expose.

This was discovered when opencode models run inside a Hermes terminal enumerated the entire Amazon Bedrock catalog because AWS_BEARER_TOKEN_BEDROCK leaked into the subprocess environment.

Impact

• Subprocesses (terminal, execute_code, MCP servers, agent delegations) can silently use leaked AWS credentials to make Bedrock calls or other AWS API requests.
• Cost-incurring API calls may occur without the user's awareness.
• Any tool that enumerates available models will show Bedrock models when it shouldn't.
• If AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY leak, the subprocess inherits all of the user's AWS capabilities, not just Bedrock access.

Related

• #7990 — broader effort to block cloud provider credentials from subprocesses
• PR #22647 — attempted salvage of #7990; was closed without merge
• agent/bedrock_adapter.py::has_aws_credentials() already checks some AWS env vars on the agent side, but this logic doesn't feed into the subprocess blocklist.

Steps to Reproduce

1. Configure Hermes with provider: bedrock or amazon-bedrock-mantle
2. Set AWS credentials via environment variables (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_BEARER_TOKEN_BEDROCK)
3. Launch a terminal session via Hermes
4. Run env | grep AWS

Expected Behavior

No AWS_* credential variables present.

Actual Behavior

Full set of AWS credentials is visible in the shell.

Affected Component

Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

No response

Debug Report

[REDACTED]

Operating System

Fedora 43

Python Version

3.11.15

Hermes Version

Hermes Agent v0.14.0 (2026.5.16)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

hermes_cli/auth.py defines the Bedrock provider like this:

"bedrock": ProviderConfig(
    id="bedrock",
    auth_type="aws_sdk",
    inference_base_url="https://bedrock-runtime.us-east-1.amazonaws.com",
    api_key_env_vars=(),  # <-- empty tuple
    base_url_env_var="BEDROCK_BASE_URL",
),

and _build_provider_env_blocklist() in tools/environments/local.py only consumes api_key_env_vars:

for pconfig in PROVIDER_REGISTRY.values():
    blocked.update(pconfig.api_key_env_vars)
    if pconfig.base_url_env_var:
        blocked.add(pconfig.base_url_env_var)

The auth_type="aws_sdk" field is never special-cased, so AWS SDK env vars never get blocked.

Proposed Fix (optional)

Add api_key_env_vars to the built-in Bedrock ProviderConfig for the standard boto3 credential variables:

api_key_env_vars=(
    "AWS_ACCESS_KEY_ID",
    "AWS_SECRET_ACCESS_KEY",
    "AWS_SESSION_TOKEN",
    "AWS_BEARER_TOKEN_BEDROCK",
    "AWS_PROFILE",
    "AWS_DEFAULT_REGION",
    "AWS_ROLE_ARN",
    "AWS_WEB_IDENTITY_TOKEN_FILE",
),

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR