The short version: Google's Threat Intelligence Group (GTIG) and Mandiant published a report this week describing "LLMjacking" — attackers stealing or harvesting LLM API keys and cloud credentials, then either burning the quota themselves or reselling access through underground proxy services known as "LLM Mixers." One victim organization accumulated nearly $1 million in fraudulent token costs through a mixer called Jet Night before the key was revoked. The report names a threat cluster, UNC6993, and documents a specific evasion trick: attackers validate stolen keys with a single-token request (max_tokens=1) so the check never shows up as a volume spike. The thread connecting every incident, including this week's separate Northflank and OpenCode disclosures, is the same one KnoxCall is built around: a bare API key is a bearer credential, and once it exists as a copy-pasteable string, anyone who copies it owns the spend.
What GTIG and Mandiant actually found
The report, titled "The Rise of LLMJacking," documents how Google's threat intelligence team and Mandiant's incident responders watched attackers turn stolen cloud identities and exposed AI endpoints into a resale business. Mandiant found that fraudulent resource consumption exceeded $100,000 in a day in individual cases, and cumulative charges at some organizations reached $1 million before access was revoked.
What sets this apart from older forms of cloud resource theft is speed. Unlike cryptojacking, which consumes resources gradually and can take weeks to produce a noticeable bill, LLMjacking can generate a massive spike in fraudulent charges in a matter of hours, because inference is billed per call rather than per hour of idle compute. There's no slow ramp a billing dashboard might catch early — the damage can be largely done by the time anyone looks.
Two separate roads into the same abuse
The report separates two attack paths that converge on identical outcomes. The first starts with stolen cloud identity and reaches an LLM API almost as a side effect. In mid-2026, the cluster tracked as UNC6993 compromised a cloud instance through a misconfigured service account key, then used that foothold to grant itself further access to an LLM API. From there it created additional API keys to expand its footprint, eventually racking up more than $100,000 in charges on that access alone.
The second path skips cloud IAM entirely and goes straight for the model credential. Separate reporting on the same research describes attackers systematically collecting corporate LLM API keys directly from public GitHub repositories. No privilege escalation, no lateral movement — just a key sitting in a commit history, a .env file pushed by accident, or a config file left in a public repo. Once copied, that string works exactly as well for the attacker as it did for the developer who leaked it, because an LLM API key carries no binding to the machine, IP address, or identity that originally requested it.
Both paths feed the same monetization layer. GTIG observed deployments using custom Node.js proxy bundles, containerized workloads, and gateway software built specifically to expose stolen access compatible with multiple frontier models at once — infrastructure built for resale, not personal use.
The one-token probe: validating a key without tripping an alarm
Before committing a stolen key to high-volume resale traffic, attackers need to confirm it still works — without generating the kind of spike that gets a key revoked in minutes. According to the research, one group checked whether keys worked by sending tiny requests configured with max_tokens=1, deliberately avoiding any traffic pattern that would read as abuse.
It's a simple, effective piece of attacker tradecraft. A request capped at a single output token costs almost nothing, returns almost instantly, and looks indistinguishable from a developer's health check or a monitoring script's keep-alive call. Most billing dashboards and usage alerts are tuned to catch sustained volume or dollar thresholds, not isolated low-cost calls. The probe exploits exactly that gap: it confirms the key is live and the quota is real before the attacker commits to the resale traffic that generates the actual bill.
This also explains why alerting strategies built purely around spend thresholds miss the opening move. By the time a volume-based alert fires, the key has already been validated, catalogued, and quite possibly listed on a mixer.
The resale layer: LLM Mixers and Jet Night
Mandiant's term for the resale infrastructure is an "LLM Mixer" — an illicit gateway that proxies, aggregates, and resells unauthorized LLM access to underground subscribers. The economics favor the buyer: pay a fraction of the legitimate rate, and the mixer operator absorbs the operational risk of running traffic through someone else's stolen credentials.
One such service, Jet Night, advertised an unlimited token plan for about $60 a month — well under the $100–$250 a legitimate heavy user typically pays for comparable access. The report ties one specific incident directly to that service: an attacker performed more than 500,000 LLM API calls in under eight hours using stolen third-party keys routed through jet-night.com, passing nearly $1 million in token costs on to the victim organization whose key had been stolen.
Notably, the mixer's own reliability became an unintentional signal. Researchers observed that Jet Night acknowledged repeated outages on its public Telegram channel — most likely because victims were discovering the compromise and revoking the underlying keys. The resale business is only as stable as its supply of stolen credentials.
Why a bare key is the wrong shape for this problem
Strip away the specific threat-cluster and resale-brand names, and the structural issue is simple: an LLM API key is a long-lived bearer credential. Whoever holds the string gets full access at full spend until someone notices and rotates it. There's no handshake tying the key to a specific process, no built-in per-caller rate ceiling, and no proof of possession beyond "I have the string." That's true whether the key leaked through a misconfigured service account, a public GitHub commit, or — as in the Northflank and OpenCode incidents disclosed in the same stretch of days — a platform-side exposure of customer-supplied secrets stored in a control plane.
This is the exact failure mode an egress proxy architecture is built to close. In KnoxCall's model, the real provider key is injected at the network edge, at the moment a request actually goes out to OpenAI, Anthropic, or another model provider. The application process, the CI runner, the AI coding agent, and the .env file never hold that key at all — they hold a scoped reference that only KnoxCall's egress wire can resolve into the real credential. If that reference leaks into a GitHub repo or a compromised container, there's nothing for an attacker to validate with a max_tokens=1 probe, because the leaked string isn't a working credential anywhere outside KnoxCall's own infrastructure.
It's worth being precise about what this does and doesn't solve. An egress-injection model doesn't stop someone from misconfiguring a cloud IAM role, and it doesn't replace the need to watch spend. What it removes is the specific object both LLMjacking paths depend on: a plaintext key that is equally valid no matter where it gets pasted. Take that object out of circulation, and GitHub scraping and credential harvesting stop producing anything a mixer can resell.
What this means if you hold production LLM keys today
- Treat LLM keys as privileged credentials, not configuration values. They belong in a secrets manager or gateway, never in source control, CI logs, or shared documents.
- Don't rely on spend alerts alone. The
max_tokens=1probe is specifically designed to be invisible to volume-based monitoring; anomaly detection needs to look at request patterns, not just dollar thresholds. - Scan your own repositories for exposed keys before someone else does. Harvesting corporate LLM keys from public GitHub repos was one of the two primary entry points GTIG documented — this is not a theoretical risk.
- Set hard spend caps at the provider level wherever your provider supports them, as a backstop independent of your own detection pipeline.
- Audit who, and what, actually holds your keys — including CI runners, local
.envfiles, and any AI coding agent with shell or file access.
For teams rethinking how AI provider keys are handled, our AI gateway overview walks through the egress-injection model in more detail, and the security page covers how KnoxCall scopes and rotates credentials without ever exposing them to calling code. If you're comparing this approach against a traditional secrets manager, see how the two models differ.
What's still unknown
Google's report doesn't name the victim organizations, and the $1 million figure is tied to one documented incident rather than an industry-wide total — treat it as a data point, not a trend line. It's also not fully clear how UNC6993 relates to the operators behind Jet Night and newapi.pro; the research presents them as related but distinct pieces of the same ecosystem rather than a single group. Expect more detail, and likely more named mixer services, as this research continues.