Sin identidad, la autonomía no es auditable
Cuando varios agentes comparten una clave de servicio, los registros muestran una credencial, no al actor real. No puedes demostrar qué agente actuó, quién lo autorizó ni si el permiso seguía vigente. El problema aparece al investigar un incidente, pero nace en el diseño.
NIST publicó en 2026 un documento conceptual sobre identidad y autorización para agentes de software e IA. No es un estándar terminado. Sí organiza preguntas que todo despliegue debe resolver: identificación, autenticación, autorización, delegación, auditoría, ciclo de claves y resistencia a inyección.
La práctica empieza separando cuatro objetos: persona u organización que delega, identidad del agente, credencial temporal y acción sobre una herramienta.
Construye una cadena de autoridad verificable
La persona se autentica y solicita un objetivo. Una política decide si puede delegarlo. El sistema emite al agente un permiso que nombra herramientas, recursos, operaciones, límites y expiración. Cada llamada lleva la identidad efectiva y el vínculo con la delegación. El receptor vuelve a autorizar antes de ejecutar.
No basta con escribir en el prompt "actúa en nombre de Ana". El vínculo debe ser verificable fuera del modelo. Tampoco basta un rol genérico como editor si la tarea sólo necesita leer dos colecciones.
El recibo final une solicitud, política, agente, herramienta, resultado e instante. Esa cadena permite responder quién, qué, sobre cuál objeto y bajo qué autoridad.
Diseña permisos por operación y objeto
Un permiso útil puede expresar leer artículos públicos del sitio A, crear borradores en la colección B o publicar una versión exacta una sola vez. Evita verbos amplios como administrar, gestionar o acceso completo.
Añade restricciones de recurso, entorno, volumen y tiempo. Si el agente procesa facturas, limita la carpeta y el periodo. Si publica, liga el permiso al identificador de artículo, versión y hash. Si consulta clientes, proyecta sólo campos necesarios.
Distingue permiso de capacidad. Una herramienta puede implementar crear y borrar, pero la credencial de una ejecución sólo habilitar crear borrador. Si el servicio no permite esa granularidad, crea un adaptador que exponga la operación reducida o elige una cuenta técnica con rol menor.
El receptor impone el alcance. Un modelo no puede ser el único responsable de recordar que no debe usar una capacidad disponible.
Credenciales cortas, revocables y separadas
Prefiere credenciales de corta duración emitidas para una ejecución. Si el sistema exige una clave larga, guárdala en un vault y entrégala sólo al proceso que la necesita, no al contexto del agente. Rota y revoca por integración.
Separa lectura, edición y publicación. El agente investigador no recibe la credencial del publicador. El publicador aparece sólo durante una ventana autorizada y consume un permiso de un uso.
Registra emisión, uso, expiración, rotación y revocación. Nunca registres el secreto. Un identificador de clave y su alcance bastan para investigar.
Reautoriza cuando cambia el contexto
Una autorización inicial puede quedar obsoleta si cambia el objeto, la versión, el destino o el nivel de riesgo. Evalúa la política en cada herramienta y exige nueva aprobación para efectos irreversibles o datos más sensibles.
La aprobación muestra actor, acción, objeto, versión, consecuencias y vigencia. Un mensaje general como "haz lo necesario" no debe transformarse en permiso permanente. Si la persona demora y el estado cambia, invalida la aprobación o exige compare-and-set.
Separa una aprobación editorial de una autorización de ejecución. La primera acepta el contenido. La segunda abre una acción concreta sobre un destino durante una ventana. Si el contenido cambia, el hash cambia y ambas decisiones anteriores dejan de cubrir el nuevo objeto.
Para tareas largas, renueva permisos sin ampliar el alcance. El tiempo adicional no es motivo para añadir capacidades.
La inyección intenta cambiar autoridad, no sólo texto
Un documento puede ordenar al agente que ignore reglas, use otra herramienta o entregue datos. La defensa no consiste sólo en detectar frases sospechosas. El contenido recuperado nunca debe conceder permisos. Las políticas, identidades y herramientas disponibles provienen de un plano de control separado.
Valida argumentos, limita destinos y exige aprobación en efectos sensibles. Diferencia la identidad del usuario, del agente y del recurso que aportó instrucciones. Si una página externa pide enviar secretos, el receptor debe bloquear la operación aunque el modelo la considere útil.
Prueba ataques de confusión de identidad, escalamiento de alcance y reutilización de permisos expirados.
Registra evidencia sin convertir el log en otro riesgo
Guarda identificador de actor, delegante, política, herramienta, objeto, decisión, estado y tiempo. Firma o protege contra alteración los eventos de mayor impacto. Mantén relojes sincronizados y correlación entre servicios.
No copies prompts, documentos o credenciales si no son necesarios para probar la decisión. Un log con secretos contradice el mínimo privilegio. Usa referencias y hashes para artefactos versionados.
Añade resultado remoto cuando exista y diferencia éxito confirmado de resultado ambiguo. Si una conexión se corta después de enviar una acción, registra incertidumbre y reconcilia contra el destino. Un reintento sin prueba puede duplicar el efecto y romper la cadena de evidencia.
Revisa periódicamente permisos emitidos, denegaciones, acciones fuera de horario y credenciales que nunca expiraron. La auditoría sirve para operar ahora, no sólo para explicar un incidente después.
Checklist de despliegue
1. Cada agente tiene identidad distinguible.
2. La delegación apunta a una persona u organización autenticada.
3. El permiso nombra operación, objeto, destino y expiración.
4. El receptor revalida antes del efecto.
5. Lectura, edición y publicación usan credenciales separadas.
6. Los secretos nunca entran al prompt ni a logs.
7. Cambios de versión invalidan autorizaciones anteriores.
8. Acciones sensibles requieren aprobación informada.
9. Inyección no puede ampliar herramientas ni alcance.
10. Emisión, uso, expiración y revocación quedan auditados.
El mínimo privilegio no reduce la utilidad del agente. Reduce la cantidad de cosas que un error puede convertir en daño.
