AAP: OAuth 2.0 para la era de los agentes de IA

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:

{
  "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; 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 y con la orquestación de subagentes, donde la delegación controlada importa de verdad.

Recursos

• Especificación y ejemplos: aap-protocol.org
• Código, JSON schemas, test vectors y reference implementation: 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 y en el repositorio github.com/aapspec, que incluye el schema, test vectors y una implementación de referencia.