The AWS Bedrock API Keys Security Guide Part 2: Detection, Prevention, and Response

This guide offers further documentation on the security risks introduced by the authentication method AWS launched in July 2025 for Amazon Bedrock. Part 1 of this series documented the risks of AWS Bedrock API keys: phantom IAM users with administrative permissions, the misleading scope of AmazonBedrockLimitedAccess, and LLMjacking exposure of up to $18,000/day per region. Part 2 will cover detection, prevention, incident response, and migration to STS.

CloudTrail is the primary detection layer for Bedrock API key abuse. This section covers detection signals, events to monitor, and deployment guidance for CloudWatch, EventBridge, and SIEM platforms.

The Primary Signal: callWithBearerToken

When recorded in CloudTrail, every Bedrock API key request carries `additionalEventData.callWithBearerToken = true`. SigV4-authenticated requests do not. The field is the definitive signal for both long-term and short-term keys.

Service Control Policies

Service Control Policies (SCPs) are the primary preventive control for Bedrock API key risks. The appropriate SCP depends on whether you need Bedrock API keys at all.

If you don't use Bedrock API keys, deploy a lockdown SCP that denies both `iam:CreateServiceSpecificCredential` (creation) and `bedrock:CallWithBearerToken` (usage) across the organization.

Long-term Key Compromise

Three response options for a compromised long-term Bedrock API key, ordered from fastest to most thorough:

Option 1: Inline deny policy (fastest)

Attach an inline deny policy to the phantom user. This blocks all Bedrock API key usage for that user within seconds, without needing to identify the specific credential ID:

STS temporary credentials are the recommended replacement. They expire in 1-12 hours, create no IAM users, use SigV4 signing, and scope through IAM role policies. They eliminate the entire class of risks in this guide: phantom users, policy scoping gaps, privilege escalation, bearer-token exposure.

Assume a role that has the necessary Bedrock permissions, export the returned temporary credentials, and use Bedrock through any standard AWS SDK or CLI:

1# Assume a role with Bedrock permissions 2aws sts assume-role \ 3--role-arn arn:aws:iam::ACCOUNT:role/BedrockRole \ 4--role-session-name bedrock-session \ 5--duration-seconds 36006 # Export the temporary credentials 7export AWS_ACCESS_KEY_ID=ASIA... 8export AWS_SECRET_ACCESS_KEY=... 9export AWS_SESSION_TOKEN=...10 # Use Bedrock normally 11aws bedrock-runtime converse \ 12 --model-id us.anthropic.claude-opus-4-7 \ 13 --messages '[{"role":"user","content":[{"text":"hello"}]}]'

If you cannot fully migrate from Bedrock API keys, these controls reduce risk:

• Short-term keys only: 12-hour maximum to avoid phantom user creation.

• CloudTrail alerts: monitor all API key usage through alerts on the callWithBearerToken signal.

• SCPs against escalation: block IAM access key creation on phantom users to prevent the privilege escalation path.

• Frequent rotation: rotate keys monthly at minimum.

• Model invocation logging: enable as both a detective control and an attacker deterrent.

Among these, the SCP denying `bedrock:CallWithBearerToken` is the highest-impact control.

Step 1: Audit for Phantom Users

Run the Bedrock Keys Security (BKS) toolkit to scan the account for phantom IAM users:

1bks scan

Alternatively, query IAM directly:

1aws iam list-users | grep BedrockAPIKey

If either command returns results, phantom users exist in the account. For each one found, check its credential status:

1aws iam list-service-specific-credentials --user-name BedrockAPIKey-xxx2aws iam list-access-keys --user-name BedrockAPIKey-xxx

The results determine the risk level and required action:

• Active service-specific credentials present: the phantom user is operational and the associated Bedrock API key is still in use.

• No credentials remain: the user is an orphaned phantom that is safe to clean up using bks cleanup.

• IAM access keys (AKIA...) present: the privilege-escalation path is exploited or prepared. Investigate immediately.

Step 2: Deploy Detection

Configure CloudTrail monitoring for four event patterns:

• API key creation: `CreateServiceSpecificCredential` events with `serviceName = bedrock.amazonaws.com`.

• API key usage: any Bedrock action where `additionalEventData.callWithBearerToken = true`.

• Phantom user creation: `CreateUser` events where the `userName` starts with `BedrockAPIKey-`.

• Privilege escalation (CRITICAL): `CreateAccessKey` events targeting `BedrockAPIKey-*` users.

The Detection Strategies section provides query templates for CloudWatch Logs Insights, EventBridge, and generic SIEM platforms.

Step 3: Implement Prevention

If you don't need Bedrock API keys, deploy an SCP that denies both `iam:CreateServiceSpecificCredential` and `bedrock:CallWithBearerToken` across the organization (template: https://github.com/BeyondTrust/bedrock-keys-security/blob/main/scps/1-block-all-keys.json).

Step 4: Restrict If Required

If you need Bedrock API keys:

• Maximum 90-day expiry: use the iam:ServiceSpecificCredentialAgeDays condition key to prevent keys that never expire (template: https://github.com/BeyondTrust/bedrock-keys-security/blob/main/scps/2-enforce-90day-max.json).

• CloudTrail alerts: monitor all usage through alerts on the callWithBearerToken signal.

• Monthly rotation: rotate keys monthly at minimum.

• Block phantom escalation: deploy an SCP to block iam:CreateAccessKey on BedrockAPIKey-* users (https://github.com/BeyondTrust/bedrock-keys-security/blob/main/scps/4-block-phantom-access-keys.json)

• Short-term over long-term: prefer short-term keys to avoid phantom user creation entirely (https://github.com/BeyondTrust/bedrock-keys-security/blob/main/scps/3-block-long-term-only.json)

• Migrate to STS where feasible (see Migration to AWS STS).

Bedrock API keys solve a real integration problem but introduce a class of risks that most organizations are not equipped to detect by default:

• Phantom IAM users persist beyond the credential lifecycle, accumulating in accounts with no automated cleanup.

• The AmazonBedrockLimitedAccess policy grants administrative Bedrock control plus IAM, VPC and KMS reconnaissance, despite its name.

• A privilege-escalation pivot exists through iam:CreateAccessKey on phantom users, exposing the full policy scope outside the Bedrock authentication boundary.

The detection signals, preventive SCPs and incident response procedures in this guide cover the full lifecycle. Highest-impact controls in priority order:

• AWS STS temporary credentials. The recommended replacement; eliminates the entire class of risk documented across both parts of this guide.

• SCP denying bedrock:CallWithBearerToken. The single highest-impact preventive control where Bedrock API keys are unavoidable.

• SCP denying iam:CreateAccessKey on BedrockAPIKey-* users. Closes the privilege-escalation pivot.

• CloudTrail alerting on additionalEventData.callWithBearerToken = true. The foundational detection signal; layer higher-confidence rules on top.

For organizations with active Bedrock API key usage, run bks scan first to discover existing phantom IAM users, then implement detection before deploying SCPs that may break in-flight workflows.

Open-source Toolkit and Templates

• Bedrock Keys Security Toolkit: https://github.com/BeyondTrust/bedrock-keys-security

• SCP Templates: https://github.com/BeyondTrust/bedrock-keys-security/tree/main/scps

• Detection Content: https://github.com/BeyondTrust/bedrock-keys-security/tree/main/detections

AWS Official Documentation

• Bedrock API Keys User Guide:
  https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html

• AWS Security Blog: Securing Bedrock API Keys:
  https://aws.amazon.com/blogs/security/securing-amazon-bedrock-api-keys-best-practices-for-implementation-and-management/

• Service-Specific Credentials:
  https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_service-specific-creds.html

• AWS Security Token Service (STS):
  https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html

• CloudTrail Event Reference:
  https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html

• Model Invocation Logging: https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html

• AWS Service Control Policies (Organizations): https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

• CloudTrail data events: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html

Phantom Labs™ researchers "think like attackers" to expose privilege escalation paths and identity attack vectors, helping defenders proactively uncover misconfigurations and detect threats in complex hybrid and cloud environments. Using advanced graph modeling, Phantom Labs researchers map attack paths to privileged access across cloud and on-premises infrastructure.

• https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys

• https://www.beyondtrust.com/blog/entry/pwning-aws-agentcore-code-interpreter

• https://www.beyondtrust.com/blog/entry/machine-learning-identity-graph-anomaly-detection