The Phantom of the Infrastructure: Investigating the Hidden IAM Risks in Bedrock API Keys

The Phantom of the Infrastructure: Investigating the Hidden IAM Risks in Bedrock API Keys

Speakers: Sergio Garcia, Security Researcher, BeyondTrust

Conference: BSides Seattle

YouTube: https://www.youtube.com/watch?v=v3wvjb9Gu-c

Overview

Sergio Garcia, a security researcher at BeyondTrust and former founding engineer at Prowler, reveals a significant security design flaw in Amazon Bedrock API Keys -- a new credential type AWS launched in July 2025 to simplify AI development. When a user generates a long-term Bedrock API key, AWS silently creates a hidden IAM user (a "phantom user") with permissions far exceeding what the "limited access" policy name suggests, including admin-level Bedrock permissions and a full reconnaissance toolkit covering IAM roles, KMS keys, VPCs, subnets, and security groups.

The research demonstrates that these phantom users persist indefinitely even after their associated API keys are deleted, creating a permanent attack surface. Within two weeks of launch, Bedrock API keys were already appearing in public GitHub repositories, enabling LLM jacking attacks that can cost victims up to $14,000 per day per region. Garcia open-sourced a complete toolkit for scanning, decoding, and remediating phantom users across AWS accounts.

This talk is essential viewing for any organization using or evaluating Amazon Bedrock, as the phantom user problem affects every AWS account that has generated a long-term Bedrock API key.

Background

▶ Watch: Sergio Garcia introduces Bedrock API keys and why they concern him (0:20)

Since its founding two decades ago, AWS has consistently recommended short-term credentials over long-term access keys. The introduction of Bedrock API keys in July 2025 reversed this guidance by offering a new type of long-lived credential specifically for interacting with Amazon Bedrock's AI services. The keys come in two flavors: short-term keys that expire with the session (up to 12 hours) and long-term keys that can be configured to never expire.

Garcia's research was prompted by the contradiction of AWS shipping brand-new long-lived credentials after years of pushing the industry toward temporary credentials and role-based access. The investigation revealed that the implementation creates hidden infrastructure with permissions that far exceed the stated "limited" scope, buried in CloudTrail events that most organizations are not monitoring for.

The broader context is the rise of LLM jacking attacks, where compromised AI service credentials are used to route attacker workloads through the victim's account, with the victim paying the compute costs. This attack pattern has become increasingly common as AI service usage has exploded.

Key Findings

▶ Watch: AWS silently creates a phantom IAM user when generating long-term keys (4:00)

Phantom IAM users: When a long-term Bedrock API key is generated (via console, CLI, or SDK), AWS automatically creates an IAM user with a predictable username pattern based on the API key prefix. This user is created without explicit consent or prominent notification -- Garcia describes it as AWS "silently" creating the user. The creation is recorded in CloudTrail but only as part of the standard event flow, not flagged as anything unusual.

"Limited" is misleading: The Amazon Bedrock Limited Access managed policy attached to phantom users contains far more than Bedrock-specific permissions. It includes: Get* and List* on all Bedrock resources (effectively admin read/write within Bedrock), DeleteGuardrails, DeleteCustomModels, plus reconnaissance permissions including DescribeKey for all KMS keys, ListRoles for all IAM roles, and DescribeVPCs, DescribeSubnets, and DescribeSecurityGroups for network infrastructure. Garcia characterizes this as "a reconnaissance toolkit" bundled into what AWS markets as a limited policy.

Permanent attack surface: Phantom users persist in the account even after all associated Bedrock API keys are deleted or expired. Garcia found multiple orphaned phantom users in test accounts -- users with no active API keys that still maintained their IAM permissions. Until manually deleted, these users represent a credential creation opportunity for any attacker with sufficient account access.

Key leakage velocity: Within two weeks of the feature's launch, Bedrock API keys were discovered in public GitHub repositories, demonstrating the inevitability of credential leakage for long-lived keys.

Account ID extraction: Both short-term and long-term Bedrock API keys can be decoded (they are Base64-encoded) to extract the AWS account ID and, for long-term keys, the phantom username. This gives attackers immediate reconnaissance data from the leaked key alone.

Technical Deep Dive

▶ Watch: Live demo: decoding keys, creating/deleting guardrails, privilege escalation (10:00)

Short-term key structure: Short-term Bedrock API keys follow the pattern bedrock-api-key-<base64>, where the Base64 payload is a SigV4 presigned URL containing the access key ID, region, and expiration. Further decoding the embedded token (also Base64) reveals the AWS account ID. Critically, short-term key creation happens entirely client-side in the browser, meaning there is no CloudTrail event for key creation -- only for subsequent key usage via the CallWithVerToken action.

Long-term key structure: Long-term keys encode a simpler Base64 string containing the API key name (which includes the phantom username) and the account ID. Decoding is trivial and provides immediate reconnaissance value.

CloudTrail fingerprint: Long-term key generation produces three CloudTrail events: CreateUser (the phantom IAM user), AttachUserPolicy (the Bedrock Limited Access policy), and CreateServiceSpecificCredential (the actual API key). The CreateServiceSpecificCredential event contains the expiration date, credential alias, credential ID, and phantom username.

Privilege escalation path: The primary attack chain begins with a leaked long-term API key in a public repository. The attacker decodes the key to extract the account ID and phantom username, then uses the key's Bedrock admin permissions for LLM jacking. But a more dangerous secondary path exists: if an attacker gains access to a compromised user in the account, they can create standard IAM access keys for the phantom user (since it is a full IAM user), unlocking the reconnaissance permissions (VPC, subnet, security group, IAM role, KMS key enumeration) that are not accessible through the Bedrock API key itself.

Detection: The key detection signal is the CallWithVerToken field in CloudTrail events, which is set to true whenever a Bedrock API key (short-term or long-term) is used. Garcia recommends alerting on this field immediately. Additional monitoring should cover: CreateServiceSpecificCredential events with expiration dates exceeding 90 days, CreateUser events where the username matches the phantom user pattern, and CreateAccessKey events on phantom users (the privilege escalation indicator).

Prevention via SCPs: Garcia provides four ready-to-deploy Service Control Policies. The first blocks all Bedrock API key creation and usage account-wide for organizations that have not approved the feature. The second uses the new bedrock:TokenType condition (released by AWS in September 2025 in response to researcher pressure) to deny long-term key usage specifically. The third uses bedrock:ServiceSpecificCredentialAge to block key creation with expiration beyond 90 days. The fourth blocks CreateAccessKey on phantom users to prevent privilege escalation.

Demo / Proof of Concept

▶ Watch: LLM jacking attack chain: $14K per day per region in victim costs (12:00)

Garcia demonstrated the complete attack chain live. Starting from a clean terminal with no credentials, he exported a long-term Bedrock API key as an environment variable and successfully called ListFoundationModels. He then decoded the key to reveal the phantom username and account ID.

To prove admin-level Bedrock access, he created a guardrail, verified its creation, and then deleted it -- all using the "limited" API key. Finally, he created standard IAM access keys for the phantom user and used those to enumerate IAM roles, demonstrating the reconnaissance capability that extends beyond Bedrock itself.

Defensive Implications

▶ Watch: Four ready-to-deploy SCPs and open-source phantom user scanner (16:00)

Organizations using Amazon Bedrock should immediately audit their accounts for phantom IAM users using Garcia's open-source toolkit, which scans for all phantom users, identifies orphaned users with no active keys, and supports automated cleanup.

For incident response, the fastest remediation for a compromised long-term key is attaching a deny-all policy to the phantom user. For short-term keys, the same deny policy must be attached to the identity that generated the key, or the aws:TokenIssueTime condition can be used to revoke past sessions. Garcia specifically warns against waiting 12 hours for short-term keys to expire naturally.

The four SCPs should be evaluated for deployment in any AWS organization, particularly the blanket deny for organizations that have not approved Bedrock API key usage and the privilege escalation prevention for phantom users.

Key Takeaways

• AWS Bedrock API keys silently create phantom IAM users with admin-level Bedrock permissions and network/IAM reconnaissance capabilities disguised as "limited access"
• Phantom users persist indefinitely even after all associated API keys are deleted, creating permanent attack surface
• Long-term keys can be configured to never expire, and were found in public GitHub repos within two weeks of feature launch
• Both key types can be decoded from Base64 to extract the AWS account ID and phantom username
• LLM jacking via leaked Bedrock API keys can cost victims up to $14,000 per day per region
• Deploy SCPs using the new bedrock:TokenType and ServiceSpecificCredentialAge conditions released in September 2025 to restrict key creation
• Monitor CloudTrail for CallWithVerToken=true events and CreateAccessKey actions on phantom users

About the Speaker(s)

Sergio Garcia is a security researcher at BeyondTrust, previously one of the founding engineers at Prowler (an open-source AWS security tool). Based in Miami and originally from Spain, he focuses on breaking AWS services and finding cloud security vulnerabilities. He publishes under the alias "Mr. Clausk" on Twitter, GitHub, and LinkedIn. Garcia's research led to AWS releasing new IAM condition keys for Bedrock in September 2025 to address the issues he identified.