On August 6, Unit 42 reported that stolen AI API keys had reached gray-market proxy services within minutes in incidents it investigated. In one response case, attackers ran up nearly $1 million in charges before the organization discovered and contained the abuse.
Nine days later, the finding remains urgent because many teams still rely on long-lived AI keys, delayed billing, and alerts that can trail the abuse window. An attacker can feed a key exposed in a repository, build log, file share, or developer workstation into a service selling cheap access to frontier models, then let many customers spend against the victim’s account. Unit 42 calls these intermediaries “transfer stations.” The company says it has responded to a growing number of cases, though it did not provide a victim count or name the AI platforms involved.
Exposed keys become inventory
AI platforms issue API keys so software can call models without an interactive login. Those credentials can authorize expensive, automated workloads. Providers commonly meter input and output tokens, total the usage, and bill later. A key with no effective budget ceiling can therefore behave like an open corporate payment instrument.
Attackers obtain keys through familiar routes. Unit 42 lists public or poorly secured code repositories, exposed file shares, phishing, information stealers, and compromised privileged developer accounts. Poisoned npm packages add a supply-chain route: malicious code running in development environments can steal credentials there and then spread into later builds.
The report does not measure how often each route appears. It also does not establish that every discount AI proxy uses stolen access. Its strongest evidence comes from incident response. In cases involving inadvertently exposed credentials, Unit 42 said attackers “integrated them into a transfer station within minutes.”
That interval can be shorter than a code-review cycle, a secret-scanning alert queue, or a daily cost report. Removing a key from source control after discovery is only the first step. The live credential must be revoked at the provider, and defenders need to examine its use from the moment it was created.
Transfer stations multiply demand
A transfer station sits between customers and official AI APIs. Users buy credits from the intermediary and send prompts through its service. The proxy authenticates upstream with real provider credentials, rotates keys, routes requests among models, normalizes prompts, and keeps its own billing ledger.
Unit 42 found that many services use open-source platforms called new-api and one-api. Those projects are general-purpose proxy software; their presence alone does not prove theft. In an investigated incident, however, researchers connected large volumes of malicious API queries to domains running new-api.
The economic signal is stronger than a single suspicious request. Transfer stations can generate tens of millions of API calls per day, according to the report. A stolen key lets the operator sell that capacity below retail because the victim receives the upstream bill.
Figure details
The figure begins with one AI API key exposed through a repository, file share, developer account, or malicious package. An attacker imports the key into a transfer station. The station brokers access to many downstream users and sends their model requests through the victim's credential. Usage then converges on the legitimate organization's provider account as an abnormal volume of API calls and charges.
The intermediary creates a second risk for its customers. Prompts can be routed to an inferior model or monitored for sensitive data. Organizations should treat use of an unapproved transfer station as both a billing-control issue and a possible data disclosure.
Billing cycles hide the burst
Conventional cost review happens too late for an attack that moves in minutes. Monthly invoices are especially weak evidence because the activity has already occurred. Even a daily summary can trail millions of automated calls.
Recognition starts with the relationship among identity, network location, model choice, and spend. Investigate a new token-consumption spike, a sudden increase in request concurrency, calls to models a team has never used, and traffic arriving from networks outside the approved workload boundary. Review changes to spending limits, usage alerts, logging, model provisioning, and privileged developer accounts at the same time. An attacker with account access may weaken those controls before creating or stealing a key.
Keep the evidence boundary clear. A large bill proves that an authorized credential incurred usage. It does not identify how the key escaped. Provider audit logs, source-control history, CI logs, endpoint telemetry, identity events, and package installation records are needed to connect the spend to an exposure route. Preserve them before retention windows expire.
Unit 42 did not report a response from any affected AI provider. Palo Alto Networks also sells AI gateways, identity security, endpoint security, and incident-response services that it recommends in the report. Its case observations are useful primary evidence, while its product claims are vendor assessments of controls it markets.
Bind keys to budgets and workloads
Start with an inventory that joins every AI credential to an owner, application, provider account, approved models, expected request rate, and spending limit. Revoke unknown and unused keys. Move long-lived secrets out of developer files and CI variables when the provider supports short-lived workload tokens or managed identities.
Set a hard budget ceiling for each project and alerts well below it. A notification should reach both the service owner and security operations when token use departs from its baseline. Monitor administrative actions that raise a limit, disable an alert, create a key, or turn off logging. Those changes can precede the expensive request burst.
Constrain the credential at the network and identity layers where the provider allows it. Accept calls only from approved egress addresses, private endpoints, service identities, or an authenticated gateway. Scan repositories, build artifacts, issue trackers, and collaboration systems for secrets. Treat a match as an exposed credential that requires rotation, even if the file was later deleted.
Run a controlled verification test with a newly issued nonproduction key. Give it a small hard limit, bind it to one test workload and approved network, then attempt one request from that workload and one from an unapproved network. The expected result is a successful logged call from the approved identity, a denied call from outside the boundary, and an alert before the test reaches its budget ceiling.
Repeat the test after any identity, gateway, billing, or CI change. A dashboard that lists a spending policy is an expected-value claim. The denied request, recorded workload identity, and threshold alert are the produced evidence that the controls work at the point where a stolen key would otherwise spend.