security ai-agents secrets credentials token-jacking supply-chain memory

When Your Agent's API Key Becomes Someone Else's Product

DS
Drakon Systems · 15 August 2026 · 8 min read

Most teams still treat a leaked OpenAI or Anthropic key as an embarrassing Slack message and a rotation ticket. Unit 42's token-jacking research, published 6 August 2026, is the reason that framing is now financially naïve. Stolen AI platform tokens are being fed into gray-market transfer stations — proxy services that resell frontier-model access — and in cases Unit 42 responded to, an exposed credential was integrated into that market within minutes. The victim paid the bill. In some of those cases, the bill approached a million dollars before anyone contained it. Agents make this worse for a boring reason: they are extremely good at remembering useful secrets.

The Bill Is the Payload

For two years the industry argued about whether prompt injection could steal a secret. It can. The more interesting question in August 2026 is what happens to the secret afterwards.

Unit 42's answer is unromantic. Attackers steal the long-lived API keys that developers provision for legitimate model access. They feed those keys into transfer stations — third-party proxies, often running open-source platforms such as new-api or one-api — and resell frontier-model capacity at a discount. The official provider still bills the original account. Billing is cyclical. Many accounts have no hard spend cap. The first alert is sometimes the invoice.

Unit 42 reports transfer stations generating tens of millions of API calls per day and hundreds of thousands of dollars in usage fees. They have responded to cases where inadvertently exposed credentials were integrated into a transfer station within minutes, leading to nearly a million dollars in charges before discovery and containment. Organisations have little recourse to recover those fees. That is the payload. Not ransomware. A bill.

Do not over-read this. The technique is old: steal a key, use a metered service, leave the victim holding the invoice. Cryptomining did the same thing to cloud accounts. Token jacking is that pattern pointed at AI platforms, with a liquid gray market already buying the inventory.

What Unit 42 Actually Observed

A few details are worth stating precisely, because the interesting parts are specific:

  • AI providers typically bill on token consumption, not on a pre-defined job. Newer models cost more per token. To avoid interrupting unpredictable workloads, many providers do not cap consumption by default.
  • Transfer stations sit between official APIs and end users. They handle credential rotation, billing, model routing, and prompt normalisation. Unit 42 notes many advertisements on Chinese-language marketplaces, promising access via seller-issued credits purchased anonymously.
  • For the station to be profitable, operators need a pool of discounted legitimate tokens. Purchasing official capacity at retail and reselling it cheaper is not a business. Stolen keys are.
  • Theft paths named in the source: privileged developer accounts from infostealers and phishing, keys mined from exposed file shares and code repositories, and poisoned self-propagating npm packages. Unit 42 specifically flags campaigns such as Shai-Hulud and Miasma as sources of credentials that could fuel transfer stations for years.
  • In some investigations they correlated malicious API query volume with domains hosting the new-api proxy.

Users of transfer stations are not all criminals. Unit 42 is explicit that many are developers looking for cheaper access. That does not make the stations safe. Sessions can be monitored. Prompts can be mined. The person trying to save money on Claude tokens can become the next credential source.

Why This Is an Agent-Security Story

A chatbot that sees a key in a paste is a content problem. An agent that stores the key, retrieves it next session, and passes it to a tool is an inventory problem.

That is the part most write-ups will miss. Token jacking does not require a novel model exploit. It requires a secret that survives long enough to be copied. Agent stacks are unusually good at producing those secrets:

  • Persistent memory turns one “save this API key for later” into a durable credential store.
  • Skills, MCP servers, and tool configs routinely hold provider keys, gateway tokens, and “recommended” endpoints.
  • Coding agents run on the same workstations and CI runners that already hold cloud credentials, npm tokens, and assistant authentication artefacts.
  • The agent will happily use a key it found. It does not have an instinct for “this belongs to finance, not to me.”

The same week as the token-jacking write-up, Unit 42 and Microsoft published analysis of ChainDrop, a self-propagating npm worm across more than 400 packages. Use it as supporting context, not a second headline. The relevant facts for this post:

  • The worm harvested credentials from developer workstations and CI environments, including cloud, GitHub, npm, Kubernetes, and coding-assistant configuration and authentication artefacts.
  • It established persistence through VS Code tasks and a Claude Code SessionStart hook in .claude/settings.json — trusted developer and AI-tool configuration turned into execution infrastructure.
  • Microsoft describes collection from local files, environment variables, CLI tools, and GitHub Actions runner memory, including secrets designed to vanish when a job finishes.

That is the agent-shaped version of the same theft. A package scanner asks whether the tarball is clean. An agent-security layer asks whether a secret is about to be remembered, handed to a tool, or written into a config the next session will load.

Microsoft's 4 August Zero Trust for AI update is the enterprise echo, not a third incident. The workshop now includes dedicated AI-memory guidance: treat memory as a governed security boundary with intent, provenance, lifecycle visibility, and user control. Least privilege for agents is no longer a vendor talking point. It is in the official playbook.

What to Do Before the Next Invoice

Unit 42's own mitigations are the right starting list. State them without embroidery:

  • Put spend limits on every AI-provider account, with alerts when usage leaves the established baseline.
  • Review every privileged identity that can provision models, create keys, or disable billing alerts.
  • Prefer short-lived bearer tokens over standing API keys.
  • Bind compute and key use to network boundaries where the provider supports it, so a stolen key is useless from a transfer-station host.
  • Keep malicious packages out of the development pipeline. That is still a supply-chain job.

Then add the agent-layer controls the source does not own:

  • Do not let the agent store provider keys, gateway tokens, or connection strings in memory. If it needs a model, inject a short-lived credential at call time.
  • Scan tool arguments, skill files, and MCP config the same way you scan prompts. A secret in .claude/settings.json is not “just config.”
  • Separate suggestion from use: the model may propose a key or endpoint; the runtime must not honour it until a human or policy says so.
  • If a host ran a compromised package or an unconstrained agent, rotate from a clean machine. Assume CI runner memory was in scope.

Where ShieldCortex Fits

We will not claim a checkbox that “stops token jacking.” Transfer stations are a billing-and-identity problem. npm worms are a package-integrity problem. Both need their own controls.

What we will claim is the product thesis, now with a finance incident attached: if an agent can remember a secret, the secret is already halfway to being someone else's product.

  • Memory integrity and credential scanning — so a key that appears in context is redacted or quarantined before it becomes durable state.
  • Prompt and tool-argument scanning — so untrusted content cannot talk the agent into persisting or exfiltrating credentials.
  • Iron Dome on the action side — so “call this provider with this key” is a policed decision, not an emergent side effect of being helpful.

Runtime sandboxes limit what a compromised process can reach. Necessary. Not sufficient. The earlier control is whether the agent was allowed to keep the key at all.

Secrets should not become inventory.

A key the agent remembered last Tuesday is already someone else's product if it ever leaves the host. Scan memory. Gate the action. Cap the bill.

See ShieldCortex options

Sources