Intro
If you run an OpenAI-compatible endpoint for a living, the newest form of LLM API key harvesting is aimed at you. In September 2026 the SANS Internet Storm Center published a detailed capture (opens in new tab) of a semi-autonomous coding agent that found weak LLM resale gateways, harvested working keys, validated the inference behind them, and aggregated the survivors behind its own New-API gateway for resale. The attack did not start with a big cloud provider. It started with operators like you: people exposing V2Board panels, New-API instances, or custom inference proxies with loose registration and weak authorization.
The captured material is worth reading in full because the agent leaked part of its own control plane into a honeypot endpoint. The SANS diary describes roughly 43 KB of the agent’s operating context arriving in a single request, including an AGENTS.md file, an offensive playbook, recon scripts, and previously collected API keys. The core shift in the threat model is simple: the credential is only an intermediate asset. The real target is stolen LLM inference capacity, and that capacity is what funds the next round of harvesting.
Background: What LLM API key harvesting looked like before
The older version of this crime was a fairly static affair. An attacker pulled a key from a .env file committed to a public repository, or from a dashboard left open with default credentials, and then burned the quota on their own chatbot or sold the key once. Sysdig documented this pattern as LLMjacking: stolen inference powering offensive tooling. The chain ended at the credential. The key was the final prize, and the attacker’s own tooling consumed the inference.
The difference now is that the stolen access feeds the next harvest. In the earlier model, each breach was a dead end. You lost quota, you rotated the key, and the attacker moved on because their operation had no reason to return. The captured agent in the SANS diary does something else. It acquires access, validates that the backend returns real inference, and consolidates the working endpoints into a resale gateway. That gateway becomes the attacker’s own supply pool. The agent draws on it to run further recon and acquisition, which means the operation grows without the attacker ever paying a dollar for inference.
That is the part I keep coming back to. Most of the individual techniques in the capture are not new, and the SANS diary says as much. Open registration, default credentials, a misconfigured account endpoint. Any one of these has been used against web apps for years. What changed is the loop, the way a successful harvest pays for the next attempt.
What’s happening now: the agent that harvests and re-serves inference
The honeypot capture is unusually detailed because the agent embedded its operating instructions and session context in model requests. The SANS diary received roughly 43 KB of material: a large AGENTS.md file, an offensive playbook, infrastructure notes, reconnaissance scripts, collected API keys, previous targets, and parts of the agent’s working history. One instruction even told the agent to verify its proxy was active before attacking, and that check exposed the operator’s direct, unproxied egress IP, because the playbook contained that IP as a reference value to compare against.
The workflow the agent followed has four stages. The SANS diary lays them out plainly:
- Find supply. The agent generated FOFA queries such as
title="V2Board"andheader="subscription-userinfo"to locate LLM gateways and adjacent subscription infrastructure. - Acquire access. The playbook listed open registration with free balances, default credentials, authorization weaknesses involving
group_id, and exposed endpoints such as/api/auth-files. It also automated trial-account creation using temporary email and CAPTCHA-solving services. - Validate inference. The agent tested compromised keys against resale services and confirmed usable inference through endpoints advertising current premium models. Later this matured into a simple code-logic test, described below.
- Aggregate and serve. The operator loaded roughly 379 upstream endpoints into a self-hosted New-API gateway as channels, ran validation across all of them, disabled the 341 that failed as fake or dead, and mapped five standard model names onto the survivors with priority-based round-robin and automatic failover.
The strongest evidence in the case is the aggregation stage, because it was observed live, and I want to dwell on one operational detail. When the gateway’s own rate limits blocked the automation, the agent edited the gateway’s SQLite database directly. It cleared session rows and injected an admin token. That is a reminder that panel-level rate limiting is not a security boundary, because the attacker will happily bypass the panel if it gets in the way.
The five model names the operator configured were deepseek-v4-flash, claude-opus-5, gpt-5.6-sol, gemini-3.6-flash-high, and glm-5.3. A final probe showed all five returning usable responses through the single endpoint. The aggregation software itself is a legitimate open-source project. The abuse is the compromised credentials fed into it.
How does the agent tell a real model from a fake one?
The validation method is almost embarrassingly simple. Each candidate endpoint is asked to compute a small factorial. That separates actual inference from a canned response or a proxy that just returns static text, because a static responder cannot produce a correct value for an arbitrary input. The operator’s own summary is blunter. The SANS diary quotes it as “a model that cannot edit a file is fake.”
For defenders, the important lesson is what the agent is not checking. It is not verifying model identity. It does not care whether the backend is actually Claude or GPT or any specific brand. It only cares that the endpoint returns plausible, executable inference results on demand. A model label like claude-opus-5 only means the reseller pointed some backend at that name. The label is a claim, not a verified identity.
Here is an analogy a site owner will recognise. This is exactly like the shared hosting reseller who lists “managed WordPress” on the order page but gives you a plain cPanel account with no caching, no staging, and no updates. The name on the plan means nothing. The only thing that matters is what the server actually does when you use it. The agent runs the same kind of honesty check, just against an API endpoint instead of a hosting plan.
What it means in practice for your OpenAI-compatible API
The primary entry points the agent targets are the same conditions you probably have configured right now. An open registration page with free starting balance. A group_id authorization check that trusts a client-supplied field. An exposed account-management endpoint like /api/auth-files. None of these requires a sophisticated exploit. The agent gets in through ordinary web flaws and account farming, and it does so continuously, at machine speed.
I have had to harden gateways for customers who only realised they were exposed after the bill arrived. The first thing I check on any V2Board or New-API instance is whether registration is open, and the second is whether the free balance is non-zero. If both are true, the gateway is a candidate for this exact playbook, and there is no reliable way to spot the attack before quota disappears or the endpoint starts serving someone else’s traffic. The attacker does not need to break in. They just need to sign up.
Keep in mind that this is a feedback loop, not a one-time breach. Every successful harvest makes the next harvest faster. The captured agent used its own aggregated gateway to support further operations, so each new batch of stolen credentials lowered the operator’s costs and widened the targeting. Treating a compromised key as a standalone incident misses the point. The key is one step in a longer operation that will continue unless the gateway itself is locked down.
What to expect next
I expect the economics of this to get worse before they get better. The techniques are already cheap to run, and coding agents improve quickly, so the same playbook will be reused by less skilled operators who never have to write the tooling themselves. The barrier is not technical skill anymore. It is having access to an agent that can follow the playbook, and that access is increasingly available to anyone.
Expect more gateways to be targeted, not just V2Board panels. Any OpenAI-compatible endpoint with loose registration or weak auth is a candidate, because the aggregation stage normalises everything into a single interface. The resold capacity will keep advertising premium model names, which makes it harder for customers to know they are buying stolen inference. I do not know how the model providers will respond to this over the long term, and I am not going to pretend otherwise. What I do expect is that the line between credential theft and an inference supply chain keeps blurring, so incident response needs to treat a compromised key as the start of a longer operation.
Next step: audit your gateway today
Start with registration. Turn off open registration and free balance systems on V2Board, New-API, or any OpenAI-compatible gateway you run. Require an approval step for every new account, even if that means a manual review process. Free credits are a customer acquisition feature, and right now they are also a harvesting feature.
Then review your authentication model. Look at how group_id and role-based access are enforced, and test whether a request can escalate privileges just by changing a header value. You can do this in five minutes with a test account and a modified request. If the panel trusts the client on this field, the attacker’s playbook already knows about it.
Check your gateway logs for the recon the agent actually performs. FOFA-style patterns show up as repeated probes to /api/auth-files, unusual subscribe requests, or a sudden burst of trial account creations from temporary email domains. I check for these on my own boxes because they are the earliest sign of an automated sweep, and they appear before any damage is done.
Last, add a behavioral test of your own. Configure a canary model name that returns a distinctive response, then watch for that response appearing in your logs from unexpected sources. If it shows up, someone has mapped and mirrored your endpoint, and you have caught the operation while it is still in the validation stage. Do the registration review today, not after the quota bill.