Was Agent-Autorisierung bedeutet
Agent-Autorisierung ist die Entscheidung darüber, was ein KI-Agent tun darf: welche Routes er aufrufen darf, welche Daten er lesen darf, welche Aktionen er ausführen darf und in welchem Umfang. Sie ist von der Agent-Identität zu unterscheiden, bei der es darum geht festzustellen, welcher Agent oder welcher Agent eines Operators die Anfrage stellt.
Die beiden werden leicht vermischt, weil sie oft zusammen auftreten. Eine signierte Anfrage sagt Ihnen, wer sie gesendet hat. Sie sagt Ihnen nicht, ob dieser Sender berechtigt sein sollte, ein Konto zu ändern, eine Bestellung auszulösen oder Daten zu exportieren. Identität ist ein Beleg, Autorisierung ist eine Policy. Unser Beitrag über was signierte Anfragen von KI-Agenten belegen und was nicht arbeitet den Unterschied heraus.
Warum die Unterscheidung wichtig ist
Anwendungen trennen bei menschlichen Nutzern bereits Authentifizierung und Autorisierung: Ein Login beweist, wer Sie sind, und Rollen sowie Berechtigungen entscheiden, was Sie tun können. Für Agenten braucht es die gleiche Trennung, mit einer zusätzlichen Sorgfaltsebene:
- Identität kann stark sein, während die Berechtigung fehlt. Ein Crawler mit einer vollkommen gültigen HTTP Message Signatures hat kein inhärentes Recht, einen Write-Endpoint aufzurufen.
- Berechtigung kann ohne starke Identität bestehen. Ein Agent, der einen API-Schlüssel eines Kunden verwendet, ist durch diesen Schlüssel autorisiert, auch wenn nichts identifiziert, welche Agent-Software ihn gerade hält.
- Die Person hinter dem Agenten ist relevant. Wenn ein Agent für jemanden handelt, stellt sich die Frage, ob diese Person ihm die Autorität eingeräumt hat (siehe delegierte Autorität).
Diese Punkte in einer einzigen Prüfung zusammenzufassen, führt zu zwei Fehlermodi: legitime Automatisierung zu blockieren, weil ihr ein menschliches Login fehlt, oder einem gut identifizierten Agenten Aktionen zuzutrauen, die er nie ausführen sollte.
Wie Autorisierung üblicherweise ausgedrückt wird
Die meisten Anwendungen autorisieren Agenten mit Mechanismen, die sie bereits haben:
- Anmeldedaten und Scopes. API-Keys oder OAuth 2.0-Tokens mit Scopes, die auf das beschränkt sind, was die Integration braucht. MCP server verwenden dasselbe Modell: Die MCP authorization specification behandelt einen geschützten Server als OAuth 2.1 Resource Server.
- Policy auf Route-Ebene. Read-only-Routes sind für bekannte Agenten geöffnet, Write-Routes erfordern eine an ein Konto gebundene Berechtigung.
- Risikostufen. Aktionen mit geringem Einfluss werden breit zugelassen, Aktionen mit hohem Einfluss erfordern stärkere Anmeldedaten, Bestätigung oder Prüfung.
- Ratenlimits und Kontingente pro Operator, pro Berechtigung oder pro Route.
Nachweise zur Agent-Identität fließen als ein Input in diese Entscheidungen ein. Für einen durchgearbeiteten Ansatz siehe wie Sie auf Anwendungsebene Policies für Menschen und KI-Agenten entwerfen. So können Sie einen verifizierten Operator anders behandeln als einen anonymen Client, aber die Berechtigung selbst kommt weiterhin aus Ihrer Policy.
Häufige Missverständnisse
- "Verifizierter Agent heißt zugelassen." Verifizierung ordnet eine Anfrage zu. Ihre Policy entscheidet weiterhin, was diese zugeordnete Partei tun darf.
- "Agenten sollten blockiert werden, solange nicht bewiesen ist, dass sie menschlich sind." Viele Agenten sind legitime Teilnehmer. Die bessere Frage ist, was jede Art von Actor Route für Route tun darf.
- "Autorisierung kann aus Verhalten abgeleitet werden." Verhalten kann die Wahrscheinlichkeit erhöhen oder senken, welche Art von Actor vorhanden ist. Es sollte nicht allein Berechtigung verleihen.
Wie Proof of Actor damit umgeht
Proof of Actor beantwortet die Beweisfrage: Welche Art von Actor ist vorhanden, auf welcher Grundlage (Verified, Declared, Inferred oder Unknown), und was ist bekannt und was nicht. Es trifft bewusst keine Berechtigungsentscheidung. Ein Agent-Ergebnis, selbst ein verifiziertes, impliziert niemals Autorisierung. In Route kombiniert Ihre Anwendung das Actor-Ergebnis mit ihren eigenen Anmeldedaten, Scopes und Risikostufen, um jede Interaktion zu allow, adapt, challenge, review oder limit, beginnend im Beobachtungsmodus, damit Sie die Ergebnisse prüfen können, bevor Sie etwas enforce.
Erfahren Sie mehr darüber, wie Entscheidungen in Ihre App passen, sehen Sie sich die Anwendungsfälle für APIs und MCP servers an oder bewerben Sie sich für frühzeitigen Zugang.
Quellen
- RFC 6749: The OAuth 2.0 Authorization Framework: Scoped Tokens für Clients
- MCP specification 2026-07-28: Authorization: OAuth-basierte Autorisierung für MCP server
- RFC 9421: HTTP Message Signatures: Was eine signierte Anfrage festlegt