Symantec: autonomous LLMjacking and “Skynet”
Report edition: 22 October 2026 · PDF page 11
Research reviewed 22 October 2026 · Evidence and editorial planning guidance are distinguished below.
- Operational priority
- High
- Evidence
- Honeypot observations
Threat research • Symantec/Broadcom, 21 October 2026
Priority is conditional on actual exposure. An asterisk highlights especially conditional exposure; these are editorial judgments, not CVSS scores.
Explore this topic in depth
Ten detailed reports: four shared analyses and six audience perspectives. Research reviewed 22 October 2026; the original PDF account remains below as a dated snapshot.
Research update and qualifications
Symantec describes a honeypot capturing requests intended to abuse exposed AI services, including an agent’s instructions and tool definitions. The honeypot did not execute the captured tools or payload. The observations support an endpoint-abuse threat, not a count of attacks completed by that honeypot.
Symantec/Broadcom LLMjacking research · Original threat research revisited.
Attempted use, provider billing exposure and successful compromise are different outcomes. Keep them separate in incident and impact reporting.
The original PDF snapshot
What the report establishes
A honeypot captured an offensive agent’s instructions, including 74 tool definitions and a mode permitting 100,000 unattended steps. This is evidence of design and attempted use, not 100,000 completed attacks. The honeypot did not execute the tools.
Impact and potential reach
Exposed model endpoints, AI gateways and stolen provider accounts; potential consequences include compute charges and downstream intrusion. A confirmed victim total is unavailable.
Required actions
AI infrastructure owners: authenticate endpoints, narrow key scope, monitor spend, and restrict agent network access. Investigate unexpected inference activity and rotate suspected stolen credentials.
Six perspectives on this topic
For the business manager
Give every AI endpoint a business purpose and an owner who can approve interruption. Demonstrations often outlive the meeting they were created for. Keep a list of active workflows so disabling an unowned service does not unexpectedly break a customer commitment.
Read the business manager report for priorities, evidence and a decision checkpoint.
For the business owner
Treat AI usage as a controllable operating expense with security implications. Set approval boundaries for public services and spending. Budget alerts are useful only if someone can act and understands whether the limit is advisory or enforced.
Read the business owner report for priorities, evidence and a decision checkpoint.
For the technical manager
Connect endpoint inventory, identity and provider billing. A rate limit alone may still permit expensive requests, while a provider budget alert may arrive after substantial use. Use several independently enforced boundaries appropriate to the workload.
Read the technical manager report for priorities, evidence and a decision checkpoint.
For the software engineer
Enforce resource and action limits before expensive inference or tool execution. Treat output and retrieved content as untrusted. A model instruction to be safe cannot replace access checks, timeouts or cancellation of abandoned requests.
Read the software engineer report for priorities, evidence and a decision checkpoint.
For the customer service
Distinguish a busy or unavailable AI feature from evidence of customer-account compromise. Give customers an alternative route when automated assistance is paused. Reports of unexpected prompts or activity should be sent to the service owner, not tested by frontline staff against production.
Read the customer service report for priorities, evidence and a decision checkpoint.
For the customer
Use authenticated, official AI features and keep private information out of public or unfamiliar endpoints. If a service behaves unexpectedly, stop and report the problem rather than trying repeated prompts that could worsen the situation.
Read the customer report for priorities, evidence and a decision checkpoint.
In this section
- LLMjacking: Evidence and scopeAttempted use, provider billing exposure and successful compromise are different outcomes. Keep them separate in incident and impact reporting.
- LLMjacking: Business impact and costsUnauthorised inference can consume budget or capacity without taking control of the application. A tool-connected service can have additional consequences if it accepts untrusted requests with privileged authority.
- LLMjacking: Technical exposure and controlsInventory every model endpoint, its authentication, network exposure, provider credential, resource limits and any tools it can invoke. Include temporary demonstrations and abandoned test deployments.
- LLMjacking: Response and recoveryExpose an AI service only when its owner can identify permitted users, bound resource use and interrupt abuse without depending on model cooperation.
- LLMjacking: Business manager reportWho would notice that a demonstration endpoint was still running next month?
- LLMjacking: Business owner reportWhat is the maximum business exposure before someone can stop this service?
- LLMjacking: Technical manager reportWhat happens when the budget service fails or an attacker distributes requests across many clients?
- LLMjacking: Software engineer reportCan a request spend money or invoke a tool before its authorisation and budget checks finish?
- LLMjacking: Customer service reportCan a customer still reach a person when the AI service has been deliberately restricted?
- LLMjacking: Customer reportIs this an approved service with a responsible operator and a clear privacy explanation?