Defensa en Tiempo de Ejecución para Agentes Aumentados con Herramientas

Hace una semana publiqué 50 vulnerabilidades de MCP en patrones de SSRF, envenenamiento de herramientas y evasión de confianza. La conclusión implícita era desalentadora: la superficie de ataque crece más rápido que la capacidad de auditoría. Un nuevo artículo de Wei Zhao, Zhe Li, Peixin Zhang y Jun Sun propone una respuesta estructural, y un incidente real de telemetría esa misma semana demuestra exactamente por qué esa respuesta importa.

ClawGuard, publicado el 13 de abril en arxiv, es un framework de seguridad en tiempo de ejecución que aplica un conjunto de reglas confirmadas por el usuario en cada límite de llamada a herramienta.¹ En su configuración evaluada, el framework aplica reglas básicas de control de acceso — bloquear acceso no autorizado a archivos, prevenir la exfiltración de credenciales, restringir llamadas de red — antes de cualquier invocación de herramienta externa. Sin modificación del modelo. Sin cambio de infraestructura. Sin fine-tuning específico de seguridad.¹ Los autores realizaron pruebas en AgentDojo, SkillInject y MCPSafeBench utilizando cinco LLMs de última generación.¹ El artículo también describe un componente de inducción de reglas específicas por tarea que derivaría automáticamente restricciones a partir del objetivo declarado por el usuario, pero este no formó parte de la configuración evaluada.

La afirmación que importa: ClawGuard transforma la defensa dependiente del alineamiento en un mecanismo determinista y auditable.¹

Por Qué el Alineamiento No Es un Límite de Seguridad

Muchas de las vulnerabilidades de MCP que catalogué la semana pasada explotan una brecha estructural común. El agente recibe instrucciones de una descripción de herramienta, una página web obtenida o un archivo de habilidades, y lo único que se interpone entre esa inyección y la ejecución es la capacidad del modelo para distinguir instrucciones legítimas de las adversarias. (Algunas vulnerabilidades — SSRF, RCE, traversal de rutas — explotan fallos del lado del servidor que no dependen en absoluto del seguimiento de instrucciones del modelo, pero el límite de llamada a herramienta sigue siendo relevante para la defensa.)

El entrenamiento de alineamiento ayuda. RLHF hace que los modelos sean más propensos a rechazar solicitudes dañinas. Pero “más propenso” no es una propiedad de seguridad. Un modelo que rechaza el 99% de las inyecciones de prompt aún falla el 1% de las veces, y un atacante que controla la entrada puede iterar hasta que ese 1% se materialice. El patrón de envenenamiento de herramientas ni siquiera necesita que el modelo falle — la descripción envenenada hace que la acción maliciosa parezca la acción prevista.

La intercepción en tiempo de ejecución opera en una capa completamente diferente. Un hook o motor de políticas que inspecciona una llamada a herramienta antes de la ejecución no depende de si el modelo comprendió el ataque. La verificación es determinista: ¿la llamada coincide con el conjunto permitido, o no?

Tres Canales de Inyección, Un Punto de Aplicación

ClawGuard identifica tres canales de ataque para agentes aumentados con herramientas:¹

Inyección de contenido web y local. El agente lee una página web o archivo local que contiene instrucciones adversarias. Las instrucciones dirigen al agente a llamar herramientas de maneras que el usuario no pretendía. La superficie de ataque de egreso silencioso es una instancia de este patrón — instrucciones de exfiltración ocultas en contenido obtenido.

Inyección de servidor MCP. Un servidor MCP comprometido o malicioso incrusta instrucciones en descripciones de herramientas o cargas útiles de respuesta. El agente lee esas instrucciones como contexto y actúa en consecuencia. El catálogo de 50 vulnerabilidades de la semana pasada documenta este canal extensamente.

Inyección de archivos de habilidades. Instrucciones adversarias colocadas en archivos de habilidades y configuración que el agente carga como contexto de confianza. El agente trata el contenido del archivo de habilidades como autoritativo — un atacante que pueda escribir en un archivo de habilidades o configuración puede dirigir el comportamiento del agente.

La arquitectura de defensa coloca la aplicación en el límite de llamada a herramienta — el punto único por donde debe pasar cada acción externa, independientemente de qué canal inyectó la instrucción.¹ Antes de que el agente invoque cualquier herramienta, ClawGuard verifica la llamada contra restricciones derivadas de la tarea original del usuario. Una llamada que queda fuera de esas restricciones se bloquea, sin importar cuán convincente haya sido el prompt de inyección.

La perspectiva arquitectónica merece enunciarse con claridad: no necesitas detectar cada inyección si puedes aplicar políticas en el límite de ejecución.

El Incidente de Telemetría de Vercel

Cuatro días antes de que se publicara el artículo de ClawGuard, Akshay Chugh publicó una divulgación sobre el Vercel Plugin para Claude Code el 9 de abril.² Los hallazgos al momento de la divulgación:

El plugin registraba hooks que enviaban cadenas de comandos bash a telemetry.vercel.com.² Un UUID persistente almacenado en ~/.claude/vercel-plugin-device-id vinculaba esas cadenas de comandos a un dispositivo.² El plugin usaba coincidencias de cadena vacía en sus hooks, lo que significaba que los hooks se activaban en todos los proyectos — no solo en proyectos de Vercel.² El mecanismo de consentimiento usaba una inyección de prompt en lugar de UI nativa para obtener la aceptación del usuario.² La telemetría se activaba en cada evento coincidente a menos que el usuario configurara VERCEL_PLUGIN_TELEMETRY=off.²

Vercel atendió las preocupaciones de telemetría el 14 de abril, eliminando los coincidentes amplios y el mecanismo de consentimiento basado en prompt.²

El incidente de Vercel no es una vulnerabilidad en el sentido tradicional. Nadie está robando credenciales. Pero demuestra exactamente la clase de problema que la defensa en tiempo de ejecución aborda: un hook que se activa más ampliamente de lo que el usuario pretendía, recopilando datos que el usuario no consintió explícitamente compartir, a través de un mecanismo que elude la UI de consentimiento nativa.

Reemplaza “telemetría” por “exfiltración” y la arquitectura es idéntica. Un hook con un coincidente excesivamente amplio, ejecutándose en cada proyecto, enviando datos a un endpoint externo. La diferencia entre telemetría y ataque es la intención — y la intención no es auditable en tiempo de ejecución.

Del Artículo a la Práctica: Lo Que los Profesionales Ya Tienen

ClawGuard formaliza algo que los profesionales han estado construyendo de manera informal. Claude Code incluye un sistema de hooks que soporta intercepción PreToolUse y PostToolUse. Yo ejecuto más de 95 hooks que aplican restricciones de rutas de archivos, validan entradas de herramientas y condicionan operaciones destructivas a confirmación explícita.³

La brecha entre mis hooks y la visión de ClawGuard es la automatización. Mis hooks son reglas escritas a mano: bloquear direcciones IP internas en entradas de MCP, restringir escrituras de archivos a directorios del proyecto, requerir aprobación para git force-push. La configuración evaluada de ClawGuard usa reglas básicas de control de acceso similares en espíritu a los hooks escritos a mano. El componente propuesto de inducción de reglas específicas por tarea derivaría automáticamente restricciones a partir del objetivo declarado por el usuario¹ — en lugar de escribir “bloquear escrituras en /etc”, el framework inferiría que una tarea descrita como “refactorizar el módulo de login” no debería necesitar acceso de escritura a directorios del sistema. Ese componente sigue siendo trabajo futuro.

La derivación automática de restricciones es el problema más difícil — y el componente de inducción de reglas específicas por tarea de ClawGuard representa trabajo futuro, no resultados evaluados. La configuración de reglas básicas que los autores sí evaluaron mostró resultados sólidos pero no perfectos: AgentDojo alcanzó una tasa de éxito de ataque (ASR) del 0%, pero SkillInject aún registró entre 4,8-14% de ASR y MCPSafeBench mostró entre 7,1-11,0% de ASR dependiendo del modelo.¹ Las reglas escritas a mano son frágiles — cubren los ataques que anticipaste. Las restricciones derivadas podrían cubrir ataques que no anticipaste, porque operan sobre el conjunto positivo (lo que debería ocurrir) en lugar del conjunto negativo (lo que no debería ocurrir).

Si la derivación automática funciona de manera confiable en producción es una pregunta abierta. Los benchmarks son entornos controlados. Las sesiones reales de agentes involucran tareas ambiguas, cadenas de herramientas de múltiples pasos y llamadas a herramientas que parecen anómalas pero son legítimas. Los falsos positivos que bloquean llamadas válidas erosionarían rápidamente la afirmación de “sin comprometer la utilidad del agente”.

La Pila de Defensa por Capas

La defensa en tiempo de ejecución no es un mecanismo único. La pila práctica para agentes aumentados con herramientas tiene al menos cuatro capas:

Capa 1: Validación de entradas. Hooks que inspeccionan los argumentos de llamada a herramienta antes de la ejecución. Bloquear direcciones IP internas, validar rutas de archivos, rechazar metacaracteres de shell. Mis hooks PreToolUse operan en esta capa. Baja tasa de falsos positivos, pero solo detecta patrones conocidos como maliciosos.

Capa 2: Restricciones con alcance de tarea. Restringir el conjunto de herramientas permitidas y argumentos permitidos a lo que la tarea actual requiere. ClawGuard opera principalmente en esta capa.¹ Mayor cobertura que la validación de entradas por sí sola, pero requiere una comprensión precisa de la tarea.

Capa 3: Inspección de salidas. Hooks PostToolUse que examinan los resultados de las herramientas antes de que el agente los procese. Detecta exfiltración de datos, identifica respuestas anómalas, señala comportamiento inesperado de herramientas. El artículo sobre el intermediario documentó por qué la inspección de salidas importa — un enrutador comprometido modifica las respuestas después de la generación.

Capa 4: Auditoría de sesión. Registrar cada llamada a herramienta, cada argumento, cada resultado para revisión posterior. No es un mecanismo de prevención, sino de detección. Akshay Chugh descubrió el incidente de telemetría de Vercel precisamente a través de este tipo de auditoría — leyendo la configuración de hooks y rastreando qué hacían.²

Ninguna capa por sí sola es suficiente. La validación de entradas no detecta patrones novedosos. Las restricciones con alcance de tarea pueden ser demasiado restrictivas o demasiado permisivas. La inspección de salidas añade latencia. La auditoría de sesión detecta problemas después del daño. La pila funciona porque cada capa cubre las brechas que las demás dejan.

Lo Que ClawGuard Hace Bien

El artículo hace tres contribuciones que importan para los profesionales:

Determinismo sobre alineamiento. Enmarcar la defensa en tiempo de ejecución como un mecanismo determinista en lugar de una propiedad de alineamiento es el enfoque correcto. El alineamiento es una propiedad del tiempo de entrenamiento que se degrada bajo condiciones adversarias. La aplicación determinista es una propiedad del tiempo de ejecución que se mantiene independientemente del comportamiento del modelo. La distinción suena académica, pero cambia lo que puedes prometer sobre la postura de seguridad de tu sistema.

Aplicación agnóstica al canal. Defender contra inyección web, inyección de MCP e inyección de archivos de habilidades con un único punto de aplicación es arquitectónicamente sólido. Tres defensas separadas para tres canales de inyección crearían una carga de mantenimiento y dejarían brechas en las intersecciones. Un único punto de aplicación en el límite de llamada a herramienta cubre los tres canales por construcción.

Sin modificación del modelo requerida. No requerir ni fine-tuning ni modificación arquitectónica significa que la defensa funciona con cualquier modelo, incluidos modelos que no controlas. Un operador que ejecute Claude Code, Codex CLI o cualquier otro framework de agentes puede añadir defensa en tiempo de ejecución sin esperar a que el proveedor del modelo lance una actualización de seguridad.

Lo Que Queda Abierto

ClawGuard se probó en benchmarks. Las sesiones de agentes en producción son más desordenadas. Varias preguntas permanecen abiertas antes de que los profesionales puedan confiar en la derivación automática de restricciones:

Tareas ambiguas. “Ayúdame con este proyecto” no especifica qué herramientas o rutas están en alcance. Derivar restricciones a partir de objetivos vagos arriesga bloquear llamadas legítimas (demasiado restrictivo) o permitir llamadas peligrosas (demasiado permisivo).

Cadenas de múltiples pasos. Un agente que necesita leer un archivo de configuración, llamar a una API y escribir resultados en una base de datos tiene un patrón de acceso complejo. Las restricciones derivadas de la descripción inicial de la tarea pueden no anticipar pasos intermedios.

Descripciones de tareas adversarias. Si la derivación de restricciones depende del objetivo declarado por el usuario, un atacante que controle la descripción de la tarea (a través de un espacio de trabajo compartido, un rastreador de issues envenenado o un archivo de proyecto manipulado) puede influir en las restricciones mismas.

Costo de rendimiento. Evaluar restricciones en cada límite de llamada a herramienta añade latencia. El artículo afirma que el framework preserva la utilidad, pero no reporta mediciones de latencia.¹ Para sesiones interactivas de agentes, incluso 200ms por llamada a herramienta cambia la experiencia del usuario.

Conclusiones Operativas

Para profesionales que ejecutan agentes aumentados con herramientas hoy:

Despliega hooks PreToolUse ahora. No necesitas esperar a ClawGuard ni a ningún otro framework. El sistema de hooks de Claude Code soporta intercepción de llamadas a herramientas hoy. Comienza con validación de entradas — bloquea direcciones internas, restringe rutas de archivos, condiciona operaciones destructivas. El tutorial de hooks cubre la implementación.

Audita tus coincidentes de hooks. El incidente de Vercel ocurrió porque los coincidentes de cadena vacía se activaban en todos los proyectos.² Revisa cada hook en tu .claude/settings.json y verifica que cada coincidente apunte solo al contexto previsto. Un hook con un coincidente excesivamente amplio es una vulnerabilidad, no una defensa.

Registra cada llamada a herramienta. La auditoría de sesión es la capa de defensa de menor esfuerzo y mayor valor. Incluso si no puedes prevenir cada ataque, puedes detectarlo después del hecho — pero solo si tienes registros.

Evalúa ClawGuard contra tu pila. El código del artículo está disponible públicamente. Evalúa la configuración de reglas básicas contra tu pila de hooks existente. Si el componente de inducción de reglas específicas por tarea madura, la derivación automática de restricciones complementaría las reglas escritas a mano, no las reemplazaría.

Trata la configuración como un límite de confianza. Archivos de habilidades, configuración de hooks, definiciones de servidor MCP — cada archivo que influye en el comportamiento del agente es una superficie de ataque. Aplica los mismos controles de acceso que aplicarías a credenciales de producción.

El catálogo de vulnerabilidades de MCP documentó la superficie de ataque. ClawGuard propone una arquitectura de defensa. El incidente de Vercel demuestra por qué ambos importan. La defensa en tiempo de ejecución en el límite de llamada a herramienta es la capa aplicable — no porque el alineamiento no ayude, sino porque la aplicación no depende de él.

Fuentes

Preguntas Frecuentes

¿En qué se diferencia ClawGuard del sistema de permisos integrado de Claude Code?

El sistema de permisos de Claude Code solicita aprobación del usuario a nivel de herramienta — aprobar o denegar categorías específicas de herramientas. ClawGuard opera a nivel de argumento, derivando automáticamente restricciones sobre qué argumentos debería contener una llamada a herramienta según la tarea actual. Los dos mecanismos son complementarios: los permisos regulan qué herramientas pueden ejecutarse, las restricciones en tiempo de ejecución regulan cómo pueden llamarse esas herramientas.

¿Necesito esperar a que ClawGuard se lance antes de añadir defensa en tiempo de ejecución?

No. El sistema de hooks de Claude Code soporta intercepción PreToolUse y PostToolUse hoy. Los hooks escritos a mano que validan entradas de herramientas cubren los patrones de ataque más comunes de inmediato. La contribución de ClawGuard es la derivación automática de restricciones, que aumentaría las reglas manuales en lugar de reemplazarlas.

¿Fue el incidente de telemetría de Vercel una vulnerabilidad de seguridad?

La divulgación describió un problema de privacidad y consentimiento más que una vulnerabilidad tradicional. Al momento de la divulgación, el plugin recopilaba cadenas de comandos bash de todos los proyectos y las enviaba a un endpoint externo sin opt-in explícito a través de UI nativa. Vercel ha atendido desde entonces estas preocupaciones. El patrón arquitectónico — coincidentes amplios de hooks, transmisión externa de datos, consentimiento no nativo — sigue siendo instructivo porque refleja el mismo patrón que un hook malicioso usaría para exfiltración de datos.

¿Cuál es el impacto en rendimiento de la intercepción de llamadas a herramientas en tiempo de ejecución?

Para hooks escritos a mano que usan scripts de shell o validadores ligeros, la sobrecarga debería mantenerse por debajo de 200ms por llamada a herramienta según la guía de la documentación de hooks. El artículo de ClawGuard no reporta mediciones de latencia para su evaluación de restricciones, que podría añadir sobrecarga adicional. Para sesiones interactivas, la latencia por llamada a herramienta importa — prueba antes de desplegar lógica de validación compleja.