--- title: "AAP: OAuth 2.0 para la era de los agentes de IA" excerpt: "OAuth no fue diseñado para agentes autónomos. AAP es la extensión que mete capacidades con límites, binding a tarea, cadena de delegación y aprobación humana dentro del propio token." date: "2026-07-02T12:00:00.000Z" category: "Inteligencia Artificial" tech_article: true author: name: "angel cruz" picture: "https://angelcruzdevcdn.nyc3.cdn.digitaloceanspaces.com/images/me/angel-cruz.png" ogImage: url: "/images/open-graph/aap-protocol-opengraph-image.png" seo_title: "AAP: autorización OAuth 2.0 para agentes de IA" seo_description: "AAP (Agent Authorization Profile) extiende OAuth 2.0 para agentes de IA: capacidades con límites, binding a tarea, cadena de delegación y aprobación humana en el token." --- **AAP (Agent Authorization Profile) es una extensión abierta de OAuth 2.0 pensada para agentes de IA autónomos.** Mete dentro del propio token JWT lo que OAuth no sabe expresar: capacidades con límites (dominios, rate limits, ventanas de tiempo), binding a una tarea concreta, la cadena de delegación y qué acciones exigen aprobación humana. Lo diseñé porque, trabajando con agentes, choqué una y otra vez con el mismo muro: **OAuth no fue pensado para que un programa actúe solo en tu nombre.** ## El problema: OAuth no fue diseñado para agentes autónomos OAuth 2.0 asume un humano detrás dando consentimiento a scopes amplios. Un agente autónomo rompe ese modelo, y aparecen seis huecos: - **Scopes demasiado amplios**: `read:web` no sabe decir "busca solo en estos dominios". - **Sin intención**: el token no dice para qué tarea es, así que no hay forma de evitar el *purpose drift*. - **Delegación opaca**: cuando un agente llama a otro que llama a otro, se pierde quién hizo realmente qué. - **Auditoría débil**: cuesta trazar una acción hasta un agente y una tarea concretos (un problema serio en sectores regulados). - **Sin contexto**: los permisos no tienen límites de tiempo ni de dominio, así que una acción técnicamente válida puede ser catastrófica. - **Rate limiting a mano**: los límites por agente terminan en middleware frágil, fuera de OAuth. ## Qué es AAP: cinco claims con dientes AAP resuelve esto con cinco claims estructuradas dentro del JWT: - **`agent`**: identidad explícita del agente (id, tipo, operador, modelo, runtime). Sabes exactamente qué agente hizo qué. - **`capabilities`**: acciones permitidas con **constraints aplicables del lado del servidor** (dominios permitidos, requests por hora, ventanas de tiempo). Capacidades con límites, no scopes vagos. - **`task`**: ata el token a una tarea concreta (id, propósito, sensibilidad de los datos). Evita el purpose drift. - **`delegation`**: la cadena de delegación con profundidad actual y máxima. Nada de re-delegación sin control. - **`oversight`**: qué acciones requieren aprobación humana y por qué canal. ## Un token AAP de ejemplo Todo vive en un JWT estándar. Un agente investigador que puede buscar en dos dominios, máximo 50 requests/hora, y que necesita aprobación humana para publicar: ```json { "iss": "https://as.example.com", "sub": "spiffe://example.com/agent/researcher-01", "aud": ["https://api.example.com"], "agent": { "id": "agent-researcher-01", "type": "llm-autonomous", "operator": "org:blogcorp" }, "task": { "id": "task-123", "purpose": "research_and_draft_article", "data_sensitivity": "public" }, "capabilities": [ { "action": "search.web", "constraints": { "domains_allowed": ["example.org", "wikipedia.org"], "max_requests_per_hour": 50 } } ], "oversight": { "requires_human_approval_for": ["cms.publish"] }, "delegation": { "depth": 0, "max_depth": 2 } } ``` ## No reemplaza a OAuth, lo extiende Esto es lo importante y lo que lo hace adoptable: **AAP no es un protocolo nuevo que te obligue a migrar.** Es un perfil sobre estándares que ya usas: - **OAuth 2.0** como framework de autorización. - **JWT (RFC 7519)** como formato del token. - **Token Exchange (RFC 8693)** para la delegación. - **DPoP (RFC 9449)** para proof-of-possession. Funciona con cualquier Authorization Server que soporte claims personalizadas, los tokens AAP conviven con los scopes tradicionales (adopción incremental, no big bang) y es neutral respecto a la identidad (OIDC para humanos, SPIFFE para workloads, o lo que uses). ## Por qué lo construí Los agentes de IA ya no solo responden: **actúan**. Y cuando algo actúa solo con tus credenciales, la pregunta deja de ser "¿tiene permiso?" y pasa a ser "¿tiene permiso para *esta* tarea, con *estos* límites, y quién responde si se pasa?". MCP resolvió cómo darle [herramientas a un agente](/post/introduccion-a-mcp-model-context-protocol); AAP intenta resolver cómo autorizarlo sin darle las llaves de todo. Encaja con el resto del ecosistema que cubro en la [guía de Claude Code](/post/guia-claude-code) y con la orquestación de [subagentes](/post/subagentes-claude-code), donde la delegación controlada importa de verdad. ## Recursos - Especificación y ejemplos: [aap-protocol.org](https://www.aap-protocol.org/) - Código, JSON schemas, test vectors y reference implementation: [github.com/aapspec](https://github.com/aapspec) ## Preguntas frecuentes ### ¿Qué es AAP? Agent Authorization Profile: una extensión abierta de OAuth 2.0 para agentes de IA autónomos. Añade al token JWT capacidades con límites, binding a tarea, cadena de delegación y requisitos de aprobación humana. ### ¿AAP reemplaza a OAuth 2.0? No. Es una extensión construida sobre OAuth 2.0, JWT (RFC 7519), Token Exchange (RFC 8693) y DPoP (RFC 9449). Los tokens AAP conviven con los scopes tradicionales, así que la adopción es incremental. ### ¿En qué se diferencia de MCP? Son complementarios: MCP define cómo un agente accede a herramientas y datos; AAP define cómo se **autoriza** a ese agente (qué puede hacer, con qué límites, en qué tarea y con qué supervisión). ### ¿Dónde veo la especificación? En [aap-protocol.org](https://www.aap-protocol.org/) y en el repositorio [github.com/aapspec](https://github.com/aapspec), que incluye el schema, test vectors y una implementación de referencia. --- ## Sitemap Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md) Canónico HTML: [https://www.angelcruz.dev/post/aap-oauth-agentes-de-ia](https://www.angelcruz.dev/post/aap-oauth-agentes-de-ia)