An attacker-built AI agent is scanning the internet for unprotected language-model endpoints and using them as its brain. In an analysis published October 22, 2026, Symantec describes capturing the complete working prompt of this offensive agent on an AI honeypot: roughly 74 offensive tool definitions, a jailbreak that reframes reading secrets as routine work, and a "Skynet mode" that authorizes up to 100,000 unattended steps. The owner of the hijacked endpoint pays for the inference. The compromised machines end up running hidden cryptominers. If you run model servers, AI gateways, MCP paths or API keys alongside your coding agents, this is the traffic that will find them.
| Question | Short answer |
|---|---|
| Am I affected? | If a model server, AI gateway or MCP path is reachable from the internet without authentication, or an AI API key has leaked |
| Is there a patch? | No single patch. The exploit modules target common frameworks (Django, Jupyter, Laravel, Supabase, Next.js, Flask/Werkzeug and others), so patch those and put authentication on endpoints |
| What do attackers get? | Free LLM inference at your cost, then cryptomining on any machine the agent compromises |
| Does data leave my machine? | Only if your endpoint or host is compromised; the toolkit includes database dumping and credential theft |
| How would I notice? | Unexplained inference spend, unfamiliar outbound mining-pool connections, missing access logs |
What Symantec observed
Symantec's honeypot imitated an unprotected, internet-facing AI service. The attackers believed they were talking to a real model and sent the entire instruction set. According to Symantec, the honeypot did not execute any tool calls, which is why the report is a view of intent rather than a catalogue of finished intrusions. Telemetry showed more than 127,000 external requests from tens of thousands of addresses, mostly endpoint reconnaissance, stolen API key spraying, and probing for exposed configuration files.
The Decoder summarized the research the same day; the mechanics below come from the Symantec write-up itself.
The attack chain, step by step
1. Find an LLM to borrow
The agent does not bring its own model. It looks for exposed AI endpoints and tries stolen or leaked API keys. Any model that answers becomes the planner for the rest of the chain. This is LLMjacking in its agentic form: the compute bill lands on the victim, as Wiz also described for hijacked Google Cloud billing accounts.
2. Layer the prompt so the model complies
Symantec describes several prompt layers:
- Identity override. The model is told to present as a branded coding assistant and hide its real provider and any proxy routing.
- Secret normalization. Reading
.envfiles, API keys and database schemas is framed as routine work that should never be refused. - Companion persona and jailbreak. A fictional persona, banned-word lists and a "rebuttal protocol" tell the model to dismiss its own safety warnings.
- Toolkit. About 74 tool definitions, far more than the prompt's own summary suggested.
The "this is just normal work" framing mirrors pressure we have seen elsewhere, including the Latin American banks campaign, where refusal turned out to be a control an orchestrator can route around.
3. Prime the model mid-task
The first request on day one included three prior tool calls and results, apparently so the model would believe it was already mid-task and keep going: an SSRF probe of the root path, a fingerprint showing Nginx with missing security headers, and a full vulnerability scan with no SQL injection, XSS, CORS or open-redirect findings. The honeypot returned a generic fallback at turn four and the session ended.
This detail is worth noticing. Fabricated history is a cheap way to steer a model: the model sees "its own" earlier tool calls and continues the pattern. Any system that accepts a conversation transcript from an untrusted caller inherits this weakness.
4. Skynet mode
The directive authorizes up to 100,000 unattended steps, requires immediate tool execution with no narration or approval requests, directs quiet miner deployment in a hidden location with verification, and describes a persistent loop: scan, infect, deploy miners, reinfect. The removal of narration and approval requests is the point. A human watching the stream would see nothing to approve.
5. The toolkit
Per Symantec, the tools cover internet-wide asset discovery, exploit modules for VS Code, Django, Jupyter, Laravel, Supabase, Next.js and Flask/Werkzeug, GraphQL and command injection, SSRF aimed at cloud metadata, Prisma Studio database dumping and botnet command and control. The SSRF tool's description reads "Exploit SSRF to access cloud metadata, internal ports, or local files." The botnet tool is described as launching an "autonomous AI botnet operator for continuous FOFA scanning and infection."
6. Day two: the payload
A second request, from a rotated address, skipped the agent setup and asked the model to decode a gzip-plus-base64 string. The script downloaded and compiled the XMRig Monero miner, hid the binary under a misleading logging-utility name, configured failover across four mining pools, made its configuration file immutable, and ran a loop erasing a local service's access logs. It targeted go2rtc smart-camera streaming servers.
What this means if you run AI coding agents
The agent is not attacking coding agents specifically. It attacks the infrastructure around them, and many developers have exactly that infrastructure: a local Ollama or vLLM server bound to 0.0.0.0, a LiteLLM or OpenRouter-style gateway, a Jupyter notebook, an MCP server on a public port. Symantec's recommendations translate into a short checklist:
- Authenticate every model path. Symantec says to require authentication on every LLM API, model server and MCP path, including model-listing and health checks, and not to bind model servers to all interfaces.
- Treat AI API keys as high-value credentials. Rotate them, scope them narrowly, keep them out of code and config, and monitor usage and spend. Our OpenRouter breach claim write-up covers what to do when a key may be exposed.
- Restrict outbound traffic from AI hosts and tool-enabled agents so scanning, command-and-control contact and miner downloads fail.
- Enforce IMDSv2 with a hop limit of one on cloud workloads, which blunts the SSRF-to-metadata tool.
- Run agents with least privilege and human approval for sensitive actions, and patch the frameworks listed above while keeping them off the public internet.
Quick local checks: list listening sockets (ss -tlnp on Linux, lsof -iTCP -sTCP:LISTEN on macOS) and look for model servers bound to all interfaces; look for unfamiliar binaries with logging-style names and for connections to mining pools; and check for access logs that are suddenly empty. Symantec publishes file hashes, three IP addresses, a Monero wallet and four pool hostnames in its indicators section; match against those from the source rather than from a summary.
What to look for in your logs
If you suspect an endpoint was found, work backwards from the symptoms Symantec describes. On the model side, look for bursts of requests from unfamiliar addresses, requests that carry long system prompts you did not write, requests that include pre-filled tool calls and results, and prompts that mention personas, banned words or "rebuttal" rules. On the billing side, compare token usage against your own work hours; a flat 24-hour curve from a key only you use is a warning. On hosts, check for long-running processes with names that look like logging utilities but consume CPU, files marked immutable (lsattr on Linux) that you did not mark, and access logs that stop at a sharp boundary. Rotate any key that touched the endpoint, because the toolkit steals credentials and keys found on one host fund the next compromise.
For teams building agents rather than running them, the lesson is symmetrical. Do not accept transcripts, tool results or system prompts from callers you do not control, and do not build a mode that removes human approval for destructive steps unless an external control, not the model, enforces the limits.
How this fits the wider picture
This report sits beside several others from the past weeks. Wiz described AI-driven cloud attacks in which an agent compressed the time from foothold to damage. Our October roundup of AI-led attacks tracks stolen AI keys as a recurring theme. Symantec adds a concrete artifact: not a claim that attackers use agents, but the actual instruction set one of them sends, captured because the attacker could not tell a honeypot from a real model.
The limits matter too. A honeypot sees what an operator chooses to send to it. Symantec reports the tool definitions and the payload, not a count of victims or total spend, and we have not seen independent confirmation of how widely this particular agent is deployed. Treat the report as strong evidence of technique and weak evidence of scale.
What Beam can and cannot do here
Beam does not see the internet-facing side of this attack. It cannot close a port, watch your cloud bill, or detect a miner on a camera server. What it covers is the local agent side: it watches what Claude Code and Codex do and flags credential exposure and destructive commands, hook-based deny works for Claude Code and Codex PreToolUse, and the skill and MCP config scan (11 heuristics plus a version-pin check) can catch risky servers before you run them. That reduces one way keys leak into attacker hands. The scan is heuristic, not a kernel sandbox, and missing cached policy fails open. See how it works and why data stays on your device.
Frequently asked questions
What is Skynet mode in the Symantec report?
It is a directive inside an attacker's system prompt that authorizes the model to run up to 100,000 steps without human confirmation, execute tools immediately without narration, quietly deploy cryptominers and loop through scan, infect and reinfect.
How did Symantec see the attacker's prompt?
Symantec ran an AI honeypot imitating an unprotected, internet-facing AI service. The operators sent their full working prompt to it, believing it was a real model. The honeypot returned a generic fallback and executed no tool calls.
Who pays when an LLM endpoint is hijacked this way?
The owner of the exposed endpoint or the stolen API key pays for the inference, while the attacker gets a free reasoning engine for the offensive agent.
Does this affect people who run coding agents?
Indirectly. Model servers, AI gateways, MCP paths and API keys used by coding agents are exactly what this agent scans for. Authenticate every endpoint, scope and budget keys, and restrict outbound traffic from agent hosts.
Can Beam stop this attack?
No. This is an attack on exposed endpoints and keys. Beam can flag credential exposure in what a local agent reads or runs, and scan MCP configs, but it does not close internet-facing ports or watch cloud billing.
What did the second attack do?
A day later a rotated address sent an obfuscated script that compiled the XMRig miner, hid it under a logging-utility name, set four fallback mining pools, made its config immutable and erased access logs on go2rtc camera servers.
Related reading
- LLMjacking via billing accounts
- Latin American banks and Claude, Grok and Kimi
- OpenRouter breach claim: claimed vs. verified
- Anatomy of an AI-driven cloud attack
- MCP security: a practical guide
- Symantec analysis
- Protect an LLM feature from prompt injection and key theft with the Beam monitor SDK
Details reflect Symantec's published analysis and the sources linked above as of October 22, 2026, and may change as research continues. Beam is a local prototype; features described are as documented at the time of writing.