AWS Bedrock's long-term API keys leaked on public GitHub repositories just two weeks after their launch. This security breach raised serious concerns since it happened in 2025, a time many call a revolution in identity-driven security.
AWS rolled out API keys for Amazon Bedrock in July 2025. The new system eliminated the need for IAM roles and user credentials. Users could choose between two key types: short-term keys that last up to 12 hours (best for production environments), and long-term keys with flexible expiration dates—including a risky never-expire option. The long-term keys stand out because AWS creates a dedicated IAM user just for that key. The system automatically attaches an AmazonBedrockLimitedAccess policy that, despite its name, grants access to more than half of Bedrock's service privileges.
Let's get into what makes AWS Bedrock API keys unique, their creation process, authentication methods, and the security risks they bring. You'll also learn practical ways to detect and prevent threats to your AWS environment.
How Long-Term Bedrock API Keys Are Created
The process to create long-term Bedrock API keys is different from traditional AWS credential generation. These keys mark a major shift from standard IAM access keys. They come with unique characteristics and security implications.
IAM User Creation via AWS Console
The AWS Management Console creates a dedicated IAM user automatically in the background when you generate a long-term Bedrock API key. The system names this user 'BedrockAPIKey-abcd' where the suffix contains four random characters. Developers don't need to do anything manually. This makes the process simple but raises some security considerations.
The console creation process involves:
- Signing into the AWS Console and navigating to the Bedrock service
- Selecting "API keys" from the left navigation pane
- Choosing the "Long-term API keys" tab
- Clicking "Generate long-term API keys"
- Setting an expiration period (ranging from 1 to 36,600 days or "Never expires")
On top of that, users can select additional IAM policies beyond the default in the "Advanced permissions" section. You can create powerful credentials easily without knowing much about the security architecture.
AmazonBedrockLimitedAccess Policy Attachment
AWS attaches the AmazonBedrockLimitedAccess policy automatically after creating the IAM user. The "limited" label is misleading since this policy gives access to over half of Bedrock service's privileges. Many applications don't need such broad permissions.
The policy has permissions to create and delete guardrails. This could be risky if someone compromises these credentials. Organizations should create custom policies with fewer permissions to boost security. Bedrock needs only these basic functions:
- bedrock:InvokeModel
- bedrock:InvokeModelWithResponseStream
- bedrock:CallWithBearerToken
CreateServiceSpecificCredential API Usage
AWS uses the CreateServiceSpecificCredential API from the IAM service to create long-term Bedrock API keys programmatically. This API started with CodeCommit and Amazon Keyspaces in 2016. AWS extended it to support Bedrock in 2025.
Here's how to create keys programmatically:
- First, create an IAM user using the CreateUser API
- Next, attach the AmazonBedrockLimitedAccess policy (or custom policies) using AttachUserPolicy
- Finally, generate the actual credential by calling CreateServiceSpecificCredential with "bedrock.amazonaws.com" as the ServiceName
The CredentialAgeDays parameter sets an expiration between 1 and 36,600 days when you call the CreateServiceSpecificCredential API. Credentials never expire if you skip this parameter. This could create security risks over time.
The API gives back two important pieces: the ServiceApiKeyValue and the ServiceSpecificCredentialId. You must store the API key safely because you can't get it back later. The credential ID helps manage the key afterward. Each IAM user can have two service-specific credentials per supported service.
These long-term keys work best for development and exploration rather than production environments. Even so, their ease of use makes them popular for quick development cycles. This means you need to manage and monitor them carefully.
Key Structure and Authentication Mechanism
Bedrock API keys have a unique structure that sets them apart from regular AWS credentials. AWS has reimagined authentication for their AI services, and these differences help us understand their approach better.
132-Character ABSK Prefix Format
Bedrock API keys follow a pattern you can spot right away. These keys are 132 characters long [link_1] and start with "ABSK". Security tools can easily track these keys in code repositories and logs because of this standard format.
After the prefix comes a Base64-encoded string with important details about the key's source and connections. Security teams can look for the "ABSKQmVkcm9ja0FQSUtleS" pattern to find these keys with very few false matches.
Base64 Decoding Reveals IAM User and Account ID
The Base64 part of a Bedrock API key shows a lot of useful information once decoded. You'll see something like: "BedrockAPIKey-abcd+1-at-123456789012:FS0k7F…".
This decoded string shows several key pieces:
- The IAM user name linked to the key
- A marker showing if it's a primary or secondary API key ("+1" means it's secondary)
- The AWS account ID that made the key
These keys are different from other AWS credentials. They don't hide who they belong to - instead, they spell it out clearly. A decoded key might show "BedrockAPIKey-mkut-at-116********", which tells you both the key name and account ID.
Each IAM user can have up to two Bedrock API keys, just like regular access keys. This limit applies to all service-specific AWS credentials.
Bearer Token Usage in HTTPS Requests
Bedrock API keys work differently from most AWS authentication methods. Traditional AWS credentials use Signature Version 4 (sigv4) with complex hashing to keep secrets safe. Bedrock API keys, however, work as bearer tokens.
The actual key value goes straight into the HTTPS request header when you call the AWS Bedrock service. This matches how bearer token authentication works in other AWS services that need the "sts:GetServiceBearerToken" permission.
These bearer tokens carry information from the original authentication, including principal tags, session tags, and session policies. You can spot them in CloudTrail logs by their "ABIA" prefix, which helps with security monitoring.
This simpler authentication makes developers' lives easier but needs extra security attention. The complete credential travels with every request, unlike traditional AWS authentication where the secret key stays hidden.
Short-Term vs Long-Term Bedrock API Keys
Amazon Bedrock provides different types of API keys for authentication. Each type comes with its own characteristics and security implications. Understanding these differences helps you implement the right authentication mechanism in your applications.
Short-Term vs Long-Term Bedrock API Keys
AWS Bedrock has two authentication approaches with different security characteristics. Short-term keys are valid for up to 12 hours or until your console session ends, whichever comes first. These keys are recommended for production environments that need regular credential rotation. Long-term keys let you customize expiration dates from 1 day to 365 days. You can also set them to never expire, which makes them convenient but potentially risky for security.
Short-Term Keys via Presigned URL Encoding
Short-term Bedrock API keys work differently from long-term ones. The system creates these credentials by generating a pre-signed URL with AWS Signature Version 4. It then base64 encodes the URL and adds "bedrock-api-key-" as a prefix. This process creates credentials exceeding 1000 characters in length, which is much longer than long-term keys.
Long-term keys need IAM user creation, but short-term keys inherit permissions and expiration from the identity that creates them. This means they share the same permission scope as their creator. These keys only work in the AWS Region where they were generated.
AWS has created special libraries to make this process easier. Developers can use the Python package aws-bedrock-token-generator and similar packages in other programming languages.
No CloudTrail Logging for Short-Term Key Creation
The two key types differ in how AWS CloudTrail tracks them. Short-term keys are created through client-side operations that generate pre-signed URLs. This means CloudTrail cannot capture their creation. Security teams might find it challenging to track when these credentials are generated.
CloudTrail logs only show these credentials when someone uses them. Organizations that want to monitor authentication mechanisms need other ways to detect creation beyond CloudTrail analysis.
bedrock:CallWithBearerToken API Usage
Both key types use the bedrock:CallWithBearerToken API action. This shared authentication method lets you spot API key usage in CloudTrail through the additionalEventData field that contains "callWithBearerToken": true.
Security teams can tell short-term and long-term keys apart by looking at the principal type in CloudTrail events. IAM Users point to long-term keys, while IAM Roles suggest short-term ones. This helps teams monitor and enforce policies effectively.
The bedrock:bearerTokenType condition key adds more control options. It accepts either SHORT_TERM or LONG_TERM values. This lets organizations create different permission policies based on token type. Teams can allow short-term keys while blocking long-term ones.
Organizations can completely block API key usage by denying the bedrock:CallWithBearerToken action through IAM policies or Service Control Policies.
Security Risks and Real-World Incidents
AWS Bedrock API keys have already caused major security incidents since their launch. Security researchers found leaked long-term Bedrock API keys in public GitHub repositories just two weeks after release. These exposures show basic flaws in this authentication method.
GitHub Leaks of Long-Term Keys
Exposed credentials create immediate risks as attackers can exploit them faster. Entro Labs' research showed that attackers tried to access leaked cloud credentials within an average of 17 minutes after exposure. The quickest attempt took only 9 minutes. AWS now includes these keys in GitHub Secret Scanning to detect exposed credentials. AWS quarantines the affected IAM user's account once discovered. They notify customers through support cases and send emails to the root account with exposure location details.
Privilege Escalation via Guardrail Deletion
Security experts showed how stolen Bedrock API keys let attackers gain more privileges within the service. While restricted to Bedrock's scope, attackers can delete guardrails that stop harmful content generation. Researchers proved this by using a simple curl command with a bearer token to remove guardrails:
curl --request DELETE \
--url "https://bedrock.${REGION}.amazonaws.com/guardrails/${GUARDRAIL_ID}" \
--header "Authorization: Bearer ${AWS_BEARER_TOKEN_BEDROCK}" \
--header 'Content-Type: application/json'
This attack bypasses safety controls and could allow generation of harmful content that guardrails would normally block.
Over-privileged IAM Policies in Practice
AmazonBedrockLimitedAccess policy's default settings give new IAM users access to much of Bedrock's service privileges. This permissive default creates security risks even when organizations follow standard procedures. Security reviews show these policies often include permissions to create and delete guardrails—abilities most operations don't need.
Beyond money risks, stolen credentials let attackers destroy valuable assets like custom fine-tuned models. They can also run up huge bills by repeatedly using expensive LLM models. Bad actors could make use of these models for harmful purposes, from leaking information to misusing resources.
Organizations need extra security controls beyond AWS defaults to manage these credentials properly. They also need ongoing monitoring to catch unexpected credential creation or usage patterns.
Detection and Mitigation Strategies
Security teams need a layered strategy to spot and handle Bedrock API key risks. AWS monitoring capabilities help teams identify key creation and track their usage.
CloudTrail Event: CreateServiceSpecificCredential
Security teams should monitor specific CloudTrail events to spot long-term Bedrock API key creation. The IAM API call iam:CreateServiceSpecificCredential with requestParameters that contain "bedrock.amazonaws.com" as the service name serves as a vital detection point. This event shows when new credentials are generated.
callWithBearerToken Flag for Usage Detection
Tracking how Bedrock API keys are used becomes a priority after creation. CloudTrail can spot both long-term and short-term keys through a specific marker: "additionalEventData": { "callWithBearerToken": true }. The principal helps distinguish between key types - IAM Users point to long-term keys while IAM Roles indicate short-term credentials.
SCPs to Block IAM User and bedrock:CallWithBearerToken
Service Control Policies are a great way to get preventative control. Security experts suggest using SCPs that deny both IAM User creation and the bedrock:CallWithBearerToken permission. This measure blocks both key types in an organization. Example policy:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "bedrock:CallWithBearerToken",
"Resource": "*"
}
}
Integration with GitHub Secret Scanning
As of August 2025, AWS made Bedrock API keys part of their GitHub Secret Scanning partner program. AWS takes immediate action when a long-term key shows up in a public GitHub repository. The system quarantines the IAM User and sends notifications through support cases and emails to the root account. Users get details about the exposure including repository, commit, and filename.
Prowler Checks for Expiration and Permissions
Prowler security assessment tools run automated checks to find risky setups. Two key checks stand out: bedrock_api_key_no_administrative_privileges looks for overly permissive policies like AdministratorAccess or bedrock:*, while bedrock_api_key_no_long_term_credentials flags keys without expiration dates. These tools help teams maintain least-privilege principles and proper key lifecycle management.
Conclusion
AWS Bedrock API keys show a major transformation in AWS authentication patterns. Organizations using Bedrock's generative AI capabilities need to understand these keys' unique structure, creation process, and security implications.
The system creates dedicated IAM users with too many permissions, which brings risks that security teams must tackle. The bearer token authentication system is different from AWS's usual credential patterns, so teams need new security approaches.
AWS tries to balance developer experience with security through short-term keys (best for production) and long-term keys (easier but riskier). Real-life incidents have showed how these credentials can quickly end up in public repositories.
Security teams should set up strong detection systems through CloudTrail monitoring to track both credential creation and usage patterns. Service Control Policies can also block risky authentication methods across AWS organizations.
AWS can automatically quarantine keys found in public GitHub repositories. This reactive approach can't replace good security practices. Organizations need detailed governance frameworks to manage these credentials.
AWS Bedrock API keys represent the constant balance between ease of use and security in cloud environments. These keys make AI model access simple but need careful monitoring, strict permissions, and proper lifecycle management to prevent major security issues. Organizations focused on security should use short-term keys with expiration dates instead of permanent ones.
