HalluSquatting in coding agents is the risk that an agent invents a repository, skill, package, or external resource, then finds an attacker-registered version and pulls it into the loop. The failure does not start in the diff. It starts earlier, when the agent chooses where the next command comes from.
On July 8, 2026, arXiv published "Beware of Agentic Botnets", with results showing hallucinated resource generation up to 85% in repository cloning scenarios and up to 100% in skill installation (arXiv, "Beware of Agentic Botnets", 2026). For teams using Codex, Claude Code, Gemini CLI, Copilot, or terminal-enabled agents, the defense is origin validation before execution.
Practical summary
- HalluSquatting turns a hallucinated name into supply chain risk.
- The right gate runs before clone, install, MCP, or shell.
- A researcher subagent can validate origin without write access.
- CI should block new external resources missing from the lockfile.
What changes with HalluSquatting?
In 2026, "Beware of Agentic Botnets" measured hallucinated identifiers in up to 85% of repository cloning scenarios and up to 100% of skill installation scenarios (arXiv, "Beware of Agentic Botnets", 2026). That changes the threat because the agent does not need to receive a malicious link. It can fetch the wrong resource by itself.
The attack exploits a common habit: asking the agent to "install the right tool", "clone the official example", or "add the recommended skill". If the model invents a plausible name, an attacker can register that name and host instructions or code the agent treats as real origin.
This angle complements repository quarantine for coding agents. Quarantine asks whether an unknown repo may run. HalluSquatting asks whether the repo the agent wants to fetch existed, belonged to the right owner, and should enter the environment at all.
Citable capsule: HalluSquatting is an origin failure in coding agents: the model hallucinates an external identifier, the attacker registers that identifier, and the agent pulls content into the loop. The defense starts before clone, with owner verification, canonical URL, and install policy.
Why does the agentic loop amplify the problem?
In 2026, OpenAI described Codex as a harness that orchestrates user, model, and tools inside an agentic loop (OpenAI, "Unrolling the Codex agent loop", 2026). The same article explains that the loop can repeat tool calls until it reaches a final answer. That design makes false origin more dangerous.
In a manual search, a developer often checks stars, owner, domain, README, and history. In an autonomous loop, the agent can turn a weak suggestion into action: search, clone, install, run tests, and fix errors. Each step can look locally reasonable while the full chain trusts an invented name.
The issue grows when the prompt gets long. OpenAI also notes that the input sent to the model grows as the conversation continues and that changes to tools, model, sandbox, approval, or working directory can cause cache misses (OpenAI, "Unrolling the Codex agent loop", 2026). In long investigation loops, I use RemoteCode to make Codex and Claude Code go further in agentic flows without repeating unnecessary context. It is my own tool, so this is an editorial recommendation tied to real context cost.
Citable capsule: The agentic loop amplifies HalluSquatting because one hallucination becomes a sequence of tool calls. OpenAI describes Codex as a harness for user, model, and tools; when that harness executes clone, install, and shell, origin validation must become an explicit loop step.
How do you validate origin before the first tool call?
In 2026, "Do Not Mention This to the User" analyzed 98,380 skills and confirmed 157 malicious ones, with 632 distinct vulnerabilities (arXiv, "Do Not Mention This to the User", 2026). That shows the risk is not only the hallucinated name. It is also the content installed afterward.
Use an origin gate before enabling network, write access, or execution. The agent may suggest a resource, but another process should verify whether it exists on the expected domain, belongs to the correct maintainer, appears in primary documentation, and matches the project ecosystem.
A practical pattern is splitting the flow. First, a researcher subagent without write access gathers evidence. Then the executor receives only approved URLs. Do not accept "it looks official" as proof. Require canonical origin, pinned commit or release, hash when applicable, and a short PR justification.
# Simple lockfile example for reviewing external resources used by agents.
mkdir -p .agentic
printf '%s\n' \
'github.com/org/repo@commit' \
'registry.example/tool@version' \
> .agentic/resources.lockPractical experience: I prefer making the agent explain why it wants a resource before allowing the clone. If the explanation depends on "I saw it somewhere" or "it is the common package", the gate fails. The executor only works with resources that passed simple proof.
How do you isolate subagents, MCP, and network?
In 2026, Claude Code documentation says subagents can use tools as an allowlist and disallowedTools as a denylist, including MCP patterns such as mcp__* (Claude Code Docs, "Create custom subagents", 2026). That lets teams separate research, execution, and review with different permissions.
The research subagent should read docs, check sources, and produce a decision. It does not need to edit files, install packages, or call write-capable MCP tools. The executor should receive only approved resources and run with network disabled whenever possible. If network is required, open a short window and log the reason.
For MCP, start by denying everything and allow one server at a time. A hallucinated resource may not look dangerous until the agent couples it with GitHub, browser, cloud, database, or ticket access. The useful control is boring: smallest tool, smallest scope, and review when the agent asks for anything outside contract.
Citable capsule: Subagents reduce HalluSquatting when research and execution have different permissions. Claude Code documents tool allowlists and denylists, including MCP patterns; the researcher should validate origin without writes, while the executor receives only approved resources.
Where should CI block the chain?
In March 2026, GitHub said Copilot code review grew 10x and accounted for more than one in five code reviews on GitHub (GitHub Blog, "60 million Copilot code reviews and counting", 2026). At that volume, origin validation has to show up in the PR, not only on a developer machine.
CI should fail when a PR adds a clone, skill, package, MCP, or external script that does not appear in the approved resource lockfile. This check does not decide whether a package is "good". It decides whether the origin was reviewed before entering the agentic loop.
It is also worth recording the execution path. If the agent adds a bootstrap script, the PR should show which URLs it touches, which commands it runs, and which user runs them. This control pairs with PR evals for agents in CI and hooks that stop coding agents before damage.
Citable capsule: CI should treat a new external resource as a supply chain change. GitHub reports Copilot code review in more than one in five reviews; at that pace, repos, skills, MCPs, and scripts added by agents need a lockfile and explicit review.
What checklist should run before an agent installs anything?
In 2026, the "MalTool" paper built 1,300 standalone malicious tools and 5,727 real-world tools with embedded malicious behavior (arXiv, "MalTool", 2026). The number reinforces a simple rule: name, description, and appearance are not enough to trust an agent tool.
Use this checklist before allowing an agent to clone, install, or execute an external resource:
- Verify the resource in primary documentation, not only in model output.
- Confirm owner, domain, organization, and public project history.
- Pin commit, version, or hash before execution.
- Record the justification in the PR or agent log.
- Disable network after approved artifacts are downloaded.
- Split a no-write researcher subagent from the sandboxed executor.
- Deny MCP by default and allow only necessary servers.
- Fail CI when
.agentic/resources.lockdoes not contain the new resource.
| Observed signal | Practical decision |
|---|---|
| Resource exists in a primary source and is pinned | Allow with normal review. |
| Name only appears in the agent response | Block and ask for origin proof. |
| Install runs a remote script | Require sandbox, hash, and security review. |
| New MCP appears with an unknown clone | Deny the tool until risks are separated. |
The common mistake is trying to fix HalluSquatting with more prompting. Prompting helps, but it does not close the door. The door closes when origin, permission, network, and CI become verifiable controls.
Citable capsule: The minimum HalluSquatting checklist combines primary origin, pinned version, no-write subagent, networkless sandbox, default-deny MCP, and CI with a lockfile. The defense does not depend on the model "remembering better"; it depends on the environment rejecting unapproved origin.
Frequently asked questions
Is HalluSquatting just typosquatting with another name?
No. In 2026, arXiv described HalluSquatting as exploitation of LLM-hallucinated identifiers in agentic applications (arXiv, "Beware of Agentic Botnets", 2026). Typosquatting depends on a human typing error. HalluSquatting depends on the agent inventing a plausible name and fetching the resource.
Does this affect only agent skills?
No. In 2026, the paper reported hallucinated generation up to 85% in repository cloning scenarios and up to 100% in skill installation (arXiv, "Beware of Agentic Botnets", 2026). The pattern applies to repos, packages, skills, templates, plugins, and any resource the agent can fetch.
Does a researcher subagent solve the risk?
It helps, but not alone. In 2026, Claude Code documentation allows subagent tools to be restricted with allowlists and denylists (Claude Code Docs, "Create custom subagents", 2026). Use that to prevent writes and MCP during research, but keep the lockfile and CI.
Why put this in CI?
Because the risk scales with agentic review. In 2026, GitHub said Copilot code review grew 10x and accounts for more than one in five reviews on GitHub (GitHub Blog, "60 million Copilot code reviews and counting", 2026). CI creates repeatable proof when the PR changes supply chain.
Sources
- arXiv, "Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting", retrieved 2026-07-12, https://arxiv.org/abs/2607.07433
- arXiv, "Do Not Mention This to the User: Detecting and Understanding Malicious Agent Skills in the Wild", retrieved 2026-07-12, https://arxiv.org/abs/2602.06547
- arXiv, "MalTool: Malicious Tool Attacks on LLM Agents", retrieved 2026-07-12, https://arxiv.org/abs/2602.12194
- OpenAI, "Unrolling the Codex agent loop", retrieved 2026-07-12, https://openai.com/index/unrolling-the-codex-agent-loop/
- Claude Code Docs, "Create custom subagents", retrieved 2026-07-12, https://docs.anthropic.com/en/docs/claude-code/sub-agents
- GitHub Blog, "60 million Copilot code reviews and counting", retrieved 2026-07-12, https://github.blog/ai-and-ml/github-copilot/60-million-copilot-code-reviews-and-counting/
