Referenzimplementierungen und Muster
Dieser Abschnitt bietet umsetzbare Implementierungsmuster und praxisnahe Beispiele, die veranschaulichen, wie Organisationen IAM-Prinzipien effektiv zur Unterstützung von KI-Agenten anwenden können.
Agenten-Onboarding
Beim Onboarding wird ein KI-Agent als eine einzigartige, nicht menschliche Entität im IAM-System bereitgestellt.
Onboarding verwalteter Agenten
Dies sind die von der Organisation verwalteten Agenten, höchstwahrscheinlich API-interagierende Agenten wie Chatbots oder digitale Arbeitskräfte.
Erstellen Sie einen dedizierten Client/eine dedizierte Anwendung für den Agenten. Der Agent wird sich mit der dem Client zugewiesenen Client-ID identifizieren – selbst wenn der Agent in die bestehende Benutzeroberfläche der Client-Anwendung integriert ist.
Aktivieren Sie die Zugriffsdelegierungsflüsse für diesen Client (z. B. device-flow, token-exchange, assertion-grant) und stellen Sie sicher, dass der Agent den ausgewählten Ablauftyp unterstützt. Der Geräteablauf ist in den meisten Anwendungsfällen der einfachste und am häufigsten unterstützte Ablauf.
Weisen Sie dem Agenten Berechtigungen gemäß den minimal gewünschten Privilegien zu. Berücksichtigen Sie das Prinzip der geringsten Privilegien – vergeben Sie standardmäßig minimale Berechtigungen und unterstützen Sie bei Bedarf eine Erhöhung der Berechtigungen durch Step-up-Authentifizierung und Zustimmung.
Konfigurieren Sie das Token, einschließlich Ablaufdauer und Aktualisierungs-Token, entsprechend den Anforderungen des Agenten. Für Agenten werden kürzerlebige Sitzungen empfohlen.
Markieren Sie die Zugriffstoken des Agenten. Falls vom Autorisierungsserver unterstützt, fügen Sie dem Zugriffstoken einen benutzerdefinierten Anspruch hinzu, der klar angibt, dass das Token an einen Agenten ausgegeben wird. Falls benutzerdefinierte Ansprüche nicht unterstützt werden, wird die dedizierte Client-ID des Agenten als Tag verwendet.
Onboarding von Bring-Your-Own-Agents (BYOA)
Diese Agenten werden nicht von der Organisation verwaltet. Vielmehr können einzelne Benutzer Agenten beauftragen, Aufgaben in ihrem Namen zu erledigen.
API-Interaktionsagenten
Wenn Sie API-interagierende Agenten unterstützen möchten, die nicht von der Organisation verwaltet werden, wird empfohlen, die dynamische Client-Registrierung (DCR) anzuwenden – die Agenten müssen sich selbst registrieren, und jeder erhält eine eigene Client-ID und eine Berechtigungskonfiguration gemäß den Richtlinien der Organisation (Geltungsbereiche, Ablauf usw., wie oben für verwaltete Agenten beschrieben).
Computerbenutzender Agent
Für computerbenutzende Agenten (CUAs), die von einzelnen Benutzern eingestellt werden, gibt es keinen echten Onboarding-Prozess, da sie Standard-Benutzeragenten wie Browser verwenden. Stattdessen werden diese Agenten ähnlich identifiziert, wie Sie von Menschen gesteuerte Benutzeragenten identifizieren – z. B. Geräte-Fingerprinting.
Authentifizierung und Zugriffsdelegierung
Wie bereits erwähnt, sollten Agenten, die im Namen von Benutzern handeln, im Namen des Benutzers Zugriff erhalten und sich niemals als Benutzer ausgeben.
API-Interaktionsagenten
Verwenden Sie standardmäßige OAuth-Zugriffsdelegationsabläufe, wie sie für den spezifischen Client des Agenten konfiguriert sind (identifiziert durch die vom Agenten verwendete Client-ID, wie im obigen Abschnitt zur Einführung beschrieben).
Computerbenutzender Agent
Ein CUA, das versucht, sich zu authentifizieren, sollte zu einem geeigneten Authentifizierungsablauf weitergeleitet werden, idealerweise automatisch (basierend auf der CUA-Erkennung) oder als Authentifizierungsoption in der Benutzeroberfläche verfügbar sein, die der Agent auswählen kann.
Der CUA-Authentifizierungsfluss wird einen delegierten Zugriffsfluss auslösen, ähnlich dem Gerätefluss, der für API-Interaktionsagenten angewendet wird. Auf diese Weise wird sich der menschliche Benutzer authentifizieren und den Zugriff explizit an den Agenten delegieren, ohne seine Anmeldedaten dem Agenten preiszugeben.
Einschränkung der Berechtigungen des Agenten
Wie in den obigen Implementierungsmustern vorgeschlagen, wird ein Agent ein Zugriffstoken verwenden, das eindeutig anzeigt, dass es sich um einen Agenten handelt und möglicherweise auch einen reduzierten Satz von Geltungsbereichen enthält (im Vergleich zu den Standard-Geltungsbereichen des Benutzers bei direkter Interaktion).
Eine Autorisierungsrichtlinie, die eine Ressource schützt, wird sich des agentenbasierten Clients bewusst sein und bei Bedarf strengere Berechtigungen durchsetzen.
Nehmen wir zum Beispiel eine Geschäftspolitik an, die von den Agenten verlangt, dass sie für die Ressourcen „Aufträge“ nur Lesezugriff haben. Hier sind einige Beispiele dafür, wie ein Zugriffstoken widerspiegeln kann, dass es an einen Agenten ausgegeben wurde:
// standard client application access token for user-X
{
"sub": "user-X",
"client_id": "app-client-123",
"scope": "read:orders write:orders",
"aud": "https://api.example.com",
"exp": 1712399999
}
// API interacting agent access token for user-X
{
"sub": "user-X",
"client_id": "agent-client-456", // different client-id
"scope": "read:orders", // limited scopes for read-only
"aud": "https://api.example.com",
"exp": 1712399999
}
// CUA intercting with the standard client application on behalf of user-X
{
"sub": "user-X",
"client_id": "app-client-123", // the client id is of the standard client-app that the agent is interacting with
"scope": "read:orders", // limited scopes for read-only
"aud": "https://api.example.com",
"exp": 1712399999,
"act" : {"client_id" : "agent-client-789"} // actor claim pointing to the agent
}
Standard-Clientanwendung – ein Beispiel für ein Zugriffstoken, das von der Standardanwendung verwendet wird (z. B. Webanwendung), sobald sich der Benutzer angemeldet hat
Der Benutzer ist das Token-Subjekt (sub claim)
Die Client-ID gehört zur Webanwendung
Der Geltungsbereich umfasst sowohl Lese- als auch Schreibzugriff
API-interagierender Agent – ein Beispiel für ein Zugriffstoken, das ein API-interagierender Agent nach der Benutzerauthentifizierung und der Zugriffsdelegation an den Agenten erhalten kann
Der Benutzer ist das Token-Subjekt
Die Client-ID gehört dem Agenten
Der Geltungsbereich erwähnt nur den Lesezugriff
CUA – ein Beispiel für ein Zugriffstoken, das die Client-Anwendung erhält, wenn sie von einem Computer Using Agent kontrolliert wird, nachdem der Benutzer den Zugriff an diesen delegiert hat
Der Benutzer ist das Token-Subjekt (sub claim)
Die Client-ID gehört zur Webanwendung
Der Geltungsbereich erwähnt nur den Lesezugriff
Act-Anspruch, der den Akteur repräsentiert, der im Namen des Benutzers handelt und angibt, dass es sich um einen Agenten handelt, basierend auf der Client-ID des Agenten
Human-in-the-Loop-Autorisierung
In einigen Fällen kann es vorkommen, dass die Berechtigung eines Agenten nicht eingeschränkt wird, sondern dass er nach einer ausdrücklichen Autorisierung durch den Benutzer im Kontext (dem Subjekt des Zugriffstokens) fortfahren darf.
In diesem Fall kann eine Autorisierungsrichtlinie eine zusätzliche Authentifizierung außerhalb des normalen Kanals durch den Benutzer und eine ausdrückliche Zustimmung des Benutzers zur Genehmigung der Tätigkeit des Agenten in seinem Namen erfordern.
Betrachten Sie zum Beispiel die folgende veranschaulichende Richtlinie:
{
"if": {
"access_token.client_id": "agent-client-*",
"requested_resource": "/orders",
"access_token.scope": "!contains:write:orders"
},
"then": {
"action": "deny",
"status": 403,
"error": "insufficient_scope",
"required_scope": "write:orders",
"message": "This operation requires user confirmation via step-up authentication."
}
}
Im Anschluss an diese Antwort wird der Agent einen Out-of-Band-Benutzerbestätigungsprozess auslösen, der einen OTP an den Benutzer sendet.
Überwachung der Agentenaktivitäten
Da die Zugriffstoken der Agenten als solche gekennzeichnet sind, ist es möglich, sich auf das Zugriffstoken als Standard-Tagging-Mechanismus zu verlassen, um Interaktionen von Agenten mit dem IAM-System und mit geschützten Ressourcen anzuzeigen.
Zum Beispiel, wenn Sie das Audit-Protokoll basierend auf der access-token.client-id betrachten, wird die Interaktionen offenlegen, die der relevante Agent im Namen eines jeden Benutzers durchführt.
Anhand des Prüfprotokolls ist es möglich, die Aktivität des Agenten zu überwachen und auf abnormales oder unerwünschtes Verhalten des Agenten hinzuweisen, das auf Halluzinationen, falsche Denkprozesse oder sogar böswillige Versuche zurückzuführen sein kann, den Agenten zu „jailbreaken“.
Starten Sie jetzt
Kontaktieren Sie uns
Erfahren Sie, wie Ping Ihnen helfen kann, sichere Erlebnisse für Mitarbeiter, Partner und Kunden in einer sich schnell wandelnden digitalen Welt zu bieten.