Identität und Authentifizierung von KI-Agenten für MVPs

Ein KI-Agent kann APIs aufrufen, Dokumente lesen, Nachrichten versenden oder Datensätze im Namen eines Nutzers aktualisieren. Wenn jede Aktion einen gemeinsamen Servicenschlüssel oder die vollständigen Zugangsdaten des Nutzers verwendet, kann das System grundlegende Fragen nicht zuverlässig beantworten: Welcher Agent hat gehandelt? Wer hat die Berechtigung delegiert? Was durfte er tun? Kann diese Berechtigung widerrufen werden, ohne alle anderen zu beeinträchtigen?

Die Agentenidentität ist die Grundlage für diese Antworten. Sie sollte als Sicherheit für Workloads entworfen werden, nicht als Persönlichkeit, Anzeigename oder Prompt-Anweisung.

Die beteiligten Identitäten trennen

Unterscheiden Sie mindestens den menschlichen oder systemischen Principal, die Agenten-Workload und das aufgerufene Tool beziehungsweise die Ressource. Bewahren Sie ihre Beziehung in jeder sensiblen Anfrage.

Ein Nutzer kann einen Agenten zur Ausgabenprüfung autorisieren, Rechnungen für eine Organisation zu lesen. Die Agentenidentität weist nach, welche Workload den Aufruf ausgeführt hat; der delegierte Kontext identifiziert Nutzer und Mandant; die Autorisierungsrichtlinie begrenzt die zulässigen Datensätze und Aktionen. Das Tool authentifiziert sich weiterhin beim Agenten oder Gateway.

Dieses Modell entspricht der NIST-Konzeptarbeit von 2026 zu Identität und Autorität von Software- und KI-Agenten, die Identifizierung, Authentifizierung, Autorisierung, Delegation, Auditierung und Risiken durch Prompt-Injection hervorhebt.

Authentifizierung und Autorisierung getrennt behandeln

Die Authentifizierung beantwortet die Frage „Wer oder was ist das?“ Die Autorisierung beantwortet: „Darf es diese Aktion jetzt ausführen?“ Ein gültiger Agenten-Nachweis sollte keinen weitreichenden Zugriff implizieren.

Verwenden Sie kurzlebige Workload-Zugangsdaten und halten Sie Geheimnisse aus dem Prompt und dem Gesprächskontext des Modells heraus. Prüfen Sie Richtlinien an einem vertrauenswürdigen Tool-Gateway oder an einer Servicegrenze. Begrenzen Sie Berechtigungen nach Möglichkeit nach Mandant, Ressource, Aktion, Zweck und Dauer.

Kontrolle	MVP-Umsetzung
Identität	Eindeutige Agenten-/Workload-Kennung
Authentifizierung	Kurzlebiger signierter Nachweis oder etablierte Workload-Identität
Delegation	Nutzer- und Mandantenkontext mit explizitem Umfang
Autorisierung	Serverseitige Zulassen-/Ablehnen-/Zurückstellen-Entscheidung
Widerruf	Agent, Zugangsdaten oder Berechtigung unabhängig deaktivieren
Audit	Akteur, Principal, Tool, Entscheidung, Ergebnis und Zeitpunkt erfassen

Prompt-Anweisungen wie „Lösche niemals Daten“ sind nützliche Verhaltenshinweise, aber keine Zugriffskontrollgrenze. Eine manipulierte oder fehlerhafte Modellausgabe sollte eine unabhängige Richtlinienprüfung durchlaufen.

Das Prinzip der geringsten Rechte auf Tools anwenden

Geben Sie einem Agenten keinen universellen API-Schlüssel. Erstellen Sie eng begrenzte Fähigkeiten: genehmigte Datensätze lesen, eine Nachricht als Entwurf erstellen oder eine vorgeschlagene Änderung einreichen. Trennen Sie „Vorbereiten“ und „Ausführen“, wenn die Folgen erheblich sind.

Validieren Sie Tool-Argumente anhand eines Schemas und erzwingen Sie Mandantengrenzen aus dem authentifizierten Kontext, nicht aus vom Modell gelieferten IDs. Fügen Sie Limits für Rate, Ausgaben und Volumen hinzu. Verlangen Sie bei irreversiblen, finanziellen, extern sichtbaren oder ungewöhnlich weitreichenden Aktionen eine menschliche Freigabe.

Der Leitfaden zu Leitplanken für KI-Agenten zeigt, wie Berechtigungen mit Eingabevalidierung und menschlicher Prüfung zusammenspielen.

Delegation und Verantwortlichkeit bewahren

Wenn ein Agent im Auftrag einer Person handelt, sollte das nachgelagerte Protokoll nicht beide Identitäten zu einer einzigen zusammenfassen. Erfassen Sie den verantwortlichen Principal, die Agentenversion, die aktive Berechtigung, das angeforderte Tool, die Richtlinienentscheidung und das Ergebnis. Vermeiden Sie die Protokollierung sensibler Prompt-Inhalte, sofern sie nicht erforderlich und geschützt ist.

Delegation sollte Autorität abschwächen, nicht erweitern. Ein Unteragent kann nicht sicher jede Berechtigung des aufrufenden Agenten erben. Übergeben Sie nur die für die Teilaufgabe erforderliche Fähigkeit, mit kurzer Gültigkeit und nachvollziehbarer übergeordneter Anfrage.

Die entstehende IETF-Arbeit beschreibt KI-Agenten als Workloads, die etablierte Identitätsstandards nutzen und dabei den delegierten Nutzerkontext bewahren können. Diese Dokumente sind noch Entwürfe; vermarkten Sie experimentelle Protokolle daher nicht als etablierte Standards. Bauen Sie auf ausgereiften Grundlagen auf und halten Sie die Identitätsschicht austauschbar.

Entscheiden, ob ein Register oder eine Blockchain nötig ist

Ein Register kann Organisationen dabei helfen, Schlüssel, Eigentümer, Status und Metadaten von Agenten zu entdecken. Ein blockchainbasiertes oder dezentrales Register kann für Parteien ohne gemeinsame Identitätsinstanz relevant sein, bringt aber Fragen zu Datenschutz, Widerruf, Governance und Integration mit sich.

Die meisten frühen Produkte arbeiten innerhalb einer Organisation oder mit wenigen bekannten Partnern. Ein herkömmlicher Identitätsanbieter, Workload-Zugangsdaten, signierte Tokens und ein Richtliniendienst sind in der Regel einfacher. Fügen Sie eine organisationsübergreifende Verifizierung erst hinzu, wenn eine reale Interaktion sie erfordert.

Identitätsfehler vor dem Start testen

Spielen Sie einen abgelaufenen Nachweis, einen widerrufenen Agenten, einen nicht passenden Mandanten, eine wiederholte Anfrage, ein verändertes Argument, übermäßige Ausgaben und einen nicht verfügbaren Freigabedienst durch. Stellen Sie sicher, dass der sichere Standard greift und Betreiber die Ablehnung verstehen können.

Testen Sie auch indirekte Prompt-Injection. Nicht vertrauenswürdige Inhalte aus Seiten oder Dokumenten dürfen keine Tools freigeben oder Richtlinien ändern können. Begrenzen Sie, worauf abgerufene Inhalte Einfluss nehmen dürfen, und halten Sie Zugangsdaten für das Modell unzugänglich. Lesen Sie das Threat Modeling für KI-Agenten, bevor Sie den Toolzugriff erweitern.

Ein MVP braucht kein universelles Identitätsprotokoll. Es braucht unterscheidbare Akteure, begrenzte und widerrufbare Autorität, unabhängige Durchsetzung und einen Audit-Trail, der Untersuchungen unterstützt. Diese Kontrollen ermöglichen es dem Team, die Autonomie schrittweise zu erhöhen, ohne die Verantwortlichkeit zu verlieren.

Ein Inventar der Agentenidentitäten erstellen

Führen Sie ein kleines Register, selbst wenn es nur ein interner Konfigurationsspeicher ist. Erfassen Sie für jeden bereitgestellten Agenten Eigentümer, Zweck, Umgebung, Version, erlaubte Tools, Aussteller der Zugangsdaten, maximale Autorität, Freigaberichtlinie und aktuellen Status. Trennen Sie Entwicklungs- und Produktionsidentitäten, damit ein Testagent keine Kundenressourcen erreichen kann.

Definieren Sie Lebenszyklusereignisse. Stellen Sie Identitäten über einen geprüften Prozess bereit, rotieren Sie Zugangsdaten automatisch und deaktivieren Sie einen Agenten, wenn sein Eigentümer das Unternehmen verlässt, sein Workflow eingestellt wird oder verdächtiges Verhalten auftritt. Der Widerruf muss an der Durchsetzungsstelle wirksam werden; einen Prompt zu ändern oder einen Anzeigeeintrag zu entfernen reicht nicht aus.

Prüfen Sie den effektiven Zugriff statt des beabsichtigten Zugriffs. Tool-Berechtigungen, delegierte Nutzerbereiche, Netzwerkpfade, zwischengespeicherte Tokens und Berechtigungen von Unteragenten können sich zu einer umfassenderen Autorität verbinden. Testen Sie, ob ein Nutzer mit geringen Rechten einen Agenten dazu bringen kann, Daten eines anderen Mandanten zu lesen oder zu ändern. Protokollieren Sie abgelehnte Versuche, damit Sicherheitsteams Richtlinienfehler von Angriffsmustern unterscheiden können.

Machen Sie die Identität schließlich dort für Betreiber und Nutzer sichtbar, wo sie eine informierte Freigabe unterstützt. Ein Freigabebildschirm sollte angeben, welcher Agent welche Aktion für wen, gegen welche Ressource und mit welcher Folge vorschlägt. Dieser Kontext macht aus einer allgemeinen Bestätigung eine sinnvolle Autorisierungsentscheidung und verringert die Wahrscheinlichkeit, dass Menschen riskante Aktionen aus Gewohnheit freigeben.

Halten Sie die erste Identitätsarchitektur bewusst klein: Ein Aussteller, eine Durchsetzungsgrenze, kurzlebige Zugangsdaten und ein eindeutiger Audit-Speicher können für einen begrenzten Workflow ausreichen. Die Komplexität sollte dem tatsächlichen Bedarf an Föderation oder Delegation folgen. Auch dieses kleine Design braucht Tests für Zeitabweichungen, Schlüsselrotation, nicht verfügbare Identitätsdienste und doppelte Anfragen. Eine sichere Ablehnung darf die Aufgabe des Nutzers nicht beschädigen; bewahren Sie einen Entwurf oder stellen Sie sichere Arbeit in eine Warteschlange, damit ein Authentifizierungsausfall Betreiber nicht dazu drängt, Kontrollen zu umgehen.

Häufig gestellte Fragen

Braucht ein KI-Agent eine eigene Identität?

Ein Agent, der Tools aufruft oder auf Daten zugreift, sollte vom Menschen, der Anwendung und anderen beteiligten Agenten unterscheidbar sein. Das ermöglicht gezielte Berechtigungen, Widerruf und aussagekräftige Audit-Einträge.

Ist die Authentifizierung eines Agenten dasselbe wie Autorisierung?

Nein. Die Authentifizierung stellt fest, welche Workload handelt; die Autorisierung entscheidet, welche Ressource und Aktion sie im aktuellen delegierten Kontext verwenden darf. Beides ist erforderlich.

Sollte ein MVP Blockchain für die Agentenidentität nutzen?

Nur wenn die organisationsübergreifende Verifizierung tatsächlich ein dezentrales Register erfordert und die Nachteile gerechtfertigt sind. Die meisten MVPs sollten mit etablierter Workload-Identität, OAuth-ähnlicher Delegation, kurzlebigen Zugangsdaten und serverseitiger Richtliniendurchsetzung beginnen.