Imagine opening your AWS bill and finding over $100,000 in Amazon Bedrock charges your team never made.
This was the reality for organizations hit by “Black October.” In October 2026, attackers extracted Amazon Bedrock API keys from breached AI developer platforms and used them to generate over $100,000 in usage.
The industry calls this LLMjacking. Attackers find exposed AWS credentials, hook them up to high-cost LLMs, and use your account as free computing power for their own workloads. While it shows up on your invoice as an AI bill, the root cause is almost always simpler: broken IAM hygiene.
At Cloudelligent, our developers spend a lot of time reviewing AWS environments, and the story is usually the same. Massive cloud security breaches rarely start with zero-day exploits. They start with forgotten access keys, unmonitored service accounts, and permissions left wide open.
Our blog breaks down how an LLMjacking attack unfolds across your IAM security setup and the priority fixes to put in place. We will also close with what to do immediately if an unexpected Bedrock charge lands on your account.
What Is LLMjacking on AWS #
LLMjacking is the theft of access to a hosted large language model (LLM). It occurs when attackers use stolen cloud credentials to run AI models on platforms such as Amazon Bedrock. This forces the victimized organization to cover the expenses.
Every LLMjacking attack starts with unauthorized access, which puts security and IAM at its center. To call Amazon Bedrock, an attacker needs a working credential and permission to use it. These are controlled by the AWS Identity and Access Management (IAM) controls.
Once an attacker has that access, the damage shows up on your bill. Amazon Bedrock calls can look like normal API usage, so the activity may not stand out.
Figure 1: How LLMjacking Works on AWS
How Attackers Get AWS Credentials for LLMjacking #
AWS access keys are the login details that software uses to connect to your AWS account. Anyone who holds a valid key can make requests on your behalf, including calls to Amazon Bedrock. That makes protecting these keys a core part of Amazon Bedrock security.
Recent incidents show three common ways attackers get hold of them.
1. Keys Left in Code or Files
Developers sometimes save keys in code, settings files, or scripts. If those files end up somewhere public, anyone can copy the key. Old keys that never expire are the biggest risk.
In fact, in September 2026, FortiGuard Labs reported attackers who used a single leaked key with full admin rights and no expiry date. They created their own user in the account and signed up for AI models.
Figure 2: How a Leaked IAM Key Led to LLMjacking (Source: FortiGuard Labs Threat Research*)*
2. Poisoned Software Updates
Sometimes attackers break into a popular software tool and hide harmful code inside a routine update. The moment your team installs the update, that code sweeps into your build environment for exposed keys.
On October 21, 2026, this happened to LiteLLM, a tool with about 23 million weekly downloads. Within hours, the attacker was testing stolen AWS keys from build servers and Kubernetes systems against Amazon Bedrock.
3. Amazon Bedrock API Keys That Never Expire
Long-term Amazon Bedrock API keys can be set to never expire. When you create one in the console, it also creates an extra IAM user. That user stays even after the key expires, and it is easy to forget.
Temporary credentials are not fully safe either. The LiteLLM attackers stole temporary credentials and tested them within hours. That is why every key should reach only what it needs, a practice called IAM least privilege.
How IAM Security Gaps Map to Each Step of the Attack #
Each IAM gap plays a different role in an LLMjacking attack. Some let attackers in, while others let them spend more or stay hidden longer.
The table below works as a simple identity and access management risk assessment. It maps each gap to the attack step it enables, so you can see which IAM controls to fix first.
| IAM Gap | Attack Step | Why It Matters | Priority | | Access keys older than 90 days | Entry | An old key still works if it leaks | Critical | | Multiple active keys or keys unused for 90 days or more | Entry | Extra keys can leak without anyone noticing | Critical | | Console users without MFA | Entry | A stolen password is enough to sign in | Critical | | Root user without MFA or with access keys | Takeover | Attackers get full control of the account and billing | Critical | | Weak or missing password policy | Entry | Weak passwords are easier to guess | Advisory | | Roles that trust unknown outside accounts or lack an external ID | Entry | Another AWS account can use the role | Advisory | | Broad Amazon Bedrock access, high quotas or many Regions | Spend | Attackers can use more models, tokens and Regions | Advisory | | Model invocation logging turned off | Hiding | No record of prompts or token usage | Advisory | | IAM Access Analyzer not enabled | Hiding | Unused keys and outside access go unflagged | Advisory |
Table 1: IAM Gaps Mapped to LLMjacking Attack Steps
Critical IAM Security Gaps to Fix First #
Critical gaps give attackers a direct way into your account, so closing them should be your first priority. AWS already provides the tools to find and close each one. The most useful is the IAM credential report, which is a downloadable list of every user in your account. It shows whether each user has Multi-Factor Authentication (MFA) turned on, how old their access keys are, and when each key was last used.
With the report in hand, you can work through the critical gaps below and follow AWS IAM security best practices:
- Turn on MFA for every console user: Multi-factor authentication (MFA) asks for a second proof of identity, such as a code or a physical key. With AWS MFA on, a stolen password alone is not enough to sign in.
Best practice: Use phishing-resistant MFA, such as passkeys or security keys. Have human users sign in through a central identity provider that issues temporary credentials.
- Replace access keys older than 90 days: Long-lived keys stay usable until someone removes them. Check each key’s last rotated date in the credential report.
Best practice: Replace old keys with IAM roles, which use temporary credentials. Rotate any keys you must keep.
- Remove extra and unused access keys: Each IAM user can have two active keys, which helps with rotation. A second key that nobody uses is another exposed key. The credential report shows when each key was last used.
Best practice: Deactivate idle keys first, confirm nothing breaks, then delete them.
- Lock down the AWS root user account: The root user has full control of the account, including billing.
Best practice: Delete all root access keys and turn on MFA for the root user.
- Find long-term Amazon Bedrock API keys: The credential report does not list these keys, but the ListServiceSpecificCredentials API does.
Best practice: Set an expiry date on any long-term Bedrock API keys you keep.
See how Cloudelligent helped a healthcare company set up single sign-on with MFA*.*
Advisory IAM Security Gaps to Review Next #
Fixing these baseline gaps immediately shrinks your attack surface and locks out the easiest entry points. But as the LiteLLM attack showed, a key can still leak even if you have taken all the right steps. Once that happens, advisory gaps decide how much damage follows. They control how far an attacker can reach and how long the activity can go unnoticed.
Under the AWS Shared Responsibility Model, these settings are yours to manage. So, let’s review these advisory cloud IAM security gaps:
-
Set a strong password policy: Add length and reuse rules, so console passwords are harder to guess, though they do not protect access keys.
-
Review roles other accounts use: Remove access for vendors that you no longer use and require an external ID for every third-party role.
-
Limit and log Bedrock access: Limit which identities can call Bedrock, and in which Regions, then turn on model invocation logging, which is off by default.
-
Turn on IAM Access Analyzer: Use IAM analytics to flag access shared outside your account and access nobody uses.
How to Spot Unexpected Amazon Bedrock Charges Early #
Even with logging turned on, LLMjacking can be hard to see in security tools alone. The first clear sign may be a jump in Amazon Bedrock spend. That is why a cloud cost optimization review should treat a sudden Bedrock cost spike as a possible security event, not only a budget issue.
Additionally, there are three AWS tools your security and finance teams can use to catch the cost spike early.
-
AWS Budgets: This alerts security and finance owners when Amazon Bedrock spend passes a set limit.
-
AWS Cost Explorer: It shows Amazon Bedrock spend by Region and usage type, so unfamiliar Regions or models stand out.
-
AWS Cost Anomaly Detection: This flags unusual spending patterns that a fixed budget might miss.
Pro Tip: Keep in mind that AWS billing data only refreshes a few times a day, so billing alerts aren’t real-time and won’t automatically stop unauthorized spending. However, establishing a clear baseline for your GenAI costs makes sudden usage spikes much easier to catch before they spiral out of control.
See how Cloudelligent helped a data analytics software company manage security and cost together and cut its AWS costs by 26%.
What to Do When You Find Unexpected Amazon Bedrock Charges #
When a budget alert or Cost Explorer shows Amazon Bedrock unexplainable charges, you need to act fast. These four steps cover your immediate containment priorities during the first 60 minutes. Use them as a critical triage guide while your full incident response playbook kicks in.
1. Confirm the Unexplained Charges
-
Ask app owners if a new project or test explains the usage.
-
Search AWS CloudTrail, your account’s record of API activity, for InvokeModel calls.
-
Note the access key ID behind any calls no one recognizes.
2. Cut Off Attacker Access
-
Deactivate the key instead of deleting it, so the evidence stays intact.
-
Attach the AWSCompromisedKeyQuarantineV2 policy to block risky actions by that user.
-
Revoke active sessions for any IAM role the attacker used.
-
Disable any leaked Amazon Bedrock API keys.
3. Find What Attackers Left
-
Check for new IAM users, access keys, and service-specific credentials.
-
Look for BedrockAPIKey users that nobody on your team created.
-
Confirm model invocation logging is still turned on.
-
Review every Region, not only your main one.
4. Recover and Report Findings
-
Open an AWS Support case about the charges and the breach.
-
Brief finance on the cost so far.
-
Replace other credentials stored in the same place as the leaked key.
-
Bring in an AWS security partner if you need help.
Find and Fix Your IAM Security Gaps with Cloudelligent #
LLMjacking turns small IAM security gaps into large Amazon Bedrock bills. These gaps are easy to miss, such as an old key, a console user without MFA, or logging that is turned off. Each one gives attackers a way in, more room to spend, or more time before anyone notices. That is why the order of fixes matters. Close the critical gaps first, then work through the advisory ones.
Maintaining strong credential hygiene across multiple AWS accounts and development teams requires continuous vigilance. As an AWS Premier Tier Partner, Cloudelligent helps organizations audit their cloud environments, remediate IAM vulnerabilities, and maintain security posture through managed cloud services. A good place to start is a ** FREE Well-Architected Review**, since its Security pillar covers identity and access management controls.
Frequently Asked Questions #
1. What is IAM security, and why is it used?
IAM security is the practice of controlling who can access your AWS resources and what they can do with them. The main IAM security benefits are fewer ways in for attackers, less room for misuse, and faster detection. Many teams use cloud IAM managed services to keep these controls in place across all their accounts.
2. What is LLMjacking on AWS?
LLMjacking on AWS occurs when attackers use stolen credentials to run AI models, often on Amazon Bedrock, in your account. You pay for every request and token they generate.
3. Does AWS MFA stop attackers who steal access keys?
No. MFA protects console sign-ins, but access keys can call AWS services without MFA unless an IAM policy requires it.
4. What is the difference between IAM and IAM Identity Center?
IAM controls users, roles, and permissions inside an AWS account. IAM Identity Center adds single sign-on across many accounts and gives people temporary credentials instead of long-term keys.
5. How do I detect unauthorized Amazon Bedrock usage?
You can catch unauthorized activity by pairing API logging with cost monitoring. Turn on model invocation logging and watch CloudTrail for InvokeModel calls you don’t recognize. AWS Cost Explorer and Cost Anomaly Detection can also flag unusual Amazon Bedrock spend.
6. Can AWS Budgets stop unauthorized Amazon Bedrock spending?
No, standard AWS Budget alerts do not stop spending on their own. Standard notifications simply alert you after a spending threshold is crossed. While you can configure automated AWS Budget Actions to apply restrictive IAM policies when alerts trigger. However, keep in mind that AWS billing data only refreshes periodically (up to once a day).