SUDP: dejar que un agente actúe con tus credenciales sin llegar a poseerlas

¿Qué es esto?

En mayo de 2026, investigadores del Imperial College London, Oxford y Stanford publicaron SUDP: Secret-Use Delegation Protocol for Agentic Systems (preprint de arXiv, versión v2 fechada el 1 de mayo de 2026). No es un ataque. Es un intento de resolver una de las piezas menos atendidas de la seguridad de los agentes: qué ocurre con las claves de API, los tokens OAuth y las claves de firma que un agente necesita para actuar de verdad.

El planteamiento de los autores es directo. La práctica de ingeniería actual es la autorización por exposición: para que un agente envíe un mensaje, suba código o llame a una API de pago, se coloca un secreto reutilizable —o algo derivado de él— dentro del runtime del agente. Pero ese runtime es justamente la frontera que puede alcanzar la entrada no confiable. Así, una inyección de prompt pasajera o una herramienta comprometida deja de ser una acción puntual y se convierte en un compromiso duradero de la cuenta, porque el atacante queda junto a una credencial reutilizable.

Cómo funciona

SUDP empieza por nombrar el problema subyacente como una abstracción clara que los autores llaman Agent Secret Use (ASU): un solicitante autónomo no confiable debe poder provocar una operación autorizada por el usuario y respaldada por un secreto, sin quedar jamás expuesto a una autoridad reutilizable sobre ese secreto. Las interfaces de token portador clásicas no pueden satisfacer ambas mitades: entregar la clave al agente funciona pero se filtra; retenerla hace que el servicio rechace la llamada.

El protocolo resuelve la tensión repartiendo el trabajo entre tres roles. El Solicitante es el runtime del agente: propone una operación concreta y canonizada, y no guarda ningún secreto. El Autorizador es el usuario con un autenticador de hardware (WebAuthn / FIDO): revisa la operación exacta propuesta y emite una concesión firmada, fresca, ligada criptográficamente a un hash de esa operación, de un solo uso, que designa la credencial habilitada para actuar. El Custodio guarda el secreto sellado, canjea la concesión exactamente una vez para realizar la acción acotada contra el servicio externo y luego borra la clave de la memoria. Solo el resultado regresa al agente.

La consecuencia es el objetivo mismo del diseño: la autoridad reutilizable nunca cruza la frontera del solicitante. Como cada ejecución está cubierta por una concesión fresca, firmada por el usuario y ligada a una sola operación canónica, propiedades como la resistencia a la sustitución, la vinculación a la operación y la resistencia a la repetición se cumplen por construcción, no por una revisión cuidadosa del código. Incluso un agente totalmente comprometido por inyección solo puede, como mucho, proponer una operación que el usuario aún debe presenciar y aprobar; nunca obtener una credencial reutilizable en otro lugar o más adelante.

Por qué importa

Este protocolo apunta directamente a la rama de “acceso a datos privados” de la conocida lethal trifecta, y en una capa donde la mayoría de las mitigaciones actuales no operan. Los separadores instrucción/datos, los motores de política por herramienta, los sandboxes y las barreras razonan sobre qué hace el agente o dónde lo hace; SUDP, en cambio, restringe para qué puede usarse un secreto, en la frontera donde vive ese secreto. Ambos enfoques se componen: una barrera de comportamiento que falla aún deja al atacante acotado por el alcance de la operación firmada por el usuario.

Los límites se enuncian con honestidad en el artículo. SUDP ofrece confidencialidad de almacenamiento y aislamiento de épocas de clave bajo supuestos explícitos de sellado y borrado, pero el forward secrecy del secreto subyacente sigue requiriendo que el entorno lo rote y lo revoque. También asume que el servicio externo acepta la llamada mediada por el custodio y que el usuario lee realmente la operación que aprueba: un descriptor de operación canonizado y legible por humanos cumple aquí un papel esencial.

Defensas

Las lecciones prácticas van más allá de este único protocolo. Trata “el agente guarda la clave de API” como un defecto de diseño, no como una comodidad: cualquier credencial reutilizable dentro de un runtime dirigible por el modelo está a una inyección de un compromiso duradero. Prefiere la autorización por operación frente a la credencial por sesión: liga la aprobación a una acción concreta y canónica en lugar de conceder al agente autoridad permanente para toda una tarea. Mantén los secretos tras un mediador (un custodio o un proxy de credenciales) que los consuma internamente y solo devuelva resultados, de modo que el agente proponga pero nunca posea. Ancla la aprobación humana en un autenticador resistente al phishing y haz que la operación aprobada sea legible para quien la firma. Y sigue rotando y revocando los secretos subyacentes: la mediación limita el radio de impacto, pero el forward secrecy de la credencial real depende de que el entorno la retire.

Estado

Aspecto	Detalle
Divulgación	Preprint de arXiv (2604.24920), v2 fechada el 1 de mayo de 2026
Autores	Xiaohang Yu, Hejia Geng, Xinmeng Zeng, William Knottenbelt (Imperial College London, Oxford, Stanford)
Clase	Investigación defensiva — protocolo de autorización para el uso de secretos por agentes
Método	Formalización del problema “Agent Secret Use”; protocolo de tres roles (Solicitante / Autorizador / Custodio); concesiones frescas de un solo uso ligadas a una operación canónica
Garantías	Autorización verificable, ligada a la operación y de un solo uso; confidencialidad de almacenamiento y aislamiento de épocas de clave bajo supuestos explícitos
Límites declarados	El forward secrecy en claro sigue requiriendo rotación/revocación del lado del entorno; asume que el servicio acepta la llamada mediada y que el usuario revisa la operación
Explotado en la práctica	No aplica — propuesta de protocolo defensivo