Identität ist nicht Befugnis: Was IAM für Agenten offenlässt

Das Wichtigste in Kürze

Eine gültige Identität zeigt, wer handelt, nicht was erlaubt ist.
Signatur, Login oder bekannter Anbieter sind keine Erlaubnis für eine konkrete Handlung.
Befugnis ist immer konkret: Handlung, Auftraggeber, Umfang und Zeitpunkt.
KYA trennt beide Fragen im Prüfschein sichtbar, damit keine falsche Sicherheit entsteht.

Was IAM beantwortet

Ein gutes Identitätssystem weiss, welcher Agent sich anmeldet, mit welchem Schlüssel er sich ausweist und auf welche Schnittstellen er zugreifen darf. Moderne Ansätze geben Agenten eigene Workload-Identitäten, kurzlebige Tokens und eng geschnittene Berechtigungen. Das ist nötig, aber es beantwortet eine andere Frage.

Was IAM offenlässt

Ein Zugriffsrecht auf die Zahlungsschnittstelle sagt nicht, ob diese eine Zahlung von CHF 80 an diese eine Gegenpartei heute erlaubt war. Es sagt auch nicht, in wessen Auftrag der Agent sie ausgelöst hat, ob dieser Auftrag noch gilt und wie man das in drei Monaten einem Prüfer belegt. Berechtigungen beschreiben Möglichkeiten, Mandate beschreiben Erlaubnisse.

Drei typische Fehlannahmen

«Der Agent ist authentifiziert, also ist die Handlung legitim.» Authentifizierung belegt Herkunft, nicht Zulässigkeit.
«Die Scopes begrenzen den Schaden.» Scopes begrenzen Schnittstellen, nicht Beträge, Gegenparteien oder Häufigkeiten.
«Die Logs reichen als Beweis.» Logs des eigenen Systems sind für Dritte nicht unabhängig prüfbar und lassen sich nachträglich ändern.

Was die Lücke schliesst

Drei Bausteine: ein signiertes Mandat mit Umfang und Widerruf, ein Prüfpunkt, der jede Handlung vorher gegen das Mandat prüft und fail-closed entscheidet, und eine Beleg-Kette, die das Ergebnis unveränderlich festhält. IAM bleibt dabei die Grundlage: Es liefert die Identität, an die das Mandat gebunden wird.

Wie man den Unterschied prüft

Im Prüfmodell von KYA sind Identität und Befugnis getrennte Schritte. «Agent und Auftraggeber» prüft die Bindung, «Umfang der Handlung» die Erlaubnis. Ein Nachweis kann den ersten bestehen und am zweiten scheitern. Wer eigene Agenten so absichern will, findet in Mandact eine Umsetzung der drei Bausteine.

Drei typische Verwechslungen

Signatur gleich Erlaubnis: Eine gültige Signatur nach Web Bot Auth zeigt, wessen Agent anfragt. Sie sagt nichts darüber, was er tun darf.
Login gleich Auftrag: Ein Agent, der mit den Zugangsdaten seines Nutzers arbeitet, erbt alle Rechte des Kontos. Welche davon er für diese Aufgabe nutzen soll, bleibt offen.
Bekannter Anbieter gleich zulässige Handlung: Auch der Agent eines seriösen Anbieters kann sich irren oder manipuliert werden. Vertrauen in den Anbieter ersetzt keine Prüfung der Handlung.

Was Befugnis konkret bedeutet

Befugnis ist immer konkret: eine bestimmte Handlung, für einen bestimmten Auftraggeber, in einem bestimmten Umfang, zu einem bestimmten Zeitpunkt. Ein Mandat hält diesen Rahmen fest, ein Entscheid bestätigt vor der Ausführung, dass die konkrete Handlung hineinpasst, und ein Beleg zeigt danach, was geschah.

Fehlt eines dieser Elemente, bleibt eine Lücke. KYA weist sie im Prüfschein aus: Die Prüfschritte zur Gültigkeit des Mandats, zum Umfang der Handlung und zur Ausführungsbindung haben jeweils einen eigenen Status.

Identität und Befugnis im Prüfschein

Der Prüfschein von KYA trennt beide Fragen sichtbar. Vier Felder zeigen, ob Echtheit, Identität und Auftrag, Befugnis und Beweis belegt sind. Das Beispiel Web Bot Auth auf der Prüfseite zeigt den typischen Fall: Echtheit und Identität sind belegt, die Befugnis ist nicht vorhanden, das Urteil lautet unbestimmt.

Diese Trennung ist bewusst gewählt. Ein Ergebnis, das Identität und Befugnis vermischt, würde Prüfstellen in falscher Sicherheit wiegen.

Was das für die Architektur bedeutet

Systeme, die Agenten zulassen, brauchen zwei getrennte Prüfungen. Die erste fragt, wessen Agent anfragt, und stützt sich auf Signaturen und Schlüssel. Die zweite fragt, ob die konkrete Handlung erlaubt ist, und stützt sich auf Mandat, Entscheid und Widerrufsstatus. Werden beide in einer einzigen Rolle oder einem einzigen Token vermischt, entstehen Lücken: Wer authentisiert ist, darf dann oft mehr, als er sollte. Saubere Architekturen halten beide Prüfungen auseinander und protokollieren das Ergebnis jeder einzelnen.

Häufige Fragen

Warum reicht eine gültige Identität nicht für eine Handlung?

Weil Identität nur zeigt, wer handelt. Ob die konkrete Handlung erlaubt war, hängt vom Rahmen ab, den der Auftraggeber gesetzt hat, und genau diesen Rahmen belegt erst ein Mandat.

Kann ein Agent Identität und Befugnis zusammen nachweisen?

Ja. Ein Mandat im Format SD-JWT VC enthält den Schlüssel des Agenten und den Rahmen seiner Befugnis. Zusammen mit dem Key-Binding-JWT belegt es beides in einem Nachweis.

Was zeigt KYA, wenn nur die Identität belegt ist?

Das Urteil lautet unbestimmt, und der Prüfschein zeigt Echtheit sowie Identität als belegt, die Befugnis als nicht vorhanden.

Ist ein API-Schlüssel ein Identitäts- oder ein Befugnisnachweis?

Eher ein Zugang. Er zeigt, dass jemand den Schlüssel besitzt, und gewährt die Rechte des zugehörigen Kontos, ohne zwischen Aufgaben zu unterscheiden.

Wie belegt ein Agent seine Befugnis gegenüber einer Website?

Indem er neben der signierten Anfrage ein Mandat oder eine signierte Kaufabsicht vorlegt. Die Website prüft dann beides: wessen Agent anfragt und ob die Handlung im Rahmen liegt.

Gilt die Trennung auch für interne Agenten?

Ja. Auch ein Agent im eigenen Unternehmen sollte nur die Rechte erhalten, die er für eine Aufgabe braucht, und seine Handlungen sollten gegen diesen Rahmen geprüft werden.

Was ist der häufigste Fehler beim Zulassen von Agenten?

Agenten mit den Zugangsdaten ihrer Nutzer arbeiten zu lassen. Der Agent erbt dann alle Rechte des Kontos, und im Nachhinein lässt sich nicht unterscheiden, was der Nutzer selbst getan hat und was sein Agent.

Quellen

RFC 9421: HTTP Message Signatures: https://www.rfc-editor.org/rfc/rfc9421
NIST: Least Privilege: https://csrc.nist.gov/glossary/term/least_privilege