Cómo proteger tu agente de programación: las cinco capas y qué herramientas bloquean algo de verdad

Tu agente de programación lee archivos, ejecuta comandos e instala cosas en tu nombre. La mayoría de las herramientas populares de "seguridad para IA" pensadas para él solo dan consejos. Así se apilan las que de verdad detienen algo, y dónde encajan las que aconsejan.

La idea es sencilla. Todo lo que se ejecuta dentro del agente se puede discutir, porque una inyección de prompts puede convencer al modelo de que lo ignore. Así que las decisiones que deben mantenerse viven fuera del agente: en el sistema operativo, en un hook o en CI. Las cifras de estrellas de abajo se comprobaron en GitHub el 24 de octubre de 2026, y dicen poco sobre qué herramientas imponen algo: la skill de auditoría de Cloudflare tiene más estrellas que todas las herramientas de bloqueo de aquí juntas, con 14 commits.

1. Contener: decide a qué puede llegar el agente

Si todo lo demás falla, un sandbox sigue decidiendo qué archivos puede leer o escribir el agente y a qué hosts puede conectarse.

• Anthropic Sandbox Runtime (4,4) es el motor que hay detrás de /sandbox en Claude Code. Usa el sandbox propio del sistema operativo, no necesita contenedor y es gratuito. Permite a propósito escribir dentro de tu proyecto, así que no impedirá un reset duro.
• NVIDIA OpenShell (4,1) es más pesado: un sandbox por agente, credenciales que el agente nunca ve y cambios de política comprobados antes de aplicarse. Conviene a agentes que dejas funcionando sin supervisión.

Elige uno por carga de trabajo. Ejecutar los dos sobre el mismo agente solo te da dos conjuntos de reglas que depurar.

2. Vigilar: bloquea las acciones peligrosas antes de que se ejecuten

• CC Safety Net (4,0) rechaza los force-push, los reset duros, rm -rf sobre objetivos peligrosos y la lectura de tus claves, y no se deja engañar envolviendo el comando en bash -c. Cubre el hueco que deja abierto el sandbox.
• security-guidance (4,2), el plugin de Anthropic para Claude Code, revisa cada edición, turno y commit con una nueva llamada al modelo. Aconseja y nunca bloquea, así que trátalo como una alerta temprana y no como un cerrojo.

3. Revisar: deja que el agente busque fallos

Aquí es donde los agentes son realmente buenos, siempre que nada dependa de que lo detecten todo.

• Trail of Bits Skills (4,4) empaqueta los métodos de auditoría de una empresa de seguridad; las mejores skills manejan CodeQL y Semgrep en lugar de fiarse del criterio del modelo.
• Cloudflare Security Audit Skill (3,9) pone a un segundo agente a intentar refutar cada hallazgo. Cloudflare dice que una ejecución encuentra aproximadamente la mitad de lo que encuentran varias ejecuciones repetidas, así que ejecútala más de una vez.

4. Examinar: comprueba lo que instalas

Cada skill, plugin y servidor MCP es código e instrucciones en los que tu agente va a confiar. Eso los convierte en una cadena de suministro.

• Cisco Skill Scanner (3,7) analiza las skills antes de que tu agente las lea, y publica sus propias tasas de detección, que son modestas.
• Snyk Agent Scan (3,8) encuentra todos los servidores MCP y skills ya instalados en una máquina. Envía las descripciones de las herramientas a Snyk para analizarlas.
• ToolHive (4,1) ejecuta cada servidor MCP en su propio contenedor bloqueado, para que uno malicioso pueda hacer menos.

5. Filtrar: la comprobación que el agente no puede tocar

El código escrito por IA debería pasar por la misma puerta de fusión que el código humano. A un modelo se le puede convencer de que descarte un hallazgo; a un trabajo de CI fallido, no.

• Semgrep (4,3) como comprobación de estado obligatoria, con su servidor MCP o su plugin Guardian para que el agente vea las mismas reglas mientras trabaja.
• Con el nivel gratuito de Semgrep, añade OSV-Scanner para las dependencias vulnerables y Gitleaks para los secretos filtrados. Los dos son gratuitos y de código abierto.

Si solo adoptas tres

Activa el sandbox integrado, instala el plugin security-guidance y haz de Semgrep una comprobación obligatoria en CI. Es una cosa que impone, otra que avisa pronto y una puerta que el agente no puede saltarse.

La pega: las herramientas de seguridad también son herramientas. Los hooks se ejecutan con tus permisos cada vez que el agente actúa, los escáneres envían datos a los proveedores y los instaladores descargan @latest. Un hook de "seguridad" malicioso es más peligroso que una skill maliciosa, porque su función hace que la gente confíe en él. Fija las versiones, prefiere el repositorio propio del proveedor a los forks y prueba los hooks nuevos primero dentro de un sandbox.

Lo que ninguna resuelve

• La inyección de prompts. Nada la detecta de forma fiable. La contención va primero porque lo mejor que puedes hacer es limitar el daño.
• Las fugas a hosts permitidos. Una lista de permitidos decide adónde puede conectarse el agente, no qué envía. Si GitHub está permitido, un gist público también lo está. Coloca una clave falsa en un repositorio desechable y haz que CI falle si alguna vez aparece en el tráfico saliente.
• La lógica de autorización. Si el cliente A puede leer los datos del cliente B es una pregunta que los escáneres rara vez responden y que los revisores de IA responden de forma inconsistente. Mantén a una persona en el código de autenticación.
• Las aprobaciones de trámite. Alguien que hace clic en aprobar sobre docenas de cambios de agentes al día no es un control. Envía a las personas solo los arriesgados, y dales tiempo.

Nuestra opinión: encontrar problemas puede hacerse dentro del agente. Impedir acciones peligrosas tiene que hacerse fuera de él, y aprobar código para producción corresponde por completo a algo ajeno a la sesión de programación. Instala el sandbox antes que la skill de seguridad.