Qué significa la autorización de agentes
La autorización de agentes es la decisión sobre qué puede hacer un agente de IA: qué rutas puede llamar, qué datos puede leer, qué acciones puede realizar y en qué volumen. Es distinta de la identidad del agente, que consiste en establecer qué agente, o qué agente de un operador, está haciendo la solicitud.
Es fácil confundir ambas porque a menudo llegan juntas. Una solicitud firmada te dice quién la envió. No te dice si ese emisor debería poder cambiar una cuenta, hacer un pedido o exportar datos. La identidad es evidencia; la autorización es política. Nuestra publicación sobre qué prueban las solicitudes firmadas de agentes de IA, y qué no prueban desglosa la diferencia.
Por qué importa la distinción
Las aplicaciones ya separan la autenticación de la autorización para usuarios humanos: iniciar sesión prueba quién eres, y los roles y permisos deciden qué puedes hacer. Los agentes necesitan la misma separación, con una capa adicional de cuidado:
- La identidad puede ser sólida aunque no exista permiso. Un rastreador con una firma de mensaje HTTP perfectamente válida no tiene por sí mismo derecho a llamar a un endpoint de escritura.
- Puede existir permiso sin una identidad sólida. Un agente que usa la API key de un cliente está autorizado por esa clave, aunque nada identifique qué software de agente la está usando.
- Importa la persona detrás del agente. Cuando un agente actúa por alguien, la pregunta pasa a ser si esa persona le otorgó autoridad (ver autoridad delegada).
Reducir todo esto a una sola comprobación conduce a dos fallos: bloquear automatizaciones legítimas porque no tienen inicio de sesión humano, o confiar en un agente bien identificado para acciones que nunca debía realizar.
Cómo se expresa normalmente la autorización
La mayoría de las aplicaciones autorizan agentes con mecanismos que ya tienen:
- Credenciales y scopes. API keys o tokens de OAuth 2.0 con scopes limitados a lo que necesita la integración. Los servidores MCP usan el mismo modelo: la especificación de autorización de MCP trata a un servidor protegido como un resource server de OAuth 2.1.
- Política a nivel de ruta. Rutas de solo lectura abiertas a agentes conocidos; rutas de escritura que requieren una credencial vinculada a una cuenta.
- Niveles de riesgo. Acciones de bajo impacto permitidas ampliamente, acciones de alto impacto que requieren credenciales más sólidas, confirmación o revisión.
- Límites de tasa y cuotas por operador, por credencial o por ruta.
La evidencia de identidad del agente alimenta estas decisiones como una entrada más. Para un enfoque práctico, consulta cómo diseñar políticas a nivel de aplicación para humanos y agentes de IA. Te permite tratar de forma distinta a un operador verificado que a un cliente anónimo, pero el permiso en sí sigue viniendo de tu política.
Conceptos erróneos comunes
- "Agente verificado significa autorizado." La verificación atribuye una solicitud. Tu política sigue decidiendo qué puede hacer esa parte atribuida.
- "Hay que bloquear a los agentes salvo que se demuestre que son humanos." Muchos agentes son participantes legítimos. La mejor pregunta es qué puede hacer cada tipo de actor, ruta por ruta.
- "La autorización se puede inferir del comportamiento." El comportamiento puede aumentar o reducir la confianza sobre qué tipo de actor está presente. No debería conceder permiso por sí solo.
Cómo lo trata Proof of Actor
Proof of Actor responde a la pregunta de evidencia: qué tipo de actor está presente, sobre qué base (Verified, Declared, Inferred o Unknown), y qué se sabe y qué no se sabe. Deliberadamente no decide el permiso. Un resultado de Agent, incluso uno verificado, nunca implica autorización. En Route, tu aplicación combina el resultado del actor con sus propias credenciales, scopes y niveles de riesgo para permitir, adaptar, desafiar, revisar o limitar cada interacción, empezando en modo de observación para que puedas comprobar los resultados antes de aplicar nada.
Obtén más información sobre cómo encajan las decisiones en tu app, revisa los casos de uso de APIs y MCP servers, o solicita acceso anticipado.
Fuentes
- RFC 6749: The OAuth 2.0 Authorization Framework: tokens con scopes para clientes
- MCP specification 2026-07-28: Authorization: autorización basada en OAuth para MCP servers
- RFC 9421: HTTP Message Signatures: qué establece una solicitud firmada