The AWS Bedrock API Keys Security Guide Part 1: Risks, Vulnerabilities, and Attack Techniques

Figure 1: Output of bks scan showing 15 phantom IAM users discovered in a single AWS account. The toolkit classifies each user as Active (credentials still in use), Orphaned (no active credentials, safe to clean up), or At Risk (IAM access keys detected, indicating potential privilege escalation). The summary identifies 10 orphaned users and flags 1 user with IAM access keys for immediate investigation.

Figure 2: Short-term API key authentication. The key inherits the caller's existing session permissions. No IAM user is created.

3. Long-Term Bedrock API Keys: These should be avoided unless packaged software requires static, long-lived credentials and can’t be modified. They can be configured to expire between one and 365 days, or set to never expire. When created through the AWS Console, they trigger the automatic phantom user provisioning described in the previous ‘Background’ section. When created through CLI or SDK, the IAM user must already exist. Long-term keys always begin with the prefix ABSK followed by a base64-encoded string. CloudTrail records CreateUser, AttachUserPolicy, and CreateServiceSpecificCredential events during Console-based provisioning.

Figure 3: Long-term API key provisioning through the AWS Console. Amazon Bedrock automatically creates a dedicated IAM user with the AmazonBedrockLimitedAccess policy attached.

Figure 4: CloudTrail event sequence is recorded when a long-term Bedrock API key is created through the AWS Console. The three events (CreateUser, AttachUserPolicy, and CreateServiceSpecificCredential) execute in sequence without explicit user confirmation.

AWS STS temporary credentials should be the default for Bedrock access. The cases that genuinely require API keys typically fall into three categories: legacy applications with hardcoded bearer token authentication, third-party AI platforms that can't use SigV4 signing, and vendor software requiring static credentials without STS support. If none of these apply, STS temporary credentials are the correct choice. AWS's own guidance reinforces this, recommending short-term keys for production use and long-term keys "only for exploratory purposes".

When long-term keys are unavoidable, organizations should enforce a maximum 90-day expiry and never select the "never expires" option. Monitor all usage through CloudTrail alerts on the callWithBearerToken signal, rotate keys monthly at minimum, deploy SCPs to block IAM access key creation on phantom users, review and scope down the AmazonBedrockLimitedAccess policy, and plan migration to STS as soon as technically feasible.

Figure 5: The Bedrock API keys management page in the AWS Console. The "generate long-term API key" button initiates the provisioning sequence that creates a phantom IAM user.

Figure 6: The key generation result. The Console returns the ABSK credential and displays the associated IAM username (BedrockAPIKey-xxxx), but the user creation itself occurred automatically without a separate confirmation step.

Figure 7: The phantom IAM user as it appears in the IAM Console. The AmazonBedrockLimitedAccess policy is already attached. This user was created automatically during API key provisioning and will persist indefinitely, even after the associated key is deleted.

The Persistence Problem

The most critical characteristic of phantom users is that they never auto-delete. The IAM user and its attached AmazonBedrockLimitedAccess policy persist indefinitely, regardless of what happens to the associated Bedrock API key. The key can expire, be manually deleted, or become inactive, but the phantom user still retains its full permissions.

Figure 8: IAM Console showing 31 phantom users accumulated in a single AWS account. Each BedrockAPIKey-* identity was created automatically during long-term API key provisioning and persists regardless of whether the associated credential is still active.

The implication is that every long-term Bedrock API key ever created through the Console has left a persistent IAM identity with administrative Bedrock permissions in the account, exploitable by anyone with iam:CreateAccessKey permissions.

Note: The persistent risk is the IAM identity, not the ABSK credential. Even after the ABSK credential expires or is deleted, the phantom user remains with the AmazonBedrockLimitedAccess policy attached. The credential has a lifecycle; the phantom user does not.

Figure 9: The AmazonBedrockLimitedAccess policy as displayed in the IAM Console, showing the Bedrock action permissions, including create, delete, and invoke operations across all Bedrock resources.

Reconnaissance Permissions

Beyond Bedrock operations, the policy grants permissions across three additional AWS services:

• iam:ListRoles: Enumerate all IAM roles in the account, providing visibility into the identity infrastructure.
• ec2:DescribeVpcs, ec2:DescribeSubnets, ec2:DescribeSecurityGroups: Map the complete network topology and firewall rules.
• kms:DescribeKey: Discover encryption keys and their configurations.

None of these permissions are required for Bedrock API key authentication. They exist in the policy because the phantom user is a full IAM user, and the policy was designed for broader Bedrock administration, not for scoping down to bearer token access.

Figure 10: Continuation of the AmazonBedrockLimitedAccess policy, showing the cross-service reconnaissance permissions granted beyond Bedrock.

The Scoping Gap

AWS correctly scoped the Bedrock API key credential itself to Bedrock operations only. However, the IAM user that backs the credential is not scoped in the same way. This creates two distinct credential types with different permission boundaries on the same identity.

Figure 11: The phantom IAM user can support three access methods, only one of which exists by default. The Bedrock API key (scoped to Bedrock) is created during provisioning. IAM access keys (full policy permissions) only exist if iam:CreateAccessKey is invoked on the user. Console access only exists if iam:CreateLoginProfile is invoked. The AmazonBedrockLimitedAccess policy applies to all three credential types, but only the Bedrock API key enforces Bedrock-specific scoping at the credential boundary.

An ABSK bearer token authenticates only to Bedrock operations. However, anyone with iam:CreateAccessKey permissions can create standard IAM access keys (AKIA...) for a phantom user. Those access keys inherit the full AmazonBedrockLimitedAccess policy without Bedrock scoping: granting IAM role enumeration across the account, VPC network reconnaissance, and KMS encryption key discovery. The result is two credential types on one identity: the ABSK token constrained to Bedrock, and the potential AKIA access key operating with the full policy scope.

Figure 12: Attack surface overview. A single long-term API key creation produces two credential types (ABSK and potential AKIA) and two attacker profiles: one exploiting leaked Bedrock API keys for LLMjacking and destructive actions, and another exploiting phantom users through compromised IAM permissions for cross-service reconnaissance.

Credential Leaks

The most straightforward attack path begins with an ABSK credential committed to a public repository or exposed in application configuration. Because long-term keys use a consistent ABSK prefix, automated scanners can detect them immediately. Once exfiltrated, an attacker can validate the key with a single HTTP request. No AWS SDK or SigV4 signing is required.

```
curl --request GET \
--url "https://bedrock.us-east-1.amaz..." \
--header "Authorization: Bearer ${LEAKED_KEY}"
```

A valid key gives the attacker full administrative control over the Bedrock service through the AmazonBedrockLimitedAccess policy. This includes deleting guardrails to remove AI safety controls, maxing out model invocation quotas for LLMjacking operations, enumerating all Bedrock resources, and disrupting production workloads by deleting provisioned throughput or custom models. The simplicity of bearer token authentication (a single header in any HTTP client) lowers the barrier to exploitation significantly, compared to SigV4-authenticated credentials.

Compromised Administrator

When an attacker gains access to an account with IAM administrative permissions through phishing, malware, or an insider threat, phantom users become ready-made escalation paths. The attacker discovers BedrockAPIKey-* users by listing IAM users, then creates standard IAM access keys for them as shown below:

```
aws iam create-access-key --user-name BedrockAPIKey-xxxx
# Returns: AKIA... access key
```

These IAM access keys aren’t scoped to Bedrock. They inherit the full AmazonBedrockLimitedAccess policy, which includes iam:ListRoles for identity enumeration, ec2:DescribeVpcs, ec2:DescribeSubnets, and ec2:DescribeSecurityGroups for network topology mapping, and kms:DescribeKey for encryption key discovery. The attacker gains cross-service reconnaissance capabilities that extend well beyond what the original Bedrock API key credential would allow, and the IAM access keys don’t expire when the Bedrock API key does.

Privilege Escalation

An attacker with limited IAM permissions who can enumerate users and create access keys can escalate privileges through phantom users without needing any Bedrock credentials at all. The attacker lists IAM users, identifies BedrockAPIKey-* entries, and attempts to create access keys for them:

```
aws iam create-access-key --user-name BedrockAPIKey-xxxx
```

If successful, the attacker moves beyond limited permissions to achieve the full scope of the AmazonBedrockLimitedAccess policy (administrative Bedrock control, along with IAM, VPC, and KMS reconnaissance). The phantom users serve as pre-positioned escalation targets that exist in the account, regardless of whether the Bedrock API keys are actively in use. This also provides the attacker with a lateral movement opportunity and a persistence mechanism, since the access keys they create are independent of the original Bedrock credential lifecycle.

Figure 13: LLMjacking business model. Attackers steal Bedrock API keys, use them to power customer-facing AI chatbot platforms, charge users subscription fees (e.g., $30/month), and generate up to $1M/year in annualized revenue while the victim incurs up to $18,000/day per region in fraudulent Bedrock charges.

Documented Incidents

Multiple security research teams have confirmed significant financial impact from LLMjacking campaigns. One victim incurred $30,000 in charges within three hours from a single burst attack [1]. In another case, AWS proactively blocked a compromised key approximately 35 hours after a scale-up in request volume, but the initial malicious activity had begun 42 days prior [4].

Observed attack volumes reflect the scale of these operations. Researchers have tracked over 85,000 API requests against a single credential set within one month, with 61,000 concentrated in a three-hour window [3]. Another operation generated 75,000+ model invocations in just two days [4]. In both cases, attackers ran concurrent asynchronous tasks with sub-second delays between requests to maximize throughput [3].

Cost Exposure Model

A leaked Bedrock API key exposes the victim to up to $18,000 per day per region in fraudulent inference charges, derived from the default Bedrock service quota of 500,000 tokens per minute (720M tokens/day) and Claude Opus 4.7's $25-per-1M-token output rate [5].

This exposure compounds rapidly in multi-region environments: four to six active regions produce roughly $72,000 to $108,000 per day. Detection lag correlates directly with total damage, and extended compromise over days or weeks regularly produces six- and seven-figure exposure consistent with documented incidents [1].

Note: Per-token prices and quotas are accurate as of April 2026. These metrics can shift, verify current rates on the AWS Bedrock pricing page before quoting.

Exploitation Patterns

The exploitation sequence is consistent across documented incidents. Attackers harvest credentials from public repositories or exposed configuration files and validate them through automated tooling within minutes. Before scaling up, they check the account's logging configuration:

```
aws bedrock get-model-invocation-logging-configuration
```

If logging is disabled, exploitation begins immediately. If logging is enabled, attackers move on to the next target. Sysdig has documented disable attempts in the wild [3], but AmazonBedrockLimitedAccess only grants bedrock:Get* on the logging configuration, not bedrock:DeleteModelInvocationLoggingConfiguration or bedrock:PutModelInvocationLoggingConfiguration. An attacker confined to the phantom user's scope therefore can't tamper with logging; the disable attempts seen in the wild were almost certainly run with broader credentials. The defensive takeaway is direct: model invocation logging acts as both a deterrent (attackers skip accounts where it's enabled) and a hard barrier on what a leaked Bedrock API key can actually do.

Bedrock API keys introduce three aggravating factors that weren’t present in the IAM-credential incidents analyzed by Sysdig and Permiso:

• Lower exploitation barrier: Bearer token authentication replaces SigV4 signing. A leaked key can be validated and exploited with a single curl command, removing the request-signing step that previously raised the technical bar for credential abuse.
• Discoverable prefixes: The ABSK* and bedrock-api-key-* prefixes are in GitHub Secret Scanning. AWS added them to the partner pattern set in August 2025, which means attacker-controlled scanners detect the same prefixes that defender tooling does, often within minutes of a public commit.
• Persistent IAM identity: Long-term key creation leaves a phantom IAM user. The user retains the AmazonBedrockLimitedAccess policy indefinitely and remains exploitable through iam:CreateAccessKey even after the original key is rotated, deleted, or expired.

Part 2 of this guide, Detection, Defense, and Response, builds on these findings with deployable controls. It includes CloudTrail detection rules anchored on the callWithBearerToken signal, Service Control Policy templates that block long-term key creation and phantom user privilege escalation, containment playbooks for compromised long-term and short-term keys, and a migration path from Bedrock API keys to STS temporary credentials.