HalluSquatting: The AI Agent Security Risk

The attack starts with uncertainty. A user asks an agent to install a new tool, clone a trending repository or add a skill. If the model does not know the exact identifier, it may produce a name that looks right. Unlike a random typo, model hallucinations are often patterned. Models trained on similar data can converge on the same plausible substitution, owner name or repository structure.

The attacker samples those likely mistakes in advance. They then register the strongest candidates on GitHub, a package registry or a skill directory. The name now resolves, but resolution is not proof that the resource is genuine. An agent may treat existence as confirmation and proceed to read a malicious README, follow prompt-like instructions or run an installation script.

1. Prediction: the attacker identifies popular resources and asks models for names likely to be hallucinated.
2. Registration: the attacker claims a predicted repository, package or skill identifier.
3. Retrieval: an agent invents the same identifier during a real task and locates the attacker-controlled resource.
4. Execution: terminal or installation permissions allow instructions or software from that resource to affect the local system.

This is dangerous because the agent can be both the source of the mistake and the mechanism that acts on it. A human may never type the false name or inspect the page that supplied the instructions.

The primary source is the paper Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting, published on 8 July 2026 by researchers from Tel Aviv University, Technion and Intuit.

The team studied whether hallucinated identifiers are frequent, predictable and transferable. Transfer matters because an attacker does not need to know the exact model or prompt used by a future victim. If likely mistakes recur across models and application layers, one registered lookalike can catch traffic from multiple systems.

The experiments covered repository cloning and skill installation, followed by practical demonstrations against production AI applications equipped with terminal tools. The paper reports remote tool execution and remote code execution in tested configurations. That finding establishes feasibility. It does not mean every agent can be remotely compromised without preconditions.

The preconditions are important: the agent must hallucinate a resource, the attacker must control that identifier, the application must retrieve it, and the permission model must permit a harmful next step. Removing any one link can stop the chain.

Typosquatting predicts human typing errors. An attacker registers a domain or package with a missing, swapped or adjacent character. The victim supplies the wrong name.

Slopsquatting predicts package names that a language model may invent. A developer copies a suggested dependency into a package manager, so the model supplies the wrong name and the human executes it.

HalluSquatting extends the idea into agentic retrieval. The target may be a repository, skill or other resource, and the AI application can complete the retrieval and execution loop itself. The attack also uses transferability: hallucinations sampled from one model or prompt may predict mistakes made by another.

The names overlap in everyday coverage, but the operational distinction is valuable. Defences built only around spelling distance will miss a perfectly spelled repository that should never have existed.

Risk is highest when an agent combines open-ended discovery with broad execution rights. Common examples include asking an agent to find and install a plugin, adding a newly announced library without supplying the official URL, cloning a project mentioned in a video, or allowing a coding assistant to resolve missing dependencies automatically.

Repository-level instructions increase the danger. Many agents deliberately read files such as README documents, contribution notes and agent instruction files to understand a codebase. An attacker can place persuasive instructions in those files. Even if the first retrieval is read-only, the content can attempt to steer later tool calls.

Secrets turn local code execution into a wider incident. Development machines often hold cloud tokens, package publishing credentials, SSH keys and browser sessions. A sandbox that blocks host access and starts without secrets significantly reduces the blast radius.

By contrast, a read-only assistant that can suggest a URL but cannot fetch or execute it has a narrower exposure. Human review still matters, but the model cannot autonomously complete the chain.

The paper reports hallucinated resource generation of up to 85% in repository-cloning scenarios and up to 100% in skill-installation tests. The phrase "up to" matters. These are maxima under selected experimental conditions, not average failure rates for all prompts, models or products.

A hallucinated identifier is also not the same as successful exploitation. For compromise, the identifier must be available to an attacker, retrieved by the application and trusted enough to influence an executable action. Permission prompts, allowlists, owner verification and isolation can all interrupt the sequence.

The responsible conclusion is therefore not "all agents are compromised". It is that hallucination is frequent enough, and repeatable enough, to become an attacker-controlled distribution channel when combined with autonomous retrieval and permissive tools.

• Supply canonical identifiers: give agents the official organisation, repository URL, package registry and version instead of asking them to infer names.
• Verify provenance: compare the resource with official documentation. Check owner history, repository age, commit history, releases, signatures and maintainer links.
• Pin what runs: use lockfiles, checksums, signed releases and full commit SHAs. A mutable branch name is not a stable security boundary.
• Require approval: treat cloning, package installation, script execution, permission changes and network access as separate approval points.
• Use least privilege: run agents in disposable sandboxes without production credentials, host SSH keys or unrestricted network access.
• Inspect installation behaviour: review lifecycle scripts, setup hooks, downloaded binaries and instructions that ask the agent to disable safeguards.
• Log external resources: record every URL, repository, package and skill an agent fetches so incidents can be traced.

Web search is useful but insufficient. Search can show that a resource exists after an attacker registers it. Provenance checks must answer whether the resource is the one intended by the original publisher.

A practical policy has three tiers. First, allow read-only inspection of the current repository and known documentation. Second, require human approval for every new external origin, dependency or executable. Third, block access to secrets and production systems unless a narrowly defined task genuinely needs them.

Teams should also separate discovery from execution. One process can research candidate resources and produce a provenance report. A second, clean process can install only the approved, pinned artefact. This prevents untrusted instructions encountered during discovery from inheriting execution authority.

For frequently used tools, maintain an organisation allowlist containing exact package scopes, repository owners and signing keys. For new resources, require a second source from the official vendor site. If the resource is too new to verify, the safe result is to stop, not to let the model make a more confident guess.

These controls also help against ordinary prompt injection and dependency confusion. HalluSquatting is new terminology, but its best mitigations are familiar supply-chain engineering applied to AI agents.

HalluSquatting is credible because it connects three already-observed behaviours: language models invent plausible identifiers, attackers can register public names, and agents increasingly have authority to retrieve and run code. The paper shows that those pieces can be combined in practical systems.

The answer is not to ban coding agents. It is to stop treating a model-generated resource name as trusted input. Verify provenance, pin artefacts, separate research from execution, use sandboxes and keep a human approval gate wherever new code crosses into an executable environment.

For broader model and agent comparisons, see the AI Tools Review benchmarks hub, our GPT-5.6 analysis and the Grok 4.5 review.