Problema
Los equipos ya no solo conectan personas a software. Conectan agentes a herramientas, datos, calendarios, CRMs, repositorios, bases de datos, navegadores y sistemas internos.
El riesgo aparece cuando el agente actua como una extensión borrosa de alguien: usa tokens de un usuario, credenciales compartidas, permisos heredados y logs que no distinguen si una acción fue humana, automática o delegada.
Sin identidad propia, el agente se convierte en una cuenta fantasma. Puede producir valor, pero también puede dejar una empresa sin trazabilidad real.
Tesis
Agent Identity sera una capa de infraestructura, no un detalle de seguridad.
Cada agente serio necesita un pasaporte operativo: identidad, owner, propósito, herramientas autorizadas, permisos, limites, caducidad, historial de ejecución y mecanismo de revocación.
La pregunta ya no es “que modelo usa”. La pregunta es “quien es este agente dentro de mi organización”.
Framework
Un pasaporte de agente debe incluir siete campos:
- Owner: persona o equipo responsable.
- Mandato: tarea para la que existe.
- Scope: sistemas, datos y acciones permitidas.
- Credenciales: tokens propios, no claves compartidas.
- Caducidad: fecha o condición de expiración.
- Traza: historial de tool calls, decisiones y outcomes.
- Revocación: forma simple de apagar permisos.
Mini-caso: un agente de finanzas reconcilia facturas. Si actua con la cuenta de una persona, cualquier error parece humano. Si tiene identidad propia, permisos limitados y caducidad mensual, la auditoria puede distinguir delegación, acción y responsabilidad.
Señal medible: porcentaje de agentes activos con owner, scope, permisos propios y fecha de revisión.
Postura: un agente sin identidad no debería tener permisos persistentes.
Por que importa ahora
MCP ya trata autorización como parte formal del protocolo, apoyandose en OAuth 2.1 para separar clientes, servidores de recursos y flujos de consentimiento. A2A empuja una idea complementaria: agentes que se descubren, describen capacidades y colaboran mediante contratos visibles. OpenAI, en su guia práctica de agentes, insiste en guardrails, supervisión humana y salvaguardas para herramientas.
La dirección es clara: los agentes dejan de ser “sesiones de chat” y empiezan a parecer entidades operativas.
Eso exige identidad. No identidad filosofica. Identidad administrativa.
Anti-ejemplo
“El agente usa la API key del equipo de operaciones.”
Funciona para una demo. Falla para producción. No sabes que permisos necesita realmente, quien los aprobo, que acción corresponde al agente y como revocar sin romper a todo el equipo.
Protocolo (3 pasos)
- Inventaria agentes activos. Incluye scripts, GPTs, workflows, MCP clients, copilotos y automatizaciones con LLM.
- Asigna identidad mínima. Owner, propósito, herramientas, permisos, logs y fecha de revisión.
- Elimina credenciales compartidas. Si no puedes hacerlo de golpe, empieza por agentes con side effects.
| Campo | Pregunta | Riesgo si falta |
|---|---|---|
| owner | quien responde | nadie corrige |
| mandato | para que existe | scope creep |
| credencial | como accede | auditoria borrosa |
| caducidad | cuando se revisa | permisos zombies |
| traza | que hizo | incidente inexplicable |
Relacionado
- Tool Registry: el nuevo mapa de riesgos de los agentes enterprise
- Output Verification Layer: el seguro invisible de los agentes en producción
- MCP en empresa: el estándar que evita el caos de agentes
Fuentes consultadas
- MCP Authorization specification
- A2A protocol specification
- OpenAI: A practical guide to building agents
Próximo paso
Elige tres agentes que ya usen herramientas reales. Crea su pasaporte operativo en una tabla y marca en rojo cualquier permiso sin owner, caducidad o traza.