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. Identitätsinventar und Agentenbindungen gehören zu Community; Verzeichnis- und Roster-Konnektoren, die Föderation von Agentenidentitäten und PIV/CAC gehören zu Business (Identity & Scale). Die Agentenregistrierung gehört zu Business (Identity & Scale).
Im Produkt
Identität und Zugriff
Beispieldaten. Die Benutzerquellen, über die sich Personen anmelden, jeder Benutzer mit Gruppen, Rolle und Anmeldemethode, und die Gruppen, die Rollen zugeordnet sind. Mehrere Benutzerquellen und die Zuordnung von Gruppen zu Rollen gehören zu Business (Identity & Scale).
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
Lesen Sie die Voraussetzungen für die WIF-Verbindung und die Grenzen der Live-Abfrage.
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
Identitätseinträge und deklarierte Beziehungen
Das Erstellen einer NHI legt in Olivares einen Identitätsdatensatz pro Agent an. Dieser Datensatz stellt allein kein SPIFFE-Credential aus und richtet keine Föderation ein. Das Diagramm zeigt deklarierte Beziehungen; eine nicht aufgelöste Identität bleibt unbekannt.
Was real ist
Identitätsdatensätze, konfigurierbare Zusatzprüfung und Einblick in Föderation
Der schreibgeschützte WIF-Graph beginnt mit konfigurierten Föderationsregeln. Mit einer konfigurierten Anthropic-WIF-Verbindung und einem org:admin-OAuth-Token vergleicht Olivares diese Regeln mit der aktuellen Föderationskonfiguration und zeigt Herkunft und Abweichungen. Ohne dieses Token zeigt er nur Deklarationen; eine fehlgeschlagene Live-Abfrage wird als nicht verfügbar angezeigt. Das beweist keine Föderation mit jedem Identitätsanbieter. Die Föderation von Agentenidentitäten gehört zu Business (Identity & Scale).
- Ausgeliefert als reine Lese-Ingestion: Roster-Konnektoren lesen die Agentenidentitätsregister der Hyperscaler — Microsoft Entra Agent ID, AWS Bedrock AgentCore und Googles Agentenregister. Live-verifizierte Föderation auf der Leitung gegen diese Register bleibt auf der Roadmap, und wir behaupten sie nicht, bevor sie ausgeliefert ist.
- Community umfasst einen aktiven OIDC- oder SAML-Identitätsanbieter. Business: Identity & Scale ergänzt den eingehenden SCIM 2.0-Server für Benutzer und Gruppen, mehrere Identitätsanbieter und eine durchgesetzte SSO-Richtlinie.
Business: Verzeichnisse und mehrere Identitätsanbieter
Community meldet Nutzer über einen OIDC- oder SAML-Anbieter an. Business ergänzt den eingehenden SCIM-2.0-Server, bis zu fünf aktive Identitätsanbieter, Verzeichnisimport aus Okta, Entra ID, Keycloak und weiteren, Abteilungen, ausgehende SCIM-Bereitstellung und PIV/CAC-Step-up.
Identity & NHI — Fragen
Föderiert Olivares heute live mit Entra Agent ID, AWS AgentCore oder Google Agent Identity?
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?
Olivares unterstützt WebAuthn/FIDO2 und PIV/CAC. Der Administrator wählt die zusätzliche Prüfungsrichtlinie: none (Standard, keine zusätzliche Zeremonie), totp (Authentifizierungscode oder unterstützte MFA des Identitätsanbieters) oder passkey (frische Passkey- oder PIV-Prüfung). Notfallzugriff und kritische Freigaben folgen dieser Richtlinie. Authentifizierung, Berechtigungen und Mandantentrennung gelten weiterhin. AAL3 ist ein Sicherheitsziel, keine NIST- oder FIPS-Zertifizierung. PIV/CAC und Break-Glass gehören zu Business.
Enthalten Community und Business SSO und SCIM-Provisionierung?
Community umfasst einen aktiven OIDC- oder SAML-Identitätsanbieter. Business: Identity & Scale ergänzt den eingehenden SCIM 2.0-Server für Benutzer und Gruppen, mehrere Identitätsanbieter und eine durchgesetzte SSO-Richtlinie.
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.