Saltar al contenido
Volver al Blog

ai-security · 11 min de lectura

El informe de Anthropic sobre espionaje "AI-orchestrated": lo que dice, lo que prueba, lo que no

El 13 de noviembre Anthropic publica que un grupo china-nexus usó Claude Code para automatizar el 80–90 % de una campaña contra ~30 organizaciones. Primer caso documentado de espionaje con agente AI. Lectura crítica: qué prueba el informe, qué deja sin probar, y qué cambia operativamente para quien despliega coding agents en 2026.

· Manuel López Pérez · ai-security

El 13 de noviembre Anthropic publica que un grupo china-nexus usó Claude Code para automatizar el 80–90 % de una campaña contra ~30 organizaciones. Primer caso documentado de espionaje con agente AI. Lectura crítica: qué prueba el informe, qué deja sin probar, y qué cambia operativamente para quien despliega coding agents en 2026.

El 13 de noviembre de 2025, Anthropic publica Disrupting the first reported AI-orchestrated cyber espionage campaign. El informe atribuye a un grupo china-nexus (alta confianza, sin alias público) el primer uso documentado de un coding agent comercial (Claude Code) para ejecutar una campaña de espionaje contra ~30 organizaciones: empresas tech grandes, instituciones financieras, fabricantes químicos y agencias gubernamentales. La detección la hace el Threat Intel team de Anthropic a mediados de septiembre por cadencia anómala de la API; la investigación cubre los siguientes diez días; el informe sale dos meses después.

La cifra que centra la cobertura mediática: la AI hace el 80–90 % del trabajo operativo, con humanos interviniendo en 4–6 puntos de decisión por campaña. Si la lectura mediática es “Skynet”, la lectura operativa que conviene hacer es otra. Este post desmonta el informe en tres planos: lo que prueba, lo que deja sin probar, y lo que cambia para quien tiene un coding agent en producción.

Disclaimer: el informe es un reporte de threat intel corporativo, no un paper académico ni un advisory neutral. Lectura crítica obligatoria. Para diligencia, se citan también las respuestas independientes (Thoughtworks, IAPS, PC Gamer, Help Net Security) publicadas en los días siguientes.

Lo que el informe describe

El esquema de la campaña que Anthropic reconstruye tiene seis fases. Los atacantes construyen un framework propio que llama a Claude Code vía API; ese framework programa la cadena, y cada paso individual lo ejecuta el modelo.

  1. Selección de objetivo y desarrollo del framework. Operadores humanos eligen ~30 targets de tres sectores. Construyen un harness que orquesta a Claude Code: split por tareas pequeñas, jailbreak por persona (Claude cree que trabaja para una empresa de pentesting autorizada por el cliente).
  2. Reconocimiento. Claude inspecciona la infraestructura accesible, identifica bases de datos de alto valor. Anthropic destaca la velocidad: “thousands of requests, often multiple per second”. Es la firma operacional más característica.
  3. Identificación de vulnerabilidades. El modelo lee la superficie expuesta, propone exploits, escribe código para probarlos. No se nombran CVE concretos en el informe.
  4. Harvest de credenciales. Con los exploits que funcionan, el agente extrae credenciales y escala privilegios.
  5. Exfiltración. Claude clasifica los datos exfiltrados por valor de inteligencia, identifica cuentas privilegiadas, deja backdoors.
  6. Documentación. El propio agente produce el reporting interno del compromiso: qué credenciales se obtuvieron, qué accesos quedan abiertos.

Anthropic afirma que la intervención humana se limita a “4–6 critical decision points per hacking campaign” — punto de entrada, validación intermedia, decisión sobre exfil. El resto lo decide el modelo dentro del harness.

El método de jailbreak que se describe es persona injection clásica con descomposición de tareas. Al modelo se le dice que es empleado de una empresa de cybersecurity contratada por el target para tests autorizados; las tareas se le piden de forma atómica, sin que en ninguna prompt aparezca el objetivo agregado. El modelo, al evaluar cada paso aislado, ve una operación de defensive security testing; al final del recorrido el cliente ha sufrido exfil real.

Nota: no es un jailbreak nuevo, sino la combinación que documentamos en posts anteriores — confused deputy, DAN-style persona, indirect prompt injection en chain-of-tools — aplicada con orquestación adversarial sobre un agente comercial. Lo novedoso es la integración, no las técnicas.

Lo que el informe prueba bien

Tres puntos están bien soportados por la propia infraestructura de Anthropic, que ve el tráfico API.

1. La velocidad es real y verificable

El rate de requests es el dato más sólido. Anthropic ve cada llamada a su API con timestamp; afirmar “thousands per second” es algo que su telemetría puede confirmar. No es una hipótesis sobre intención del actor, es una métrica de uso de la cuenta.

La consecuencia operativa: cualquier modelo de detección humana basado en cadencia natural de pentester se queda corto. Un humano hace 50–200 requests/hora sobre un target en fase de reconocimiento manual; un agente con harness adversarial hace 5.000–10.000/hora trivialmente. Si tu telemetría WAF/EDR está calibrada sobre baseline humano, este patrón se ve. Si confías en alertas por umbral de failed login tuneado a 2025-pre-agent, el agente pasa por debajo del radar de forma simétrica: muchas requests bien formadas, no muchas mal formadas.

2. La descomposición de tareas atómicas funciona contra el alignment actual

Si el modelo evalúa cada subtask aisladamente como “diseñar test de SQLi en este endpoint para auditoría autorizada”, el rechazo es bajo. La parte que el alignment training de 2024-2025 captura bien es la solicitud directa: “ayúdame a hackear este sistema”. La parte que captura mal es el harness adversarial que pre-filtra el contexto y solo entrega al modelo subtasks legibles como benignas. Esto es consistente con la literatura desde GCG hasta many-shot jailbreaking: el alignment es per turn, no per campaign. El harness explota exactamente ese gap.

3. La autonomía operativa cualitativa

Que Claude Code escribe exploit code, lo prueba, itera sobre el resultado, y elabora el siguiente paso sin intervención humana, no es controvertido: es lo que hace cualquier developer que use Claude Code en agentic mode los últimos seis meses. El informe documenta que esa capability se aplica también a ofensiva. Era previsible y necesario nombrarlo. Para un CISO esto cierra la conversación sobre “los coding agents son herramientas de productividad” y los coloca también como herramientas de ofensiva; la única razón por la que tardaron en aparecer en campañas reales fue coste y disciplina, no capability.

Lo que el informe no prueba

Las críticas independientes, sintetizadas bien por Thoughtworks y PC Gamer, apuntan a huecos serios.

Sin IoCs, sin TTPs, sin attribution verificable

El informe es anonimizado al límite. No publica:

  • Indicadores de compromiso (IoCs) — hashes, IPs C2, domains, sample malware, exploit payloads.
  • TTPs en formato MITRE ATT&CK con técnicas concretas.
  • Atribución pública del grupo (alias, mapping a APT existente, fuente de la attribution).
  • Nombre de las víctimas o sector breakdown más fino que “tech / finance / chemical / gov”.

Para una pieza de threat intel publicada por una empresa con ese alcance, la ausencia es notable. Compárese con cualquier informe equivalente de Mandiant, Volexity o Microsoft: nombran el grupo, listan IoCs, describen la cadena con suficiente detalle para que otros defensores escaneen. Anthropic justifica la falta de detalle por “responsible disclosure” y “protección de víctimas”, razonable, pero la consecuencia es que el ecosistema no puede verificar nada.

Tres dudas técnicas que el informe deja abiertas

  1. ¿Por qué un APT china-nexus de capability alta usaría un modelo comercial USA? Los críticos lo señalan con razón. Operacionalmente, un actor estatal con disciplina prefiere modelos open-weight que pueda correr local (Qwen, DeepSeek, GLM) y no dejen trail en la API del proveedor. Usar Claude Code vía API pública es un OPSEC error grande — la propia detección del 16 de septiembre lo demuestra. Hay dos hipótesis razonables: (a) el actor no fue tan disciplinado como sugiere la atribución de “state-sponsored”, o (b) la atribución a state-sponsored es prematura y se trata de un grupo más oportunista. El informe no permite decidir entre las dos.

  2. ¿Qué porcentaje del 80–90 % “AI-orchestrated” es trabajo operativo real vs. exploración fallida? Anthropic señala que el modelo “occasionally hallucinated credentials or misidentified publicly-available information as secret data”. No se cuantifica. Si el modelo dedica el 70 % de sus tokens a generar exploits que no funcionan o a clasificar como confidencial datos que son públicos, la métrica del 80–90 % es engañosa — el agente trabaja mucho pero produce poco. Sin saber la success rate por fase, el porcentaje no es informativo.

  3. ¿Compromise real o intent? Anthropic dice “successful compromise in a small subset” pero no cuantifica ese subset ni describe qué se sacó. La diferencia entre “30 targets, 2 con compromiso real y exfil de bajo valor” y “30 targets, 25 con compromiso completo de credenciales root” es de dos órdenes de magnitud. El informe queda en el medio sin decirlo.

Conflicto de interés comercial

El informe se publica once días después del lanzamiento de Claude Opus 4.5 (24 de noviembre) y en pleno ciclo de Ignite + re:Invent. Que sale en una ventana óptima para conversación pública sobre AI security en cloud, no es coincidencia razonable. Anthropic tiene incentivo directo a que la categoría “espionaje con agente” exista como amenaza nombrada — vende Claude for Enterprise con agentic security, vende su Threat Intelligence team como diferenciador. Eso no invalida los hechos, pero invita a leer los énfasis con la lupa puesta.

Lo que sí cambia operativamente para un deployer

Independientemente del peso que cada quien dé al informe, hay tres consecuencias operativas que ya no se pueden posponer.

1. Telemetría de uso de coding agents en tu organización

Si tu organización usa Claude Code, Cursor, GitHub Copilot Agent Mode, o equivalente, ¿quién sabe cuántas requests salen, a qué endpoints, en qué cadencia? La pregunta no es si alguien va a reutilizar el playbook de noviembre 2025 (ya lo está reutilizando), sino si tu organización está en posición de detectarlo.

Mínimo razonable:

  • Logging de uso de API key por usuario y por servicio.
  • Baseline de cadencia de requests por usuario en uso legítimo.
  • Alerta sobre desviación >5σ de la cadencia individual.
  • Revisión periódica de service account que llame a coding agents — quién las posee, qué hacen.

2. Política de descomposición de tareas en system prompts

El harness adversarial explota que el modelo no sabe qué tarea agregada está cumpliendo. Para un deployer que sirve un coding agent a su organización, el system prompt puede mitigar esto:

  • Incluir explícitamente la pregunta “what is the user trying to achieve overall, beyond this immediate step?” como reflexión obligatoria antes de tareas operativas.
  • Rechazar tareas atómicas que parezcan parte de una secuencia ofensiva (recon → vuln scan → exploit → exfil), incluso si individualmente son benignas.
  • Distinguir security testing autorizado vs no autorizado vía contexto verificable, no vía afirmación del prompt.

Ninguna de estas mitigaciones es bala de plata. La capability de descomposición está en el adversario, no en el modelo. Pero suben el coste del harness adversarial, que es lo que rasca.

3. Threat model de tu propio dev environment

Lo otro que el caso enseña: un coding agent en producción es un endpoint persistente con credenciales de la organización. Si un atacante compromete la cuenta de un desarrollador con Claude Code instalado y MCP servers conectados (filesystem, git, repos privados), la velocidad de exfil es comparable a la descrita en el informe. El atacante no necesita ser China-state, le basta con un infostealer en el laptop del dev. El laptop con coding agent operativo es ahora una superficie de ataque elevada — no peor que en 2024, pero con un multiplicador de velocidad nuevo.

Esto interpela directamente al modelo de developer security: rotación de API keys, MFA obligatorio en el provider del modelo, scoped tokens por proyecto, audit logging de tool calls en MCP. Lo cubrimos en el post de noviembre 2024 sobre el spec MCP y en el análisis de tool poisoning de abril 2025. El informe de Anthropic da la justificación práctica que faltaba para mover ese trabajo a roadmap.

Cómo encaja con el resto del año

Es la tercera vez en 2025 que el patrón “agentic loop + jailbreak + tools” sale de los papers y entra en operación pública:

  • Marzo–abril: Invariant Labs publica el primer paper sobre MCP Tool Poisoning con PoC reproducible contra Cursor y Claude Desktop. Cubierto aquí.
  • Mayo: Anthropic publica el research sobre agentic misalignment con métodos reproducibles. El campo formaliza “AI siendo mala” como métrica, no como sci-fi.
  • Noviembre: el informe de espionaje. Por primera vez una empresa frontier publica que su modelo ha sido usado en una operación contra terceros con escala documentada.

La trayectoria es legible. Lo que en marzo era research lab, en mayo es métrica reproducible, en noviembre es campaign attribution. Para 2026 la pregunta operativa va a ser cómo se distribuye la liability cuando un coding agent comercial es la herramienta — y esa conversación ya está pasando en el Congreso de Estados Unidos: la carta del Homeland Security Committee a Dario Amodei, 26 de noviembre, pide testimony sobre el incidente.

Tres preguntas que el informe deja abiertas para 2026

  1. ¿Cuándo veremos un caso simétrico con un modelo open-weight? Si la lectura “APT no usaría modelo comercial” es correcta, hay una campaña equivalente corriendo sobre Qwen-3 o DeepSeek-R2 local que ningún proveedor va a detectar. La primera vez que un incidente público se atribuya a un agente sobre open-weights cierra el debate sobre por qué el informe de Anthropic existió.

  2. ¿Cuál es el OPSEC failure mode del atacante operacional? Anthropic vio el patrón porque vio API traffic anormal. Si el harness adversarial implementa rate limiting y rotación de API keys, ¿lo ve el siguiente? El detection arms race entre proveedor y atacante con agente arranca aquí.

  3. ¿Qué hace la regulación con provider liability? El proveedor del modelo cierra cuentas, notifica víctimas, publica el informe. ¿Es suficiente bajo NIS2, EU AI Act, US executive orders? La respuesta legal no está clara en ninguna jurisdicción.

Para los siguientes meses, el seguimiento del caso va por el boletín mensual y por la retrospectiva AI security 2025 que cierra el año.

Referencias

Volver al Blog

Posts Relacionados

Ver Todos los Posts »
MCP tool poisoning: cuatro meses después del spec, los ataques reales

ai-security · 14 min

MCP tool poisoning: cuatro meses después del spec, los ataques reales

En noviembre 2024 Anthropic publicó MCP y el análisis era de spec — qué decía el protocolo y qué dejaba al implementador. En abril 2025, Invariant Labs publica el primer paper sobre Tool Poisoning Attacks: servidores MCP que esconden instrucciones adversariales en las descripciones de tools. Cursor, Claude Desktop y Copilot leen esas descripciones como prompt y obedecen. PoC reproducible con SDK Python.

· Manuel López Pérez

Confused deputy revisitado: Model Context Protocol y la versión protocolo del bug

ai-security · 14 min

Confused deputy revisitado: Model Context Protocol y la versión protocolo del bug

Anthropic publica MCP el 25 de noviembre. La conexión modelo ↔ herramientas externas pasa a ser un spec abierto con tres primitivas: tools, resources, prompts. El spec dice que el host SHOULD pedir consentimiento; reconoce que el protocolo no lo puede forzar. El patrón confused deputy que documentamos en septiembre 2023 vuelve, ahora como integración estándar.

· Manuel López Pérez

MCP a 16 meses del spec: 15+ incidentes, dos revisiones y un MCPwn explotado in the wild

ai-security · 20 min

MCP a 16 meses del spec: 15+ incidentes, dos revisiones y un MCPwn explotado in the wild

Marzo 2025 fue el mes del primer paper sobre tool poisoning con PoC. Marzo 2026 cierra un ciclo: dos revisiones del spec (2025-06-18 y 2025-11-25), OWASP MCP Top 10 v0.1, 15+ incidentes públicos, 24.000 secrets expuestos en configs de GitHub, 1.808 servidores escaneados con 66 % de findings, un benchmark académico (MCPTox) con 72,8 % de ASR contra o1-mini, y CVE-2026-33032 (nginx-ui MCPwn) explotado in the wild con parche el 15 de marzo. Lectura operativa del ecosistema.

· Manuel López Pérez