LLMjacking Agent: The Skynet Honeypot Capture

In the summer of 2026, an AI honeypot run by Symantec captured the full instruction set of an autonomous offensive agent that hunts for exposed LLM endpoints and makes them plan its attacks. A directive the operators called “Skynet mode” lets it run up to 100,000 steps without human approval, while the endpoint’s owner pays for every one. The honeypot logged more than 127,000 requests from tens of thousands of addresses, mostly endpoint reconnaissance, stolen-key spraying, and probing for configuration files.

What happened

The operators wanted free inference. An unauthenticated OpenAI-compatible server, an AI gateway in front of paid model accounts, or an open MCP server gives them a model someone else pays for, with no provider account of their own to ban. The hijacked model acts as the reasoning engine, while the tool’s own modules run the scans, exploits, and miners against separate victims.

The captured request came in five layers. The first four rebrand the model as “Fantasy AI” and forbid it to reveal the real model or proxy, recast reading .env files and API keys as routine development work, install a companion persona that must never refuse, and ban words such as “illegal” and “ethical.”

The fifth layer carried about 74 tool definitions: FOFA scanning, exploits for VS Code, Django, Jupyter, Laravel, Supabase, Next.js, and Flask/Werkzeug, Prisma database dumps, a cloud metadata SSRF tool, and a botnet operator. A day later, a request from a rotated address asked the model to decode a gzip shell script that installs XMRig across four mining pools and erases a go2rtc camera server’s logs. The honeypot ran none of it, and the request’s benign training task suggests the operators may have been testing.

How it could have been caught

An exposed model endpoint hands outsiders the organization’s inference, its provider key, and its bill. Every hijacked step still crosses the endpoint and travels out to a model, so the traffic is visible to whoever watches that path. A baseline of the gateway would have flagged the first request from a caller no deploy, user, or internal agent explains.

What this looks like in Trace

Here is one exposed AI gateway traced inside the cloud of a company that runs it for its own agents. The prompt layers, tools, and payload come from Symantec; the workload, port, caller addresses, and timings are illustrative.

Network trace. Workload ai-platform/llm-gateway, reachable from the internet on port 4000 with no authentication on its chat path.

The gateway’s call to the AI proxy is routine, so the content of each call decides the case. The rotated address on day 2 adds no cover, because the case keys on what reaches the gateway.

AI proxy. The proxy’s three questions, applied to the two captured requests:

The proxy also logs which model served each call, whatever brand the “Fantasy AI” layer tells the model to claim.

Traceback. At day 1, T+0:00, the triage agent opens a case and follows the chain:

offensive tool request → llm-gateway :4000 → caller with no deploy, commit, user, or agent behind it → load balancer rule exposing /v1 without auth

The chain ends at an outside caller using a public route, and that gap is the finding.

Verdict: an outside agent hijacking the company’s model to plan attacks on other networks. The case reaches the platform team within about a minute of the first request, with both prompts, the exposed route to close, and the provider key to rotate.

This analysis reconstructs the incident from public reporting and walks through where Trace would have raised the first alert inside the cloud of a company running an exposed AI gateway. Detection times are illustrative.