Listen to this Post
Introduction
AWS Bedrock’s introduction of long-term API keys was designed to accelerate AI development by simplifying authentication. However, security researchers have uncovered a critical flaw in the generation process: when a developer creates a long-term key through the console, AWS automatically provisions a persistent IAM user with an overly permissive policy that can delete guardrails, modify custom models, and access KMS keys. These “phantom IAM users” remain active indefinitely, creating a massive supply chain security risk that persists even after the key is revoked.
Learning Objectives
- Understand how AWS Bedrock long-term API keys create persistent IAM users with the `AmazonBedrockLimitedAccess` managed policy, and why this policy is dangerously over-privileged.
- Learn to identify “phantom users” using AWS CLI commands and open-source tooling like BKS or Prowler, and implement effective revocation and cleanup procedures.
- Deploy preventative controls including Service Control Policies (SCPs) to block long-term key creation and enforce least-privilege access for AI workloads.
You Should Know
- Demystifying the “Phantom User” – Anatomy of a Broken Authentication Model
AWS Bedrock API keys behave fundamentally differently from standard AWS credentials. Unlike typical IAM access keys that require SigV4 request signing, Bedrock API keys function as simple bearer tokens, which bypass the cryptographic signing process. The long-term API key encodes the AWS account ID and IAM user name directly in plain Base64; a decoded key reveals a string such as BedrockAPIKey-a2ng-at-888888888888, exposing the IA M user name and account ID in plaintext.
The API key generation process is uniquely risky. When a developer selects “Generate API Key” for long-term use on the Bedrock console or passes the associated API call, AWS automatically creates a dedicated IAM user with a name format like BedrockAPIKey-XXXX. This user is then attached to the AWS managed policy AmazonBedrockLimitedAccess. Despite its name, the policy is far from limited. It includes more than half of the Bedrock service’s privileges, including permission to:
– Delete custom models, guardrails, and provisioned concurrency
– Access training data stored in S3 buckets
– Pass IAM roles to other services (iam:PassRole)
– Read KMS keys used for model encryption
If a developer modifies the permissions attached to that user – for example, by adding `bedrock:` policies or broader IAM privileges – the API key becomes a master key that can effectively control the entire AI environment. The most dangerous aspect is that revoking the API key does not delete the underlying phantom IAM user. That user, along with all its permissions, continues to exist indefinitely, waiting to be discovered and exploited.
Risk Quantification: If an attacker obtains a leaked Bedrock API key, they inherit the full permission set of the associated IAM user. They can then delete guardrails to remove content safety barriers, steal custom‑ tuned models, run up massive bills by invoking the most expensive models at high volume, and pivot into the rest of the AWS account by leveraging iam:PassRole. Recent research has also demonstrated that long-lived API keys can bypass Service Control Policy (SCP) enforcement entirely, as the authentication path does not always trigger SCP evaluation.
- BKS Toolkit – Discovering and Remediating Phantom IAM Users
To address this oversight, the security community has released several open‑source toolkits. The most notable is the Bedrock Keys Security (BKS) toolkit, which can be installed via:
pip3 install bedrock-keys-security
Step‑by‑step guide to remediation:
1. List Phantom Users Using AWS CLI:
Find all IAM users with "Bedrock" in their name aws iam list-users --query "Users[?contains(UserName, 'Bedrock') || contains(UserName, 'bedrock')].[UserName,CreateDate,UserId]" --output table
For each suspicious user, verify its attached policies:
aws iam list-attached-user-policies --user-name [bash] If the policy is AmazonBedrockLimitedAccess, examine its permissions aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess --version-id v1
2. Use the BKS Toolkit for Automated Cleanup:
The BKS toolkit automates the detection of phantom users, offline decoding of leaked keys, and bulk revocation of compromised credentials. After installation, you can run a full audit:
bedrock-keys-security audit --profile your-aws-profile
This command enumerates all Bedrock API keys across your account and cross‑references them with their associated IAM users.
3. Revoke a Compromised API Key:
If you suspect exposure, immediately deactivate the specific credential using the AWS CLI or Python SDK:
aws iam update-service-specific-credential \ --service-specific-credential-id ACCAEXAMPLE123EXAMPLE \ --status Inactive
In Python, you can revoke the key with:
import boto3
iam_client = boto3.client("iam")
iam_client.update_service_specific_credential(
service_specific_credential_id="ACCAEXAMPLE123EXAMPLE",
status="Inactive"
)
Critical Note: Revoking the key does NOT delete the IAM user. You must also manually delete the `BedrockAPIKey-XXXX` IAM user [13†L3-L12].
4. Delete the Phantom IAM User:
Delete all access keys from the user aws iam list-access-keys --user-name BedrockAPIKey-XXXX aws iam delete-access-key --user-name BedrockAPIKey-XXXX --access-key-id KEY_ID Delete the user aws iam delete-user --user-name BedrockAPIKey-XXXX
3. Short-term vs. Long-term: Choosing the Safer Path
AWS offers two types of Bedrock API keys. Short‑term keys are effectively pre‑signed URLs using SigV4, lasting up to 12 hours. They inherit the permissions of the session that created them and expire automatically, which dramatically reduces the window of exposure. The recommended approach from AWS is to avoid API keys entirely and use temporary STS credentials whenever possible. However, when third‑party software requires a static bearer token, short‑term API keys are the next best option.
How to generate a short‑term Bedrock API key:
Short‑term keys are generated through the Bedrock console or using the aws-bedrock‑token‑generator client library. They look like a long base64‑encoded pre‑signed URL. Decoding such a key reveals a standard AWS signature v4 request URL that expires within hours.
- LLMjacking – How Attackers Monetize Leaked Bedrock Keys
Once an attacker obtains a valid Bedrock API key, they can immediately use it to invoke any LLM model available in the region. This practice, known as “LLMjacking,” allows adversaries to run their own prompts at the victim’s expense, generating massive usage bills. In recent campaigns, attackers have used stolen AWS credentials to interact with Bedrock models for generating malicious content, including custom jailbreaks that bypass content filters. Because Bedrock is integrated with other AWS services, a compromised API key can also be used to exfiltrate training data from S3 or KMS‑encrypted resources. Monitoring CloudTrail logs for the `CallWithBearerToken` action is essential to detect such abuse. Each API call using a Bedrock API key appears in CloudTrail with the additional event data callWithBearerToken: true.
- Preventative Controls – SCPs, IAM Policies, and Guardrails
The most effective way to eliminate the risk is to prevent the creation of long‑term Bedrock API keys altogether. AWS recommends implementing a Service Control Policy (SCP) that explicitly denies the `CreateServiceSpecificCredential` action when the service name is bedrock.amazonaws.com. This guidance is now part of the AWS Security Blog’s official recommendations.
Example SCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyBedrockApiKeys",
"Effect": "Deny",
"Action": "iam:CreateServiceSpecificCredential",
"Resource": "",
"Condition": {
"StringEquals": {
"iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com"
}
}
}
]
}
In addition to SCPs, you should enforce least‑privilege IAM policies that limit Bedrock access to only the necessary models and actions. For organizations that have already banned IAM users altogether, the SCP blocks this new feature automatically.
Monitoring and Alerting:
- Set up EventBridge rules that trigger on `CreateServiceSpecificCredential` events with the condition
serviceName = bedrock.amazonaws.com. - Use security tools such as Prowler or the BKS toolkit to perform daily scans of all IAM users for any with names matching `BedrockAPIKey-` and review their permissions.
- For existing phantom users, export a list of all `BedrockAPIKey-` users and evaluate whether each has any active access keys attached. If not, delete the user immediately.
What Undercode Say
- Key Takeaway 1: AWS Bedrock long‑term API keys create persistent IAM users that remain active even after the API key is revoked. This vulnerability turns a developer convenience feature into a permanent backdoor, allowing attackers to pivot from a compromised key to full control of the AI pipeline.
- Key Takeaway 2: Proactive mitigation requires a multi‑layered approach: blocking key creation with SCPs, automating detection using open‑source tooling like BKS, and enforcing strict IAM least‑privilege policies. The easiest path to security is to avoid long‑term keys entirely and use temporary STS credentials instead.
Prediction: As cloud providers race to fuel generative AI adoption, the tension between developer convenience and security will only intensify. Over the next 12–18 months, expect AWS to either deprecate the “never expires” long‑term API key option or introduce mandatory expiration limits with forced rotation. Organizations that fail to implement SCPs and automated remediations today will face a wave of LLMjacking incidents, just as we saw with exposed database credentials in the 2010s. The industry is likely to see the emergence of dedicated CSPM (Cloud Security Posture Management) rules that specifically target Bedrock API key generation and phantom user cleanup, turning this manual process into an automated guardrail.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mrcloudsec Aws – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
