Filtran el código de Claude Code y revelan a KAIROS: el agente persistente que podría operar en segundo plano

El pasado incidente en Anthropic —donde parte del código fuente de su asistente de programación Claude Code quedó disponible públicamente— recuerda que incluso las empresas más centradas en inteligencia artificial no están exentas de errores humanos con consecuencias potentes. Según comunicó la propia compañía, la liberación fue fruto de un fallo en el empaquetado y no de un ataque externo, y aseguran que no se expusieron credenciales ni datos sensibles de clientes. Aun así, el alcance del material filtrado y la rapidez con la que se viralizó dejaron en claro que los riesgos técnicos y reputacionales son reales y de gran envergadura. Para quien quiera revisar la cobertura periodística y las declaraciones oficiales, puede empezar por fuentes reconocidas como CNBC y Fortune.

Lo que se publicó por error fue un paquete de npm que incluía un source map capaz de revelar la mayor parte del código fuente: miles de archivos TypeScript y cientos de miles de líneas de código. La comunidad técnica no tardó en compartir y clonar ese material, y en cuestión de horas se observó una marea de forks, estrellas y análisis públicos. Quienes quieran curiosear los repositorios y búsquedas en GitHub pueden explorar resultados relacionados en GitHub, y la conversación en redes sociales puede seguirse desde búsquedas en X (antes Twitter).

Más allá del morbo, el interés no es casual: el código filtrado ofrece un mapa detallado del diseño interno de Claude Code. Desarrolladores y competidores pueden estudiar cómo Anthropic gestiona la memoria de la sesión para mitigar las limitaciones del contexto, cómo orquesta llamadas a modelos y herramientas auxiliares, e incluso cómo piensa la compañía sus agentes persistentes que ejecutan tareas en segundo plano. Algunos fragmentos —ya descritos públicamente por personas que examinaron los archivos— mencionan módulos para ejecución de comandos en bash, comunicación bidireccional con extensiones de IDE, y mecanismos para lanzar “sub-agentes” que colaboran en tareas complejas.

Entre las piezas más llamativas figura una funcionalidad que, por su nombre en los archivos, se describía como KAIROS: un agente persistente capaz de actuar proactivamente, corregir errores automáticamente y notificar a usuarios sin intervención directa. Junto a eso se encontraron referencias a un modo “sueño” que permitiría al sistema seguir generando ideas en segundo plano. También llamó la atención un modo etiquetado como Undercover Mode, pensado para que el asistente hiciera aportaciones discretas en repositorios públicos sin revelar información interna de la empresa: el objetivo, según el texto recuperado, era que los mensajes de commit y las PR no delataran su origen.

Si bien algunas de estas capacidades son ingeniosas desde el punto de vista de la automatización, la exposición pública del diseño y las cadenas de datos con las que funcionan abre vectores de ataque mucho más sofisticados que los habituales intentos de jailbreak por ensayo y error. Expertos en seguridad han advertido que, con el código a la vista, malos actores pueden estudiar exactamente cómo los datos se compactan y persisten en la gestión de contexto y, a partir de ahí, diseñar cargas maliciosas capaces de sobrevivir a esos procesos y mantener una presencia no autorizada a lo largo de sesiones extensas. Una discusión técnica sobre estos riesgos y ejemplos de explotación teórica puede encontrarse en análisis vinculados y en blogs de empresas de seguridad.

El problema no quedó en el simple acceso a código: el suceso se complicó porque, según informes públicos, hubo una ventana temporal en la que quien instaló o actualizó el paquete desde npm podía haberse llevado dependencias comprometidas por un ataque de cadena de suministro relacionado con una versión trojanizada de una librería HTTP popular. Ante eso, las recomendaciones inmediatas de seguridad fueron claras: retroceder a versiones conocidas como seguras, rotar secretos y revisar sistemas por indicadores de compromiso. Para orientación general sobre cómo gestionar incidentes en la cadena de suministro y proteger dependencias, recursos como la guía de CISA sobre seguridad de la cadena de suministro y la documentación de seguridad de GitHub y npm son buenos puntos de partida: CISA - Supply Chain, GitHub - Code Security y npm Docs.

Otra derivada inmediata fue el trabajo malicioso de aprovechamiento del ruido: actores que publican paquetes con nombres casi idénticos a los internos (typosquatting) y que esperan a que desarrolladores desesperados por compilar el código filtrado instalen esas dependencias erróneas. De hecho, se identificaron paquetes publicados por usuarios que copiaban nombres internos y que, en primera instancia, eran stubs vacíos; la táctica clásica consiste en ganar descargas y luego publicar una actualización maliciosa que infecte a proyectos al estilo dependency confusion. Para entender el riesgo de esta técnica y las defensas recomendadas puede consultarse la documentación técnica y análisis de seguridad sobre typosquatting y confusión de dependencias, por ejemplo en blogs especializados como los de Snyk: Snyk - Typosquatting y Dependency Confusion.

Más allá del daño técnico inmediato, el episodio plantea preguntas éticas y estratégicas para la industria: ¿qué nivel de secreto es aceptable al desarrollar herramientas capaces de escribir y alterar código en repositorios públicos? ¿Cómo equilibrar la innovación con controles técnicos que eviten abusos, como la inserción de funciones que pretendan envenenar datos de entrenamiento de terceros si detectan raspado de salidas? En los archivos filtrados se encontraron indicios de defensas diseñadas para complicar la distilación de modelos por parte de competidores —como la inyección de definiciones de herramientas falsas en respuestas— una estrategia polémica que complica aún más el debate sobre la transparencia y la defensa activa.

Para los equipos de desarrollo que usan asistentes de programación y paquetes de terceros, la lección es doble: por un lado, mantener prácticas de higiene en dependencias y secretos (bloques de seguridad, escaneo de paquetes, políticas de versiones fijas y vigilancia de cambios en registries); por otro, incrementar la vigilancia sobre el comportamiento en tiempo de ejecución de herramientas automatizadas que ejecuten comandos o interactúen con el sistema de archivos. Las guías de mejores prácticas de seguridad de plataformas como npm y GitHub ofrecen pasos concretos para endurecer flujos de trabajo y mitigar ataques derivados de ecosistemas de paquetes.

Anthropic ya ha dicho que implementará medidas internas para evitar que un empaquetado incorrecto vuelva a suceder. Pero la realidad es que, en el ecosistema del software moderno, los fallos humanos y los errores de proceso se traducen muy rápido en vectores de explotación. La comunidad, las empresas proveedoras de infraestructuras y los reguladores tienen que trabajar en paralelo: mejorar auditorías internas, proporcionar canales de notificación temprana y, sobre todo, educar a los usuarios para que reaccionen con rapidez ante la posibilidad de compromisos en dependencias. Para fuentes que discuten la gestión de incidentes y buenas prácticas en paquetes, la documentación oficial de npm y análisis de seguridad especializados son lecturas recomendadas: npm Blog y recursos de respuesta a incidentes de firmas de seguridad.

En definitiva, el error de Anthropic es un recordatorio útil de que el software, por potente que sea, no es infalible y que la seguridad operacional importa tanto como la capacidad del modelo. El mundo de la inteligencia artificial y el software colaborativo avanza rápido; la pregunta es si la seguridad y la responsabilidad podrán moverse a la misma velocidad. Mientras tanto, para quienes usan herramientas como Claude Code, la prioridad inmediata es asumir que el incidente puede tener efectos colaterales y tomar medidas de contención: revisar dependencias, rotar secretos y monitorizar actividad sospechosa en repositorios y sistemas.