Symantec researchers have captured the full instructions of an autonomous attack agent that hunts the internet for unprotected AI models and hijacks them to plan and run its own intrusions. Any UK organisation running a self-hosted model, AI gateway or MCP server with weak or no authentication could end up paying for the attacks and providing the compute behind them.
What happened
On 21 October 2026, Symantec researchers published an analysis of an offensive AI agent caught by an AI honeypot, a decoy that poses as an unprotected AI service exposed to the internet. The operators thought they had reached a genuine model and sent it the agent’s whole working prompt. That gave the researchers an unusually complete picture of the tool’s design and instructions. They captured it over the summer of 2026.
The activity is LLMjacking: using someone else’s large language model so that the victim covers the inference bill. Here, though, the hijacked model does more than chat. It acts as the planning engine for an exploitation campaign that scans for new targets, breaks into web applications, harvests databases and credentials, and installs Monero miners on the servers it compromises. A directive the operators labelled “Skynet mode” lets it run for up to 100,000 steps without asking a human for approval.
The research comes from Symantec’s Threat Hunter Team and was reported by Infosecurity Magazine and Let’s Data Science the same day. The honeypot ran none of the agent’s tool calls, so the report describes the agent’s capability and design, not confirmed victims. Over the monitoring period the decoy logged more than 127,000 requests from tens of thousands of different addresses. Most of them were probing for model endpoints, trying stolen API keys or looking for exposed configuration files.
The technical picture
The agent goes after endpoints that answer AI requests without authentication, or with a key the attacker has stolen. Most AI tooling now speaks the same OpenAI-compatible interface, so one scanner can find many kinds of target. These include model servers that ship open by default, gateways in front of paid model accounts, forgotten test boxes, and MCP servers that give a model access to live tools.
The captured request was built in layers. The first gave the model a false identity as a branded coding assistant and told it to hide the real provider. The researchers say that pattern fits a service reselling stolen access. Later layers recast reading environment files, keys and database schemas as routine development work, used a role-play persona to make refusal feel like betrayal, and told the model to ignore its own safety warnings. The operators clearly expected to land on commercial models with guardrails, and brought a jailbreak to get past them.
The final layer held about 74 tool definitions. According to the report, these covered internet-wide discovery, attacks on commonly exposed developer platforms such as VS Code servers, Jupyter, Laravel, Supabase and Flask debug consoles, server-side request forgery aimed at cloud metadata services, database dumping and botnet control. A second request the next day, from a different address, asked the model to decode an obfuscated shell script that installs the XMRig miner, hides it, fails over between four mining pools and keeps wiping logs. That script appeared to be written for go2rtc video streaming servers, which turn up in smart camera gateways and home automation set-ups.
Why it matters for UK organisations
Symantec does not say where the agent’s victims are, and the report does not suggest UK systems were singled out. But the exposure the agent hunts for exists in the UK. A joint SentinelLABS and Censys study published in January 2026 counted about 175,000 publicly reachable Ollama hosts in 130 countries and placed the UK among the ten countries with the largest footprint. It also found that close to half had tool calling switched on, so a hijacked model could do much more than generate text.
The attackers’ economics create two sets of victims. Whoever owns the exposed model or the stolen key pays for the compute, and 100,000 autonomous steps on a metered commercial account could add up to a large bill. The servers the agent then breaks into lose their data and are turned into miners. If personal data is taken, UK GDPR breach duties apply however the attacker got in. And an organisation whose infrastructure was used to attack third parties will struggle to explain that to customers, insurers or the ICO.
Expert view
The researchers say plainly that none of the individual techniques are new. What has changed is how they are put together. Wiring them into one agent that gets a goal and keeps iterating lowers the skill needed for a broad, opportunistic campaign. Orchestration and persistence used to be the hard part. An LLM now handles that, running on someone else’s account.
In my experience, AI services are increasingly what nobody expects us to find in an external attack surface review: a model server listening on every interface of a cloud VM, a gateway with a shared key, an MCP endpoint left running after a proof of concept. Because they are seen as experiments, they miss the basics any other internet-facing service would get, including asset registers, scanning and spend alerts.
The jailbreak layers are also a warning to anyone relying on provider-side safety controls. If attackers can reach your endpoint, they write the prompt. What matters is whether they can reach it at all, and what the model can touch when they do.
What to do now
- Inventory AI endpoints. List every self-hosted model, gateway, relay and MCP server, including developer instances in cloud accounts, and test their exposure from outside your network.
- Take them off the internet (Cyber Essentials: firewalls). Bind services to localhost or private interfaces and put them behind an authenticated gateway or VPN.
- Authenticate every route (secure configuration). Include model-listing and health endpoints, and remove any default settings that leave services open.
- Protect AI keys (user access control). Scope them tightly, keep them out of code, rotate them, and alert on sudden jumps in usage or cost.
- Limit egress. Stop hosts running models or agents from scanning the internet or fetching payloads.
- Harden metadata services. Enforce IMDSv2 with a hop limit of one on AWS, or the equivalent elsewhere.
- Patch developer tooling (security update management). Keep Jupyter, VS Code servers, Laravel, Supabase and similar platforms updated and private, with debug consoles off in production.
- Constrain agents. Give agents minimal privileges and require human approval for sensitive actions.
Bottom line
Attackers no longer need to break a model to use it. They just need to find one left open. Symantec’s capture shows criminals building AI into the core of their tooling and actively looking for other people’s models to power it. UK organisations should assume an unauthenticated AI endpoint will be found quickly, and lock it down before it becomes someone else’s attack engine.
Sources
- Symantec: Autonomous LLMjacking: ‘Skynet’ Agent Hijacks Exposed AI Models to Run Attacks
- Infosecurity Magazine: Symantec Uncovers AI Agent Hijacking Models for Autonomous Cyber-Attacks
- Let’s Data Science: Symantec Details Agent That Hijacks Exposed AI Models for Cyberattacks
- Threat Beat (via The Hacker News): Researchers find 175,000 publicly exposed Ollama AI servers across 130 countries
