Symantec says attackers built an agent configured for up to 100,000 unattended steps using exposed AI services. Its October 21 report describes captured instructions, not a verified run of that length.
According to Symantec’s research, a decoy AI service collected the instructions during summer 2026. The design combined model access with tools for scanning, exploitation, credential theft and cryptocurrency mining, alongside attempts to override model safeguards.
What the captured session actually shows
The honeypot executed none of the tools. It returned a fallback response and the session ended. The request contained an earlier tool-call history, but that history was supplied by the sender rather than generated by the honeypot.
The Wall Street Journal reported that Symantec had not identified real-world attacks by this particular agent. That limits what can be concluded about its operational success.
The distinction is consequential: an instruction describes intended behaviour; an execution trace shows what happened. A large step allowance does not establish that the agent can maintain a useful plan, recover from errors or complete its mission.
Why stolen model access matters
The broader practice is known as LLMjacking. Sysdig’s earlier research documented attackers using stolen cloud credentials to reach paid AI services, transferring consumption costs to the account owner. Its May 2024 report also warned that exhausting model quotas could disrupt legitimate use.
In a separate report published June 17, 2026, Sysdig described an offensive software pipeline using an exposed Ollama server for model reasoning. That provides independent evidence of a similar approach, but it does not connect the operator or software to Symantec’s case.
For an AI service owner, this creates an operational question beyond whether a chatbot refuses a harmful request: can an unknown caller consume the organisation’s resources at all? A refusal is a response after a request reaches the model. Access control determines who is allowed to make that request.
Model access and tool access are different boundaries
A useful way to evaluate the risk is to separate three permissions: calling a model, invoking a tool and acting on another system. Possession of one should not silently grant the others.
Consider a hypothetical research assistant with a paid model account and a document-search tool. If its model credential is stolen, the first investigation should establish what that credential permits. Access to inference alone does not automatically demonstrate access to the organisation’s documents. If the same gateway also exposes tools, those permissions need their own review.
That distinction changes the response. A team needs to identify the affected account, service and tool permissions before deciding which systems are exposed. Treating every suspicious prompt as equivalent to a server compromise can obscure the evidence needed to contain the actual problem.
AgentsCalling’s coverage of OpenAI’s internal agent-monitoring failures examines a related oversight problem. Here, the evaluation question is whether the controls outside the model can prevent unauthorised use even when a caller submits hostile instructions.
What a useful defensive check would measure
Sysdig’s 2024 research recommends detailed logging and monitoring of cloud activity. Those records matter because a bill, a model request and a downstream action answer different questions about an incident.
A practical evaluation could use a privately controlled test gateway, a small spending allowance and a harmless mock tool. Reviewers could check whether an unauthorised request is rejected before inference, whether a revoked test credential stops working and whether the mock tool enforces its own permissions.
The useful output would be evidence of each boundary working: a rejected request, an attributable usage record and a denied tool action. A budget alert should also reach someone able to respond; merely recording the threshold is a different outcome.
This proposed check would evaluate the organisation’s controls without recreating an offensive agent. The central lesson for buyers is to ask what the surrounding system can enforce independently of the model’s willingness to comply.
Prepared with AI-assisted research and drafting. AgentsCalling has not independently tested the captured agent.
About Puneet Sharma

Puneet Sharma · Freelance Writer
Puneet Sharma is a freelance writer covering AI agents, automation and the software changing how we work. His coverage at AgentsCalling starts with the questions a reader might ask over a conversation: What does this tool actually do? Where does it fall short? And is it useful beyond the demo? His articles explore new launches, practical workflows and the trade-offs behind giving software more responsibility, with explanations that make room for readers who are still getting familiar with AI.



