# Leaked Amazon Bedrock API Key? Revoke It Now

> Amazon Bedrock API key exposed on GitHub? Find its IAM user, delete the key, check Bedrock usage in CloudTrail and tighten policies. Step-by-step guide.

Source: https://leakwatch.net/secrets/amazon-bedrock-api-key

---

[LeakWatch](/)

[Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/)

1.  [Home](/)
2.  [Secrets](/secrets)
3.  Amazon Bedrock API Key

AI · Secret guide

# Leaked Amazon Bedrock API Key: what to do in the first hour

Critical severityDetected onlyLast verified October 23, 2026 · 5 min read

An Amazon Bedrock API key is a bearer token. Whoever holds it can call the models you have access to in Bedrock without any other AWS credential, and every request is billed to your AWS account. A long-term key is tied to an IAM user, so it carries that user’s permissions. Find out which user owns the leaked key first, because that decides how far the damage can reach. Then replace the key and look at what it was used for.

[Check your GitHub account for leaked secrets — free](/)

Provider

Amazon Bedrock

Severity

Critical

Impact

SaaS account access and billing

Checked live by LeakWatch

No

## What an Amazon Bedrock API Key looks like

Bedrock keys start with the literal prefix `ABSK`, followed by a long body of letters, digits, `+` and `/`:

```text
ABSK…XXXX   Amazon Bedrock API key (masked)
```

Long-term and short-term keys share the prefix. Short-term keys are much longer because they carry an encoded session token, so a long value is not proof of a long-lived key. Neither type looks like a classic AWS access key ID, which starts with `AKIA`. An access key ID and secret access key are a different credential; if the same file contains them, handle them as well. See the [AWS access key](/secrets/aws-access-key) guide.

## How Amazon Bedrock API Keys get leaked

-   **Environment files committed by accident.** A `.env` file holding the Bedrock bearer token sits next to the code that reads it, and nobody added it to `.gitignore`.
-   **Notebooks and scripts.** A key pasted into a notebook or a quick test script to try a model call, then pushed with the rest of the project.
-   **Client-side code.** A web or mobile app that calls Bedrock directly from the browser ships the token to every visitor. Calls should go through your own backend.
-   **CI logs.** A debug step that prints request headers or the full environment, so the token ends up in a build log that others can read.
-   **Shared configuration.** IDE or agent settings files that store the token and get copied into a team dotfiles repository.

## What to do in the first hour

1.  **Find the owner.** Work out whether the leaked value is a long-term or a short-term key, and which IAM user a long-term key belongs to. Write down that user’s name before you change anything, because you will need it for the audit.
2.  **Create a replacement.** For production, AWS recommends short-term keys or IAM roles instead of long-term keys. Issue the new credential first, deploy it, and confirm that the application still works.
3.  **Deploy the new value** to your secret manager or environment, and keep each credential limited to one application.
4.  **Revoke the exposed key** using the steps in the revocation section below. Do not leave it active while you investigate.
5.  **Audit usage.** In AWS CloudTrail, search for activity by the owning IAM user since the exposure, especially Bedrock calls from unfamiliar IP addresses or regions. Look for model invocations you did not make, and for large volumes of requests. Keep in mind that CloudTrail events can take some time to appear.
6.  **Review the IAM user.** Check which policies are attached to the user. If it has more access than the application needs, reduce it. A long-term key can only reach what its user can reach.
7.  **Clean the repository.** Remove the value and rewrite history if you want to. See [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github), and [deep scan your whole git history](/blog/deep-scan-your-whole-git-history) if the value may have been committed in an older branch.

Not sure what else leaked? [Run a free scan](/).

[Not sure what else leaked? Run a free scan.](/)

## Revoke it at AWS

Long-term Bedrock keys are managed in the Amazon Bedrock console, in its API keys section, and they are tied to the IAM user that owns them. Go to the API keys page, find the key that matches the leaked value, and delete it or deactivate it. A deleted or deactivated key stops working for new requests. A long-term key also works only in the AWS region where it was generated, so check that region when you search. If you cannot match the key in the list, check the IAM user’s credentials. AWS documents the full procedure for compromised keys in its [guidance on handling compromised Bedrock API keys](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-revoke.html). If the value was a short-term key, it expires on its own, but you should still block the owning user’s access and check CloudTrail.

## How LeakWatch detects it

The rule is called Amazon Bedrock API Key. It looks for the literal `ABSK` prefix at a word boundary, followed by between 109 and 269 characters from the base64 alphabet, which covers both the long-term and the short-term formats. The keyword that narrows the search is `absk`. The severity is **critical**, because a valid Bedrock key can run model calls billed to your account. This type is not checked live: LeakWatch does not send any request to AWS with the value it found. A match tells you the value has the right shape, not that the key still works.

LeakWatch detects this format but does **not** check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.

## FAQ

Is a short-term key safer than a long-term one?

Yes, in most cases. A short-term key expires within a short window, so a leaked copy becomes useless sooner. AWS recommends short-term keys or IAM roles for production, and long-term keys mainly for exploration. Still, treat a leaked key of either kind as live until you have checked.

Can someone use this key to reach other AWS services?

Not through the Bedrock key itself. It authenticates Bedrock calls, and those calls are limited by the permissions of the IAM user behind it. That is why the owning user’s policies matter. If the file also held an AWS access key pair, that pair is a separate and broader risk.

Do I need to rotate the other credentials in the same file?

Yes, if they were in the same file. Check each value on its own. Bedrock keys, AWS access keys and the keys for other model providers are issued and revoked in different places, and each needs its own replacement.

## Related

-   [AWS access key](/secrets/aws-access-key)
-   [Anthropic (Claude) API Key](/secrets/anthropic-api-key)
-   [OpenAI API key](/secrets/openai-api-key)
-   [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github)
-   [Which vendors leak most this week](/leaks/trends)
-   [All secret guides](/secrets)

[Get alerted next time a secret leaks — create a free account](/)

LeakWatch is not affiliated with Amazon Bedrock.

![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp)

Gabriel Diyan (0xCr0c0)

Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about).

[GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab)

LeakWatch

Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about).

Scan

-   [Product](/product)
-   [Live feed](/leaks)
-   [Trends](/leaks/trends)
-   [API docs](/docs)
-   [CI/CD](/docs?tab=ci)

Read

-   [Blog](/blog)
-   [Secret guides](/secrets)
-   [Changelog](/changelog)
-   [About](/about)

Verify

-   [Security](/security)
-   [Privacy](/privacy)
-   [Terms](/terms)
-   [Legal](/legal)
-   [Contact](/contact)
-   [Status](https://status.leakwatch.net)

© 2026 LeakWatch

[GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)
