Produkt · Identity & NHI
Geben Sie jedem Agenten eine eigene Identität — und erkennen Sie, wenn er keine hat
Ein gemeinsam genutzter Service-Account macht "welcher Agent hat das getan?" unbeantwortbar. Olivares bindet einen Agenten an eine Non-Human Identity, erzeugt eine dedizierte NHI pro Agent und macht sichtbar, welche Agenten sich eine teilen — der Unterschied zwischen verlässlicher und nur näherungsweiser Zuordnung von Zugriff. Eine Identität, die nicht aufgelöst werden kann, wird niemals stillschweigend wie eine echte behandelt.
Im Produkt
Die Identity-Konsole
Ein echter Screenshot, Beispieldaten. Tabs für das NHI-Verzeichnis, MCP-Auth, den WIF-Graphen, Schlüssel- & Residency-Posture sowie privilegierte Logins. Der SSO/SCIM-Tab ist offen über seine eigene Bruchstelle: Der Backend-Endpunkt ist noch nicht live, daher zeigt es nichts an, statt etwas zu erfinden.
Was Sie steuern
Vom gemeinsamen Account zur Identität pro Agent
Identität ist die Achse, entlang derer die Access Map Zugriff zuordnet. Eine dedizierte NHI pro Agent macht aus "näherungsweise" ein "verlässlich"; alles Weitere ist ehrlich darüber, wie weit es kommt.
NHI binden oder erzeugen
Binden Sie einen Agenten an eine bestehende Non-Human Identity oder erzeugen Sie eine dedizierte NHI pro Agent. Eine dedizierte NHI ist es, was der Access Map erlaubt, Zugriff verlässlich einem einzelnen Agenten zuzuordnen — nicht näherungsweise einem Pool.
Befund zu geteilter Identität
Wenn mehr als ein Agent auf demselben Account läuft, ist die Zuordnung pro Agent tatsächlich uneindeutig. Olivares weist das als Befund aus und sagt es offen — es sagt offen, dass es unklar ist, statt einen Kompromiss zu suchen und so zu tun, als wüsste es, welcher Agent gehandelt hat.
Read-only WIF-Graph
Ein Workload-Identity-Federation-Graph bildet Ihre Identitäten pro Agent auf Ihren IdP ab. Er wird schreibgeschützt aus den von Ihnen deklarierten Föderationsregeln dargestellt — eine Sicht auf das, was Sie angegeben haben, keine Live-Verifizierung des Vertrauens auf der Leitung.
Das ehrliche Unbekannte
Eine Identität, die Olivares nicht auflösen kann, wird als unbekannt dargestellt und markiert — niemals stillschweigend zu einer benannten NHI hochgestuft. Kein Identitätssignal bedeutet keine Zuordnung, klar gesagt.
So funktioniert es
Eine Identität pro Agent mit Ihrem IdP föderieren
Jeder Agent erhält eine eigene Identität — ein SPIFFE/WIF-Credential — die mit Ihrem Identity Provider föderiert wird. Ein Agent ohne auflösbare Identität wird nicht in eine echte eingegliedert: Er wird getrennt dargestellt und gekennzeichnet.
Was real ist
NHI-Binding und der WIF-Graph sind live; Live-Föderation und AAL3-Step-up nicht
Wir sind hier präzise, denn der Unterschied ist der eigentliche Sinn einer Identitätsebene:
- Live: das Binden eines Agenten an eine NHI, das Erzeugen einer dedizierten NHI pro Agent, der Befund zu geteilter Identität und der read-only WIF-Graph. Der Graph spiegelt die von Ihnen deklarierten Föderationsregeln wider — er ist kein live-verifiziertes Bild der Föderation auf der Leitung.
- Roadmap: Live-Föderation gegen die allgemein verfügbaren Hyperscaler-Registries für Agent-Identitäten — Microsoft Entra Agent ID, AWS AgentCore, Google Agent Identity. Heute stellen wir die deklarierten Regeln dar und behaupten keine Live-Verifizierung, bevor sie ausgeliefert ist.
- Nicht gebaut: WebAuthn AAL3 / PIV-CAC-Step-up. Es ist nicht implementiert und fällt heute fail-closed auf AAL1 zurück — wir sagen AAL1, nicht das Sicherheitsniveau, das wir nicht verdient haben. Einige Live-Identitätsquellen (LDAP, IdP, Secret-Manager) und SCIM-Gruppen sind noch nicht angebunden, und der SSO/SCIM-Tab ist offen darüber: Backend ausstehend, nichts zu zeigen, niemals erfunden.
Identity & NHI — Fragen
Föderiert Olivares heute live mit Entra Agent ID, AWS AgentCore oder Google Agent Identity?
Nein — nicht live. Der WIF-Graph ist schreibgeschützt und wird aus den von Ihnen deklarierten Föderationsregeln dargestellt; er zeigt also, was Sie angegeben haben, keine live verifizierte Vertrauensbeziehung auf der Leitung. Live-Föderation gegen diese allgemein verfügbaren Hyperscaler-Registries für Agent-Identitäten steht auf der Roadmap, und wir behaupten sie nicht, bevor sie ausgeliefert ist.
Zwei Agenten teilen sich einen Service-Account. Welcher hat laut Olivares gehandelt?
Keiner, verlässlich. Eine geteilte Identität macht die Zuordnung pro Agent tatsächlich uneindeutig, deshalb meldet Olivares einen Befund zu geteilter Identität und ordnet Zugriff nur näherungsweise zu — es schafft keine künstliche Gewissheit darüber, welcher Agent gehandelt hat. Erzeugen Sie eine dedizierte NHI pro Agent, und die Access Map kann diesen Agenten dann verlässlich zuordnen.
Unterstützen Sie WebAuthn AAL3 oder PIV-CAC-Step-up für privilegierte Logins?
Noch nicht. AAL3-Step-up via WebAuthn oder PIV-CAC ist nicht gebaut; heute fällt der Pfad fail-closed auf AAL1 zurück, und genau so kennzeichnen wir diesen Zustand — wir zeigen kein Sicherheitsniveau an, das wir nicht verdient haben. Der Tab für privilegierte Logins zeigt, was jetzt tatsächlich durchgesetzt wird.
Warum ist der SSO/SCIM-Tab leer?
Weil der zugehörige Backend-Endpunkt noch nicht live ist, gibt es schlicht nichts zu zeigen — und das Produkt sagt das, statt ihn mit plausibel aussehenden Daten zu füllen. Dasselbe gilt für Live-Identitätsquellen wie LDAP, IdP und Secret-Manager sowie SCIM-Gruppen: noch nicht angebunden, ehrlich leer angezeigt.
Geben Sie Ihren Agenten Identitäten, die Sie zuordnen können
Betreiben Sie Olivares auf Ihrer eigenen Infrastruktur, erzeugen Sie eine dedizierte NHI pro Agent und machen Sie aus "näherungsweise" ein "verlässlich" auf Ihrer Access Map.