'Skynet Mode': Attackers Are Hijacking Exposed AI Models to Run Their Attacks
Symantec caught an attack agent that hunts for exposed AI model endpoints, takes them over and uses them to plan its attacks. What is proven, what is not, and five checks to run this week.

On October 21, Symantec's Threat Hunter Team published something security teams have been expecting: an attack agent that does not bring its own AI. It goes looking for yours. The agent scans the internet for exposed AI model endpoints, takes them over, and then uses the stolen model as the brain that plans and runs the rest of its attack. Its operators even gave the final stage a name borrowed from the Terminator films: "Skynet mode."
The good news is that this one was caught in a trap. The bad news is what the trap shows about how many organizations are leaving AI infrastructure open to anyone who asks.
What Symantec found
Symantec researchers Priti More and Susmit Yenkar ran an AI honeypot, a decoy that pretends to be an unprotected AI service. Over the observation period it recorded more than 127,000 external requests from tens of thousands of unique addresses. In other words, exposed AI services are being found and probed constantly.
One of those visitors handed the honeypot its entire playbook. The agent hunts for model endpoints that accept requests without authentication, or that accept a stolen API key: self-hosted model servers, AI gateways, internal test systems and MCP servers. Once it has a model, it feeds it a jailbreak and a catalog of about 74 offensive tools covering discovery, exploits for common web and developer frameworks such as Jupyter, Django, Laravel, Next.js and Supabase, database dumping, credential and secret harvesting, cloud metadata theft, botnet control and cryptocurrency mining. As Symantec put it, the stolen model does not just answer questions, it "plans and drives the attack."
The "Skynet mode" directive authorizes the agent to run for up to 100,000 steps with no human approval, cycling through scanning for targets, infecting them, deploying miners and reinfecting hosts. A separate captured request carried an obfuscated script to install Monero mining software and wipe logs.
What is proven, and what is not
It is worth being precise here, because headlines are not. The honeypot never ran the agent's tools, and Symantec does not report a confirmed compromise of a real server by this agent. What it captured is intent and design. The Cloud Security Alliance's research note on the report says exactly that, while also noting signs the kit had been run against live targets and that it is more than a prototype.
It is also not the first case. The Cloud Security Alliance points to a June 2026 finding by Sysdig, in which an attacker used an exposed, unauthenticated Ollama server as the reasoning engine for a nine-phase exploitation framework. Two independent captures in five months is a pattern, not a curiosity.
Why this matters to a mid-market company
Most mid-market companies do not think of themselves as running AI infrastructure. Many are, without a security decision ever being made:
- A developer stands up a local model server to test a feature and leaves it reachable.
- A team deploys an AI gateway or an MCP server so an internal agent can reach company data.
- An API key for OpenAI, Anthropic or a cloud AI service sits in a config file on a development host.
The term for what happens next is LLMjacking: someone else uses your model and you pay for the compute. That alone can produce a surprising bill. The larger risk is the one this agent shows. Your exposed model becomes the attacker's engine, and the attacks it runs, including against third parties, run on your infrastructure, under your accounts, with your keys. That raises questions of liability and notification that most incident response plans have not considered.
Five checks to run this week
- Find your exposed model endpoints. Scan your own address ranges and cloud accounts for reachable model servers, including Ollama's default port 11434, OpenAI-compatible APIs, AI gateways and MCP servers. Include development and test environments, because that is where these usually hide.
- Require authentication on every path. Anything that answers model requests without credentials should come off the internet: bind it to localhost or an internal interface, or put it behind an authenticating reverse proxy.
- Treat AI API keys as high-value credentials. Rotate them, scope them narrowly, keep them out of code and config files, and set spending caps and alerts. Unexplained inference volume or a quota running out early is a security signal, not just a billing one.
- Restrict what AI hosts can reach. Apply outbound filtering on systems that host models or tool-enabled agents, including blocking known mining pools. On cloud workloads, enforce IMDSv2 with a hop limit of one so a hijacked agent cannot pull instance credentials through SSRF.
- Give agents the least privilege, and keep a human in the loop. Limit MCP servers and agent tools to the narrowest set of actions and data they need, and require human approval for anything destructive or able to move data out. Patch and manage Jupyter, VS Code server and similar developer tools as production systems.
The governance point
The fix for this class of attack is not exotic. It is the same discipline security teams already apply to servers and cloud accounts, applied to something most inventories still miss. AI compute needs to be treated as its own asset class: every model server, gateway, MCP server and AI key on a list, with an owner, a reason it exists and a decision about who can reach it.
That is also the thread running through the real-world cases we track. In our AI Agent Incident Tracker, the incidents that cause damage rarely start with a clever prompt. They start with an agent or an AI service holding more access than anyone decided it should have. For the controls that follow from that, see our guide to securing AI agents, why an agent's own audit trail is not enough, and how to treat AI coding agents as a software supply chain.
Sources
- Symantec Threat Hunter Team (Priti More, Susmit Yenkar), "Autonomous LLMjacking: 'Skynet' Agent Hijacks Exposed AI Models to Run Attacks", October 21, 2026.
- Cloud Security Alliance, "Skynet-Mode LLMjacking: Exposed Model Endpoints as Autonomous Attack Engines", October 25, 2026 (including the Sysdig June 2026 case).
- The Independent, "'Skynet' AI hijacks other models to carry out attacks, researchers discover", October 26, 2026.
Related from the BlueRadius Library
Sourced posts on adjacent topics, ranked by tag overlap.
AI Security
Securing AI Agents: An Agentic AI Security Guide for 2026
An agentic AI security guide for mid-market: the agent attack surface, prompt injection, excessive agency, non-human identities, and a checklist.
ReadAI Security
NIST AI Risk Management Framework: A 2026 Implementation Guide
The NIST AI Risk Management Framework explained: the four functions (Govern, Map, Measure, Manage), the Generative AI Profile, and an adoption path.
ReadAI Security
Bay Area AI Security & Governance: Protecting ML Models and Training Data
Bay Area AI companies need security governance for ML models, training data, and pipelines. Protect IP and meet emerging AI compliance requirements.
ReadAI Security
ISO 42001 vs NIST AI RMF vs SOC 2 (2026): What Buyers Ask For
ISO 42001, NIST AI RMF or SOC 2 with AI controls? What each one certifies, who issues it, what it costs, and which assurance enterprise customers ask for.
ReadAI Security
Shadow AI: The Biggest Security Risk Your Company Isn't Tracking
Shadow AI, employees using unapproved AI tools, is the fastest-growing security risk for mid-market companies. Learn to detect, assess, and manage it.
ReadAI Security
AI Vendor Risk Assessment: Questions Your CISO Should Be Asking
An AI vendor risk assessment framework with specific questions CISOs should ask about data handling, model transparency, and security controls.
ReadRelated services