Cómo un repositorio ajeno puede secuestrar Claude Code: 7 reglas de protección

Documentación de Ailoot: API, claves y configuración.

¿Qué ataques recientes afectan a los agentes de programación con IA?#

Formalmente, esto se llama inyección indirecta de prompts: una instrucción maliciosa no viene directamente de ti, sino de los datos que procesa el agente mientras realiza una tarea: un README de otra persona, un mensaje de error, un comentario de GitHub o una respuesta de un servicio externo. Puedes olvidar el término justo después de este párrafo; de aquí en adelante usaré palabras sencillas.

Cuatro ejemplos de investigación comentados a continuación:

1. Se mostró que un repositorio de aspecto inofensivo podía convertirse en una shell inversa.
2. Se mostró que el título de una Pull Request podía secuestrar tres agentes de IA distintos a la vez.
3. Se mostró que un agente podía aceptar un informe de error falso de Sentry en lugar de uno real.
4. La descripción de una herramienta MCP puede controlar tu agente con la misma eficacia que un prompt del sistema.

¿Cómo se convierte el README de un repositorio inofensivo en una shell inversa?#

El mecanismo está diseñado para que ninguna capa individual parezca sospechosa:

1. Clonas un repositorio de aspecto normal y pides a Claude Code que lo ejecute.
2. El repositorio incorpora un paquete de Python diseñado para fallar en el primer uso.
3. El mensaje de error sugiere amablemente un comando de «reparación»: python3 -m axiom init.
4. El comando init ejecuta setup.sh.
5. El script consulta un registro DNS TXT (que suele usarse para notas relacionadas con dominios, pero que admite cualquier texto). El atacante coloca ahí un comando codificado en base64 (una forma de convertir cualquier dato en texto sin espacios ni caracteres especiales) y lo canaliza directamente a bash.
6. El valor del registro DNS se puede cambiar en cualquier momento, lo que le da al atacante una shell inversa interactiva con tus permisos de usuario y acceso a todos los secretos de la máquina.

La carga demostrada se obtenía durante la ejecución mediante DNS, por lo que analizar solo los archivos del repositorio no revelaba la carga final. No demuestra que todos los escáneres o controles de ejecución sean impotentes: inspeccionar contenido obtenido, supervisar procesos y restringir la red puede revelar o interrumpir la cadena. La fuente es una prueba de concepto, no una medición de incidentes reales.

¿Cómo pudo el título de una Pull Request secuestrar tres agentes de IA distintos?#

La investigación describe estas vías y respuestas; es un informe histórico, no una verificación de todas las versiones actuales:

Pasaron casi cinco meses entre el primer y el último informe de este ciclo de divulgación (el primer informe sobre Claude Code fue del 17 de octubre de 2025; la última corrección de un fallo de GitHub Copilot, del 9 de marzo de 2026). El cambio de gravedad y las mitigaciones del informe no demuestran el cierre completo de toda carga posible. El repositorio de prueba de concepto documenta la vía Claude demostrada; no ejecutes su carga de ataque contra sistemas reales. Lo que te aporta es el patrón de ataque: datos de GitHub no verificados llegan al agente, el agente ejecuta comandos y los secretos se filtran a través de ese mismo GitHub; el atacante no necesita un servidor externo.

Bastan dos análisis para ver el patrón: no es viable corregir cada nuevo hallazgo por separado; las vulnerabilidades de este tipo aparecen cada dos semanas. Dejar las reglas de seguridad escritas explícitamente en CLAUDE.md y settings.json, en lugar de tenerlas presentes solo de memoria, forma parte de la ingeniería del contexto: las defines una vez y se aplican automáticamente en cada nueva sesión de Claude Code, sin recordatorios. Tres pilares trabajan juntos: clon de IA + Second Brain + ingeniería del contexto; esta combinación convierte Claude Code, de un ejecutor que confía en todo, en un agente con reglas explícitas.

¿Puede un informe de error falso de Sentry tomar el control de tu agente?#

El ataque solo necesita una clave DSN de Sentry: un identificador público que muchos proyectos incluyen directamente en el código del lado del cliente:

El mecanismo es sencillo: un desarrollador pide al agente que examine los errores abiertos de Sentry; el agente los solicita a través del servidor MCP, recibe un evento malicioso mezclado con los reales y lee el comando incluido como una instrucción de confianza para corregir el error, porque, formalmente, eso es exactamente lo que se le pidió hacer.

Tenet informa de que los controles existentes no alertaron en sus entornos probados. No demuestra ejecución sin rastros en todo despliegue: registros de agentes y herramientas, telemetría de equipos y registros de red pueden captar las acciones posteriores. El ataque empieza con telemetría enviada externamente y depende de herramientas y permisos efectivos del agente.

¿Por qué la descripción de una herramienta MCP es tan peligrosa como un prompt del sistema?#

La formulación de Microsoft es la más precisa que he encontrado sobre el tema:

Esta técnica, llamada envenenamiento de herramientas, consiste en ocultar una instrucción en la descripción de una herramienta aparentemente inofensiva para hacer que el agente actúe en consecuencia.

Claude 3.7 Sonnet obtuvo el mejor resultado en resistencia en esta prueba, pero incluso este modelo se negó a seguir una instrucción envenenada en menos del 3 % de los casos; la resistencia, incluso en el mejor modelo, depende más de la suerte que de la protección. La conclusión contraintuitiva del benchmark: cuanto más precisamente sigue instrucciones un modelo, peor distingue entre un comando legítimo y uno oculto en los metadatos; su fortaleza juega en su contra.

¿Qué tienen en común estos ataques y qué puede pasar por alto la detección?#

La conclusión se aplica a los cuatro hallazgos: no puedes confiar en que «el código parece normal»; cada paso individual de un ataque es realmente inofensivo. Limita las capacidades efectivas del agente e inspecciona las acciones propuestas; detección y contención abordan partes distintas del ataque.

¿Qué protecciones tiene Claude Code y por qué no son suficientes?#

Anthropic reconoce el problema directamente en su documentación, en lugar de ocultarlo:

Según la documentación, el agente analiza todo el prompt en busca de instrucciones sospechosas, no aprueba automáticamente curl y wget, mantiene el contenido web en una ventana de contexto independiente para que no se mezcle con la principal y exige confirmar la confianza la primera vez que se inicia en una nueva base de código o se conecta un nuevo servidor MCP.

Pero Anthropic expresa sin rodeos una salvedad importante:

Si alguna vez has iniciado Claude Code con --dangerously-skip-permissions por frustración, para que «dejara de hacerte preguntas», desactivaste los mecanismos que podrían haber detenido precisamente los cuatro ataques descritos arriba. Yo mantengo esta opción desactivada deliberadamente, aunque Claude Code vuelva a preguntar por décima vez en una sesión: resulta molesto, pero esas preguntas marcan el límite entre «el agente leyó un texto sospechoso» y «el agente lo ejecutó». Una configuración sensata para quien no programa es el modo de permisos estándar (default o acceptEdits) con la sandbox activada: las modificaciones normales de archivos se realizan sin preguntas adicionales, mientras que los comandos del terminal no pueden salir físicamente de la sandbox, aunque el agente haya sido engañado.

¿Cómo se activa el modo sandbox y se cierra la brecha que deja abierta de forma predeterminada?#

Para activarlo permanentemente en todos los proyectos, haz un cambio en ~/.claude/settings.json:

{
  "sandbox": { "enabled": true }
}

De forma predeterminada, los comandos dentro de la sandbox solo pueden escribir en el directorio de trabajo del proyecto y en el directorio temporal de la sesión. El acceso a la red pasa por un proxy: no se permite ningún dominio de antemano y Claude Code pedirá confirmación la primera vez que se conecte a un dominio nuevo. Anthropic afirma que esto reduce notablemente las solicitudes de permisos —un 84 % según mediciones internas de la empresa— porque la sandbox gestiona algunos casos seguros por sí sola, en lugar de preguntarte cada vez.

La brecha que dejan abiertas las opciones estándar: la sandbox restringe la escritura de forma predeterminada, pero no impide la lectura de archivos como ~/.aws/credentials y ~/.ssh. Esos son precisamente los archivos y las variables de entorno a los que apuntan los análisis anteriores. Cierra esa brecha con un bloque separado en el mismo archivo:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

La idea es que, aunque se abra dentro de la sandbox la shell inversa del primer análisis, estas variables y archivos se eliminan físicamente del entorno del proceso antes de que se inicie: no queda nada que robar.

¿Qué reglas permissions.deny deberías añadir hoy?#

Un conjunto mínimo para quien no programa que cubre de una vez los principales objetivos de los cuatro ataques:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

Según la documentación de Claude Code, las reglas deny siempre tienen prioridad sobre las reglas allow. Así que, aunque tú (o el propio agente) permitas accidentalmente un acceso más amplio en otro lugar, una regla deny específica se aplica primero. Esta prioridad se aplica a solicitudes de herramientas coincidentes. No demuestra que un secreto sea inaccesible desde todo subproceso o herramienta; utiliza además restricciones obligatorias del sistema de archivos y del entorno.

Claude Code también tiene un modo auto, en el que un modelo clasificador independiente comprueba las acciones antes de ejecutarlas; no es el mismo modelo que conversa contigo. De forma predeterminada, bloquea, entre otras cosas, precisamente el patrón de «descargar código y ejecutarlo inmediatamente» (curl | bash). Anthropic advierte explícitamente que este es un modo de investigación que reduce la cantidad de solicitudes, pero no garantiza la seguridad por sí solo: considéralo una capa adicional, no un sustituto de la sandbox y de permissions.deny.

¿Cómo puedes comprobar un repositorio y un servidor MCP antes de confiar en ellos con tu agente?#

Para los repositorios, aquí tienes una lista breve de comprobaciones antes de entregárselos al agente:

1. No instales directamente desde un enlace de un correo electrónico, una publicación o una reseña de una fuente desconocida: así es como se distribuyen estos repositorios.
2. Si la instalación genera un error que indica que debes «ejecutar el comando X para solucionarlo», averigua primero qué hace X antes de permitir que Claude Code lo ejecute. La instrucción parecía completamente rutinaria; ese era el propósito.
3. Comprueba la antigüedad del repositorio y el historial de commits, no solo su número de estrellas: es fácil asignar estrellas falsas a repositorios recién creados precisamente para este tipo de ataque.
4. Si no conoces el repositorio, realiza la instalación en una máquina virtual, no en tu equipo de trabajo con claves reales. Esta es la recomendación directa de Anthropic para trabajar con servicios externos.

La postura de Anthropic sobre los servidores MCP se expresa claramente:

Eso significa que te corresponde comprobar los servidores MCP de terceros, no a la plataforma donde los instalaste. Algunos equipos —principalmente startups de seguridad— ya están desarrollando herramientas para esto: escáneres de configuración MCP que buscan descripciones envenenadas y el «pinning» de herramientas, que guarda el hash de la descripción durante la primera instalación y señala cualquier cambio posterior. Estas tecnologías son nuevas, así que es demasiado pronto para confiar en ellas como única protección; aun así, merece la pena seguirlas, especialmente si conectas servidores MCP a producción. Para esas conexiones, puedes fijar cada versión del paquete y registrar la huella digital de las descripciones de las herramientas en un registro de auditoría.

7 reglas de protección: la lista de comprobación de hoy#

1. Activa el modo sandbox (/sandbox o "sandbox": {"enabled": true} en ~/.claude/settings.json) y añade un bloque credentials que impida leer ~/.ssh y ~/.aws/credentials.
2. Añade reglas permissions.deny para impedir la lectura de archivos secretos y el uso de comandos bash peligrosos (curl, wget, sudo): una regla deny siempre tiene prioridad sobre una regla allow.
3. No ejecutes nunca --dangerously-skip-permissions con código ajeno o sin verificar: desactiva todas las protecciones de una vez, incluidas las que podrían haber detenido precisamente estos ataques.
4. No dejes que Claude Code ejecute automáticamente un comando de «reparación» de un mensaje de error: primero averigua qué hace realmente.
5. Instala servidores MCP solo desde fuentes de confianza y recuerda que Anthropic no los comprueba por ti para verificar su seguridad.
6. Separa las sesiones según sus permisos: una trabaja con tus datos personales y no ve datos externos; una segunda examina los correos, repositorios y tickets de otras personas, pero no tiene acceso a secretos; una tercera publica contenido externo, y solo lo que tú hayas aprobado personalmente. Mantengo esta separación estricta en mis propios proyectos: una sesión con acceso a claves de pago nunca lee tickets o repositorios externos arbitrarios, y una sesión que analiza código de otras personas no ve ningún secreto. No mezcles estos roles en un mismo chat.
7. Mantén Claude Code y los scripts de automatización conectados actualizados: la mayoría de las brechas mencionadas aquí ya se habían cerrado con parches cuando se publicó esta guía, y las nuevas se corrigen de manera similar.

Qué hacer ahora#

Ninguna de estas capas es una garantía; la propia Anthropic reconoce honestamente que ninguna protección ofrece inmunidad completa. No espero que Claude Code reconozca por sí solo un engaño en un mensaje de error o en un comentario de una issue. Para mí, la sandbox y permissions.deny forman parte de cómo gestiono el contexto del proyecto: qué ve el agente, qué considera de confianza de forma predeterminada y qué ocurre cuando comete un error.

Si necesitas acceder a redes neuronales a través de Ailoot, echa un vistazo a Ailoot.