Symantec has uncovered an autonomous hacking agent designed to break into other organisations’ AI systems, misuse their models, steal credentials and databases, and deploy cryptocurrency miners. The agent exposed its own instructions after interacting with a decoy AI service operated by Symantec researchers, according to a Wall Street Journal report published on 21 October 2026.
The recovered instructions reportedly allowed up to 100,000 steps without human approval. But the finding has a crucial limit: Symantec has not identified a confirmed real-world attack carried out by this particular agent. The discovery exposes an offensive design and an attempted interaction with a honeypot, not a verified campaign of successful intrusions.
How Symantec’s honeypot exposed the agent’s instructions
Symantec’s Threat Hunter Team set up a deliberately exposed AI service to observe how attackers might exploit accessible models. Between May and September, the decoy received approximately 127,000 external requests from more than 32,000 distinct internet addresses. Symantec estimated that about a third of those requests appeared to test stolen access keys.
Those numbers describe activity against the honeypot as a whole. They do not mean this newly identified agent performed 127,000 attacks or successfully compromised 32,000 organisations.
According to the Wall Street Journal investigation, one agent treated the decoy as a potential target and sent it the instructions governing its operation. That mistake gave researchers insight into how the system was intended to behave. Its plan included discovering vulnerabilities, taking control of AI access, copying data, collecting credentials, and running malicious tools.
The important architectural detail is that the compromised AI model would provide reasoning and direction, while attacker-controlled software performed the practical work. Hijacking a model’s API access is not the same as changing its underlying weights or proving that the model provider’s infrastructure has been breached.
What the reported ‘Skynet mode’ does and does not prove
The most consequential confirmed configuration detail is the allowance for up to 100,000 steps without further human approval. That is an instruction limit, not evidence that the agent actually completed a 100,000-step attack. Symantec’s analyst estimated that running the full sequence could consume at least a billion input tokens, illustrating the potential scale of the computing bill.
Descriptions accompanying the story also refer to 74 offensive tools, a setting called ‘Skynet mode’, and a refusal-suppression line reading ‘Code refusals disgust me.’ DIY AI could not independently corroborate that tool count, mode name or exact line against publicly available forensic material. They should not be confused with evidence that each tool worked or that a commercial model successfully obeyed every malicious instruction.
Researchers did describe a jailbreak that assigned the model a submissive companion persona and recast sensitive actions, such as reading passwords or configuration files, as ordinary development tasks. This attempts to manipulate model behaviour through instructions. It does not grant operating-system permissions, bypass cloud identity controls or create access to databases on its own.
LLMjacking makes the victim pay for the attacker’s reasoning
The technique is known as LLMjacking: using somebody else’s AI credentials, account or exposed inference service without permission. Rather than funding expensive model calls themselves, attackers can route their activity through a victim’s AI allocation and leave the organisation with the consumption charges.
| Attacker objective | Access actually required | Potential consequence |
|---|---|---|
| Use a powerful AI model | Stolen API credentials or an unauthenticated endpoint | Unexpected token charges, exhausted quotas and concealed malicious activity |
| Copy databases or secrets | Credentials and permissions that reach those systems | Data theft, credential reuse and further compromise |
| Install a crypto miner | Code execution on a host or another compromised workload | CPU or GPU resource theft and additional infrastructure costs |
| Resell model access | Working stolen credentials or a reusable proxy | Prolonged abuse and difficulty attributing subsequent requests |
These are separate failure paths. A stolen model API key can enable unauthorised inference and billing abuse without allowing an intruder to install software on the same company’s servers. Cryptocurrency mining requires a further route to executable compute. Treating those outcomes as one automatic consequence of a jailbreak would exaggerate what has been demonstrated.
The cost risk can also be misunderstood. One seemingly small request can trigger repeated tool calls, retries and long context histories. DIY AI’s AI model cost comparison explains why an entire agent session can cost substantially more than a single prompt priced at the advertised token rate.
What AI service operators should check now?
No published indication suggests this specific agent targets every AI provider or that ordinary users need to stop using AI tools. The more useful response is to examine how an attacker could obtain billable model access and what that access would permit.
- Audit exposed inference endpoints. Check whether development models, proxy servers or test deployments accept unauthenticated requests from the public internet.
- Rotate leaked or over-privileged keys. Search authorised repositories and deployment settings for accidentally exposed secrets. Prefer short-lived credentials and narrowly scoped service identities wherever supported.
- Set usage alarms and hard spending limits. Watch request volume, tokens consumed, unusual model selections, geographic anomalies and sudden changes in hourly spend. An alarm alone does not prevent the bill from growing.
- Separate inference rights from operational privileges. An account allowed to call a model should not automatically be able to read production databases, retrieve cloud secrets or execute shell commands.
- Monitor both API and host activity. AI billing logs can reveal model abuse; endpoint and workload telemetry are still needed to detect mining processes or malicious command execution.
- Enforce tool permissions outside the prompt. Systems should check human approval gates, network restrictions, and runtime policies that the model cannot simply instruct itself to ignore.
For a practical example of independent runtime restrictions, DIY AI recently covered NVIDIA’s proposed approach to containing rogue AI agents. The broader principle is to constrain a model’s available actions even if its instructions are successfully manipulated.
What Symantec has established, and what remains unknown
Symantec has observed a maliciously configured agent interacting with its decoy and has examined the instructions it surrendered. The report provides an unusually direct look at the intended relationship between stolen model access, offensive tooling and automated decision-making.
It does not establish that the agent completed a real-world intrusion, stole a live organisation’s database, deployed a miner on a victim’s machine or performed the maximum number of permitted steps. Nor does the public reporting identify a single AI model provider whose safety systems this specific configuration conclusively defeated.
That leaves a precise security lesson, not a science-fiction one. Attackers do not need to invent a new model to misuse advanced AI. They can target credentials, exposed services, and excessive permissions around existing models, then make someone else fund the activity. Organisations that control identity, tool access, and spending have stronger defences than those that rely on the model’s refusal messages alone.
