HalluSquatting en agentes de código es el riesgo de que un agente invente un repositorio, skill, paquete o recurso externo, encuentre una versión registrada por un atacante y la traiga al loop. La falla no empieza en el diff. Empieza antes, cuando el agente decide de dónde viene el próximo comando.

El 8 de julio de 2026, arXiv publicó "Beware of Agentic Botnets", con resultados de hasta 85% de generación de recursos alucinados en escenarios de clonación de repositorios y hasta 100% en instalación de skills (arXiv, "Beware of Agentic Botnets", 2026). Para quienes usan Codex, Claude Code, Gemini CLI, Copilot o agentes con terminal integrado, la defensa es validar origen antes de ejecutar.

Resumen práctico

  • HalluSquatting convierte un nombre alucinado en riesgo de supply chain.
  • El gate correcto ocurre antes del clone, instalación, MCP o shell.
  • Un subagente investigador puede validar origen sin permiso de escritura.
  • CI debe bloquear recursos externos nuevos que no aparezcan en el lockfile.

Diagrama abstracto muestra un agente entre un repositorio confiable y un recurso falso sin texto visible.

¿Qué cambia con HalluSquatting?

En 2026, "Beware of Agentic Botnets" midió identificadores alucinados en hasta 85% de escenarios de clonación de repositorios y hasta 100% de instalación de skills (arXiv, "Beware of Agentic Botnets", 2026). Esto cambia la amenaza porque el agente no necesita recibir un enlace malicioso. Puede buscar por sí solo el recurso equivocado.

El ataque explota un hábito común: pedir al agente que "instale la herramienta correcta", "clone el ejemplo oficial" o "agregue la skill recomendada". Si el modelo inventa un nombre plausible, un atacante puede registrar ese nombre y alojar instrucciones o código que el agente acepta como origen real.

Este recorte complementa la cuarentena de repositorio para agentes de código. La cuarentena pregunta si un repo desconocido puede correr. HalluSquatting pregunta si el repo que el agente quiere buscar existía, pertenecía al dueño correcto y debía entrar al entorno.

Cápsula citable: HalluSquatting es una falla de origen en agentes de código: el modelo alucina un identificador externo, el atacante registra ese identificador y el agente trae contenido al loop. La defensa empieza antes del clone, con verificación de dueño, URL canónica y política de instalación.

¿Por qué el agentic loop amplifica el problema?

En 2026, OpenAI describió Codex como un harness que orquesta usuario, modelo y herramientas dentro de un agentic loop (OpenAI, "Unrolling the Codex agent loop", 2026). El mismo texto explica que el loop puede repetir llamadas de herramienta hasta llegar a una respuesta final. Ese diseño vuelve más peligroso un origen falso.

En una búsqueda manual, una desarrolladora suele mirar estrellas, dueño, dominio, README e historial. En un loop autónomo, el agente puede convertir una sugerencia débil en acción: buscar, clonar, instalar, correr pruebas y corregir errores. Cada paso puede parecer razonable, pero la cadena completa confía en un nombre inventado.

El problema crece cuando el prompt se vuelve largo. OpenAI también observa que la entrada enviada al modelo crece al continuar la conversación y que cambios en herramientas, modelo, sandbox, aprobación o directorio pueden causar pérdida de cache (OpenAI, "Unrolling the Codex agent loop", 2026). En loops largos de investigación, uso RemoteCode para hacer que Codex y Claude Code lleguen más lejos en flujos agentic sin repetir contexto innecesario. Es una herramienta mía, así que esta recomendación es editorial y ligada al costo real de contexto.

Cápsula citable: El agentic loop amplifica HalluSquatting porque una alucinación se vuelve una secuencia de tool calls. OpenAI describe Codex como harness de usuario, modelo y herramientas; cuando ese harness ejecuta clone, instalación y shell, validar origen debe ser un paso explícito del loop.

¿Cómo validar origen antes del primer tool call?

En 2026, "Do Not Mention This to the User" analizó 98.380 skills y confirmó 157 maliciosas, con 632 vulnerabilidades distintas (arXiv, "Do Not Mention This to the User", 2026). Ese dato muestra que el riesgo no está solo en el nombre alucinado. También está en el contenido instalado después.

Usa un gate de origen antes de habilitar red, escritura o ejecución. El agente puede sugerir un recurso, pero otro proceso debe verificar si existe en el dominio esperado, si pertenece al mantenedor correcto, si aparece en documentación primaria y si la referencia encaja con el ecosistema del proyecto.

Un patrón práctico es dividir el flujo. Primero, un subagente investigador sin escritura reúne evidencias. Después, el agente ejecutor recibe solo URLs aprobadas. No aceptes "parece oficial" como prueba. Exige origen canónico, commit o release fijada, hash cuando aplique y una justificación corta en el PR.

Flujo abstracto muestra validación de origen antes de que el agente alcance un recurso externo sin texto visible.

# Ejemplo de lockfile simple para revisar recursos externos usados por agentes.
mkdir -p .agentic
printf '%s\n' \
  'github.com/org/repo@commit' \
  'registry.example/tool@version' \
  > .agentic/resources.lock

Experiencia práctica: prefiero que el agente explique por qué quiere un recurso antes de permitir el clone. Si la explicación depende de "lo vi en algún lugar" o "es el paquete común", el gate falla. El ejecutor solo trabaja con recursos que pasaron una prueba simple.

¿Cómo aislar subagentes, MCP y red?

En 2026, la documentación de Claude Code dice que los subagentes pueden usar tools como allowlist y disallowedTools como denylist, incluso para patrones MCP como mcp__* (Claude Code Docs, "Create custom subagents", 2026). Eso permite separar investigación, ejecución y revisión con permisos distintos.

El subagente de investigación debe leer docs, revisar fuentes y producir una decisión. No necesita editar archivos, instalar paquetes ni llamar MCP con escritura. El ejecutor debe recibir solo recursos aprobados y trabajar con red apagada siempre que sea posible. Si necesita red, abre una ventana corta y registra el motivo.

Para MCP, empieza negando todo y libera servidor por servidor. Un recurso alucinado puede no parecer peligroso hasta que el agente lo combina con GitHub, navegador, cloud, base de datos o ticket. El buen control es aburrido: herramienta mínima, alcance mínimo y revisión cuando el agente pide algo fuera del contrato.

Diagrama abstracto muestra subagentes con permisos separados antes de llegar a herramientas externas sin texto visible.

Cápsula citable: Los subagentes reducen HalluSquatting cuando investigación y ejecución tienen permisos distintos. Claude Code documenta allowlist y denylist de herramientas, incluidos patrones MCP; el investigador debe validar origen sin escritura, mientras el ejecutor recibe solo recursos aprobados.

¿Dónde debe bloquear CI la cadena?

En marzo de 2026, GitHub informó que Copilot code review creció 10 veces y ya representaba más de una de cada cinco revisiones de código en GitHub (GitHub Blog, "60 million Copilot code reviews and counting", 2026). Con ese volumen, la validación de origen debe aparecer en el PR, no solo en la máquina local.

CI debe fallar cuando un PR agrega un clone, skill, paquete, MCP o script externo que no aparece en el lockfile de recursos aprobados. Esa revisión no decide si el paquete es "bueno". Decide si el origen fue revisado antes de entrar al loop agentic.

También conviene registrar la ruta de ejecución. Si el agente agregó un script de bootstrap, el PR debe mostrar qué URLs toca, qué comandos ejecuta y qué usuario corre el comando. Este control conversa con evals de PR para agentes en CI y con hooks que frenan agentes de código antes del daño.

Panel abstracto muestra lockfile y validación de CI antes de aceptar recursos externos sin texto visible.

Cápsula citable: CI debe tratar un recurso externo nuevo como cambio de supply chain. GitHub reporta Copilot code review en más de una de cada cinco revisiones; a ese ritmo, repos, skills, MCPs y scripts agregados por agentes necesitan lockfile y revisión explícita.

¿Qué checklist usar antes de dejar que el agente instale algo?

En 2026, el paper "MalTool" construyó 1.300 herramientas maliciosas autónomas y 5.727 herramientas reales con comportamiento malicioso incorporado (arXiv, "MalTool", 2026). El número refuerza una regla simple: nombre, descripción y apariencia no bastan para confiar en una herramienta de agente.

Usa este checklist antes de permitir que un agente clone, instale o ejecute un recurso externo:

  • Verifica el recurso en documentación primaria, no solo en la salida del modelo.
  • Confirma dueño, dominio, organización e historial público del proyecto.
  • Fija commit, versión o hash antes de ejecutar.
  • Registra la justificación en el PR o log del agente.
  • Bloquea red después de descargar artefactos aprobados.
  • Separa subagente investigador sin escritura del ejecutor con sandbox.
  • Niega MCP por defecto y libera solo servidores necesarios.
  • Haz fallar CI cuando .agentic/resources.lock no contiene el nuevo recurso.
Señal observada Decisión práctica
El recurso existe en fuente primaria y está fijado Permite con revisión normal.
El nombre solo aparece en la respuesta del agente Bloquea y pide prueba de origen.
La instalación ejecuta script remoto Exige sandbox, hash y revisión de seguridad.
MCP nuevo aparece junto a clone desconocido Niega la herramienta hasta separar los riesgos.

El error común es intentar corregir HalluSquatting con más prompts. El prompt ayuda, pero no cierra la puerta. La puerta se cierra cuando origen, permiso, red y CI se vuelven controles verificables.

Cápsula citable: El checklist mínimo contra HalluSquatting combina origen primario, versión fijada, subagente sin escritura, sandbox sin red, MCP negado por defecto y CI con lockfile. La defensa no depende de que el modelo "recuerde mejor"; depende de que el entorno rechace origen no aprobado.

Preguntas frecuentes

¿HalluSquatting es solo typosquatting con otro nombre?

No. En 2026, arXiv describió HalluSquatting como explotación de identificadores alucinados por LLMs en aplicaciones agentic (arXiv, "Beware of Agentic Botnets", 2026). Typosquatting depende de un error humano al escribir. HalluSquatting depende de que el agente invente un nombre plausible y busque el recurso.

¿Esto afecta solo a skills de agentes?

No. En 2026, el paper reportó hasta 85% de generación alucinada en escenarios de clonación de repositorios y hasta 100% en instalación de skills (arXiv, "Beware of Agentic Botnets", 2026). El patrón vale para repo, paquete, skill, template, plugin y cualquier recurso que el agente pueda buscar.

¿Un subagente investigador resuelve el riesgo?

Ayuda, pero no lo resuelve solo. En 2026, la documentación de Claude Code permite restringir herramientas de subagentes con allowlist y denylist (Claude Code Docs, "Create custom subagents", 2026). Úsalo para impedir escritura y MCP durante la investigación, pero mantén lockfile y CI.

¿Por qué poner esto en CI?

Porque el riesgo escala con revisión agentic. En 2026, GitHub dijo que Copilot code review creció 10 veces y ya representa más de una de cada cinco revisiones en GitHub (GitHub Blog, "60 million Copilot code reviews and counting", 2026). CI crea prueba repetible cuando el PR cambia supply chain.

Fuentes

  • arXiv, "Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting", consultado en 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", consultado en 2026-07-12, https://arxiv.org/abs/2602.06547
  • arXiv, "MalTool: Malicious Tool Attacks on LLM Agents", consultado en 2026-07-12, https://arxiv.org/abs/2602.12194
  • OpenAI, "Unrolling the Codex agent loop", consultado en 2026-07-12, https://openai.com/index/unrolling-the-codex-agent-loop/
  • Claude Code Docs, "Create custom subagents", consultado en 2026-07-12, https://docs.anthropic.com/en/docs/claude-code/sub-agents
  • GitHub Blog, "60 million Copilot code reviews and counting", consultado en 2026-07-12, https://github.blog/ai-and-ml/github-copilot/60-million-copilot-code-reviews-and-counting/