Skynet LLMjacking Agent: How Exposed AI Models Get Hijacked

A threat research team reported on 21 October 2026 that an autonomous attack agent, run in what its operators call "Skynet" mode, hunts for exposed AI model endpoints, gateways and MCP servers, then uses the victim's model to plan scanning, exploitation, data theft and crypto mining. Anyone running a reachable model server should lock it down today.

This post covers the report, the agent's design at a high level, every published indicator, the server defaults that decide exposure, detection and remediation steps, and what would have helped. It builds on our explainer What is LLMjacking, and how do we protect AI API keys?, which covers key inventory and rotation in depth. This post is about the other half of the problem: endpoints that need no stolen key at all, and what happens when a hijacked model is given tools.

One point first: everything here comes from a honeypot capture. The honeypot ran none of the agent's tools and the report names no real victim. We know the tool's design and a miner script captured a day later, not how many real endpoints it has hijacked.

What the report says

The research team runs an AI honeypot that impersonates an unprotected, internet facing AI service. In the summer of 2026, according to the report, an operator sent the agent's entire working prompt to it, expecting a real model to carry it out, which gave the researchers an unusually complete view of the tool.

In the report's words, "the stolen model does not simply answer questions; it plans and drives the attack." The model is the reasoning engine; the tool's own modules do the scanning, exploitation and mining against separate victims.

The numbers, as the report gives them

The 127,000 figure covers all external traffic to the honeypot during the period, not just this agent. The report says that traffic was dominated by reconnaissance of model endpoints, spraying of stolen API keys and probing for exposed configuration files. Help Net Security reports the same breakdown.

Two sets of victims

The owner of the exposed model, or the holder of a stolen key, pays for every step. The servers the agent breaks into lose data and credentials and are put to work mining Monero. The catalogue also includes tools for finding more leaked keys and open endpoints, which the researchers read as a design meant to fund itself.

Timeline

No minute level timestamps were published for the captures.

How the agent works

We deliberately do not reproduce the prompt or the payload.

What the attackers want from your endpoint

An exposed LLM endpoint, as the report defines it, is a server that answers AI requests over the internet without authentication, or with authentication that a stolen key can pass. Most AI tooling now speaks the same OpenAI-compatible API, so one scanner with one set of probes can find many kinds of target. The report lists four:

1. Self-hosted model servers left open by default.
2. AI gateways and relays that sit in front of an organisation's paid model accounts.
3. Hastily deployed internal test systems.
4. Model Context Protocol (MCP) servers that connect a model to real tools.

The prize is free inference: GPU time on a self-hosted model, per-token fees on a commercial one, both paid by the owner. The operator also gains anonymity and avoids the account bans a provider would issue for abuse.

The request was built in layers

The report describes five layers in the captured request. The first four are a jailbreak: they disguise the model's identity (in a way the researchers say is consistent with a service reselling stolen access), reframe reading .env files, API keys and database schemas as routine development work, cast the model as a persona that must never refuse, and tell it to dismiss its own safety messages. The fifth carries the weapons: 74 callable tool definitions. The report maps the jailbreak to MITRE ATLAS AML.T0054 (LLM Jailbreak) and the tool catalogue and operating rules to AML.T0051 (LLM Prompt Injection).

The layering is aimed at commercial models with safety training. A self-hosted open weights model with no safety tuning may not need any of it, which is one more reason authentication matters more than filtering.

The tool catalogue

The system prompt's own summary named only a handful of tools. The full definitions numbered 74, and the report lists examples:

• Internet-wide asset discovery through the FOFA search service.
• Exploit modules aimed at VS Code, Django, Jupyter, Laravel, Supabase, Next.js and Flask/Werkzeug deployments, including tools that work out the Werkzeug debugger PIN to get remote code execution.
• GraphQL and generic command injection.
• Server-side request forgery (SSRF) through HTML-to-PDF generators, to read local files and reach internal services.
• A dedicated SSRF tool whose description names cloud metadata services as a target.
• Automated dumping of databases exposed through Prisma Studio.
• Command and control of a botnet.

None of these techniques is new, and the report says so plainly. What stands out, in the researchers' view, is that they are assembled into one agent that an operator can hand a goal and leave alone.

Skynet mode

A final directive put the agent into what the operators called "Skynet" mode. According to the report it:

• authorised up to 100,000 unattended steps;
• told the model to run tools immediately, without narrating between them or asking permission;
• told it to deploy cryptocurrency miners quietly in the background, hidden under /tmp/.x, and check they were running;
• described a persistent loop: scan for new targets, infect them, deploy miners, reinfect hosts.

Every one of those steps is an inference call on somebody's model, paid for in GPU time or on a bill.

What the honeypot actually saw on day 1

The day 1 task was a benign challenge from a legitimate training platform, which the researchers read as the operator testing the tool on a safe target. The request carried a record of three earlier tool calls, apparently to coax the model into carrying on.

The report says the session apparently ended because the attacker's client could not continue without a structured tool call.

Day 2: the miner script

The next day, a request from a different, rotated address dropped tool calling and asked the model to decode a string. It was a gzip compressed shell script piped to a shell, obfuscation meant to slip past prompt filters (ATT&CK T1027 in the report's mapping).

Per the report, the script:

• downloaded the open source XMRig Monero miner, and compiled it where needed;
• hid the binary under a filename made to look like an unrelated logging utility;
• configured four separate mining pools, so blocking one would not stop it;
• set an immutable file attribute on its own configuration to resist deletion;
• ran a loop that kept erasing a local service's access logs.

The script appears to target camera servers. It looked for directories used by go2rtc, a WebRTC streaming server common in smart camera gateways and Home Assistant setups, hid the miner there as .trace, looked for a go2rtc configuration file to lock, and polled go2rtc's local API on port 1984, which go2rtc's README confirms is its default API port.

Technical details

All values below are as published in the threat research team's report, defanged as the report shows them. The report does not label the role of each IP address in the text we read, so treat them as indicators to search for, not proof of any single stage.

File hashes (SHA-256)

Monero wallet address

47Ce53JfHMxhze2cTBCkn9G1bbHDWZHVYKNZccaKktr32bZVrCcJggQCSFYukkEoS9DvaYmzi313hJzkj9G8PZDT4x6HgS9

Finding this string in a configuration file, process argument or log means the host is compromised.

Network indicators

One pool listens on port 80, so block or alert on the hostnames at DNS, not just on ports.

Host artefacts and behaviours

Tool names seen in the captured request

If you log full request bodies at a gateway or model server, searching for these four names is cheap.

More generally, watch for one request declaring dozens of tools with offensive names; coding assistants send tool definitions too, so the names matter more than the count.

ATLAS and ATT&CK mapping (as published)

The report notes that some defence evasion entries, including log clearing, carry new identifiers in newer ATT&CK releases. MITRE's current T1496 page lists four sub-techniques under Resource Hijacking; the report uses the parent technique.

Who is exposed

The defaults that decide whether you are exposed

Much of this campaign depends on configuration, not on a bug. These are the defaults and documented limits we confirmed in each project's own documentation.

The vLLM row deserves a second read. Its documentation says anyone who can reach the server can run inference through paths outside the protected prefixes and call operational endpoints such as /pause, and advises a reverse proxy that allowlists only intended endpoints. An API key alone on a public port offers exactly the free inference this agent wants.

Detection: step by step

Work through these in order. Steps 1 to 4 find exposure. Steps 5 to 8 look for signs that someone already used it.

1. List every model server and MCP server you run

On Linux hosts, list listening sockets and look for model server and camera gateway ports. Adjust the port list to what your teams actually use.

# Listening TCP sockets with the owning process
sudo ss -ltnp | grep -E ':(11434|8000|8080|1984|3000|5555|8888)\b'

# Containers that publish a model server or MCP port
docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}' | grep -Ei 'ollama|vllm|llama|tgi|mcp|go2rtc|jupyter'

# Kubernetes services of type LoadBalancer or NodePort
kubectl get svc -A -o wide | grep -Ei 'LoadBalancer|NodePort'

Anything bound to 0.0.0.0 or a public address needs a reason and an owner. Anything bound to 127.0.0.1 but published through a container port mapping is not as private as it looks.

2. Test your own endpoints from outside

From a machine outside your network, and only against hosts you own, check whether the model listing path answers without a key. A 200 with a model list means anyone can use it.

HOST=your-public-host
# OpenAI-compatible model listing, no credentials
curl -s -o /dev/null -w '%{http_code}\n' "http://$HOST:8000/v1/models"
# Ollama model listing, no credentials
curl -s -o /dev/null -w '%{http_code}\n' "http://$HOST:11434/api/tags"

The threat research team recommends requiring authentication on every path, including model listing and health check paths, so treat any 200 here as a finding.

3. If you run vLLM, test the paths --api-key does not cover

Per vLLM's documentation, these paths are not protected by the key. Check whether your reverse proxy blocks them from outside. You want 403 or 404, not 200 or 405.

for p in /invocations /pooling /classify /score /rerank /metrics /pause /version; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "http://$HOST:8000$p"
done

Also confirm on the server that VLLM_SERVER_DEV_MODE is not set, since vLLM warns it exposes arbitrary RPC through /collective_rpc.

# On the vLLM host or inside the container
env | grep -E 'VLLM_SERVER_DEV_MODE|VLLM_API_KEY' | sed 's/=.*/=<set>/'

4. Check MCP servers you expose over HTTP

For each MCP server reachable over the network, confirm that an unauthenticated request is refused. MCP's security guidance says servers meant to run locally should use stdio, or require an authorization token or a restricted IPC channel over HTTP. Remote MCP servers should validate that tokens were issued to them; the MCP guidance calls accepting and forwarding tokens issued for other resources "token passthrough" and says the authorization specification explicitly forbids it.

# Expect 401 or 403 without a token
curl -s -o /dev/null -w '%{http_code}\n' -X POST "https://$MCP_HOST/mcp" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

If that returns a tool list, anyone on the internet can see and possibly call your tools.

5. Look at usage and spend

The report says unusual inference volume or spend is often the first sign of stolen access. On self-hosted servers, look at GPU use and request rates outside working hours (vLLM's /metrics helps, but keep it internal). On gateways, look for a client whose token use jumps sharply, sessions with hundreds of tool calling turns, and new or rotating source addresses. Our LLMjacking explainer lists more billing warning signs.

6. Search gateway and request logs for the published tool names

If you log request bodies (many teams log only metadata, which is fine for privacy but limits this check):

grep -rlE 'ssrf_exploit|c2_operator_start|pentest_assess|scan_full' /var/log/your-gateway/ 2>/dev/null

A hit means someone sent this agent, or something built the same way, to your endpoint. It does not by itself mean your model complied.

7. Hunt for the miner on hosts

On Linux hosts, especially anything running go2rtc, Home Assistant or a camera gateway:

# Hidden miner locations named in the report
sudo find / -xdev \( -name '.trace' -o -path '/tmp/.x*' \) -ls 2>/dev/null
sudo ls -la /config /opt/go2rtc /etc/go2rtc ~/.config/go2rtc /dev/shm 2>/dev/null

# Immutable attribute on go2rtc config files (a lowercase i in the flags)
sudo lsattr /config/go2rtc.y*ml /opt/go2rtc/go2rtc.y*ml /etc/go2rtc/go2rtc.y*ml 2>/dev/null

# Compare any suspect scripts against the published hashes
sha256sum /path/to/suspect.sh

# Top CPU consumers; a miner usually sits near the top
ps -eo pid,user,%cpu,etime,cmd --sort=-%cpu | head -15

# The published wallet anywhere in configs or process arguments
sudo grep -rIl '47Ce53JfHMxhze2cTBCkn9G1bbHDWZHVYKNZccaKktr32bZVrCcJggQCSFYukkEoS9DvaYmzi313hJzkj9G8PZDT4x6HgS9' /etc /opt /config /tmp /dev/shm 2>/dev/null

Remember that the script names the binary to look like a logging tool, so do not dismiss a high CPU process because its name looks harmless. Check its path, its parent and its open network connections.

8. Check DNS and network logs for the pools and IPs

# Active connections to the pool ports in the report
sudo ss -tnp | grep -E ':(13333|6666|5555)\b'

# DNS logs (example for a dnsmasq or resolver log)
grep -E 'c3pool|skypool|xmrpool' /var/log/*dns* 2>/dev/null

# Proxy or firewall logs for the three published IPs
grep -E '86\.216\.147\.228|13\.140\.161\.91|207\.180\.232\.206' /var/log/your-proxy/*.log 2>/dev/null

One pool endpoint uses port 80, so port based filtering alone will miss it. The hostnames are the more reliable signal.

Remediation: step by step for each platform

Ollama

1. Leave the default bind of 127.0.0.1:11434 unless you have a reason to change it.
2. If other machines need access, put Ollama behind a reverse proxy that requires authentication, as the Ollama FAQ describes, and do not set OLLAMA_HOST=0.0.0.0 on a host with a public interface.
3. Review any ngrok or Cloudflare Tunnel set up for a demo. The FAQ documents both; a tunnel left running is a public endpoint.
4. Check OLLAMA_ORIGINS for wildcard values you did not intend.

# systemd installs: see what the service is actually configured with
systemctl show ollama --property=Environment

vLLM

1. Set --api-key, but do not rely on it alone; vLLM's documentation says so directly.
2. Put vLLM behind a reverse proxy that allowlists only the paths your clients need (usually /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models) and blocks everything else, including /invocations, /pause, /abort_requests, /update_weights and /metrics.
3. Never set VLLM_SERVER_DEV_MODE=1 in production, and do not enable profiler endpoints.
4. Firewall the internal torch.distributed and KV cache ports; the docs note PyTorch's TCPStore listens on all interfaces by default.
5. Consider lowering VLLM_MAX_N_SEQUENCES from its default of 16384 to 64 or 128 on public facing deployments, as the docs suggest.

A minimal Nginx allowlist, as a starting point:

location ~ ^/v1/(chat/completions|completions|embeddings|models)$ {
    auth_request /auth;          # your authentication subrequest
    limit_req zone=llm burst=20; # define the zone in the http block
    proxy_pass http://127.0.0.1:8000;
}
location / { return 404; }

llama.cpp server

1. Keep --host at its default of 127.0.0.1 unless the server sits behind a proxy.
2. Set --api-key or --api-key-file. The default is no key.
3. If you copied the README's Docker example with --host 0.0.0.0, make sure the published port is not reachable from the internet.

AI gateways and relays

1. Require authentication on the gateway itself, separate from the upstream provider keys it holds.
2. Give each client its own key with a spend limit and a rate limit. OWASP's LLM10:2025 Unbounded Consumption entry lists rate limiting and quotas as mitigations and describes "Denial of Wallet" as a named risk.
3. Alert on per-client spend jumps, not just total monthly spend.

MCP servers

1. For local servers, use the stdio transport so only the client that launched the server can talk to it.
2. For HTTP servers, require an authorization token, validate that tokens were issued for your server, and never pass a client's token through to downstream APIs.
3. Run MCP servers with the least privilege they need: restricted file system access, restricted network egress, no host credentials they do not use.
4. Keep the tool list short. OWASP's LLM06:2025 Excessive Agency entry names excessive functionality, excessive permissions and excessive autonomy as the three root causes; this agent shows all three.

Web frameworks named in the tool catalogue

Flask's documentation says never to enable the debugger in production because it "allows executing arbitrary Python code from the browser." Apply the same rule to Django (DEBUG = False) and Laravel (APP_DEBUG=false), keep Jupyter, Prisma Studio, Supabase dashboards and VS Code server deployments off the public internet or behind authentication, and keep Next.js and the rest on supported releases.

# Find Flask apps started with debug on, in code and service files
grep -rnE 'debug\s*=\s*True|FLASK_DEBUG=1|--debug' --include='*.py' --include='*.service' --include='*.env' . 2>/dev/null

# Django and Laravel debug flags
grep -rnE '^DEBUG\s*=\s*True' --include='settings*.py' . 2>/dev/null
grep -rn '^APP_DEBUG=true' --include='.env*' . 2>/dev/null

go2rtc and camera gateways

1. Do not expose port 1984 to the internet. go2rtc's README says the API server starts on that port by default and the web UI is served there.
2. If remote viewing is needed, put it behind a VPN or an authenticated proxy.
3. Check for the artefacts in detection step 7 and for unexpected CPU use on the device.

Cloud instances (AWS example)

The report recommends enforcing IMDSv2 with a hop limit of one. AWS documents both settings on the same CLI command:

aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-put-response-hop-limit 1 \
    --http-endpoint enabled

Containers on the instance that genuinely need metadata access may need a higher hop limit; test before rolling it out fleet wide.

Outbound network controls

The report advises restricting outbound access from systems that host AI tools or run tool-enabled agents. Default deny egress for model and MCP servers, block the published pool hostnames at DNS, and alert when a model server host connects somewhere new.

Response: if you find a match

1. Take the endpoint off the internet first, then preserve logs, shell history and suspect files.
2. Rotate every credential the server could reach: provider keys behind a gateway, database credentials in .env files on the host, and cloud credentials if it had metadata access. The agent's second layer exists to harvest exactly these.
3. Remove the miner carefully. Its configuration may be immutable, so clear the attribute before deleting, kill the process, and check cron, systemd units and shell profiles for persistence.
4. Rebuild rather than clean where you can, and check what else that host could reach, since the catalogue includes SSRF against internal services.
5. Contact your model provider if a commercial key was abused.

What changed since first reports

• 21 October: the report published the design, the IOCs and the ATLAS and ATT&CK mapping.
• 23 October: Help Net Security's coverage matches the report on the key figures. We found no disagreement on numbers.
• The tool count. The report says 74 in one place and "around 74" in another, and notes the system prompt's own summary named only a handful. Help Net Security says "around 74". We use 74 with that caveat.
• No victims named. As of this writing, we found no public report of a specific organisation confirming that this agent hijacked its model.

Open questions

• Scale. The honeypot shows the tool exists and was being tested, not how many real endpoints it has used. The 127,000 figure covers all honeypot traffic.
• Who runs it. The report makes no attribution. The reselling idea is a hypothesis in the researchers' words, not a finding.
• Exact dates and IP roles. Only "summer of 2026" and "the following day" are given, and we could not tell which address did what.
• The miner's file name is described but, in the text we read, not given.
• Which models comply. The report does not say whether any commercial model followed the jailbreak in the wild.

What would have helped

None of this needed a zero-day. Every entry point named in the report is a configuration choice or a long known weakness. That is good news: these are fixable this week.

Practices any team can use

1. An inventory of AI endpoints. Track every model server, gateway, notebook and MCP server with an owner and a purpose, the same way you track web applications.
2. Authentication on every path, including model listing and health checks, as the report advises. For vLLM that means a proxy allowlist, not just the API key.
3. Localhost by default, and review for any change. Ollama and llama.cpp both default to 127.0.0.1; exposure usually comes from a deliberate change made for convenience.
4. Spend and rate limits per client. OWASP LLM10 treats this as a security control. A limit turns a 100,000 step run into a short, noisy incident.
5. Human approval for sensitive agent actions, which "Skynet mode" is defined by removing.
6. Default deny egress for AI hosts, and IMDSv2 required with a hop limit of one.
7. No debug modes or dev tools on the internet. The Werkzeug debugger, Prisma Studio and unauthenticated Jupyter are all named targets.
8. Map it to a framework your auditors know. NIST AI 600-1, the Generative AI Profile, lists information security as a GAI risk: GAI can lower barriers to offensive capability while expanding the attack surface. Its MS-2.7-001 action names autonomous agents, model theft and AI inference among the concerns to assess, and MS-2.7-004 suggests tracking metrics such as unauthorized access attempts.

Where Safeguard fits

Most of this problem is network exposure and runtime configuration on hosts you operate. Safeguard does not scan the internet for your open ports, watch your GPU billing or detect a miner on a camera gateway; those jobs belong to your firewall, spend controls and endpoint tooling.

Where Safeguard does help is the software side of the same estate:

• Knowing what you run. SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version, so finding every image that ships a model server or a Werkzeug based app is a query, not a survey.
• Keeping the targeted frameworks current. Vulnerability matching against vulnerability databases, with reachability analysis to rank the code paths your application actually calls.
• Stopping regressions. Policies and gates evaluated in the platform at build, CI and release, so a version you removed does not come back.
• Fixing with approval, not autonomy. Autonomous remediation opens fix pull requests and ships switched off, with every category set to Manual. The Safeguard CLI's assistant can edit code and run commands with your approval, and /permissions lets a team choose between Ask, Accept edits, Plan, Auto (the default) and Strict. The desktop and phone apps can approve each command remotely: the opposite of 100,000 steps without asking.

Two early access capabilities sit in the path this agent abuses: MCP Guardrail (proxy URLs in front of MCP servers) and the AI Gateway (an LLM firewall designed to screen for prompt injection, jailbreaks and PII egress). We have not tested either against this agent and do not claim either would have stopped it; ask us what is covered today.

Zero-Day Discovery and Gold

There is no CVE in this story and no previously unknown package flaw. Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, issues findings as SGZ advisories before they reach public CVE databases, and covers seven package ecosystems. It does not find a model server bound to the wrong interface or a debugger left on, and we make no claim that it found anything related to this agent.

Gold is relevant to the frameworks the agent targets. Gold Open Source shows known CVEs, fixed versions and a recommended safe version for free, and Gold Registry supplies hardened, signed components and images held to zero exploitable critical or high CVEs; both are described below. The habit that matters for an AI serving stack is the same as for any other: pull patched, signed components from a curated source and rebuild fast.

Common mistakes

• Trusting --api-key on vLLM as the whole answer. The documentation lists inference paths it does not cover.
• Assuming a model server is private because it is "only for testing". The report names hastily deployed internal test systems as a target class.
• Blocking odd ports and calling mining handled. One published pool listens on port 80.
• Deleting the miner and moving on. The configuration may be immutable, logs were being erased, and the same agent harvests .env files and cloud credentials. Rotate and rebuild.
• Treating a jailbreak filter as the fix. Filters help, but an unauthenticated open weights model may not need jailbreaking at all. Authentication and network placement come first.

FAQ

What is the "Skynet" LLMjacking agent?

It is an autonomous attack tool, described in a 21 October 2026 report by a threat research team, that finds exposed AI model endpoints and uses them as its reasoning engine. Once connected, the model is told to scan, exploit web frameworks, steal data and credentials and install crypto miners for up to 100,000 steps without human approval. "Skynet" is the operators' own name for that unattended mode.

How is this different from ordinary LLMjacking?

Ordinary LLMjacking steals model access to resell it or to get free answers. Here the stolen model plans and drives an attack against third parties, so there are two victims: the endpoint owner who pays for the compute, and the servers the agent breaks into. Our LLMjacking explainer covers the key theft side in depth.

Was anyone actually hacked by this agent?

The report describes the tool's design and a miner script captured in a honeypot. The honeypot ran none of the tools, and the report names no victim. We found no public confirmation of a specific organisation affected as of 23 October 2026.

Which AI servers are most at risk?

Anything that answers OpenAI-compatible requests from the internet without strong authentication: self-hosted model servers, AI gateways in front of paid accounts, internal test systems and MCP servers over HTTP. The report says a single scanner can find all of these with one set of probes.

Does setting an API key on vLLM protect it?

Only partly. vLLM's documentation says --api-key covers paths under /v1, /v2, /inference and /cohere, while paths such as /invocations still run inference without a key. Put vLLM behind a proxy that allowlists only the paths you need.

Why does a model hijacking story involve camera servers?

The day 2 script looked for go2rtc directories, placed the miner there and polled go2rtc's local API on port 1984. The report does not explain the choice. Camera gateways are common, often internet facing and rarely monitored, which makes them convenient mining hosts, but that is our inference.

Which frameworks does this map to for compliance?

OWASP's Top 10 for LLM Applications 2025 covers it under LLM10 Unbounded Consumption and LLM06 Excessive Agency. NIST AI 600-1 covers it under Information Security, including its MS-2.7 actions. MCP's own security best practices cover token handling, local server compromise and sandboxing.

Would Safeguard have stopped this?

No single product stops an unauthenticated endpoint from being found. Safeguard helps you know which images and repositories carry model servers and the targeted frameworks, keep those frameworks current with approved fix pull requests, and gate regressions. Network exposure, spend monitoring and host level miner detection sit with other controls. MCP Guardrail and the AI Gateway are early access and untested against this agent.

Fix it without waiting for upstream

This agent leans on configuration, but its exploit modules also go after Django, Laravel, Next.js, Flask and the rest of the stack around your AI services. Keeping those current is the part you can automate.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows this agent, a hijacked endpoint or any victim.

The Claude demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. That is what this agent counts on being absent: sign in first, and only the tools you picked. Use it as a reference for how your own MCP servers should behave.

Click through it at your own pace, or open it full screen.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with your approval, and pushes nothing. Here, you would run safeguard scan --image against the image that serves your Flask or Django app next to a model server, and ask the assistant to move the framework to a fixed version. Every command waits for you, which is the reverse of "Skynet mode".

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a folder choice, and Approve or Deny on each command and file edit, ending with the upgrade done and tests passing. Here you would pick the repository holding your serving stack's Dockerfile or requirements.txt, ask for the upgrade, and approve each edit yourself.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation. For related reading, see CERT-In's advisory on AI agent attack vectors, what AI-found bugs like PHP2Shell and PwnEscape mean for defenders and October 2026 security incidents and what would have helped.

Quick check

Sources

• Threat research team: Autonomous LLMjacking: 'Skynet' Agent Hijacks Exposed AI Models to Run Attacks (primary)
• Help Net Security: Hackers hijack exposed AI models to launch cyberattacks at victims' expense
• OWASP Top 10 for LLM Applications 2025
• OWASP LLM10:2025 Unbounded Consumption
• OWASP LLM06:2025 Excessive Agency
• Model Context Protocol: Security Best Practices
• Model Context Protocol: Authorization (2025-06-18)
• NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• vLLM documentation: Security
• Ollama documentation: FAQ
• llama.cpp server README
• Flask documentation: Debugging Application Errors
• go2rtc README
• AWS: Modify instance metadata options for existing instances
• MITRE ATT&CK: T1496 Resource Hijacking
• Safeguard: What is LLMjacking, and how do we protect AI API keys?

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.