Qué significa la autoridad delegada
La autoridad delegada es el permiso que una persona (o una organización) da a un agente de IA para actuar en su nombre. Cuando un asistente reserva una reunión en tu calendario, crea un ticket de soporte a tu nombre o recupera una factura del portal de un proveedor, está ejerciendo una autoridad que provino de ti.
Una buena delegación tiene tres propiedades: está acotada (el agente puede hacer algunas cosas, no todo), limitada en el tiempo (expira o puede revocarse) y atribuible (la aplicación que recibe la solicitud puede saber de quién se está ejerciendo la autoridad).
Por qué importa para las aplicaciones
Desde el punto de vista de una aplicación, una solicitud de un agente plantea hasta tres preguntas distintas:
- ¿Qué cliente envió esto? Eso es la identidad del agente, que las solicitudes firmadas pueden establecer (consulta HTTP Message Signatures).
- ¿Bajo la autoridad de quién está actuando? Eso es la delegación.
- ¿Esa autoridad es suficiente para esta acción? Eso es la autorización, decidida por la política de la propia aplicación.
Una solicitud firmada por un operador de asistentes conocido responde bien a la primera pregunta. Por sí sola, no dice nada sobre la segunda. El asistente puede estar actuando para uno de tus usuarios, para alguien que no es tu usuario o completamente por iniciativa propia. Tratar la identidad del cliente como prueba del consentimiento de una persona es uno de los errores más comunes en el diseño orientado a agentes. Consulta qué prueban, y qué no, las solicitudes firmadas de agentes de IA.
Cómo suele expresarse la delegación
- Concesiones al estilo OAuth. La persona inicia sesión en tu aplicación y concede a un agente un token con alcances limitados, tal como se define en OAuth 2.0 (RFC 6749). Entonces tu aplicación sabe exactamente qué autoridad lleva el token, y la concesión puede revocarse (RFC 7009).
- API keys vinculadas a una cuenta que un usuario crea para una integración concreta, idealmente con permisos reducidos.
- Confirmaciones dentro de la aplicación para acciones de alto impacto, en las que la persona aprueba una acción específica que el agente preparó.
- Reclamaciones de delegación a nivel de token. OAuth 2.0 Token Exchange (RFC 8693) define una reclamación
act(actor) que registra a una parte actuando en nombre de otra. El trabajo más reciente sobre cómo expresar la delegación de agentes en las solicitudes todavía está en desarrollo, y las aplicaciones deben verificar cualquier reclamación de delegación contra sus propios registros en lugar de aceptarla al pie de la letra.
Ideas erróneas comunes
- "Si el agente está verificado, el usuario lo aprobó." La verificación identifica al cliente. La aprobación tiene que venir de la persona, a través de un canal en el que tu aplicación confíe.
- "Un agente usando la sesión de mi usuario está bien." Puede serlo, pero la sesión se emitió para uso humano interactivo. Muchas aplicaciones prefieren una concesión dedicada y acotada para la automatización, para que las acciones sean atribuibles y revocables.
- "La delegación es todo o nada." Las delegaciones más seguras son estrechas: acceso de lectura amplio, acceso de escritura solo para acciones concretas y confirmación para cualquier cosa irreversible.
Cómo se relaciona Proof of Actor
Proof of Actor te ayuda a ver cuándo una interacción está impulsada por un agente o asistida por IA, y sobre qué base: Verified, Declared, Inferred o Unknown. Ese contexto te dice dónde surgen las preguntas de delegación, por ejemplo un autonomous agent actuando dentro de una sesión de cuenta humana. Proof of Actor no emite ni valida credenciales de delegación, y un resultado Agent nunca implica que una persona autorizó la acción. Las concesiones, los alcances y las confirmaciones de tu propia aplicación deciden eso, y Route te permite aplicar la política adecuada por ruta una vez que has observado tráfico real. Para patrones de política, consulta diseñar políticas a nivel de aplicación para humanos y agentes de IA.
Lee qué puede y qué no puede establecer la evidencia, o solicita acceso anticipado.
Fuentes
- RFC 6749: The OAuth 2.0 Authorization Framework: concesiones acotadas de un resource owner a un client
- RFC 7009: OAuth 2.0 Token Revocation: revocación de un token delegado
- RFC 8693: OAuth 2.0 Token Exchange: la reclamación
act(actor) para la delegación