Skip to main content
AnthropicClaude CodeAI security

La filtración de Claude Code y el fin de las integraciones grises

El código fuente de Claude Code se filtró a través de un sourcemap de npm, lo que permitió analizar su lógica interna de confianza y firma. Para las empresas, la señal es clara: la integración no oficial de IA en agentes propietarios es frágil, se rompe fácilmente y conlleva riesgos legales y de seguridad.

Contexto técnico

Yo no construiría ninguna integración de IA en torno a lo que se extrajo de Claude Code tras la filtración. La historia es sonada, pero mi conclusión es pragmática: si el acceso se basa en la ingeniería inversa de la lógica del cliente, no es arquitectura, sino un agujero temporal.

La filtración en sí no ocurrió ayer, sino el 31 de marzo de 2026: el paquete de npm @anthropic-ai/claude-code@2.1.88 incluía un sourcemap, del cual se recuperó código TypeScript legible. Se trataba de unas 512.000 líneas y casi 1.900 archivos. Yo diría que no solo se expuso un cliente de interfaz de usuario, sino casi toda la infraestructura de agentes.

Lo que resultó especialmente revelador no fue la cantidad de líneas, sino su contenido. Incluía capas de orquestación, llamadas a herramientas, lógica de reintentos, control de permisos, integraciones MCP, puentes con IDE, memoria, coordinación multiagente e incluso modos para ocultar detalles internos. Cuando una capa así queda al descubierto, un atacante no obtiene la llave de una puerta, sino el plano de todo el edificio.

Luego, la gente empezó a aplicar ingeniería inversa al sistema de firma y verificación de integridad. Por lo que he visto en los análisis públicos, no se trata de que alguien encontrara una clave privada secreta, sino de algo más: se entendió la lógica de confianza, la verificación de artefactos, las comprobaciones de identidad y los límites en los que el cliente confía en la infraestructura de Anthropic. Esto ya es suficiente para crear forks, wrappers y clientes no oficiales convincentes.

Lo más probable es que Anthropic haya reforzado la seguridad hace tiempo. El paquete fue retirado, los pipelines depurados y las reglas de publicación de artefactos endurecidas. Por lo tanto, cualquier cliente no autorizado construido sobre esos hallazgos hoy parece una estructura muy frágil con una vida útil corta.

Impacto en el negocio y la automatización

Para las empresas, hay tres conclusiones, y todas son desagradables para los amantes de las soluciones alternativas. Primero: si construyes tu automatización de IA sobre un acceso no oficial a un agente propietario, no tienes estabilidad. El proveedor cambia el flujo de confianza y tu pipeline se cae sin previo aviso.

Segundo: el riesgo no es solo técnico, sino también legal. Anthropic no es conocida por su clemencia en estos casos, por lo que un conector no oficial puede pasar de ser un "hack rápido" a un problema para el cumplimiento normativo y las adquisiciones.

Tercero: el mercado ya no es el de antes, donde era necesario aferrarse a esta solución alternativa. Actualmente, OpenAI parece más fuerte en cuanto a su modelo y más estable en su trayectoria como plataforma, por lo que hoy en día ni siquiera consideraría la opción de "entrar mediante ingeniería inversa".

En Nahornyi AI Lab, suelo resolver este mismo dilema para los clientes: decidir dónde se necesita una arquitectura de IA adecuada con APIs oficiales, rutas de respaldo y control de costos, y dónde el equipo tiende por costumbre a un hack frágil. Si tu flujo de trabajo de agentes depende de un acceso inestable o una integración no oficial, desmontémoslo por capas y construyamos un esquema funcional sin una bomba de tiempo.

Estos eventos subrayan los desafíos continuos para proteger modelos de IA sofisticados. Previamente, examinamos un problema de seguridad relacionado con Claude, específicamente un fallo de autorreflexión, demostrando cómo la inyección de prompts podría explotarse para causar denegación de servicio e interrumpir la automatización de IA.

Compartir este articulo