Bedrock’s New API Keys: Convenience at a Hidden Security Cost

Recently, the AWS team rolled out the red carpet for a slick new feature in their post, “Accelerate AI development with Amazon Bedrock API keys.” The promise was a dream for developers: a dead-simple way to get your hands dirty with generative AI, fast. As a Founding Engineer at Prowler, I love anything that makes life easier, but my job is to be professionally paranoid. My first thought was, “What’s the catch?“

So, I put on my detective hat and decided to find out. What I discovered is a crucial story about how a feature designed for convenience can, if you’re not careful, become a security blind spot.

The First Clue: A User with a Secret

When exploring Bedrock’s new API keys, I saw two options: long-term keys and short-term keys. My investigation focused on the long-term keys, as they exhibit a fascinating behavior: AWS creates a brand-new, dedicated IAM user just for that key. 

My security instincts lit up immediately. This wasn’t just a key; it was a new identity in my AWS account. While my focus was on these permanent keys, it’s critical to understand that short-term keys are just as dangerous. They inherit all the permissions of the user who creates them and can last up to 12 hours. If an administrator generates a short-term key, they have effectively created a temporary admin token. My primary question remained: how secure was this auto-generated user for the long-term key, and could the AWS_BEARER_TOKEN_BEDROCK I received actually wield its power? To prevent this, AWS provides a secure default. When it creates the IAM user, it attaches the AmazonBedrockLimitedAccess managed policy, a great, secure starting point. The real danger begins when a well-intentioned developer, frustrated by permission errors, decides to swap that safe policy for something a little more… powerful.

The Hypothesis: The True Power of API Key IAM Permissions

This led me to the central question. If an attacker gets their hands on only this bearer token, they can’t mess with my S3 buckets or IAM roles. But what if a developer had granted the key’s user bedrock:* or the user that created the short-term key has admin privileges? What could an attacker do with a master key that only opens one door?

It turns out, they can still burn the whole house down from the inside. They could perform a form of privilege escalation within the Bedrock service itself. This isn’t about becoming a full AWS admin; it’s about seizing control of the AI environment to:

• Run up catastrophic bills by hammering the most expensive models.
• Destroy priceless assets like fine-tuned custom models.
• Sabotage security by deleting Guardrails, effectively escalating their own privileges to generate harmful or toxic content that was previously blocked.

I had a theory. Now I needed proof.

The Experiment: The curl Command That Broke the Case

To get my proof, I had to act like an attacker. I bypassed the safety nets of the AWS SDKs and went straight for the jugular: a raw curl command. My target: a test Guardrail. My weapon: the supposedly “limited” bearer token.

This was the command that would reveal everything:

# Set our variables for the heist
export AWS_BEARER_TOKEN_BEDROCK="the_bedrock_api_key_here"
export REGION="us-east-1"
export GUARDRAIL_ID=$(aws bedrock list-guardrails --region ${REGION} --query 'guardrails[0].id' --output text)

# The direct and destructive API call
curl --request DELETE \
  --url "https://bedrock.${REGION}.amazonaws.com/guardrails/${GUARDRAIL_ID}" \
  --header "Authorization: Bearer ${AWS_BEARER_TOKEN_BEDROCK}" \
  --header 'Content-Type: application/json'

I hit Enter. The terminal was silent. The Guardrail was gone.

That was the “aha!” moment.

The bearer token wasn’t a keycard with limited access; it was a ghost key that passed on every ounce of power from its parent IAM user. The case was cracked.

The Solution: Automating the Lockdown with Prowler

Manually checking every key in a large organization is impossible. This is why I built two essential checks for Prowler to cover the primary risks: permissions and lifetime.

First, to tackle excessive permissions, I created bedrock_api_key_no_administrative_privileges. It automatically hunts down every Bedrock API key and scans its associated IAM user, looking for dangerously permissive policies like AdministratorAccess or the treacherous bedrock:*.

You can run it with this command:

prowler aws -c bedrock_api_key_no_administrative_privileges

FAIL us-east-1: API key ACCXXXX in user BedrockAPIKey-XXXX has full service access through inline policy Bedrock-Admin.

But a powerful key that lives forever is also a huge risk. To address key lifetime, I also developed bedrock_api_key_no_long_term_credentials. This check specifically targets long-term keys and flags any that are configured to never expire, treating them as a critical finding.

You can run it with:

prowler aws -c bedrock_api_key_no_long_term_credentials

FAIL us-east-1: Long-term Bedrock API key ACCXXXX in user BedrockAPIKey-XXXX exists and never expires.

Together, these two checks provide comprehensive, automated coverage for the main risks associated with these new keys.

Running these checks from the command line provides immediate, powerful results. For a centralized view and continuous monitoring, the findings in Prowler Cloud are visualized on a single dashboard, making it even easier to track, prioritize, and manage your security posture across your entire cloud environment.

Here’s how these findings look in the UI:

Conclusion: The Timeless Lesson

New cloud features will always promise to make our lives easier. But as this investigation shows, two timeless security principles are more important than ever.

First, the Principle of Least Privilege. Before you embrace these handy new keys, ensure the permissions behind them are on a tight leash.

Second, always enforce key expiration. A long-term Bedrock API key can be dangerously configured with no expiration at all, making it a permanent liability if compromised. To help you enforce this principle automatically, we built the bedrock_api_key_no_long_term_credentials check. As a best practice, always set the shortest practical expiration date for any key you create to limit the window of exposure.

Your billing and security teams will thank you for enforcing both.

Update Prowler, run the new check, and make sure your journey into generative AI is built on a foundation of rock-solid security.

Our investigation into these API keys was just the tip of the iceberg. Securing your AI workloads requires a holistic approach, covering more than just credentials. That’s why Prowler includes a comprehensive suite of checks specifically designed to harden your entire Amazon Bedrock environment.

To explore all of them, from ensuring model evaluation jobs are private to checking logging configurations, visit our central resource, Prowler Hub.

Here’s a quick look at the full set of Bedrock checks you can explore right now:

Get Started with Prowler Cloud

Prowler Cloud is the easiest way to continually check for Bedrock and other cloud misconfigurations.If you have not already done so, give Prowler a spin by signing up for a free trial