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 extension borrosa de alguien: usa tokens de un usuario, credenciales compartidas, permisos heredados y logs que no distinguen si una accion fue humana, automatica o delegada.
Sin identidad propia, el agente se convierte en una cuenta fantasma. Puede producir valor, pero tambien 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, proposito, herramientas autorizadas, permisos, limites, caducidad, historial de ejecucion y mecanismo de revocacion.
La pregunta ya no es “que modelo usa”. La pregunta es “quien es este agente dentro de mi organizacion”.
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 condicion de expiracion.
- Traza: historial de tool calls, decisiones y outcomes.
- Revocacion: 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 delegacion, accion y responsabilidad.
Senal medible: porcentaje de agentes activos con owner, scope, permisos propios y fecha de revision.
Postura: un agente sin identidad no deberia tener permisos persistentes.
Por que importa ahora
MCP ya trata autorizacion 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 practica de agentes, insiste en guardrails, supervision humana y salvaguardas para herramientas.
La direccion 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 produccion. No sabes que permisos necesita realmente, quien los aprobo, que accion 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 minima. Owner, proposito, herramientas, permisos, logs y fecha de revision.
- 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 produccion
- MCP en empresa: el estandar que evita el caos de agentes
Fuentes consultadas
- MCP Authorization specification
- A2A protocol specification
- OpenAI: A practical guide to building agents
Proximo 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.