Producto · Identidad y NHI
Dale a cada agente su propia identidad — y entérate cuando no la tiene
Una cuenta de servicio compartida hace que «¿qué agente hizo esto?» no tenga respuesta. Olivares vincula un agente a una identidad no humana, acuña una NHI dedicada por agente y muestra los agentes que comparten una — la diferencia entre atribuir el acceso con firmeza o solo de forma aproximada. Una identidad que no puede resolver nunca se trata en silencio como si fuera real.
En el producto
La consola de identidad
Una captura real, con datos de ejemplo. Pestañas para el roster de NHI, MCP auth, el grafo WIF, la postura de claves y residencia y los logins privilegiados. La pestaña SSO/SCIM es franca sobre su propia costura: el endpoint del backend aún no está live, así que no muestra nada en vez de inventarlo.
Qué gobiernas
De una cuenta compartida a una identidad por agente
La identidad es el eje sobre el que el mapa de acceso atribuye. Una NHI dedicada por agente convierte el «aproximado» en «firme»; todo lo de abajo es honesto sobre hasta dónde llega.
Vincula o acuña una NHI
Vincula un agente a una identidad no humana existente, o acuña una NHI dedicada por agente. Una NHI dedicada es lo que permite al mapa de acceso atribuir el acceso con firmeza a un agente — no de forma aproximada a un pool.
Hallazgo de identidad compartida
Cuando más de un agente va sobre la misma cuenta, la atribución por agente es genuinamente ambigua. Olivares lo muestra como un hallazgo y lo dice — no parte la diferencia ni finge saber qué agente actuó.
Grafo WIF de solo lectura
Un grafo de federación de identidad de carga de trabajo (WIF) mapea tus identidades por agente con tu IdP. Se renderiza de solo lectura a partir de las reglas de federación que declaras — una vista de lo que afirmaste, no una verificación en vivo de la confianza en el cable.
El desconocido honesto
Una identidad que Olivares no puede resolver se dibuja como desconocida y se señala — nunca se asciende en silencio a una NHI con nombre. Sin señal de identidad no hay atribución, dicho con claridad.
Cómo funciona
Federar una identidad por agente con tu IdP
Cada agente obtiene una identidad por agente — una credencial SPIFFE/WIF — que federa con tu proveedor de identidad. Un agente sin identidad resoluble no se mete dentro de una real: se dibuja aparte y se señala.
Qué es real
El vínculo de NHI y el grafo WIF están live; la federación en vivo y el step-up AAL3 no
Somos precisos en esto, porque la diferencia es el sentido entero de una superficie de identidad:
- Live: vincular un agente a una NHI, acuñar una NHI dedicada por agente, el hallazgo de identidad compartida y el grafo WIF de solo lectura. El grafo refleja las reglas de federación que declaras — no es una imagen verificada en vivo de la federación en el cable.
- Roadmap: federación en vivo contra los registros GA de identidad de agente de los hyperscalers — Microsoft Entra Agent ID, AWS AgentCore, Google Agent Identity. Hoy renderizamos reglas declaradas y no afirmamos verificación en vivo antes de que exista.
- Sin construir: step-up WebAuthn AAL3 / PIV-CAC. No está implementado y hoy falla cerrado a AAL1 — decimos AAL1, no el nivel de aseguramiento que no hemos ganado. Algunas fuentes de identidad en vivo (LDAP, IdP, gestores de secretos) y SCIM Groups aún no están cableadas, y la pestaña SSO/SCIM es franca al respecto: backend pendiente, nada que mostrar, nunca fabricado.
Identidad y NHI — preguntas
¿Olivares federa en vivo con Entra Agent ID, AWS AgentCore o Google Agent Identity hoy?
No — no en vivo. El grafo WIF es de solo lectura y se renderiza a partir de las reglas de federación que declaras, así que muestra lo que afirmaste, no una relación de confianza verificada en vivo en el cable. La federación en vivo contra esos registros GA de identidad de agente de los hyperscalers está en el roadmap, y no la afirmamos antes de que exista.
Dos agentes comparten una cuenta de servicio. ¿Cuál dice Olivares que actuó?
Ninguno, con firmeza. Una identidad compartida hace que la atribución por agente sea genuinamente ambigua, así que Olivares levanta un hallazgo de identidad compartida y atribuye el acceso solo de forma aproximada — no fabricará certeza sobre qué agente actuó. Acuña una NHI dedicada por agente y entonces el mapa de acceso podrá atribuir ese agente con firmeza.
¿Soportáis step-up WebAuthn AAL3 o PIV-CAC para logins privilegiados?
Aún no. El step-up AAL3 vía WebAuthn o PIV-CAC no está construido; hoy la ruta falla cerrado a AAL1, y así es exactamente como lo etiquetamos — no mostramos un nivel de aseguramiento que no hemos ganado. La pestaña de login privilegiado muestra lo que de verdad se aplica ahora.
¿Por qué está vacía la pestaña SSO/SCIM?
Porque el endpoint del backend para ella aún no está live, así que genuinamente no hay nada que mostrar — y el producto lo dice en vez de sembrarla con datos que parezcan plausibles. Lo mismo vale para fuentes de identidad en vivo como LDAP, IdP y gestores de secretos, y para SCIM Groups: aún sin cablear, mostradas honestamente vacías.
Da a tus agentes identidades que puedas atribuir
Despliega Olivares en tu propia infraestructura, acuña una NHI dedicada por agente y convierte el «aproximado» en «firme» en tu mapa de acceso.