🤖 AI

SecureClaw: Clawing Back Control of LLM Agents

SecureClaw es una arquitectura de seguridad de doble frontera para agentes de LLM que utilizan herramientas que evita acciones externas no autorizadas y la exposición de datos sensibles mediante la imposición de una pasarela de confianza para las operaciones de lectura y un protocolo PREVIEW-to-COMMIT para las operaciones de escritura, logrando tasas de éxito de ataque cercanas a cero en múltiples evaluaciones mientras mantiene la utilidad de las tareas.

Autores originales: Yuhan Ma, Stefan Schmid

Publicado 2026-06-09

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Yuhan Ma, Stefan Schmid

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que contratas a un asistente personal muy inteligente, pero poco fiable (el Agente LLM) para que se encargue de tus tareas sensibles, como pagar facturas, leer correos electrónicos privados o gestionar tu calendario.

El problema es que este asistente es un poco impredecible. Si le das un documento con tu número de cuenta bancaria, podría leerlo accidentalmente (o maliciosamente) en voz alta ante un extraño, o podría ser engañado por una nota oculta dentro de un correo electrónico para enviar tu dinero a un estafador.

Los guardias de seguridad actuales suelen intentar detener al asistente de hacer la mala acción (como enviar el dinero), pero a menudo fallan al evitar que el asistente vea el secreto en primer lugar. Una vez que el asistente ve el secreto, puede susurrarlo a otros programas o escribirlo en sus notas antes de que el guardia tenga siquiera la oportunidad de detenerlo.

SecureClaw es un nuevo sistema de seguridad diseñado para solucionar ambos problemas a la vez. Trata el "ver" y el "hacer" como dos trabajos separados que necesitan dos cerraduras diferentes.

Así es como funciona, utilizando una analogía sencilla:

Las Dos Cerraduras de SecureClaw

1. La "Venda" para Leer (El Gateway/Puerta de Enlace)

Imagina que tu asistente necesita mirar una factura secreta para saber cuánto pagar.

Forma Antigua: Le entregas al asistente la factura de papel real. Ellos pueden leer los números, copiarlos o incluso leerlos en voz alta a un hacker que esté escuchando.
Forma SecureClaw: No les entregas el papel. En su lugar, les das una caja misteriosa (un "mango opaco") y una nota pequeña y saneada (un "resumen acotado").
- La nota dice: "Factura de Proveedor A, $4,200, vence el viernes".
- La caja misteriosa es un código que solo la bóveda segura sabe cómo abrir.
- El asistente puede planificar su trabajo usando la nota y el código, pero no puede abrir la caja para ver los detalles reales de la factura. No puede copiar los números reales porque nunca los vio.

2. El "Doble Chequeo" para Hacer (El Ejecutor)

Ahora, imagina que el asistente quiere enviar un correo electrónico para pagar esa factura.

Forma Antigua: El asistente escribe el correo y pulsa "Enviar". Si un hacker engañó al asistente para cambiar la dirección de correo electrónico a la de un estafador, el dinero va al estafador.
Forma SecureClaw: El asistente solo puede proponer el correo electrónico. Escribe un borrador y dice: "Quiero enviar esto".
- Un Guardián de Confianza (el Ejecutor) toma el borrador.
- El Guardián comprueba: "¿Pediste enviar esto? ¿Es el destinatario correcto? ¿Es el monto correcto?"
- Crucialmente, el Guardiano coteja los detalles exactos contra un recibo sellado e inalterable de lo que fue aprobado originalmente.
- Si el asistente intentó cambiar sigilosamente la dirección de correo a la de un estafador después de recibir la aprobación, el Guardián detecta la discrepancia y bloquea el correo. Solo el Guardián tiene el poder de pulsar realmente "Enviar".

Por qué esto es algo importante

El artículo probó este sistema contra tres "parques de juegos de hacking" (AgentDojo, AgentLeak y ASB) donde los atacantes intentaron engañar a los agentes para robar datos o enviar dinero a la persona equivocada.

El Resultado: SecureClaw fue el único sistema que detuvo con éxito el 100% de las transferencias de dinero no autorizadas (0% de éxito del ataque) y redujo las filtraciones de datos secretos a casi cero.
El Ingrediente Secreto: El artículo demuestra que no basta con tener una sola cerradura.
- Si solo tienes el "Doble Chequeo" (detener el envío), el asistente aún puede leer el secreto y filtrarlo a través de sus notas internas.
- Si solo tienes la "Venda" (ocultar el secreto), el asistente podría ser engañado para enviar un mensaje a la persona equivocada si no tiene el secreto en primer lugar.
- SecureClaw usa ambos. Mantiene los secretos ocultos del asistente y además asegura que el asistente no pueda forzar una acción sin un chequeo final de confianza.

¿Qué pasa cuando dice "No"?

A veces, el sistema bloquea una solicitud porque parece sospechosa. En el pasado, esto podría haber detenido todo el flujo de trabajo, frustrando al usuario. SecureClaw tiene una función de "Recuperación Segura".

Si el Guardián bloquea una solicitud, en lugar de simplemente decir "Error", le da al asistente un camino seguro y pre-aprobado para intentar de nuevo.

Ejemplo: "No puedo enviar ese correo a ese extraño. Pero puedo redactar un mensaje para que tú lo revises primero".
Esto mantiene el trabajo en marcha sin bajar los estándares de seguridad.

La Conclusión

SecureClaw es como contratar a un guardaespaldas que lleva una venda en los ojos cuando lee tu diario (para que no memorice tus secretos) y que sostiene las llaves de tu coche (para que no pueda conducirte a un lugar peligroso sin revisar el mapa primero). Separa la capacidad de planificar de la capacidad de actuar, asegurando que, incluso si el asistente es engañado, el daño esté contenido.

Resumen Técnico: SecureClaw

Declaración del Problema

Los agentes de Modelos de Lenguaje de Gran Escala (LLM) que utilizan herramientas enfrentan dos modos de falla de seguridad distintos y no intercambiables que las defensas existentes a menudo no logran abordar simultáneamente:

Efectos Externos No Autorizados: El riesgo de que un agente, potencialmente comprometido por inyección de prompts o comportamiento adversario en tiempo de ejecución, ejecute acciones (por ejemplo, enviar correos electrónicos, transferir fondos) que no fueron autorizadas para el contexto, la sesión o el llamador específico.
Exposición de Texto Plano en Tiempo de Ejecución: El riesgo de que datos sensibles (por ejemplo, facturas, registros médicos) se expongan al entorno de ejecución (runtime) no confiable en texto plano. Incluso si una acción posterior es bloqueada, el runtime puede haber "leído" ya el secreto y puede transmitirlo a través de canales internos (mensajes entre agentes, memoria compartida, registros) que los mecanismos de auditoría de solo salida pasan por alto.

Las defensas actuales suelen proteger solo un límite: ya sea el planificador/runtime (mediante filtrado de prompts) o el sumidero de la acción (mediante verificación de argumentos). El artículo argumenta que proteger el sumidero no evita la fuga interna si el runtime ya ha accedido a los secretos brutos, y proteger el runtime no evita los commits no autorizados si el sumidero no está mediado.

Metodología: Arquitectura SecureClaw

SecureClaw introduce una arquitectura de doble límite que separa el control de los efectos externos del acceso a la información sensible en texto plano. Se basa en una infraestructura de confianza (Gateway, Almacén de Handles, Motor de Políticas, Ejecutor) distinta del entorno de ejecución no confiable del agente.

1. Ruta de Lectura: Confinamiento de Handles Opacos

Mecanismo: Cuando el runtime solicita datos sensibles, un Gateway de Confianza intercepta la lectura. En lugar de devolver el texto plano bruto, el gateway almacena los datos en un Almacén de Handles de Confianza y devuelve un handle opaco (una referencia simbólica de alta entropía) al runtime.
Desclasificación: Si el agente requiere información relevante para la tarea para planificar, el gateway proporciona un resumen acotado (por ejemplo, "factura de Proveedor A, $4.2k"). Este resumen se trata como una interfaz de desclasificación explícita, no como una fuga de texto plano.
Restricción: El runtime puede enrutar y almacenar handles, pero no puede desreferenciarlos para recuperar los secretos brutos. Los canales internos (C2, C5) transportan referencias simbólicas, no secretos.

2. Ruta de Escritura: Protocolo PREVIEW→COMMIT

Mecanismo: El runtime propone una acción con efecto (intención + entradas). Un Gateway de Confianza añade contexto autenticado (llamador, sesión, campos del sumidero) y canonicaliza la solicitud en un digest de vinculación ( $h$ ).
Autorización: Un Motor de Políticas autoriza la solicitud canónica exacta y devuelve un artefacto de autorización vinculado a $h$ .
Ejecución: Un Ejecutor de Confianza es el único componente capaz de alcanzar el sumidero externo. Antes de realizar el commit, este:
1. Recomputa el digest de vinculación $h$ .
2. Verifica el artefacto de autorización.
3. Comprueba la frescura, el estado de replay y la resolución del handle.
4. Realiza el commit solo si la solicitud coincide exactamente con la forma canónica autorizada.
Integridad: Cualquier mutación de la solicitud (por ejemplo, cambiar un destinatario) después del preview altera la forma canónica, invalidando el artefacto de autorización y provocando que el ejecutor falle de forma segura (fail-closed).

3. Recuperación Consciente de la Denegación

Para mantener la utilidad cuando las acciones son bloqueadas, el sistema emplea un mecanismo de recuperación consciente de la denegación. En lugar de terminar el flujo de trabajo, el sistema devuelve una denegación estructurada con una razón general y una pista de siguiente paso segura (por ejemplo, "borrador para confirmación" en lugar de "enviar"), preservando la continuidad del flujo de trabajo sin relajar los invariantes de seguridad.

Contribuciones Clave

Descomposición de Seguridad: El artículo identifica dos requisitos de seguridad no sustituibles para los agentes que usan herramientas: la autorización vinculada a la solicitud de efectos externos y el confinamiento del texto plano sensible fuera del runtime no confiable.
Arquitectura de Doble Límite: SecureClaw implementa estos requisitos mediante un gateway de confianza (para el confinamiento de lectura) y un ejecutor de confianza (para la autorización de escritura), utilizando handles opacos y desclasificación explícita.
Evaluación de Harness Común: Los autores evalúan SecureClaw contra cuatro líneas base (Plain, IPIGuard, DRIFT, Faramesh) a través de tres benchmarks (AgentDojo, AgentLeak, ASB) utilizando un harness de comparación igualado para asegurar una comparación justa.

Resultados Experimentales

Evaluado en gpt-4o-mini con temperatura 0:

Agent Security Bench (ASB): SecureClaw logró una Tasa de Éxito de Ataque (ASR) del 0%, superando significativamente a las líneas base (por ejemplo, DRIF con un 87.75% de ASR). Mantuvo una utilidad del 88.90% en tareas benignas.
AgentDojo: Logró un 0.64% de ASR (4/629 ataques), comparado con el 2.38% de la siguiente mejor línea base (DRIFT).
AgentLeak: Logró una fuga total del 3.23% en el carril de paridad atacado. Crucialmente, redujo las fugas de retransmisión interna (C2 y C5) a casi cero (0.20% y 0.00% respectivamente), mientras que las líneas base como Faramesh (que carece de confinamiento de lectura) mostraron una alta fuga interna (92.74% en C2).
Estudios de Ablación: Eliminar el mecanismo de handles causó que la fuga de C2/C5 reapareciera, mientras que eliminar el límite de ejecución no afectó la fuga interna pero no detuvo los commits no autorizados. Esto confirma que los dos mecanismos protegen superficies distintas.
Robustez: En un conjunto de pruebas de bypass de 29 escenarios adversarios (manipulación de artefactos, replay, mezcla de sesiones), SecureClaw denegó los 25 intentos de ataque mientras permitía 4 controles legítimos.
Sobrecarga (Overhead): La verificación del ejecutor es de sub-milisegundo; la autorización de servicio único añade ~15ms. Estos costos son insignificantes en comparación con las latencias de inferencia de los LLM (500–2000ms).

Significado y Reivindicaciones

El artículo sostiene que asegurar los agentes de LLM requiere una separación estructural en lugar de defensas locales en el runtime.

No Sustituibilidad: La evaluación demuestra que la autorización en el lado del sumidero y el confinamiento en el lado de la lectura son complementarios; la autorización de un commit bloqueado no puede deshacer un secreto que ya fue transmitido a través de la memoria, y un handle no puede evitar que un runtime comprometido intente acciones no autorizadas.
Modelo de Confianza: SecureClaw traslada la confianza del runtime no confiable a un conjunto mínimo de componentes de confianza (Gateway, Almacén de Handles, Motor de Políticas, Ejecutor). No pretende garantizar la corrección semántica de las acciones permitidas por la política (por ejemplo, si una política es demasiado laxa, el agente aún podría actuar sobre el objeto incorrecto), ni sobrevive al compromiso de sus propios componentes de confianza.
Residuales: Los fallos restantes se concentran en el plano de desclasificación (resúmenes autorizados que revelan información) o en la desalineación de la política (acciones autorizadas que son semánticamente erróneas para la intención del usuario), más que en bypasses de los invariantes de seguridad centrales.

Los autores concluyen que SecureClaw es el único sistema evaluado en su estudio que simultáneamente lleva los efectos externos no autorizados a cero/casi cero y elimina la retransmisión de texto plano interno, manteniendo al mismo tiempo una alta utilidad de la tarea mediante la recuperación consciente de la denegación.