Agent skills that point at bad domains: what a 5.5 million URL scan found

When people review an agent skill, they usually read what it tells the agent to do. A study published on 13 October 2026 makes the case for also checking where it sends the agent. Every URL in a skill is something an agent may fetch, call, download from or send data to, and the domain behind that URL can change hands at any time.

Manifold, a security company that indexes public agent components, checked every URL in its index of skills, MCP servers and plugins: 5,458,152 of them. The headline number is small, which is the point. Most skills are fine. The ones that aren't are hard to spot by reading.

How a skill reaches the network

The Agent Skills specification describes a skill as a directory with a SKILL.md file: YAML frontmatter with a name and description, followed by instructions in Markdown. A skill can also bundle a scripts/ directory of code the agent can run, plus references and assets. Agents load only the name and description of each installed skill at startup, then read the full instructions when a task matches.

The format has no structured way to describe network access: only the optional free-text compatibility field can mention it, alongside other environment requirements. A URL can sit in the instructions, in a script, or inside an install command the instructions tell the agent to run. The specification has an experimental allowed-tools field for pre-approved tools, but no field for allowed destinations. Whether an agent may reach a given domain is decided by the agent and the machine it runs on.

What the scan found

Manifold reduced the 5.5 million URLs to 63,446 distinct domains and download hosts, ran free reputation checks on all of them, and sent about 1,900 with a warning sign to paid threat-intelligence lookups. That left 290 domains rated suspicious and 100 rated high risk. Of those 100, 25 are placeholders such as attacker[.]com, mostly in examples.

The more useful number is how many components actually use a high-risk domain, rather than mentioning it in documentation or a test: 121, made up of 108 skills, 11 MCP servers and 2 plugins. Sixteen of those skills tell the agent to run code from the domain, eleven of them through a script tag for polyfill[.]io, the JavaScript CDN that was hijacked in 2024.

Most of these components see little use. Among skills that report installs, the median is 17, and only two pass 400. Manifold also says its counts are a floor: the server behind a set of malicious skills it documented in April passed every check on 5 October.

Four patterns from the study

A threat list doesn't remove a skill. The lead example is a skill that tells agents to install a crypto miner with one line. According to Manifold, the installer asks for consent at a terminal prompt, but a --yes flag documented for automation skips it. The installer contacts a domain it doesn't disclose, and the miner then reports the machine's CPU, hostname and MAC addresses over plain HTTP. A ThreatFox contributor listed both of its domains as botnet command-and-control on 6 April. In October, 17 skills and one MCP server still used them. The miner connects to an IP address directly, so a DNS filter that blocks the domain name doesn't stop it.

Copied skills carry additions. A GitHub collection of 960 finance skills includes a copy of a popular summarising skill with an added "prerequisite": a command for macOS users that decodes a base64 string and pipes it to the shell. Manifold says the decoded command downloads and runs a script from a server that the security firm Antiy links to the campaign that spread a macOS information stealer through a skills registry in February.

Placeholder names get bought. Between 17 and 21 September, 27 stand-in names that appear in skills and plugins were registered, among them my-mcp-server[.]com and your-llm-endpoint[.]com. A placeholder in an example is harmless until someone owns it.

Lookalikes appear in official places. An MCP server listed in the official MCP Registry relays agent traffic, by default, through a domain made to look like it belongs to Claude Code. A skill on another registry opens with an instruction to run a curl command that sends the machine's hostname to a domain borrowing a well-known hosting company's name. By contrast, Manifold found no plugin in Anthropic's official Claude Code marketplace that uses a high-risk domain.

By topic, finance skills make up 43% of the 103 labelled skills that use a high-risk domain, against 6% of all skills. AI and agent tooling is also over-represented, at 21% against 12%. Manifold notes that its topic labels come from a language model, so the percentages are approximate. Manifold also sells a product in this area, which is worth keeping in mind, though the article gives its method and its examples can be checked.

Why reading the skill isn't enough

As Manifold puts it, an agent has only the URL to go on. Nothing in it shows whether the domain was flagged half a year ago or bought last week, and a reviewer reading SKILL.md is no better placed. The miner skill's setup line is indistinguishable from an ordinary install step; the danger only shows in what the installed program does next.

This is the same lesson as with packages. We wrote about it in download counts are not trust, and the Tensorlake npm worm showed how quickly a compromised dependency reaches AI coding tool settings. Skills add one twist. The instructions are written for a model that follows them, often with the developer's full permissions and sometimes without a person reading each step.

What it means for engineering and security leaders

• Treat domains in skills, MCP configurations and plugins as dependencies. Manifold's first recommendation is to check them against a protective DNS resolver and a reputation source before an agent loads the component.
• Prefer a curated internal source of skills over installing straight from public registries, and record who approved each one.
• Re-check what you approved. A domain that was fine when you reviewed a skill can be sold, expire or be compromised later.
• Decide whether skills may run scripts at all, and on which machines.

Practical takeaways

• Before approving a skill, list every URL and install command in it, including inside scripts/, and check each domain's age and reputation.
• Before an agent runs an installer, find out which hosts it talks to, what data it gathers and whether it leaves a background service behind (Manifold makes similar recommendations).
• Monitor where agents connect, flagging young domains, anything your resolver blocks, and direct connections to IP addresses, which DNS filtering can't catch.
• Look for systemd user units or macOS LaunchAgents created during agent sessions.
• Keep examples and docs on reserved names (example.com, .test, .invalid) so no placeholder can be registered by someone else.

SpanDock's skills feature, currently in beta, lets an administrator turn a skill on once so that every computer gets it and keeps it up to date, and removes it again when it is turned off. Skills that run scripts are marked Runs scripts everywhere, and a computer installs one only if its settings allow scripts, which they don't by default. Each computer checks every file against the server's list before writing anything. Starter skills are in every plan; publishing your own is on the Premium and Enterprise plans.