NISTs vorgeschlagene Grundsätze zur Agentenidentität geben KI-Assurance-Teams einen nützlichen Ausgangspunkt, um die Verantwortung für Nachweise zuzuordnen. Der praktische nächste Schritt besteht darin, einen folgenreichen Workflow zu nehmen und festzulegen, wer belegen kann, dass dessen Identität, delegierte Befugnisse und Zugriffskontrollen funktionieren. Eine bloße Liste von Prinzipien beantwortet diese Fragen nicht.
In einer Veröffentlichung vom 27. Oktober hat NIST zehn erste Designgrundsätze für das Management von Agentenidentitäten vorgeschlagen. Sie umfassen eigenständige Agentenidentitäten, eingeschränkte Delegation, begrenzte Rechte, widerrufbare Autorisierung, Auslöser für menschliche Prüfung, signierte Mandate, die Trennung von Richtlinie und Schlusslogik, deterministische Zugriffsentscheidungen, Überwachung und unveränderliche Nachweise. NIST betont, dass die Umsetzung das Transaktionsrisiko und den Bereitstellungskontext widerspiegeln sollte, und räumt ein, dass aktuelle Standards und Technologien möglicherweise nicht jeden Grundsatz sofort erfüllen können.
Dies sind vorgeschlagene Designprinzipien. Die Veröffentlichung begründet keine neue Rechtspflicht und zertifiziert kein Produkt. Die folgende Analyse von Maetra konzentriert sich darauf, wie eine für Compliance verantwortliche Person diesen Vorschlag in einen belastbaren Nachweisplan überführen könnte.
Jeder Kontrolle eine Person zuordnen, die sie belegen kann
Betrachten wir einen beispielhaften Support-Agenten, der eine Kundenerstattung vorschlagen kann. Die fachliche verantwortliche Stelle weiß, wann eine Erstattung angemessen ist. Ein Identitätsteam verwaltet Anmeldedaten. Ein Anwendungsteam kontrolliert den Endpunkt für Erstattungen. Ein Sicherheitsteam überwacht ungewöhnliche Aktivitäten. Jedes Team kann einen nützlichen Teil der Antwort liefern, während niemand den gesamten Workflow besitzt.
Maetra empfiehlt, mit einem kurzen Eintrag zu beginnen, der den Workflow, die folgenschwere Aktion, die verantwortliche Stelle und die beteiligten Systeme benennt. Ordnen Sie jede Kontrollfrage einem verantwortlichen Team zu. So sollte beispielsweise das für den Endpunkt verantwortliche Team nachweisen können, was passiert, wenn eine ansonsten gültige Anfrage mit bereits abgelaufener Befugnis eingeht.
Der Nachweis sollte die tatsächlich getestete Konfiguration eindeutig benennen. Ein Screenshot aus einem früheren Pilotbetrieb kann belegen, dass eine Einstellung einmal existierte, aber nicht, dass sie in der heutigen Bereitstellung noch verwendet wird. Halten Sie deshalb Umgebung, Konfigurationsrevision, Testdatum und prüfende Person zusammen mit dem Ergebnis fest.
Die Prüfung an einer realen Transaktion ausrichten
Die folgende Struktur ist ein Vorschlag für eine Prüfung, keine offizielle NIST-Zuordnung und auch keine Aussage, dass jede Bereitstellung bereits jedes Designziel erfüllen kann.
| Prüfungsfrage | Empfohlene verantwortliche Stelle | Nützlicher Nachweis |
|---|---|---|
| Welcher Agent und welche Workload haben die Anfrage gestellt? | Identitäts- oder Plattformteam | Identitätsregistrierung, verknüpft mit der bereitgestellten Konfiguration |
| Welche Befugnis erreichte den nachgelagerten Dienst? | Anwendungsverantwortliche Stelle | Ein abgegrenzter Test, der die angeforderte Aktion und den zulässigen Umfang zeigt |
| Was passiert, wenn die Befugnis abläuft oder widerrufen wird? | Identitäts- und Endpunktverantwortliche | Ein dokumentiertes Ablehnungsergebnis an der tatsächlichen Durchsetzungsgrenze |
| Welche Risikobedingung erfordert eine menschliche Prüfung? | Verantwortliche Stelle für die fachliche Kontrolle | Versionierte Regel, Prüfverantwortung und ein Test des Pfads in den Status „ausstehend“ |
| Kann der Agent seinen eigenen aufbewahrten Verlauf verändern? | Verantwortliche Stelle für die Nachweisinfrastruktur | Zugriffskonfiguration und ein unabhängig aufbewahrtes Testprotokoll |
In einer kleinen Organisation können mehrere Verantwortlichkeiten bei einer Person liegen. Der Eintrag sollte die Verantwortlichkeiten dennoch getrennt ausweisen. Andernfalls kann ein fehlgeschlagener Test zwischen Teams hin- und hergeschoben werden, ohne dass jemand für die Korrektur verantwortlich ist.
Lücken dokumentieren, ohne sie standardmäßig als Ausnahmen umzudeuten
Ein brauchbarer Assurance-Eintrag muss Raum für Unsicherheit lassen. Wenn ein nachgelagerter Dienst eine weit gefasste Berechtigung akzeptiert, die sich nicht auf die konkrete Aufgabe eingrenzen lässt, dokumentieren Sie diese Einschränkung und die betroffene Aktion. Kennzeichnen Sie den Grundsatz nicht als erfüllt, nur weil der Agent einen sorgfältig formulierten Prompt erhalten hat.
Maetra empfiehlt, drei Zustände sauber zu trennen: in der aktuellen Umgebung nachgewiesen, geplant aber ungetestet und derzeit nicht unterstützt. Ergänzen Sie zu jedem Zustand den Nachweislink und den Auslöser für die nächste Prüfung. So wird eine Roadmap überprüfbar, ohne künftige Entwicklungsarbeit als bereits umgesetzte Kontrolle darzustellen.
Bei einem Workflow mit hoher Tragweite kann eine ungelöste Lücke rechtfertigen, die durch den Agenten erreichbaren Aktionen zu reduzieren, während die verantwortliche Stelle Alternativen bewertet. Diese Entscheidung gehört in den Risikoprozess der Organisation. Die vorgeschlagenen Grundsätze liefern weder einen allgemeingültigen Risikoschwellenwert noch schreiben sie vor, dass jede Aktion eine menschliche Freigabe erfordert.
Nachweise nur wiederverwenden, wenn dieselbe Grenze gilt
Ein Test der Identitätsplattform kann mehrere interne Assurance-Fragen stützen. Wiederverwendung ist hilfreich, wenn die darauf gestützten Workflows tatsächlich dieselbe Konfiguration und denselben Durchsetzungspfad nutzen. Irreführend wird sie, wenn ein Team ein erfolgreiches Testergebnis von einem Endpunkt auf einen anderen überträgt, der andere Anmeldedaten akzeptiert oder dieselbe Prüfung umgeht.
Führen Sie eine einfache Abhängigkeitsdokumentation: Welche Workflows stützen sich auf diesen Nachweis, welche Konfiguration teilen sie sich und welche Änderung macht die Schlussfolgerung ungültig? Eine Änderung der Berechtigungsrichtlinie, ein neuer nachgelagerter Dienst oder ein neuer Delegationspfad sollten eine eingegrenzte Prüfung auslösen. Das ist eine empfohlene betriebliche Praxis, kein von NIST vorgegebenes Aktualitätsintervall.
Ein unabhängiger Kommentar von Oktsec behandelt ebenfalls Laufzeitprüfungen und Lücken in Bereitstellungen. Dabei handelt es sich um die Umsetzungsbewertung des Autors zu seinem eigenen Produkt, nicht um eine Bewertung durch NIST. Teams sollten Nachweise aus ihrer eigenen Bereitstellung verlangen, bevor sie die Behauptung eines Anbieters zur Übereinstimmung akzeptieren, einschließlich der von Maetra.
Ein nützliches erstes Ergebnis
Wählen Sie eine Aktion aus und erstellen Sie einen Prüfvermerk, den eine andere Person nachvollziehen kann, ohne am ursprünglichen Projekt beteiligt gewesen zu sein. Nehmen Sie die verantwortliche Stelle, die aktuelle Konfiguration, die verwendete Befugnis, eine erfolgreich zugelassene Anfrage, eine abgewiesene Anfrage und die offenen Lücken auf. Lassen Sie das für den betreffenden Endpunkt verantwortliche Team bestätigen, was diese Ergebnisse tatsächlich belegen.
Maetra Comply unterstützt Framework-Zuordnung und Nachweismanagement. Es kann dabei helfen, relevante Kontrollnachweise und ihre Zuständigkeiten zu organisieren, während die Bereitstellungsteams weiterhin selbst nachweisen müssen, dass Identitäts- und Zugriffsdurchsetzung funktionieren. Als Ausgangspunkt können Sie sich die Framework-Abdeckung von Maetra ansehen und einen bestehenden Kontrolleintrag auswählen, den Sie verbessern.
Quellen
- NIST: Design Tenets for Agent Identity Management Systems, 27. Oktober 2026.
- Oktsec: NIST's agent identity tenets, read from the runtime, 30. Oktober 2026. Unabhängiger Anbieterkommentar, keine Zertifizierung und keine Produktvalidierung durch NIST.