Was delegierte Autorität bedeutet
Delegierte Autorität ist die Erlaubnis, die eine Person oder eine Organisation einem KI-Agenten gibt, in ihrem Namen zu handeln. Wenn ein Assistent einen Termin in Ihrem Kalender bucht, ein Support-Ticket in Ihrem Namen erstellt oder eine Rechnung aus dem Portal eines Lieferanten abruft, übt er eine Autorität aus, die von Ihnen ausgegangen ist.
Gute Delegation hat drei Eigenschaften: Sie ist eingeschränkt (der Agent kann einige Dinge tun, nicht alles), zeitlich begrenzt (sie läuft ab oder kann widerrufen werden) und zuordenbar (die empfangende Anwendung kann erkennen, wessen Autorität gerade ausgeübt wird).
Warum das für Anwendungen wichtig ist
Aus Sicht einer Anwendung wirft eine Agentenanfrage bis zu drei getrennte Fragen auf:
- Welcher Client hat das gesendet? Das ist die Agentenidentität, die signierte Anfragen feststellen können (siehe HTTP Message Signatures).
- Unter wessen Autorität handelt sie? Das ist Delegation.
- Reicht diese Autorität für diese Aktion aus? Das ist Autorisierung, entschieden durch die eigene Richtlinie der Anwendung.
Eine signierte Anfrage von einem bekannten Betreiber eines Assistenten beantwortet die erste Frage gut. Über die zweite sagt sie für sich genommen nichts aus. Der Assistent kann im Auftrag eines Ihrer Nutzer handeln, im Auftrag von jemandem, der nicht Ihr Nutzer ist, oder vollständig aus eigener Initiative. Client-Identität als Beweis für die Zustimmung einer Person zu behandeln, ist einer der häufigsten Fehler bei der Gestaltung agentenseitiger Systeme. Siehe was signierte Anfragen von KI-Agenten belegen und was nicht.
Wie Delegation üblicherweise ausgedrückt wird
- OAuth-artige Berechtigungen. Die Person meldet sich bei Ihrer Anwendung an und erteilt einem Agenten ein Token mit begrenzten Scopes, wie in OAuth 2.0 (RFC 6749) definiert. Ihre Anwendung weiß dann genau, welche Autorität das Token trägt, und die Berechtigung kann widerrufen werden (RFC 7009).
- API-Keys mit Kontobezug, die ein Nutzer für eine bestimmte Integration erstellt, idealerweise mit engen Berechtigungen.
- Bestätigungen in der App für Aktionen mit hoher Wirkung, bei denen die Person eine konkrete, vom Agenten vorbereitete Aktion freigibt.
- Delegations-Claims auf Token-Ebene. OAuth 2.0 Token Exchange (RFC 8693) definiert einen
act-Claim (actor), der festhält, dass eine Partei für eine andere handelt. Neuere Arbeiten zum Ausdruck von Agentendelegation in Anfragen entwickeln sich weiter, und Anwendungen sollten jeden Delegations-Claim mit ihren eigenen Aufzeichnungen abgleichen, statt ihn für bare Münze zu nehmen.
Häufige Missverständnisse
- "Wenn der Agent verifiziert ist, hat der Nutzer zugestimmt." Verifizierung identifiziert den Client. Die Zustimmung muss von der Person kommen, über einen Kanal, dem Ihre Anwendung vertraut.
- "Ein Agent, der die Sitzung meines Nutzers verwendet, ist in Ordnung." Das kann sein, aber die Sitzung wurde für die interaktive Nutzung durch einen Menschen ausgestellt. Viele Anwendungen bevorzugen für Automatisierung eine eigene, eingeschränkte Berechtigung, damit Aktionen zugeordnet und widerrufen werden können.
- "Delegation ist alles oder nichts." Die sichersten Delegationen sind eng gefasst: breiter Lesezugriff, Schreibzugriff nur für bestimmte Aktionen und Bestätigung für alles, was nicht rückgängig zu machen ist.
Wie Proof of Actor damit zusammenhängt
Proof of Actor hilft Ihnen zu erkennen, wann eine Interaktion agentengesteuert oder KI-unterstützt ist, und auf welcher Grundlage: verifiziert, erklärt, abgeleitet oder unbekannt. Dieser Kontext zeigt Ihnen, wo Delegationsfragen entstehen, zum Beispiel bei einem autonomen Agenten, der innerhalb einer menschlichen Kontositzung handelt. Proof of Actor stellt keine Delegationsnachweise aus und validiert sie auch nicht, und ein Agent-Ergebnis bedeutet niemals, dass eine Person die Aktion autorisiert hat. Die eigenen Berechtigungen, Scopes und Bestätigungen Ihrer Anwendung entscheiden darüber, und Route ermöglicht es Ihnen, die richtige Richtlinie pro Route anzuwenden, sobald Sie realen Traffic beobachtet haben. Für Richtlinienmuster siehe Richtlinien auf Anwendungsebene für Menschen und KI-Agenten entwerfen.
Lesen Sie was die Evidenz belegen kann und was nicht, oder für den frühen Zugang bewerben.
Quellen
- RFC 6749: The OAuth 2.0 Authorization Framework: eingeschränkte Berechtigungen von einem Ressourceninhaber an einen Client
- RFC 7009: OAuth 2.0 Token Revocation: ein delegiertes Token widerrufen
- RFC 8693: OAuth 2.0 Token Exchange: der
act-Claim (actor) für Delegation