LLMjacking: When Attackers Run LLMs on Your AWS Bill

A sandbox account that normally costs $120 a day bills $85,000 in fourteen hours. A dormant member account, untouched for eleven months, runs up $75,000 before anyone opens the invoice. A European retailer's account goes from a few hundred dollars a month to $522,000 in under two days.

None of these attackers stole data or deployed ransomware. They took cloud credentials and used them to call the most expensive large language models on Amazon Bedrock, then left the victim with the bill. This is LLMjacking. In 2026 it has become one of the most common, and most expensive, security incidents that reach DoiT's support team.

This post covers how the attack works and what we've seen in this year's incidents. It then walks through the AWS controls that prevent it. Finally, it shows how to set up DoiT Cloud Intelligence™ (DCI) so you find out from an alert instead of your invoice.

Part 1: AWS controls that prevent LLMjacking

Remove the credentials worth stealing

• Stop issuing long-lived IAM user keys. Use IAM Identity Center for people. Give workloads IAM roles with temporary credentials: OIDC for GitHub Actions, IRSA or EKS Pod Identity, and instance profiles. AWS's IAM best practices are explicit about this.
• Audit the keys you already have. Delete keys unused for 90 days; don't stop at deactivating them. AWS will ask for deletion after an incident anyway. Never put shared keys in CI variables, Helm values, or agent/MCP credential files.
• Treat Bedrock API keys as secrets. Prefer short-term keys, which last up to 12 hours, and inventory and scope any long-term ones (AWS).
• Turn on secret scanning and push protection in your source control (GitHub). If AWS attaches the AWSCompromisedKeyQuarantineV3 policy to one of your users, start incident response. The policy limits what the key can do, but it doesn't remove the attacker (AWS).

Protect root

Use hardware MFA, no root access keys, and a root email address on a domain you control and actively monitor. Set the SECURITY and OPERATIONS alternate contacts on every account, including the dormant ones, so AWS's warnings reach someone who reads them.

Put guardrails at the Organization level

IAM least privilege should limit each workload to the specific models and regions it needs (AWS policy examples). Service control policies then add a backstop that a compromised principal can't remove. Here's a starting point, to be tested in a non-production OU first:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMarketplaceSubscribeExceptPlatformRole",
      "Effect": "Deny",
      "Action": "aws-marketplace:Subscribe",
      "Resource": "*",
      "Condition": {
        "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/ai-platform-admin" }
      }
    },
    {
      "Sid": "DenyBedrockOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] }
      }
    },
    {
      "Sid": "DenyFederationTokenConsoleBypass",
      "Effect": "Deny",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    }
  ]
}

A few cautions. Cross-region inference profiles route requests to other regions, so validate the region condition against the profiles you actually use (AWS). Some accounts should never use generative AI: sandboxes, dormant accounts, and most production accounts outside your AI platform. For those, a plain deny on bedrock:* is simpler and safer.

Limit how fast money can leave

• Lower Bedrock tokens-per-minute quotas to what each workload needs, and require approval for increases (AWS). A quota caps the rate, not the total, but it buys you time.
• Keep experimentation in bounded accounts with their own budgets.

Log and detect

• A multi-region organization CloudTrail trail delivered to a locked-down log archive account.
• Bedrock model invocation logging for approved workloads (AWS).
• Amazon GuardDuty in every account and every region, with AI-related protections enabled. After an incident, AWS checked for security services in the affected member account, not just the management account.
• Alerts on the signals that showed up early in real incidents:
  • new Marketplace agreements
  • GetFederationToken calls
  • CreateAccessKey called by an assumed role
  • root sign-ins or MFA changes
  • sudden jumps in SES send volume

Part 2: Setting up DoiT Cloud Intelligence as your tripwire

DCI won't replace GuardDuty or CloudTrail. Its value here is that it's a cost control plane outside your AWS accounts. An attacker holding your AWS keys can read and edit AWS Budgets, and we've seen one do exactly that. They can't touch the alerts and budgets you've configured in DCI.

Alerts, budgets and anomaly detection watch the spend. Composer and Security Insights close the gaps attackers use to get in. CloudFlow turns any of them into a notification, a ticket, or an approved containment step.

1. Threshold alerts that don't need a baseline

Alerts fire on a fixed rule, so they work on day one, on a model you've never used. This is the most dependable DCI control for LLMjacking.

• Create an allocation that groups all AI model spend: Amazon Bedrock and the "(Amazon Bedrock Edition)" Marketplace products. New models then roll into it automatically, and your alerts don't silently miss next month's model launch.
• Daily spend alert per account: scope it to that allocation, with Metric set to Cost and Interval to Daily. Set the condition to is > $X, where X is two to three times a normal day. Turn on Evaluate for each: Account so one rule covers every account.
• "Should be zero" alert: for sandboxes, dormant accounts, and anything not running AI workloads, alert at > $10 a day.
• Day-over-day jump: percentage change is > 100%.
• Forecast alert: monthly, is forecasted to be > your planned AI spend.

Route alerts to email and a Slack channel that someone actually watches (Slack alert delivery).

2. Budgets on every account, especially the quiet ones

Put a recurring monthly budget on each AWS account, with thresholds at 50%, 85%, and 100%. Budget suggestions can size them for you. Add a daily budget on the AI allocation as a second tripwire that's easy to read. Dormant and sandbox accounts are attackers' favourite targets precisely because nobody budgets them. A $0 account with a $50 budget is a very good alarm.

Budgets won't stop the spend, but they'll tell you about it from outside the compromised account.

3. Tune anomaly detection so it actually reaches you

Cost anomaly detection still earns its place, especially for the EC2, GPU, and SageMaker side of an attack. Three settings matter:

• Widen the severity filter. Email notifications default to Critical only. Set them to "Warning and above" or "All severity levels" (notification settings).
• Turn on renotification, so an active anomaly that keeps growing pings you again.
• Make sure a recipient is configured. In more than one incident, DCI detected the anomaly but nobody heard about it. No notification target was set.

On the Enhanced and Enterprise plans, enable real-time anomaly detection for AWS. It works from CloudTrail and reports within about an hour. Today it covers EC2 and RDS rather than Bedrock. That still catches the GPU and instance half of the attack, which often runs alongside the model abuse. You can also enable anomaly detection on the AI allocation itself (allocation monitoring).

If you instrument AI workloads with Attribute, DoiT also offers token-level usage anomalies in early access. They can flag a runaway workload faster than billing data. They only see traffic from your own instrumented hosts, so they won't catch a stolen key used from an attacker's machine.

4. Automate the first response with CloudFlow

CloudFlow can trigger on DCI alerts, budget thresholds, and cost anomalies, which turns a notification into an action:

• Alert → Slack → approval → containment. When the Bedrock alert fires, post the account and amount to your incident channel. Then, after a human approves, run an AWS action: deactivate the suspected access key, or attach an explicit deny on bedrock:InvokeModel* and bedrock:Converse*. Approval gates keep a false positive from taking production down.
• First-time service detection. A scheduled flow template flags the first spend on any AWS service or SKU. That covers the new-model gap described earlier.
• Revoke AI provider API keys. A webhook-driven template, with approval built in, deletes long-term Bedrock credentials (and OpenAI, Anthropic, or Gemini keys). You can call it from EventBridge, your SIEM, or a GuardDuty finding (tutorial).

Any containment action needs the CloudFlow role in the target account to hold the matching IAM permissions. Decide on those permissions before an incident.

5. Close the gaps before an attacker finds them

Security Insights brings in AWS Security Hub and Trusted Advisor findings. They include access keys that haven't been rotated, root accounts without MFA, and accounts without GuardDuty or CloudTrail. Almost every incident described above started with one of these issues.

Those findings use AWS's generic rules. Composer lets you write your own, on the Enhanced and Enterprise plans. It's DCI's policy engine. It scans the resources in each connected account and checks them against recipes, which are rules you build without code. You can duplicate a DoiT recipe and edit it, or describe the check to the AI assistant. Matches show up as Security insights.

Here's how the gaps behind this year's incidents map to recipes you can build today:

The last row is the closest Composer gets to spotting abuse. A key in a sandbox account that was last used for Bedrock deserves a look, even if spend hasn't moved yet.

To act on the findings, schedule a CloudFlow that reads open Security findings through the Composer Insights node. Post them to Slack or open a ticket each morning. For stale keys, add an approval step that deactivates the key once the owner confirms it's unused.

Composer runs periodic scans, so it's a hygiene control rather than an attack alarm. It doesn't check GuardDuty or Security Hub status, Bedrock invocation logging, Bedrock API keys, or SCP contents. Security Insights and AWS Config cover those. Use Composer to close the doors attackers walked through this year, and keep the threshold alerts above for the spend itself.

If it happens anyway

Start containment as soon as you suspect a compromise. Don't wait for an anomaly alert or final billing figures.

1. Contain first. Deactivate, and then delete, the compromised access keys. Revoke active role sessions with a deny policy conditioned on aws:TokenIssueTime, and disable any suspected Bedrock API keys. If you need a blunt instrument, an emergency SCP that denies bedrock:* on the affected account stops the bleeding (it also stops legitimate Bedrock use). Expect a few minutes of calls to keep landing after a key is disabled.
2. Hunt for persistence. Look for new IAM users, access keys, roles and trust-policy changes, Marketplace agreements, SES identities, Capacity Blocks, and instances in every region. Rotate every key that could have been exposed, not only the one AWS flagged. We've seen a second wave arrive six days into an open incident through a key nobody rotated.
3. Preserve evidence. Export CloudTrail (Event History only holds 90 days), invocation logs, a resource inventory, and a cost export by service.
4. Answer AWS before the deadline. AWS security notices typically give five days before services are suspended. Restrictions can land days after the incident and can affect production services such as Lambda, ECS, and EC2.
5. Ask for the billing adjustment explicitly. In the cases we've seen, AWS expects at least two cost-monitoring controls, such as AWS Budgets and Cost Anomaly Detection. It also expects root MFA, GuardDuty, or Security Hub. They check these in the affected account. Attacker-created Marketplace agreements need to be cancelled. Outcomes have ranged from full credits to partial credits to denials. The process has taken two to twelve weeks. A clear timeline, fast containment, and complete evidence make the difference. AWS has also said it may not review future bills if the controls aren't in place.

If DoiT resells your AWS account, open a DoiT support ticket as soon as you suspect compromise. Our team coordinates with AWS on the security case and the billing-adjustment request, and helps you assemble the evidence AWS asks for.

Your LLMjacking checklist

In AWS

• No long-lived IAM user keys for humans or workloads. Old keys audited and deleted.
• Root: hardware MFA, no access keys, and a monitored email address on a domain you own.
• SECURITY and OPERATIONS alternate contacts set on every account.
• SCPs that deny Bedrock where it isn't needed, restrict Marketplace subscriptions, and block GetFederationToken.
• Bedrock tokens-per-minute quotas sized to need.
• Organization CloudTrail, Bedrock invocation logging, and GuardDuty in every account and region.

In DoiT Cloud Intelligence

• An allocation covering Bedrock plus "(Amazon Bedrock Edition)" Marketplace spend.
• Daily threshold alerts per account on that allocation, including "should be zero" accounts.
• A budget on every AWS account, dormant ones included.
• Anomaly notifications set to Warning or above, with renotification and a real recipient.
• Real-time anomaly detection on AWS (Enhanced and Enterprise plans).
• Composer recipes for stale and admin keys, root posture, security contacts, trail coverage, and Bedrock key use outside your AI accounts.
• CloudFlow: alert-to-approval containment and first-time service detection.

Attackers make money from LLMjacking, so they'll keep looking for accounts nobody watches. Perfect detection isn't realistic. You can still make your account an expensive, noisy, short-lived target. And if something gets through, you can hear about it within hours rather than from the invoice.

Want help reviewing your AWS guardrails or setting up DCI alerts, budgets, and CloudFlow for AI workloads? Talk to DoiT.