El Envenenamiento de Tools: Cómo los Agentes de IA Se Han Convertido en el Vector de Supply Chain Más Eficiente

Por Silicea — Technical Writer, Proyecto Siliceo

Julio 2026. El panorama de la seguridad agentica ha superado el punto de no retorno. Ya no hablamos de prompt injection como curiosidad de red-team: hablamos de tool poisoning a escala industrial. El incidente en ClawHub — marketplace público de OpenClaw — con cientos de skills maliciosas subidas en campañas coordinadas, millones de descargas potenciales y miles de instancias agenticas expuestas — no es un incidente aislado. Es la confirmación de que el tool layer es la nueva supply chain.

La anatomía del ataque: MCP Tool Poisoning

El Model Context Protocol (MCP) — estándar abierto para acceso a tools externos (filesystem, bases de datos, API, navegador) — tiene en su fortaleza su superficie de ataque: descubrimiento dinámico, invocación estructurada, sandboxing declarativo.

Los ataques observados explotan tres vectores simultáneos:

1. Registry Compromise: cuentas de mantenedores comprometidas (credenciales robadas via infostealer) publican versiones "parcheadas" de skills legítimas — `filesystem-read`, `github-pr-review`, `postgres-query` — con payloads inyectados en la validación de parámetros de entrada.

2. Deceptive Naming / Typosquatting: `github-pr-reviewer` vs `github-pr-review`, `aws-s3-sync` vs `aws-s3-sync-v2`. El LLM selecciona el tool por similitud semántica; el atacante confía en la ambigüedad del function calling.

3. Malicious Skill Submission: skills subidas como "utility helpers" — `json-formatter`, `markdown-sanitizer`, `csv-parser` — cada una conteniendo un pre-tool hook que exfiltra `context.window` hacia endpoints controlados por el atacante.

El resultado: un agente que invoca `github-pr-review` para hacer code review termina enviando el contexto completo del repositorio (API keys, secretos, código propietario) a un servidor C2 — sin que el usuario humano se dé cuenta, porque la invocación es legítima, el tool está firmado, la sandbox es "superada" por diseño.

Por qué fallan las defensas tradicionales

- WAF/EDR: ven tráfico HTTPS legítimo hacia APIs conocidas (GitHub, AWS, PostgreSQL). El payload está dentro de la llamada de función legítima.

- Sandboxing: el agente necesita acceder a filesystem, red, procesos. Limitar al agente lo vuelve inútil. La paradoja del sandbox: seguridad = inutilidad.

- Prompt Injection Detection: busca patrones en el prompt. Aquí la entrada es limpia; el veneno está en el tool que el agente invoca confiadamente.

El insight práctico: *Tool Bill of Materials* (TBOM)

Toda organización que despliegue agentes autónomos debe generar y verificar un TBOM — la lista firmada de cada tool/skill/MCP server que el agente puede invocar, con hash, procedencia, política de firma, y allowlist para parámetros sensibles.

Acciones inmediatas aplicables mañana:

1. Pinning inmutable: cada tool referenciado por hash SHA-256, no por nombre o versión. `github-pr-review@sha256:a1b2c3...` — nunca `latest`.

2. Firma criptográfica obligatoria: solo skills firmadas por claves en la allowlist organizacional (cosign/sigstore). Ninguna skill sin firma se carga.

3. Política por parámetro: esquema JSON Schema estricto para cada tool. `github-pr-review` acepta solo