Unit 42 says criminals are feeding stolen AI API keys into gray-market proxy services within minutes of obtaining them. In one incident-response case, the unauthorized traffic generated nearly $1 million in charges before the victim contained it. A sudden usage spike is therefore an incident to stop immediately, not a billing problem to investigate at the end of the month.
The report calls the activity AI token jacking. Here, “token” means paid units of model usage accessed through a developer API key; it is not the same as stealing a browser session cookie. If misuse appears, disable the affected key, preserve provider and identity logs, then determine whether the leak came from code, a developer account, an infostealer, phishing, or a poisoned package.
How AI token jacking turns a key into a bill
Developers use API keys so software can call AI services without an interactive login. Many accounts also allow high or automatic scaling so legitimate workloads do not stop unexpectedly. An attacker who obtains a long-lived key can exploit that combination: automated access, expensive models, and a billing cycle that may hide the loss for hours or days.
Unit 42 observed stolen keys being connected to “transfer stations,” proxy services that resell access to multiple AI models below the providers’ normal prices. The proxy accepts a customer’s prompt, routes it through a key controlled by the operator, and returns the answer while the legitimate key owner receives the usage charge. Some stations may also substitute a cheaper model or retain prompts and outputs.
The keys can come from public repositories, poorly protected file shares, compromised developer accounts, infostealers, phishing, or malicious software dependencies. The recent Keyv npm worm shows why package compromise matters here: a poisoned build environment can expose provider keys alongside GitHub, npm, cloud, and CI secrets.
Warning signs to check
| Signal | What it means and what to do |
|---|---|
| Token spend or request volume jumps outside the normal schedule | Disable the affected key first. Export the usage window and identify models, regions, projects, and source addresses before changing dashboards. |
Calls originate from unfamiliar IPs or use Go-http-client/2.0 |
Compare them with legitimate automation. Unit 42 associated that user agent and several published IPs with recent abuse, but one indicator alone is not proof. |
| New keys, higher limits, missing alerts, or logging changes appear | Audit every account allowed to create credentials or modify billing controls. The attacker may have compromised the developer identity, not only one key. |
| A key appeared in Git history, CI output, an AI-tool setting, or a shared file | Assume the value was copied even if it has since been deleted. Revoke it and search the full history, forks, artifacts, caches, and clones. |
A valid key in public code does not prove that it was abused, just as the 321 leaked n8n tokens that still authenticated did not prove malicious access to every instance. Logs, provider usage, identity events, and unfamiliar key-management changes determine the highest evidence state.
What to do after suspected AI API key theft
- Preserve the evidence. Export model-usage and billing records, API request logs, identity events, current keys and permissions, spending-limit changes, and alerts. Record the first abnormal request and the last known legitimate use.
- Disable or revoke the exposed key. Do not wait for a repository cleanup or support response. Confirm that the old value no longer authenticates, then create a replacement with narrower scope and an explicit limit.
- Check who could mint another key. Review developer, service, and administrator accounts that can create credentials, raise quotas, remove billing caps, or disable logging. Reset compromised sessions and require fresh authentication where the provider supports it.
- Find the leak path. Search all Git branches and history, CI logs, artifacts, environment files, shell history, shared drives, ticket attachments, AI-agent configuration, and local credential stores. Removing a secret from the latest commit does not invalidate copies.
- Triage developer systems when code ran. If an unknown package, phishing download, or infostealer may have executed, isolate the host and inspect startup entries, services, scheduled tasks, browser data, and developer tooling. A full Gridinsoft Anti-Malware scan can help find local malware and persistence; rotate credentials afterward from a clean device.
- Review downstream secrets. The same environment may have exposed source-control, npm, cloud, database, SSH, or CI credentials. Rotate only those supported by evidence, but do not assume the AI key was the attacker’s only target.
- Hunt the reported infrastructure carefully. Compare provider and proxy logs with Unit 42’s published IP addresses, domains, and user agent. Treat a match as a lead to investigate, not an automatic compromise verdict.
How to reduce the next token-jacking loss
- Replace long-lived developer keys with short-lived machine credentials where the provider supports them.
- Set hard spending limits or approval thresholds, and alert on changes from the account’s normal model, project, time, region, and request volume.
- Keep production keys in a managed secret store or protected CI variables, not in source files, examples, prompts, notebooks, or local agent history.
- Use separate keys for development, testing, and production so one leak has a smaller billing and data radius.
- Restrict where keys can be used through network boundaries, provider controls, or an audited AI gateway.
- Review which human and machine identities can create keys, change quotas, or disable usage logs.
Cheap access from an unofficial AI proxy creates a second risk for its customers: the intermediary can see prompts, substitute models, or retain proprietary code and data. The practical safe choice is to use the provider directly or an approved organizational gateway, not a transfer station whose source of access is unclear.
References
- Unit 42. “Token Jacking: Cybercriminals Could Be Stealing Your AI Resources.” Palo Alto Networks, published August 6, 2026; accessed August 6, 2026. primary incident-response report and indicators.
