Securing Amazon Bedrock API keys: Best practices for implementation and management

Recently, AWS released Amazon Bedrock API keys to make calls to the Amazon Bedrock API. In this post, we provide practical security guidance on effectively implementing, monitoring, and managing this new option for accessing Amazon Bedrock to help you build a comprehensive strategy for securing these keys. We also provide guidance on the larger family of service-specific credentials, so that you can also reinforce your AWS CodeCommit and Amazon Keyspaces (for Apache Cassandra) implementation if needed.

Our recommendation is to use temporary security credentials provided by AWS Security Token Service (AWS STS) service whenever possible as a preferred authentication method.

API keys can be used when your use case blocks the use of temporary AWS STS credentials. A common example is when using third-party or packaged software that specifically requires API key authentication through HTTP bearer tokens and cannot be configured to use SigV4 signing with temporary AWS STS credentials.

If you find that you don’t need to use API Keys, consider using service control policies (SCPs) to deny the creation and use of these keys.

If you conclude that your use case requires API keys, then consider the two types of API keys:

• Short-term API keys: Consider using short-term API keys if AWS STS credentials cannot be used, because they provide a built-in expiration mechanism and will automatically expire after a specified duration, stopping credentials from being used indefinitely if they are exposed.
• Long-term API keys: Long-term API Keys should only be used when neither AWS STS credentials nor short-lived credentials can be used, such as with packaged software and SDKs that expect a static long-lived API key and cannot be modified.

While implementing the controls in this post addresses most API key security concerns, remember that security is an ongoing process. Continue following AWS security best practices and regularly review your security posture as part of a comprehensive security strategy.

Service-specific credentials are specialized authentication credentials that provide direct access to specific AWS services. These credentials are different from other AWS security credentials (such as access keys, secret access keys, and session tokens) and are designed for use with specific AWS services.

The key characteristics of service-specific credentials include:

• Each credential is tied to a specific AWS service
• They are associated with AWS Identity and Access Management (IAM) principals
• They can be managed through both the AWS Management Console and the AWS Command Line Interface (AWS CLI)
• They can be monitored through AWS CloudTrail
• The prefix to a service-specific credential ID is ACCA
• Organizations can control the creation and use of service-specific credentials through SCPs

Let’s learn more about service-specific credentials and their use with Amazon Bedrock.

Amazon Bedrock API keys are service-specific credentials that provide direct access to Amazon Bedrock. The bedrock:CallWithBearerToken permission grants the ability to use these tokens to perform Amazon Bedrock API actions.

Key types and characteristics

There are two types of API keys, and they have the following characteristics.

Short-term API keys:

• Uses pre-signed SigV4 authentication
• Short-term API keys are generated locally on the client side, therefore their creation of these short-term keys won’t be recorded in CloudTrail
• Cannot be retrieved through credential reports or AWS CLI calls
• Last as long as the IAM session that generated the API key or 12 hours, whichever is shortest
• Have the same permissions as the role that you use to generate the key
• Pattern: bedrock-api-key-YmVkcm9jay5hbWF6b25hd3MuY29tLz9BY3Rpb249Q2FsbFdpdGhCZWFyZXJUb2tlbiZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsP[A-Za-Z0-9\\]+={0,2}

Long-term API keys:

• When an Amazon Bedrock long-term API key is created through the Amazon Bedrock console, AWS automatically generates a dedicated IAM user with the naming convention BedrockAPIKey-xxx and attaches the AmazonBedrockLimitedAccess managed policy
• The IAM user created through the Amazon Bedrock console doesn’t have console access enabled, a console password, an access key, or multi-factor authentication (MFA) enabled
• Alternatively, when an Amazon Bedrock long-term key is created through the IAM console, you can associate the Amazon Bedrock service-specific credential directly to an existing IAM user
• Each IAM user can have up to two long-term API keys
• Can be configured with expiration periods ranging from one day to indefinite duration.
• Duration can be controlled with three new condition keys to govern API keys for Amazon Bedrock. Here is an example SCP.
• Pattern: ABSKQmVkcm9ja0FQSUtleS[A-Za-z0-9+\/]+={0,2}
• CloudTrail will log an event when long-term API keys are created, as shown in the following example. You can also identify long-term API keys using the AWS CLI.

{
    "eventTime": "2025-07-23T17:39:08Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateServiceSpecificCredential",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0",
    "requestParameters": {
        "userName": "BedrockAPIKey-0g21",
        "serviceName": "bedrock.amazonaws.com",
        "credentialAgeDays": 36500
    },
    "responseElements": {
        "serviceSpecificCredential": {
            "createDate": "Jul 23, 2025, 5:39:08 PM",
            "expirationDate": "Oct 7, 2125, 5:39:08 PM",
            "serviceName": "bedrock.amazonaws.com",
            "serviceCredentialAlias": "BedrockAPIKey-1234-56-EXAMPLE
",
            "serviceCredentialId": "ACCA123456789EXAMPLE",
            "userName": "BedrockAPIKey-0g21",
            "status": "Active"
        }
    }
}

There are several key aspects to understand when working with API keys. Short-term API keys are generated on the client-side and aren’t visible through standard AWS API listings.

Long-term API keys offer some additional visibility and can be managed through multiple methods. You can identify which principal has an associated long-term API key by using the Amazon Bedrock console or IAM console. You can list service-specific credentials using AWS CLI commands or the AWS SDK, which will list the service-specific credentials for a specified user.

Bedrock has introduced three condition keys that enhance your ability to control and secure API key usage within your AWS environment:

• You can use the iam:ServiceSpecificCredentialServiceName condition key to allow the AWS services that a principal can create service-specific credentials for.
• Use the iam:ServiceSpecificCredentialAgeDays condition to enforce security best practices by setting a maximum duration limit for long-term API keys at creation time.
• Finally, by using the bedrock:BearerTokenType condition key, you can deny or allow the use of a specific type of API key for Amazon Bedrock, whether it’s a short-term or long-term API key.

These condition keys play an important role in managing the distinct security characteristics of short-term and long-term API keys, enabling security teams to enforce organizational policies and security best practices through SCPs at the AWS Organizations level. To learn more, see the GitHub repo for examples of how to apply these SCPs.

Short-term API keys include a native expiration window that helps limit potential security exposure. When implementing these keys, be aware that they inherit the permissions of the signing principal, which can be more than Amazon Bedrock permissions. You can implement comprehensive monitoring as described in the Detect section.

Long-term API keys, which can be configured with extended expiration periods, offer convenience for long-running applications but should have special attention regarding controls and monitoring mechanisms to offset the increased exposure window these credentials present.

If your organization has decided that Amazon Bedrock API keys aren’t required for your environment, you can implement SCPs to block the creation of service-specific credentials (iam:CreateServiceSpecificCredential) and block bearer token use for Amazon Bedrock (bedrock:CallWithBearerToken).

Note: If you do not use the condition iam:ServiceSpecificCredentialServiceName in an IAM policy, iam:CreateServiceSpecificCredential will then also deny the creation of API keys for other services, such as AWS CodeCommit and Amazon Keyspaces (for Apache Cassandra).

Here’s an example SCP that denies the creation of Amazon Bedrock service-specific credentials and the use of API keys in Amazon Bedrock. This prohibits builders in your organization from creating new API keys, reducing the risk of unauthorized key creation. This approach is valuable for organizations that want to maintain strict control over their authentication methods or have no business need for service-specific credentials. A condition can also be added to the SCP to allowlist specific roles to be able to create service-specific credentials by adding a condition ArnNotLikeIfExists for the principals listed under aws:PrincipalArn.

As part of protecting API keys, regularly review and adjust permissions to align with the principle of least privilege. For long-term API keys created through the Amazon Bedrock console, AWS automatically creates an IAM user with the AmazonBedrockLimitedAccess managed policy. This policy grants access to various Amazon Bedrock, AWS Key Management Service (AWS KMS), IAM, Amazon Elastic Compute Cloud (Amazon EC2), and AWS Marketplace actions. For both long-term and short-term API keys, evaluate if your principals have more permissions than required for their use case. If excessive permissions are identified, replace the AmazonBedrockLimitedAccess policy with a custom policy that has scoped down permissions.

API keys require different monitoring approaches based on their type. While the creation of short-term API keys cannot be detected because they are generated client-side, the creation of long-term API keys can be monitored through CloudTrail events. However, the use of both short-term and long-term API keys can be detected through CloudTrail events. Because of their extended validity period, long-term API keys are more susceptible to unauthorized use, making comprehensive monitoring essential. Organizations should implement stringent monitoring controls including:

• Monitor CreateUser events with BedrockAPIKey- prefix usernames. If a user was created through the Amazon Bedrock console, the event will look like the following:

{
    "eventTime": "2025-07-23T17:39:08Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateUser",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0",
    "requestParameters": {
        "userName": "BedrockAPIKey-0g21"
    },
    "responseElements": {
        "user": {
            "path": "/",
            "userName": "BedrockAPIKey-0g21",
            "userId": " AIDACKCEVSQ6C2EXAMPLE",
            "arn": "arn:aws:iam: 111122223333:user/BedrockAPIKey-0g21",
            "createDate": "Jul 23, 2025, 5:39:08 PM"
        }
    }
}

• Track CreateServiceSpecificCredential events for requestparameters.serviceName = bedrock.amazonaws.com
• Watch for active API key usage indicators:
  • additionalEventData.callWithBearerToken = true
  • eventSource = bedrock.amazonaws.com

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": " AIDACKCEVSQ6C2EXAMPLE",
        "arn": "arn:aws:iam::user/BedrockAPIKey-0g21",
        "accountId": "",
        "userName": "BedrockAPIKey-0g21"
    },
    "eventTime": "2025-07-23T17:39:37Z",
    "eventSource": "bedrock.amazonaws.com",
    "eventName": "Converse",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "",
    "userAgent": "curl/8.11.1",
    "requestParameters": {
        "modelId": "us.anthropic.claude-3-5-haiku-20241022-v1:0"
    },
    "responseElements": null,
    "additionalEventData": {
        "callWithBearerToken": true,
        "inferenceRegion": "us-west-2"
    }
}

For a list of events to monitor, see Security Playbook for Responding to Amazon Bedrock Security Events.

Amazon EventBridge rules

You can enhance your security monitoring by implementing Amazon EventBridge rules to detect and alert on Amazon Bedrock API key lifecycle events, such as CreateServiceSpecificCredential.

Using EventBridge rules for monitoring has four components.

• EventBridge rules: CreateServiceSpecificCredentialRule and BearerTokenUsageRule monitor CloudTrail for credential creation and bearer token usage
• SNS topic: BedrockAlertsTopic delivers encrypted security alerts through email
• KMS key: SNSEncryptionKey encrypts SNS messages
• IAM roles: Provide necessary access for service operations

The preceding EventBridge rules monitor for specific patterns within a CloudTrail log, keying from eventName (the action being performed), eventSource (the service that the action is being performed by or to), and additionalEventData (the block of details of the response).

The following rule checks for the CloudTrail event CreateServiceSpecificCredential.

        source:
          - aws.iam
        detail-type:
          - AWS API Call via CloudTrail
        detail:
          eventSource:
            - iam.amazonaws.com
          eventName:
            - CreateServiceSpecificCredential

Use the following rule to look for actions performed with an API key (BearerToken = true):

        detail-type:
          - AWS API Call via CloudTrail
        detail:
          additionalEventData:
            callWithBearerToken:
              - true

EventBridge rule deployment

Use the CloudFormation template to set up automated monitoring for both the creation of service-specific credentials and their subsequent use. The template configures EventBridge to send email notifications when the preceding CloudTrail events are detected, providing real-time awareness of API key operations in your environment. To learn more, see the GitHub repo for the details of this solution and the CloudFormation template.

AWS Config rule for compliance

Use an AWS Config rule to monitor IAM users for active service-specific credentials to help maintain compliance with security policies.

The following are the steps taken by the AWS Config rule:

1. Every 24 hours, the AWS Config rule triggers a Lambda function that enumerates IAM users in the account
2. For each user, the function checks for active service-specific credentials
   1. Users with service-specific credentials are marked as NON_COMPLIANT
   2. Users without active credentials are marked as COMPLIANT
3. Results are submitted to AWS Config for reporting and potential remediation

Config rule deployment

You can deploy this AWS Config rule by using AWS Config RDK, in CloudShell, or using your local CLI.

1. git clone https://github.com/awslabs/aws-config-rules.git
2. cd aws-config-rules/python-rdklib
3. git fetch && git checkout IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS
4. pip install rdk rdklib
5. rdk deploy IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS
6. aws configservice start-config-rules-evaluation --config-rule-names “IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS”

Respond and recover

Every incident response plan starts with the preparation phase. As part of the preparation phase, you should maintain clear records of API key ownership and usage, document which applications and teams use specific keys, and if long-term API keys are necessary, consider using secure storage such as AWS Secrets Manager.

When a security incident involving API keys is suspected, immediate action is crucial. The first step is to verify the potential compromise by reviewing CloudTrail logs to correlate API key creation use with approved change requests. This helps identify unauthorized key creation or use. Additionally, analyzing the source IP addresses and user agent strings from these logs can help determine if the access originated from approved locations and applications or potentially malicious sources.

The incident response approach varies significantly between key types. For short-term keys, while their maximum 12-hour expiration window limits potential damage, it’s still important to take immediate action rather than waiting for expiration. Security teams should identify applications or systems using the compromised short-term key and revoke the IAM role session or deny permissions to bedrock:CallWithBearerToken from the identity.

If an Amazon Bedrock long-term API key is involved in an active security event, security teams can take immediate action through either the console or AWS CLI. Through the console, teams can use the IAM console to quickly deactivate or delete long-term API keys. For organizations with automated response procedures, the AWS CLI provides commands for key management:

Respond using the AWS CLI

Use the following steps to respond to an API key event.

1. Identify service-specific credentials:

aws iam list-service-specific-credentials --user-name <user name> --service-name bedrock.amazonaws.com

2. For immediate containment, you can deactivate the credential using the credential ID from the previous step:

aws iam update-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name> --status Inactive

3. After you’ve assessed the event, you can permanently remove the associated API keys:

aws iam delete-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name>

During the recovery phase, focus on creating new secure keys with appropriate configurations, updating application configurations, and make sure that all affected continuous integration and delivery (CI/CD) pipelines and development teams are notified of the changes.

Review of Amazon Bedrock API keys

The following table summarizes the various elements related to Amazon Bedrock API keys mapped to the NIST CSF 2.0 core function.

Type	Identify	Protect	Detect (using events in CloudTrail)	Respond
Short-term API key Whitetexttexttexttext	Short-term API keys are generated client-side and are not listed by an AWS API.	Creation: Cannot block creation because short-term API keys are generated client-side. Use: Deny action bedrock:CallWithBearerToken to avoid use Modify permissions for long-term and short-term Amazon Bedrock API keys	Creation: Occurs client-side and no events are present in CloudTrail Use: CloudTrail events with additionalEventData.callWithBearerToken = true EventBridge rules and SNS to detect/notify on the usage of API keys.	Revoke IAM role session or deny permissions from identityWhitetexttexttext
Long-term API key Whitetexttexttexttext	IAM ListServiceSpecificCredentials action using the AWS CLI or SDKs	Creation: Deny action iam:CreateServiceSpecificCredential to block creation of service specific credentials across the services, including Amazon Bedrock. Use: Deny action bedrock:CallWithBearerToken to avoid use Modify permissions for long-term and short-term Bedrock API keys	Creation: CloudTrail events with eventName iam:CreateServiceSpecificCredential, and iam:CreateUser when using the console. Use: CloudTrail events with additionalEventData.callWithBearerToken = true EventBridge rules and SNS to detect and notify on creation and usage of API keys. Config rule	Use the console or AWS CLI to quickly deactivate or delete long-term API keys Whitetexttexttext

Broader service-specific credentials: Beyond Amazon Bedrock

Along with Amazon Bedrock support of API keys, other AWS services support service specific credentials, such as AWS CodeCommit and Amazon Keyspaces.

The security measures suggested in this post can also be applied to these services. The following table lists common use cases for these service specific credentials.

Service	Use case	Service name in response from iam:ListServiceSpecificCredentials	Suggested alternatives
AWS CodeCommit Git credentials	Used to upload, add, or edit a file in an AWS CodeCommit repository	codecommit.amazonaws.com	Methods include SSH authentication and federated authentication: AWS CodeCommit: Setting up using other methods
Amazon Keyspaces credentials for Apache Cassandra	Used for Apache Cassandra-compatible access	cassandra.amazonaws.com	SigV4 authentication plugin is available and supports multiple programming languages and enables IAM roles and federated identities to authenticate. Create temporary credentials to connect to Amazon Keyspaces using an IAM role and the SigV4 plugin

Conclusion

Understanding the implications of long-term API keys and how to manage them helps you to make informed decisions about your Amazon Bedrock API key implementation strategy. The key is to align security controls with risk appetite and operational requirements while maintaining a strong security posture.

AWS strongly recommends using AWS STS credentials as the primary authentication method wherever possible. If AWS STS credentials cannot be used, consider short-term API keys with their built-in expiration mechanism. Long-term API keys should only be implemented when neither AWS STS credentials nor short-term credentials are viable options. When implementing API keys, organizations should focus on identifying API keys through AWS CLI and CloudTrail logs, protecting by implementing preventive controls such as SCPs to manage API key creation and usage, detecting API key activities through comprehensive monitoring using CloudTrail events, EventBridge and AWS Config rules, and responding by maintaining clear incident response procedures to quickly address potentially compromised API keys.

Best practice is to implement these controls while maintaining proper access controls through the principle of least privilege. This layered approach helps you maintain a strong security posture while effectively using API keys for your development needs.