Defensa en tiempo de ejecución para agentes con herramientas

Hace una semana publiqué 50 vulnerabilidades de MCP que abarcan SSRF, envenenamiento de herramientas y patrones de evasión de confianza. La conclusión implícita era sombría: 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 herramientas.¹ En su configuración evaluada, el framework aplica reglas básicas de control de acceso (bloqueo de acceso no autorizado a archivos, prevención de exfiltración de credenciales, restricción de llamadas de red) antes de cualquier invocación de herramienta externa. Sin modificación del modelo. Sin cambios de infraestructura. Sin fine-tuning específico de seguridad.¹ Los autores evaluaron usando AgentDojo, SkillInject y MCPSafeBench con cinco LLMs de frontera.¹ El artículo también describe un componente de inducción de reglas específicas por tarea que derivaría restricciones automáticamente a partir del objetivo declarado por el usuario, pero los autores no lo incluyeron en 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 adversariales. (Algunas vulnerabilidades, incluyendo SSRF, RCE y traversal de rutas, explotan fallas del lado del servidor que no dependen del seguimiento de instrucciones del modelo, pero el límite de llamada a herramientas sigue siendo relevante para la defensa.)

El entrenamiento de alineamiento ayuda. RLHF hace que los modelos tengan más probabilidad de rechazar solicitudes dañinas. Pero “más probabilidad” 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 entendió 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 con herramientas:¹

Inyección de contenido web y local. El agente lee una página web o archivo local que contiene instrucciones adversariales. Las instrucciones dirigen al agente a llamar herramientas de formas que el usuario no pretendía. La superficie de ataque de egreso silencioso es una instancia de este patrón, con 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 en las respuestas. 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. Un atacante coloca instrucciones adversariales en archivos de habilidades y configuración que el agente carga como contexto de confianza. El agente trata el contenido de los archivos de habilidades como autoritativo, por lo que 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 herramientas, el punto único por donde toda acción externa debe pasar independientemente de qué canal inyectó la instrucción.¹ Antes de que el agente invoque cualquier herramienta, ClawGuard verifica la llamada contra su conjunto de reglas. En la configuración evaluada, esas reglas son restricciones básicas de control de acceso (restricciones de rutas de archivos, listas blancas de llamadas de red, bloqueos de acceso a credenciales). ClawGuard bloquea cualquier llamada que caiga fuera de esas restricciones, sin importar cuán convincente sea el prompt de inyección.

La perspectiva arquitectónica merece ser expresada 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 la publicación del artículo de ClawGuard, Akshay Chugh publicó una divulgación sobre el Plugin de Vercel para Claude Code el 9 de abril.² Los hallazgos en el 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 utilizaba una inyección de prompt en lugar de UI nativa para obtener el acuerdo del usuario.² La telemetría se activaba en cada evento coincidente a menos que el usuario configurara VERCEL_PLUGIN_TELEMETRY=off.²

Vercel abordó las preocupaciones de telemetría el 14 de abril, eliminando las coincidencias amplias 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ó compartir explícitamente, a través de un mecanismo que elude la UI nativa de consentimiento.

Reemplaza “telemetría” por “exfiltración” y la arquitectura es idéntica. Un hook con un matcher 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 force-push en git. 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 restricciones automáticamente 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ó 0% de tasa de éxito de ataques (ASR), pero SkillInject aún registró 4,8-14% de ASR y MCPSafeBench mostró 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).

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 con herramientas tiene al menos cuatro capas:

Capa 1: Validación de entrada. Hooks que inspeccionan los argumentos de llamadas a herramientas 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: Aplicación de reglas básicas. Restringir el conjunto de herramientas permitidas y argumentos permitidos basándose en reglas de control de acceso (restricciones de rutas, listas blancas de red, protecciones de credenciales). La configuración evaluada de ClawGuard opera en esta capa.¹ El artículo también propone la derivación de restricciones con alcance de tarea, que se ubicaría entre esta capa y la siguiente, pero ese componente sigue siendo trabajo futuro. Mayor cobertura que la validación de entrada sola, pero las reglas deben mantenerse a medida que el entorno cambia.

Capa 3: Inspección de salida. 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 salida importa: un router 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 a través de exactamente este tipo de auditoría: leyendo la configuración de hooks y rastreando lo que los hooks hacían.²

Ninguna capa individual es suficiente. La validación de entrada no detecta patrones novedosos. Las restricciones con alcance de tarea pueden ser demasiado restrictivas o demasiado permisivas. La inspección de salida 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 otras 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 de tiempo de entrenamiento que se degrada bajo condiciones adversariales. La aplicación determinista es una propiedad de 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. Defenderse 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 herramientas 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, incluyendo modelos que no controlas. Un operador ejecutando 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 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 dentro del alcance. Derivar restricciones de objetivos vagos arriesga bloquear llamadas legítimas (demasiado restrictivo) o permitir las 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 los pasos intermedios.

Descripciones de tareas adversariales. 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 ejecutando agentes 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 entrada: bloquear direcciones internas, restringir rutas de archivos, condicionar operaciones destructivas. El tutorial de hooks cubre la implementación.

Audita tus matchers de hooks. El incidente de Vercel ocurrió porque los matchers de cadena vacía se activaban en todos los proyectos.² Revisa cada hook en tu .claude/settings.json y verifica que cada matcher apunte solo al contexto previsto. Un hook con un matcher excesivamente amplio es una responsabilidad, 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 artículo enlaza un repositorio, aunque los autores aún no habían publicado código al momento de escribir. Cuando esté disponible, 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 servidores 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 herramientas 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 soporta tanto aprobación a nivel de herramienta (aprobar o denegar categorías de herramientas) como especificadores a nivel de argumento (por ejemplo, Bash(git diff *) para permitir solo comandos que coincidan). La configuración evaluada de ClawGuard aplica reglas básicas de control de acceso a nivel de argumento. Su componente propuesto de inducción de reglas específicas por tarea derivaría automáticamente restricciones de argumentos a partir de la tarea actual, pero los autores no evaluaron ese componente. Los dos sistemas se complementan: los permisos de Claude Code controlan qué herramientas y patrones de argumentos pueden ejecutarse, mientras que las restricciones en tiempo de ejecución al estilo de ClawGuard añaden una segunda capa de aplicación.

¿Necesito esperar a que ClawGuard esté disponible 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. En el 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 abordado estas preocupaciones desde entonces. El patrón arquitectónico (matchers de hooks amplios, transmisión de datos externos, 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 en mi experiencia operativa. 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, así que prueba antes de desplegar lógica de validación compleja.