An attacker was using a coding agent to collect access to other people’s AI services and turn it into a service of their own. Then the agent chose a researcher’s honeypot as a free AI backend. Its requests handed over approximately 43 KB of the attacker’s own working context: instructions, collected API keys, reconnaissance scripts, infrastructure notes, previous targets, and parts of the agent’s history.
In a September 11 report, SANS Internet Storm Center researcher Renato Marinho reconstructed the operation from a series of captures. The interesting part is both sides of that exchange: how the attacker assembled a functioning pool of AI access, and how the agent’s choice of backend exposed the work behind it.
1. The agent chose a free backend—and sent its working context
Marinho’s honeypot imitated an OpenAI-compatible inference endpoint: an API that accepts requests in a format familiar to AI clients. The coding agent repeatedly selected it as a free backend. Compatibility made the endpoint usable; it said nothing about who operated it.
This particular client included operating instructions and session context in its model requests. The approximately 43 KB contained a large AGENTS.md instruction file, an offensive playbook, and material from the ongoing operation. The researcher therefore received more than a question for a model to answer. The request explained what the agent was doing, how it was supposed to work, and which credentials and targets it had already collected.
The failure happened when that context went upstream. The published account describes the client sending it as part of ordinary requests; it does not describe the researcher first breaking into the attacker’s computer or tricking the agent with a prompt injection. An endpoint can learn sensitive information simply by being the destination the client trusts with its request.
2. Even the proxy-check instruction revealed something
The playbook told the agent to verify that its proxy was active before attacking. To make that comparison, it included the operator’s direct, unproxied egress IP as a reference value. That instruction itself reached the honeypot.
This is a particularly revealing mistake: a precaution intended to check whether the network route was concealed carried the information it was meant to help conceal. Even if a connection arrives through a proxy, the receiving service can read an address written inside the request. HTTPS likewise protects traffic on the way to the endpoint; it does not hide the request from that endpoint’s operator.
3. The access hunt targeted ordinary gateway weaknesses
The captured workflow used FOFA, an internet asset search engine, to find LLM gateways and related subscription infrastructure. Queries looked for recognizable page titles and subscription-related HTTP headers. That gave the agent candidates to investigate; a search result alone was not proof of a compromise.
The access-acquisition playbook then listed several routes:
- Free starting balances and trial accounts. Open registration supplied initial credit. Temporary email and CAPTCHA-solving services supported automated trial-account creation.
- Default credentials. A gateway left with known login details offered a direct route into an account or panel.
- Weak authorization. The playbook targeted decisions involving a client-supplied
group_idand exposed account-management endpoints, including/api/auth-files.
These routes are different. Farming free credits abuses an account offer; using stolen keys or exploiting an authorization flaw crosses a different access boundary. The common aim was to obtain usable inference capacity. The report does not establish that every listed technique succeeded against every collected endpoint.
The authorization detail matters because an identifier supplied by a client should identify a requested resource, not establish the client’s right to use it. In this operation, the agent was looking for services where that boundary—or basic account protection—was weak enough to turn into access.
4. A working key was only the start of verification
The agent tested collected keys against resale services. Some endpoints advertised premium models, some exposed extremely high default billing limits, and another returned its full model catalog without authentication. None of those observations alone proved the advertised model was available or genuine.
Later, the workflow used a small factorial calculation as a code-logic test, intended to distinguish usable inference from canned replies. That was a practical filter for the attacker: an endpoint that merely accepted a key was of little use if it could not answer a basic task.
Passing that test still did not authenticate the model’s identity. A reseller can attach a familiar model name to a different backend. The evidence supports working responses behind advertised names, not independently verified access to those named models. A high displayed billing limit also does not establish actual spending or a victim’s loss.
5. Roughly 379 connections became one working API
A later capture showed the attacker building the aggregation service. The operator deployed a self-hosted New-API gateway, a legitimate open-source project, and loaded roughly 379 upstream endpoints as channels using the collected credentials.
The workflow tested the channels and disabled 341 that failed as fake or dead. It then mapped five standard model names onto the surviving channels, configured priority-based round-robin routing, and enabled automatic failover. A final probe obtained usable responses under all five configured names through the single gateway.
That made the operation more than a collection of keys. The gateway could select among surviving connections and try another when one failed, presenting the pool as one service to its clients. The credentials were inputs; the output was usable AI capacity behind a unified API.
Keep the counts separate: 379 refers to imported channels, 341 to disabled channels, and five to configured model names. They are not counts of compromised companies, victims, or independently authenticated models. The report also does not show that the honeypot was one of the surviving channels.
Marinho observed a human-directed loop: an agent helped find access, validate it, and assemble capacity that could support further work. He did not demonstrate fully autonomous self-replication. The related problem of AI tokenjacking with stolen API keys becomes more useful to an attacker when unreliable connections can be pooled behind one working service.
6. When its own panel got in the way, the agent edited the database
The gateway’s own rate limits blocked part of the automation. The agent responded by editing the gateway’s SQLite database directly, clearing session rows and inserting an admin token.
This happened on the operator’s self-hosted gateway. It is evidence of the control the coding agent had over that environment, not a demonstrated bypass of someone else’s hosted service. A limit imposed by a web panel is not an effective boundary against an actor who can rewrite the database underneath it.
What the case actually demonstrates
The reversal is the clearest lesson here. While the attacker checked whether other people’s AI access worked, the coding agent sent its own operational context to an untrusted recipient. The backend did not need to steal that context from the machine. The client delivered it.
Source
- Renato Marinho, SANS Internet Storm Center, September 11, 2026: The Self-Expanding Stolen Inference Supply Chain. The report’s publication date does not establish the dates of the underlying captures.
