NIST: más de 600 respuestas y ninguna identidad única para agentes

El 29 de septiembre de 2026, el Centro Nacional de Excelencia en Ciberseguridad (NCCoE) del NIST publicó el balance de más de 600 respuestas sobre identidad y autorización de agentes de IA, recibidas de la industria, el gobierno y la academia. Su proyecto DevSecOps será el primer caso de implementación para demostrar cómo identificar, autenticar y autorizar agentes durante el desarrollo de software. Se trata de una demostración prevista: todavía no se ha adoptado un mecanismo común de identidad.

La respuesta inmediata para las empresas es separar la identidad del agente de la autoridad que puede ejercer en cada tarea. El resumen técnico del NCCoE recoge una preferencia mayoritaria por ampliar estándares existentes, junto con la falta de acuerdo sobre un método único para identificar agentes; un participante planteó la diferencia entre «who is acting» y «what bounded authority is being exercised». Identificar una conexión, por tanto, deja abierta la pregunta de qué acción concreta fue autorizada y por quién.

Por qué DevSecOps será el primer caso

El entorno elegido permite observar permisos distintos dentro de una misma cadena de trabajo. Un agente empresarial puede proponer código, revisar un cambio o intervenir en el despliegue; cada actividad alcanza recursos diferentes y puede requerir una autorización diferente. La cobertura de AI News Bank sitúa la elección de DevSecOps como el primer entorno de prueba para los controles de identidad y acceso de este proyecto.

Las respuestas pidieron distinguir el desarrollo del despliegue por sus riesgos y recursos, además de examinar la integración con canalizaciones de entrega continua y el acceso a secretos. Entre los escenarios propuestos figura permitir que un agente escriba una propuesta de cambio sin concederle por ello permiso para publicarla. Esos escenarios orientan el trabajo previsto: aún no son resultados de una implementación terminada.

La diferencia importa cuando una tarea se divide entre agentes. Si uno prepara un cambio y otro lo despliega, conocer la identidad de ambos solo resuelve parte del problema. La decisión de acceso también debe conservar el encargo original, los límites de la delegación y la operación solicitada en cada punto de la cadena.

Identidad, permisos y auditoría: dónde hay acuerdo

Las respuestas distinguen controles que suelen quedar mezclados bajo la expresión «identidad del agente». Esta matriz traduce los puntos de mayor acuerdo a decisiones observables en el caso DevSecOps; describe prioridades surgidas de los comentarios, no requisitos normativos emitidos por el NIST.

Identidad: distinguir al agente de una persona y relacionar su servicio o carga de trabajo, su instancia de ejecución y la persona u organización que lo autorizó. Sigue abierta la forma exacta de representarlo entre entornos con modelos de confianza diferentes.
Autenticación: comprobar que el agente y, cuando corresponda, su entorno de ejecución son quienes afirman ser. Credenciales de carga de trabajo, firmas, autenticación mutua y atestación aparecen como mecanismos posibles; una base de confianza estable puede convivir con credenciales operativas de vida corta.
Autorización: evaluar la operación solicitada en el contexto de la tarea, incluso cuando el agente llama a una herramienta o a una API. El acuerdo favorece políticas verificables y permisos acotados, aplicados por un componente separado del razonamiento del modelo.
Delegación: conservar quién otorgó autoridad, a qué agente, para qué propósito y con qué límites. Al pasar una tarea a un subagente, el alcance debe reducirse a lo necesario para su función; falta una representación común que viaje entre servicios y organizaciones.
Auditoría: registrar la solicitud, las identidades y delegaciones pertinentes, la decisión de acceso y la acción ejecutada. Una anotación que solo diga que hubo una llamada permite ver el resultado, pero no reconstruir la autoridad que lo hizo posible.

En una canalización de software, estas distinciones evitan que una credencial válida se interprete como permiso general sobre todo el ciclo. La autorización para proponer código no tiene por qué incluir acceso a secretos ni capacidad de modificar una canalización. Si la tarea cambia durante la ejecución, la decisión de acceso debe evaluarse con el nuevo contexto, en vez de depender únicamente de los permisos obtenidos al inicio.

Qué piezas se pueden reutilizar y qué falta definir

La orientación predominante consiste en combinar infraestructura de identidad ya desplegada con extensiones específicas para agentes. OAuth aporta mecanismos de autorización; SPIFFE/SPIRE ofrece un modelo operativo para identidades de cargas de trabajo. En el inventario técnico aparecen además trabajos sobre intercambio de tokens, cadenas de actores y credenciales vinculadas al contexto de ejecución, con grados de madurez distintos. Su inclusión en el inventario no equivale a una aprobación general para cualquier despliegue.

Una decisión especialmente difícil es cómo expresar el propósito autorizado. Algunas propuestas plantean un mandato firmado que describa los resultados y límites aprobados por una persona. Continúa abierto cómo estructurar ese mandato para que distintos sistemas lo interpreten de la misma manera sin transmitir datos personales o contexto sensible innecesario.

También queda por resolver qué información debe incorporarse a una credencial y cuál conviene consultar durante la ejecución. La procedencia del agente, su versión, la cadena de delegación y la política aplicable pueden influir en una decisión de acceso, pero transportarlo todo en cada solicitud aumentaría la complejidad y la exposición de datos. La siguiente definición del proyecto será el borrador de su descripción, con el alcance, la arquitectura, los casos de uso y los estándares propuestos para la demostración.