# Black October: how to contain stolen AI provider keys after the AI developer platform breaches

> Nine AI developer platforms reported breaches in October 2026 that exposed stored AI keys. What to rotate first, how to check Bedrock abuse, how to scope keys.

- Published: 2026-11-02
- Author: Enforster AI (https://enforster.ai)
- Category: AI Security
- Tags: AI Security, Security Operations, Access Control, Supply Chain, LLM
- Canonical URL: https://blog.enforster.ai/black-october-stolen-ai-keys-developer-platforms

## Key takeaways

- Wiz counted nine AI developer platforms that disclosed incidents in October 2026, from Fireworks AI on October 6 to Northflank on October 30, and found no single vulnerability linking them.
- The shared target was stored environment variables, especially AI provider keys, which attackers validated within minutes and resold as discounted model access, a pattern called LLMjacking.
- In one case Wiz observed about 1.7 million Amazon Bedrock calls in roughly 13 hours from a single address, and two cases together likely ran up over $100k at list price.
- Rotation means revoking the old credential at the issuing provider, not only pasting a new value into the hosting platform, because a copied key stays valid until the issuer kills it.
- Amazon Bedrock logs InvokeModel and Converse calls to CloudTrail as management events by default, so you can search for a leaked access key's model usage without having enabled anything in advance.

---

If you stored AI provider keys or cloud credentials as environment variables on an AI developer platform that disclosed a breach in October 2026, treat those secrets as stolen. Revoke them at the issuing provider, check the provider's logs for use you did not make, and replace them with narrower credentials. Attackers in this wave went after stored environment variables because AI keys convert to cash quickly: they validate a key within minutes and resell the model access.

This article covers what happened, the order to rotate in, how to check an Amazon Bedrock key for abuse, and how to limit what the next stolen key can do.

## What happened in "Black October"?

On October 30, 2026, Wiz published ["Black October" for AI Developer Platforms](https://www.wiz.io/blog/black-october-for-ai-developer-platforms), a summary of incidents disclosed by nine platforms that month: Fireworks AI (October 6), Andromeda (October 9), Zeabur (October 14), Lightning AI (October 15), OpenCode (October 16 to 17), Railway (October 20), Warp (October 23), CommandCode (October 28), and Northflank (October 30).

The entry points differed. Several platforms pointed to credential access. Railway described privilege escalation in its build infrastructure, Warp a third-party vendor dependency, and OpenCode a legacy system. Wiz found no single vulnerability or dependency tying them together, and Fireworks, OpenCode, and Warp reported signs of what they called an agent swarm attack.

What the incidents shared was the objective. Wiz describes attackers looking for stored environment variables, with a focus on those that grant AI access.

Northflank's [status page](https://status.northflank.com/) is the most detailed public timeline. A Wiz threat alert arrived at 11:43 UTC on October 30, and by 13:58 Northflank told customers to assume all environment variables had been decrypted. Users later confirmed unauthorized use of their AI keys. On November 2 Northflank said evidence pointed to secrets held in its control plane, that it had seen no sign that workloads or workload data were accessed, and that it had patched CVE-2026-98432 across its fleet.

> **Not only the nine platforms:**
>
> Wiz's list covers incidents disclosed in October. If any platform holding your secrets announces a credential incident, the response below applies the same way.

## Why are AI keys the prize?

A static AI provider key is a bearer credential with a meter attached. Whoever holds it can spend your quota on frontier models from anywhere, and the bill arrives later.

Wiz traced two Amazon Bedrock keys from this wave:

- **Case A.** The first `InvokeModel` call, a validation check, came within 30 minutes of the reported credential access. About 800,000 calls followed over roughly 30 hours, around 90% of them successful. The key's policy allowed `global.*` cross-region inference profiles, and only about 6% of calls were throttled.
- **Case B.** The key was restricted to `us.*` profiles, so early calls failed. The attacker adapted, and about 1.7 million calls came over roughly 13 hours from one address, more than a million of them successful.

Wiz estimates the two cases likely ran up over $100k at list price. It also describes two resale operations offering discounted frontier model access, one of which had access to the stolen keys, though Wiz could not tie either directly to the flood of calls. This is LLMjacking: stolen keys turned into a resold API.

The platform breach is a supply chain problem. You did nothing wrong in your own code, but one compromised control plane exposed every customer's secrets at once.

## What should you rotate first?

Rotate everything stored on the affected platform, but in order of how fast it can hurt you. Northflank's guidance gives a sensible order: AI provider keys, cloud provider credentials, payment keys, private keys, then database credentials. It also covers both integration secrets and project secrets, and shared or global secret groups as well as per-service variables.

For each secret, rotation has three steps, and the first is the one teams skip:

1. **Revoke at the issuer.** Delete or disable the old key in the AI provider, cloud console, or payment dashboard. Updating the value on the hosting platform does nothing to a copy the attacker already holds.
2. **Issue a narrower replacement.** Use the incident to cut scope: one key per workload, limited to the models and regions that workload uses.
3. **Redeploy and confirm.** Update the secret, redeploy, and check that the old key now fails.

Northflank also revoked access tokens, sessions, version-control integrations, and cross-account IAM roles, so expect to reconnect integrations. Treat any you reconnect as new trust decisions.

> **Inventory before you rotate:**
>
> Export the list of secret names from every project and secret group before you start. It becomes your rotation tracker and your record of what was exposed.

## How do you check whether a stolen Bedrock key was used?

You can investigate without having prepared. AWS [documents](https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html) that Bedrock logs `InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, and `ConverseStream` to CloudTrail as management events, which CloudTrail records by default. Each event includes the caller identity, the access key ID, the source IP address, the Region, and the model ID.

Start with the leaked access key ID:

```bash
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA_LEAKED_KEY_ID \
  --start-time 2026-10-01T00:00:00Z \
  --region us-east-1 \
  --query 'Events[].{time:EventTime,name:EventName}'
```

Event history is per Region, so repeat the lookup in each Region where you use Bedrock, or query a multi-Region trail. Then look for these signals, drawn from what Wiz observed:

- A single `InvokeModel` call from an unfamiliar IP address shortly after the platform's breach window, followed by a burst of calls.
- Calls to models your application does not use, especially the most expensive tier.
- Quota enumeration on Bedrock or EC2, and attempts at account-level changes. Wiz saw a `PutAccountDataRetention` attempt with one stolen key.
- Source addresses from Wiz's indicator list, which includes 23.106.46.239, 38.246.114.118, 104.243.32.50, and 31.57.201.201.

One counting trap: AWS notes that streaming calls produce an extra stream-completion event with an `eventType` of `AwsServiceEvent`. It carries token counts but is not an API call, so count only `AwsApiCall` events when you measure call volume.

For other providers, check the usage and billing views for each key or project and report unexpected use to the provider. Northflank tells customers to contact providers such as OpenAI or Anthropic directly.

## How do you limit the blast radius of the next stolen key?

Rotation fixes this incident. Scoping decides how bad the next one is.

### Scope Bedrock credentials to the profiles you use

The difference between Wiz's two cases is instructive. The Case A key allowed `global.*` profiles, and the attacker ran with few throttles. The Case B key's `us.*` restriction caused early failures but did not stop the abuse. Scoping slows an attacker and narrows what they can reach; it does not replace revocation.

AWS's [inference profile documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference-prereq.html) shows how to allow invocation only through a named inference profile using the `bedrock:InferenceProfileArn` condition key, and how to block global routing with an explicit deny:

```json
{
  "Effect": "Deny",
  "Action": ["bedrock:InvokeModel*"],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:RequestedRegion": "unspecified" }
  }
}
```

Pair the deny with allow statements that name only the inference profiles and foundation models the workload calls. A key that can reach one model in one geography is worth less to a reseller.

### Keep fewer long-lived keys on third-party platforms

A hosting platform that stores a static key can lose it. Where the platform supports workload identity or short-lived credentials, prefer those. Otherwise give each service its own key so one leak stays one rotation. The same reasoning applies to CI, covered in [AI coding agents in GitHub Actions without leaking secrets](https://blog.enforster.ai/ai-coding-agents-in-github-actions-without-leaking-secrets).

### Alert on spend, not just on errors

Case B shows how fast abuse adds up: over a million successful calls in about 13 hours. Daily budget alerts per key or project, set close to normal usage, are often the first signal you get. Per-user and per-key budgets are covered in [Denial of wallet: rate limits and cost controls for LLM applications](https://blog.enforster.ai/denial-of-wallet-cost-controls-for-llm-applications).

> **Gateways hold keys too:**
>
> A model gateway or router that stores provider keys for you is the same kind of target as a hosting platform. See [vetting AI aggregators and model gateways](https://blog.enforster.ai/ai-aggregator-data-exposure-vetting-model-gateways) for what to ask before you hand one your keys.

## A response checklist

- Confirm which platforms hold your secrets, and whether any disclosed an incident in October 2026.
- Export the names of every exposed secret, including shared and global groups.
- Revoke AI provider keys at the provider first, then cloud credentials, payment keys, private keys, and database credentials.
- Search CloudTrail for each leaked AWS access key ID across every Region where you use Bedrock.
- Review usage and billing for every other AI provider key, and report unexpected use to the provider.
- Disable public access to platform-hosted databases and add-ons where you had it enabled.
- Reissue keys scoped per workload, per model, and per Region, and deny global inference routing where you do not need it.
- Set per-key spend alerts close to normal daily usage.

The breaches in this wave had different causes, but the response is the same each time: assume the secret is gone, kill it where it was issued, and make sure the replacement can do less than the one you lost.