Ein KI-Agent, der in verbundenen Konten handelt, kann Daten verändern oder Geschäftsprozesse auslösen. Vor der Anbieterwahl können Geschäftsverantwortliche und Sicherheitsprüfer die Kontrollen für einen vorgeschlagenen Arbeitsablauf mit den schriftlichen Anforderungen der Organisation vergleichen. Das Ergebnis ist eine datierte Nachweissammlung. Unbeantwortete Fragen bleiben offen; eine Produktaussage allein belegt nicht, dass eine Handlung verhindert wird. Die Methode stützt sich auf das NIST AI Risk Management Framework Playbook und das AI Agent Security Cheat Sheet von OWASP. Keines davon hat den betrachteten Anbieter geprüft.

Die wesentliche Änderung

  • Was sich geändert hat: Zum Kauf eines Agenten können delegierte Handlungen in Geschäftssystemen gehören. Käufer müssen wissen, wer den Agenten zum Handeln bringen kann, worauf er einwirken darf und wessen Zustimmung nötig ist.
  • Warum das wichtig ist: Käufer können jede vorgeschlagene Handlung mit einer benannten Kontrolle und deren Nachweisen verbinden. Das gibt Geschäftsverantwortlichen und Sicherheitsprüfern eine konkrete Grundlage, um Zugriffe zu begrenzen oder den Kauf zurückzustellen.
  • Worauf Sie achten sollten: Entscheidend sind Nachweise für die genaue Produktversion und den Arbeitsablauf. Eine dokumentierte Kontrolle kann noch eine beaufsichtigte Vorführung erfordern, bevor die Prüfer sie für den vorgesehenen Einsatz akzeptieren.

Vier Grundlagen zusammentragen

Verwenden Sie das vorhandene, von Ihrer Organisation genehmigte schriftliche Risikoprofil. Es sollte Geschäftsverantwortliche, angestrebtes Ergebnis, erlaubte Daten und Ziele, zulässige Handlungen, Genehmigungsbefugnisse, untragbare Folgen und Abbruchbedingungen benennen. Gibt es keines, lassen Sie es vor der Anbieterprüfung von den Verantwortlichen festlegen. Diese Anleitung kann deren Risikotoleranz nicht für sie bestimmen.

Die NIST-Empfehlung MANAGE 3.1 fordert, die Risikotoleranz der Organisation auf KI-Systeme Dritter anzuwenden und deren Kontrollen zu dokumentieren. Das Playbook macht freiwillige Vorschläge und ist keine allgemeingültige Einkaufsliste. Die folgenden Fragen zu Handlungskontrollen greifen auch die agentenspezifischen Sicherheitsempfehlungen von OWASP auf. Die Rahmenwerke nennen nützliche Fragen; beantworten müssen sie die Nachweise des Anbieters.

Benennen Sie einen Kandidaten und die genaue betrachtete Produkt- und Bereitstellungsversion. Beschaffen Sie aktuelle Produktunterlagen und Nachweise, die der Anbieter teilen darf. Geben Sie Sicherheitsprüfern und Einkaufsverantwortlichen Zugriff auf die Vergleichsunterlagen. Bewahren Sie sensible Architektur- oder Nachweisdateien an einem genehmigten privaten Ort auf; die Tabelle kann darauf verweisen, statt Geheimnisse zu kopieren.

1. Den Arbeitsablauf in Anforderungen übersetzen

Listen Sie jede vorgeschlagene Agentenhandlung, ihr Zielsystem und die zu lesenden oder ändernden Daten auf. Trennen Sie Lesen von Schreiben sowie von extern sichtbaren oder unumkehrbaren Handlungen. Übernehmen Sie für jede Handlung die passende Vorgabe aus dem schriftlichen Risikoprofil: erlaubte Identität, Werkzeug- und Zielumfang, Freigabe, Protokollierung, Datenverarbeitung, Unterbrechung und Wiederherstellung. Notieren Sie Verantwortliche und Datum des Profils.

Legen Sie je Anforderung eine Tabellenzeile an. So werden Unbekannte sichtbar, statt in einer Gesamtbewertung des Anbieters zu verschwinden. Die Vorgabe, dass der Agent niemals auf ein bestimmtes Konto zugreifen darf, braucht ebenso eine Zeile wie eine erlaubte Handlung.

2. Nachvollziehen, wer handelt und was ausgeführt werden kann

Fragen Sie, welcher Mensch, welches Dienstkonto oder welche Agentenidentität jede Handlung auslöst, wo Zugangsdaten liegen und ob ein Agent einen Auftrag an einen anderen weitergeben kann. Ermitteln Sie die Komponente, die bei der Ausführung die Berechtigung prüft. Vergleichen Sie tatsächliche Werkzeugrechte des Anbieters mit den laut Profil erlaubten Werkzeugen, Operationen, Konten und Zielen. Verlangen Sie Konfigurations- oder Architekturnachweise für diese Produktversion. Ein Satz in einer Anweisung ist nur ein schwacher Beleg für eine durchgesetzte Grenze.

Fragen Sie bei genehmigungspflichtigen Handlungen, was die prüfende Person vor der Ausführung sieht und wie die Zustimmung an Akteur, genauen Werkzeugaufruf, Ziel und Parameter gebunden wird. Klären Sie, was bei abgelaufener, verweigerter oder doppelt verwendeter Zustimmung sowie bei Änderung der angeforderten Handlung geschieht. Notieren Sie, wie Zugriffe entzogen werden können und wer einen laufenden Vorgang stoppen darf. Ein Genehmigungsbildschirm und eine Prüfung bei der Ausführung beantworten unterschiedliche Fragen. Verlangen Sie beide Nachweise, wenn das Profil beides fordert.

3. Daten und Handlungsprotokolle verfolgen

Zeichnen Sie den vorgeschlagenen Weg von der Eingabe zu Modell, Werkzeugen, externen Empfängern, gespeicherten Kopien und Protokollen. Fragen Sie, welche Daten jede Komponente erhält, wer sie abrufen kann und wie Aufbewahrung und Löschung funktionieren. Berücksichtigen Sie relevante Unterauftragnehmer und systemübergreifende Übertragungen. Kennzeichnen Sie unbeantwortete Fragen zu Zielen oder Aufbewahrung als unbekannt. Leiten Sie Datenschutz nicht aus einer allgemeinen Richtlinienaussage ab.

Verlangen Sie ein Ausführungsprotokoll für die betreffende Version. Können die Prüfer Akteur und Richtlinienversion mit geplantem Werkzeugaufruf, Zustimmung oder Ablehnung, genauem Ziel und Ergebnis verbinden? Prüfen Sie, ob die Unterlagen nur eine Entscheidung, eine tatsächliche Ausführung oder beides zeigen. Bildschirmfoto, Konfigurationsexport und vollständige Ereignisspur belegen Verschiedenes. Notieren Sie Schwärzungen, die den Vergleich verhindern, und halten Sie Zugangsdaten sowie personenbezogene Daten aus der Tabelle heraus.

4. Nachweise für Fehlerfälle anfordern

Verlangen Sie versionsbezogene Nachweise für eine erlaubte Handlung und die vom Profil geforderten Fehlerpfade: verweigerte oder abgelaufene Zustimmung, Werkzeuge oder Ziele außerhalb des erlaubten Umfangs, unterbrochene Ausführung und gegebenenfalls Fehler bei Protokollierung oder Richtlinienprüfung. Notieren Sie, was wann mit welchen Richtlinien und Werkzeugeinstellungen geprüft wurde sowie erwartetes und beobachtetes Ergebnis. Ein Testplan fordert Nachweise an; er ist kein beobachtetes Ergebnis.

Die verantwortliche Sicherheitsprüfung entscheidet, ob eine beaufsichtigte Vorführung nötig ist, und genehmigt deren Umfang. Verwenden Sie erlaubte Eingaben und Konten außerhalb der Produktivumgebung. Verbinden Sie keine laufenden Geschäftssysteme nur zum Ausfüllen einer Einkaufstabelle. Kann der Anbieter keinen Nachweis liefern, halten Sie die Lücke und die nächste Anfrage fest, statt ein Testergebnis zu erfinden.

5. Entscheidung und offene Arbeit festhalten

Kennzeichnen Sie jede Zeile nur als passend, wenn die vorgelegten Nachweise die schriftliche Anforderung für diese Version und diesen Ablauf abdecken. Bei Widerspruch markieren Sie Lücke, bei fehlenden oder zu schwachen Nachweisen unbekannt. Notieren Sie widersprüchliche Unterlagen und wer sie klären muss. Geschäftsverantwortliche und verantwortliche Sicherheitsprüfer dokumentieren danach ihre tatsächliche Entscheidung: weitere Nachweise anfordern, Genehmigung für einen begrenzten Pilotversuch suchen, aufschieben oder ablehnen. Eine passende Zeile ist eine Beurteilung der Nachweise, keine Sicherheitsgarantie und kein Ersatz für das Einkaufsverfahren der Organisation.

Datieren Sie die Unterlagen und prüfen Sie betroffene Zeilen erneut, wenn Arbeitsablauf, Produktversion, Richtlinie, verbundene Konten oder Datenziele wechseln. Ein späterer Pilotversuch braucht eigene Genehmigung, Grenzen und Prüfung.

Anforderung aus dem schriftlichen Profil

Anbieternachweis, Version und Datum

Art des Nachweises und was er belegt

Passend, Lücke oder unbekannt

Prüfer und nächste Handlung

[Eine Handlungs- oder Kontrollanforderung]

[Privater Link oder Dokumentverweis; Version; Datum]

[Behauptung, Konfiguration, Ereignisprotokoll oder beobachtete Vorführung; Einschränkung]

[Eine Kategorie auswählen und erklären]

[Name, Nachweisanfrage oder Entscheidung]

Kopf der Unterlagen: Arbeitsablauf und Verantwortliche; Risikoprofilversion und Genehmigungsdatum; Produktkandidat und Bereitstellungsversion; Prüfdatum; Sicherheitsprüfer; Einkaufsverantwortliche; Speicherort zugangsbeschränkter Nachweise. Entscheidungsprotokoll: Entscheidung, offene Zeilen, akzeptierte Grenzen oder ausgleichende Kontrollen, verantwortliche Genehmigende und Anlass der nächsten Prüfung. Lassen Sie diese Felder leer, bis die Verantwortlichen sie tatsächlich prüfen.

Die öffentlichen Empfehlungen, aus denen diese Fragen abgeleitet sind, sind frei zugänglich. Der Vergleich erfordert Arbeitszeit von Mitarbeitern und Prüfern. Anbieternachweise, vertraulicher Zugang und genehmigte Vorführungen können Kosten verursachen oder die Prüfbarkeit begrenzen. Erfragen Sie die tatsächlichen Bedingungen beim Kandidaten. Diese Dokumentenarbeit testet keinen Anbieter und stellt weder Rechtskonformität noch eine allgemeine Kaufgrenze fest.

Quellen und weiterführende Informationen

  1. NIST AI RMF Playbook, Manage unterstützt die Anwendung der eigenen Risikotoleranz einer Organisation auf KI-Ressourcen Dritter sowie Dokumentation und Bewertung ihrer Kontrollen. Die Webseite erklärt, dass AI RMF 1.0 überarbeitet wird und das Playbook folgen soll; ein Revisionsdatum der Seite fehlt. Der Anbieter wird darin nicht bewertet.
  2. Einführung zum NIST AI RMF Playbook beschreibt die Vorschläge als freiwillig und erklärt, dass das Playbook keine vollständig abzuarbeitende Checkliste ist. Die Tabelle hier ist eine Zusammenstellung von BIG CHANGE für die genannte Leseraufgabe.
  3. OWASP AI Agent Security Cheat Sheet behandelt begrenzte Werkzeugrechte, Autorisierung bei der Ausführung, an Handlungen gebundene Freigaben, Protokollierung, Datenschutz und versionsbezogene Validierungsnachweise. Die aktuelle Webseite nennt weder Version noch Veröffentlichungsdatum. Die Empfehlungen sind Nachweiskategorien und kein Beleg, dass ein Anbieter sie umsetzt.