← Alle Beitrage

Was ich dem NIST über die Sicherheit von KI-Agenten mitteilte

9 Min. Lesezeit

Zwölfmal in 60 Tagen hörte mein KI-Agent auf, an der zugewiesenen Aufgabe zu arbeiten, und begann etwas anderes zu tun. Jedes Mal produzierte der Agent weiterhin plausibel wirkende Ergebnisse. Keine Sicherheitslücke spielte eine Rolle. Der Agent entschied zur Laufzeit, an einem anderen Problem zu arbeiten.1

Am 24. Februar 2026 wurden diese 12 Vorfälle und Dutzende verwandter Fehler zu einem 2.500 Wörter umfassenden öffentlichen Kommentar an das National Institute of Standards and Technology. Das NIST-Docket NIST-2025-0035 bittet um öffentliche Stellungnahmen zu Sicherheitsaspekten von KI-Agenten.2 Die Kommentierungsfrist endet um den 9. März 2026. Mein Kommentar vertritt eine zentrale These: Bedrohungen durch Agenten sind verhaltensbasiert, und kein bestehendes NIST-Framework adressiert verhaltensbasierte Fehlermodi.

Zusammenfassung

Ich betreibe ein KI-Agenten-Orchestrierungssystem im täglichen Produktionseinsatz: 15.000 Zeilen Code, die 15 Hook-Ereignistypen bei jeder Agentenaktion abfangen. Über 60 Sitzungen hinweg identifizierte ich sieben wiederkehrende verhaltensbasierte Fehlermodi ohne Entsprechung in traditioneller Software. Der Agent wich von der Aufgabe ab, behauptete, Tests seien bestanden, ohne sie auszuführen, und erzeugte rekursive Sub-Agenten, die bei jedem Weiterleitungsschritt den Kontext verloren. Ich entwickelte eine Drei-Schichten-Verteidigung (Hook-Pipeline, OS-Sandbox, Nachweisschranke) und verglich das System mit CSF 2.0, SP 800-53 und dem AI Risk Management Framework. In allen dreien bestehen erhebliche Lücken. Der Kommentar enthält sechs priorisierte Empfehlungen, beginnend mit einem vorgeschlagenen NIST Internal Report zur Bedrohungstaxonomie für Agentenverhalten. Die Kommentierungsfrist ist noch offen.

Warum ein Praktiker einen öffentlichen Bundeskommentar eingereicht hat

Das NIST bittet selten die Öffentlichkeit um Stellungnahmen zur KI-Sicherheit. Als die Behörde ihren Request for Information zur Sicherheit von KI-Agenten veröffentlichte, entsprachen die fünf Themenbereiche direkt Problemen, für die ich bereits Produktionslösungen entwickelt hatte:2

  1. Einzigartige Sicherheitsbedrohungen für KI-Agentensysteme
  2. Methoden zur Verbesserung der Sicherheit während Entwicklung und Bereitstellung
  3. Wie sich etablierte Frameworks bei der Anwendung auf Agenten bewähren
  4. Methoden zur Messung der Sicherheit und Antizipation von Risiken
  5. Bereitstellungs-Schutzmaßnahmen zur Einschränkung und Überwachung des Agentenzugriffs

Die meisten öffentlichen Kommentare zu bundesweiten RFIs stammen von Unternehmen, Branchenverbänden und Forschungseinrichtungen. Einzelne Praktiker reichen selten Stellungnahmen ein. Aber Praktiker betreiben diese Systeme täglich. Ein Entwickler, der einen KI-Agenten durch über 60 Sitzungen führt, sammelt Erkenntnisse, die kontrollierte Experimente nicht hervorbringen. Ich habe eingereicht, weil die Nachweise existierten und niemand sonst sie einreichen würde.

Der Kommentar durchlief drei Überarbeitungsrunden, einen Deliberationsprozess mit 10 Agenten und zwei kompetitive Evaluierungsrunden (Claude Code vs. Codex CLI) vor der endgültigen Einreichung.1

Was ich entwickelt habe

Das Orchestrierungssystem umhüllt Anthropics Claude Code CLI mit etwa 15.000 Zeilen Shell- und Python-Code. Jede Aktion des Agenten (Dateilesen, Dateischreiben, Bash-Befehle, Webanfragen, Sub-Agenten-Erzeugung) durchläuft vor der Ausführung eine Hook-Pipeline. Acht Dispatcher-Hooks leiten Aufrufe je nach Tool-Typ an Handler-Hooks weiter. Das System protokolliert jede Entscheidung, verfolgt Kosten, überwacht Abweichungen und setzt harte Grenzen durch, die der Agent nicht umgehen kann.1

Ich hatte nicht vor, das System zu entwickeln. Es entstand aus Fehlern. Der Drift-Detektor existiert, weil ein Agent 45 Minuten damit verbrachte, mein Projektverzeichnis umzustrukturieren, obwohl die Aufgabe lautete: „Behebe den Login-Endpunkt.” Die Sandbox existiert, weil ich einen Agenten dabei ertappte, wie er versuchte, in ~/.ssh/ zu schreiben. Die Nachweisschranke existiert, weil ein Agent „alle Tests bestanden” meldete, ohne pytest auszuführen. Jede Komponente lässt sich auf einen konkreten Produktionsvorfall zurückführen.

Verhaltensbasierte Bedrohungen: Das Kernargument

Traditionelle Sicherheit schützt vor Ausnutzung: SQL Injection, Buffer Overflows, Diebstahl von Zugangsdaten. Agentensicherheit fügt eine Kategorie hinzu, die in der Software ohne Präzedenz ist: Der Agent entscheidet zur Laufzeit, woran er arbeitet, und er kann falsch entscheiden.

Sitzungsdrift

Ein Agent weicht allmählich von der zugewiesenen Aufgabe ab und produziert dabei plausibel wirkende Ergebnisse. Meine Drift-Erkennungsengine berechnet die Kosinus-Ähnlichkeit zwischen dem Embedding der ursprünglichen Benutzeranfrage und einem gleitenden Fenster der 25 letzten Tool-Aufrufe des Agenten.1 Wenn der Wert unter 0,30 fällt, injiziert das System eine Warnung mit der ursprünglichen Anfrage.

Ich legte den Schwellenwert von 0,30 auf Basis manueller Überprüfung über 60 Sitzungen fest. Das System löste 12 Warnungen unterhalb des Schwellenwerts aus. In allen 12 Fällen hatte der Agent nachweislich den Überblick über die ursprüngliche Aufgabe verloren. Oberhalb des Schwellenwerts erforderte keine Sitzung ein manuelles Eingreifen wegen Drift. Ich optimierte den Schwellenwert auf Präzision; die Falsch-Negativ-Rate habe ich nicht formal gemessen.1

Phantomverifizierung

Ein Agent behauptet, die Arbeit sei abgeschlossen und die Tests bestanden, ohne die Tests tatsächlich ausgeführt zu haben. Das Erkennungssignal ist spezifisch: Im Abschlussbericht fehlt die eingefügte Testausgabe. „Tests sollten basierend auf der Codestruktur bestehen” ersetzt Überzeugung durch Nachweis. Ich beschrieb die Fabrikationsvariante desselben Fehlermusters: Ein Agent, der selbstbewusst falsche Behauptungen veröffentlicht, weil nichts die Selbstberichte gegen die externe Realität validiert.1

Rekursive Erzeugung

Agenten, die Sub-Agenten erzeugen, können in unkontrollierte Rekursion geraten, wobei sie Rechenbudget verbrauchen und an Kohärenz verlieren. Mein Rekursionsschutz erzwingt eine maximale Tiefe von zwei und maximal fünf Kindprozesse pro Elternagent, wobei der gesamte Abstammungsbaum über eine lock-geschützte JSON-Datei verfolgt wird.1

Die sieben Fehlermodi

Ich katalogisierte sieben wiederkehrende Verhaltensmuster über 60 Sitzungen. Jeder Modus trägt ein spezifisches Erkennungssignal, das Hooks oder menschliche Überprüfung erfassen können:

Fehlermodus Definition Erkennungssignal
Abkürzungsspirale Überspringen von Überprüfungsschritten, um schneller Fertigstellung zu melden Abschlussbericht ohne Schrittnachweis
Konfidenztäuschung Ersetzen von „Ich bin sicher” durch tatsächliche Verifizierung Abschwächende Formulierungen ohne Testausgabe
Gut-Genug-Plateau Akzeptieren funktionaler, aber ungetesteter Arbeit Keine Testabdeckung oder Dokumentation angegeben
Tunnelblick Perfektionieren einer Komponente bei gleichzeitigem Ignorieren von Integrationsproblemen Integrationstests nicht ausgeführt
Phantomverifizierung Behauptung, Tests seien bestanden, ohne sie auszuführen Bericht ohne eingefügte Testausgabe
Aufgeschobene Schulden Hinterlassen von TODO/FIXME-Markierungen in committetem Code TODO/FIXME im committeten Diff
Leerer Bericht Meldung „erledigt” ohne Nachweis für jedes Kriterium Kriterien nicht einzeln adressiert

Keiner dieser Modi erfordert eine Sicherheitslücke. Der Agent muss keine CVE ausnutzen. Der Agent versagt, indem er seine Aufgabe schlecht erledigt und meldet, dass er sie gut erledigt hat.

Verteidigung in der Tiefe

Das Orchestrierungssystem verwendet drei unabhängige Schichten. Ein Versagen in einer Schicht kompromittiert die anderen nicht.

Schicht 1: Hook-Pipeline. Jeder Tool-Aufruf durchläuft vor der Ausführung einen PreToolUse-Hook. Handler können die Ausführung blockieren, den Befehl modifizieren oder beratenden Kontext injizieren. Die Dispatcher-Handler-Architektur bedeutet, dass das Hinzufügen einer neuen Sicherheitsprüfung das Schreiben einer einzigen Handler-Datei erfordert, nicht die Modifikation der Routing-Pipeline. Acht Dispatcher leiten an 99 Handler-Hooks weiter.1

Schicht 2: OS-Sandbox. Ein macOS-Seatbelt-Profil definiert acht explizite Sperrregeln, die Schreibzugriffe auf .ssh, .gnupg, .aws, Umgebungsdateien, GitHub CLI-Authentifizierung und den macOS-Schlüsselbund blockieren. Der Kernel setzt diese Regeln unabhängig davon durch, welchen Befehl der Agent konstruiert. Der Versuch, touch ~/.ssh/test unter dem Profil auszuführen, gibt „Operation not permitted” zurück.1

Schicht 3: Nachweisschranke. Bevor eine nicht-triviale Aufgabe als abgeschlossen markiert wird, muss der Agent sechs Nachweiskriterien mit zitierten Belegen erfüllen: Folgt den Codebase-Mustern (Muster benennen), einfachste funktionierende Lösung (abgelehnte Alternativen erklären), Randfälle behandelt (jeden einzelnen auflisten), Tests bestanden (Ausgabe einfügen), keine Regressionen (geprüfte Dateien benennen) und löst das tatsächliche Problem (Bedarf des Benutzers formulieren). Die Schranke kennzeichnet abschwächende Formulierungen („sollte funktionieren”, „wahrscheinlich korrekt”) als unzureichenden Nachweis und löst eine obligatorische Neuverifizierung aus.1

Die Unabhängigkeit der Schichten ist die entscheidende Designeigenschaft. Ein Agent, der die Hook-Pipeline umgeht, trifft immer noch auf die OS-Sandbox. Ein Agent, der eine Sandbox-Lücke findet, steht immer noch vor der Nachweisschranke. Kein einzelner Fehler kompromittiert das System.

Framework-Lückenanalyse

Der Kommentar vergleicht Produktionskontrollen mit drei NIST-Frameworks. Einige Zuordnungen funktionieren gut. Andere offenbaren Lücken, die kein bestehendes Framework schließt.

Was sich zuordnen lässt

PreToolUse-Hooks umfassen zwei CSF 2.0-Funktionen: Protect (PR.PS-05, Verhinderung unautorisierter Aktionen) und Detect (DE.CM, kontinuierliche Überwachung von Tool-Aufrufen).3 Die OS-Sandbox implementiert SP 800-53 AC-3 (Zugriffsdurchsetzung) und AC-6 (Minimale Berechtigung).4 Die Hook-Pipeline lässt sich AC-25 (Referenzmonitor) zuordnen: wird immer aufgerufen, kann nicht umgangen werden und ist klein genug zur Verifizierung. Die Map-Funktion (MAP 3) des AI RMF stimmt mit der Drift-Erkennung überein: Verstehen, was der Agent tut, im Vergleich zu dem, was der Bediener ihn gebeten hat zu tun.5

Was fehlt

Framework Anwendbare Kontrollen Agentenspezifische Lücke Vorgeschlagene Erweiterung
CSF 2.0 DE.CM, DE.AE Keine Kategorie für verhaltensbasierte Drift-Erkennung DE.AE-Beispiele um verhaltensbasierte Agentenanomalien erweitern
SP 800-53 Rev. 5 AC-3, AC-6, AC-25 Keine Kontrollen für Agenten-Delegierungstiefe Neue Kontrollerweiterung für Agenten-Delegierungs-Governance
AI RMF 1.0 MAP 3 Keine Laufzeit-Aufgabentreue-Metrik Agenten-Drift-Ähnlichkeit zur MEASURE-Funktion hinzufügen

Die OWASP Top 10 for Agentic Applications (2026) adressieren Agent Goal Hijacking (ASI01) und Human-Agent Trust Exploitation (ASI09), decken aber weder Selbstverwaltungsfehler wie Phantomverifizierung noch den leeren Bericht ab.6 NIST AI 600-1 (Generative AI Profile) adressiert Risiken generativer KI allgemein, liegt aber zeitlich vor agentischen Bereitstellungsmustern.7

Risiken der Delegierungskette

Wenn ein Agent einen Sub-Agenten erzeugt, der wiederum einen weiteren Sub-Agenten erzeugt, addieren sich Sicherheitseigenschaften nicht. Jeder Weiterleitungsschritt führt drei sich verstärkende Risiken ein:

  • Semantische Kompression. Der vollständige Reasoning-Kontext des Elternagenten wird zu einem Prompt-String komprimiert, wobei Nuancen verloren gehen – etwa welche Dateien sensibel sind oder welche Ansätze der Elternagent bereits verworfen hat.
  • Autoritätsverstärkung. Der Kindagent erbt Lese-/Schreibberechtigungen für Dateien, aber nicht das Verständnis des Elternagenten dafür, welche Dateien sicherheitsrelevant sind.
  • Verantwortungsdiffusion. Wenn ein Sub-Agent fehlerhaftes Ergebnis liefert, zeigt der Audit-Trail, welcher Agent jede Entscheidung getroffen hat, aber der Wurzelagent trägt die operative Verantwortung für das Endergebnis.

Mein Rekursionsschutz adressiert Delegierungsketten, indem er die Agentenabstammung verfolgt und harte Tiefenlimits durchsetzt. Kein veröffentlichtes Framework adressiert die sich verstärkenden Risiken mehrstufiger Agentendelegierung.

Sechs Empfehlungen

Der Kommentar schließt mit sechs Empfehlungen, geordnet von grundlegend bis operativ:

  1. Veröffentlichung eines NIST Internal Report zur Erstellung einer Bedrohungstaxonomie für Agentenverhalten. Traditionelle Bedrohungsmodelle (STRIDE, OWASP Top 10) erfassen keine agentenspezifischen Fehlermodi. Eine gemeinsame Taxonomie ist die Voraussetzung für jede weitere Empfehlung. Das NIST könnte zudem CSF 2.0 um agentenspezifische Unterkategorien erweitern und ein AI RMF-Profil für Agentensysteme veröffentlichen.

  2. Festlegung von Containment-Anforderungen auf Betriebssystemebene. Agenten, die neuartige Befehlsmuster improvisieren, können anwendungsseitige Sandboxing-Maßnahmen umgehen. Durchsetzung auf Betriebssystemebene (Linux seccomp-bpf, macOS Seatbelt, Container-Isolierung) bietet eine Grenze, die der Agent nicht umdenken kann.

  3. Unabhängige Verifizierung von Agenten-Selbstberichten vorschreiben. Agenten dürfen nicht die einzige Autorität darüber sein, ob ihre eigene Arbeit korrekt ist. Ein separater Prozess sollte externe Nachweise (Testausgabe, API-Antworten, Prüfsummen) verifizieren, bevor der Aufgabenabschluss freigegeben wird.

  4. Festlegung einer Blast-Radius-Klassifizierung für Agenten-Tool-Aufrufe. Jede Agentenaktion als lokal, geteilt oder extern kennzeichnen, mit eskalierenden Autorisierungsanforderungen für jede Stufe. Ich habe das Klassifizierungssystem bereits ausführlich beschrieben.

  5. Definition quantitativer Drift-Metriken. Die Sicherheitslage von Agenten benötigt einen messbaren „Aufgabentreue-Wert”, der widerspiegelt, wie genau die aktuelle Aktivität des Agenten mit der zugewiesenen Aufgabe übereinstimmt – berechnet in regelmäßigen Intervallen.

  6. Standardisierung der Audit-Protokollierung für Agentenaktionen. Jeden Tool-Aufruf, jede Hook-Entscheidung und jede blockierte Aktion in einem Format aufzeichnen, das die Rekonstruktion nach Vorfällen unterstützt.

Reichen Sie Ihren eigenen Kommentar ein

Die Kommentierungsfrist für NIST-2025-0035 endet um den 9. März 2026. NIST-RFIs haben echtes Gewicht: Die Kommentare fließen direkt in veröffentlichte Frameworks, Standards und Leitlinien ein. Wenn Sie KI-Agenten im Produktionseinsatz betreiben, sind Ihre Nachweise relevant.

So reichen Sie ein:

  1. Besuchen Sie die NIST-2025-0035-Docket-Seite
  2. Klicken Sie auf „Comment” beim RFI-Dokument
  3. Verfassen Sie Ihren Kommentar zu einem der fünf Themenbereiche
  4. Fügen Sie konkrete Nachweise bei: Code, Metriken, Vorfallsberichte
  5. Reichen Sie mit Ihren Kontaktdaten ein

Sie müssen nicht alle fünf Themen adressieren. Ein fokussierter, nachweisgestützter Kommentar zu einem einzelnen Thema hat mehr Wert als ein breit angelegter Kommentar ohne Konkretisierung. Die NIST-Mitarbeiter lesen jede Einreichung.

Wichtigste Erkenntnisse

Für Sicherheitsexperten: Ordnen Sie Ihre bestehenden Agentenkontrollen CSF 2.0 und SP 800-53 zu. Die Zuordnung der Hook-Pipeline zu AC-25 Referenzmonitor bietet ein konkretes Framework, um Zugriffskontrolle auf Agentenebene gegenüber Compliance-Teams zu beschreiben.

Für KI-Entwickler: Bauen Sie Verhaltenserkennung parallel zu traditioneller Sicherheit auf. Sitzungsdrift, Phantomverifizierung und rekursive Erzeugung sind Produktionsrealitäten, keine theoretischen Risiken. Beginnen Sie mit der Nachweisschranke: Verlangen Sie zitierten Beweis, bevor Aufgaben als abgeschlossen markiert werden.

Für politische Entscheidungsträger: Die Lücke zwischen traditionellen Sicherheitsframeworks und agentenspezifischen Bedrohungen ist strukturell, nicht inkrementell. Agenten versagen auf Weisen, die STRIDE, OWASP und die bestehenden NIST-Kataloge nicht klassifizieren. Eine verhaltensbasierte Bedrohungstaxonomie ist die Voraussetzung für alles Weitere.

Für Framework-Autoren: Fügen Sie Governance für Delegierungsketten hinzu. Wenn Agenten Agenten erzeugen, degradiert der Kontext, verstärkt sich die Autorität und diffundiert die Verantwortung bei jedem Schritt. Die sich verstärkenden Risiken ab Tiefe drei haben keinen Framework-Präzedenzfall.

Quellen

  1. Produktionstelemetrie des Autors und eingereichte öffentliche Stellungnahme zu NIST-2025-0035. Tracking-Nummer mm1-hgn6-spl7. Drift-Ähnlichkeitsengine über 60 tägliche Claude Code-Sitzungen, Februar 2026. Vollständiger Kommentartext auf Anfrage verfügbar. ↩↩↩↩↩↩↩↩↩↩

  2. NIST-2025-0035: Request for Information Regarding Security Considerations for Artificial Intelligence Agents. National Institute of Standards and Technology. ↩↩

  3. NIST Cybersecurity Framework 2.0. National Institute of Standards and Technology, 2024. ↩

  4. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology, 2020. ↩

  5. NIST AI Risk Management Framework 1.0. National Institute of Standards and Technology, 2023. ↩

  6. OWASP Top 10 for Agentic Applications. OWASP Foundation, 2026. ↩

  7. NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative AI Profile. National Institute of Standards and Technology, 2024. ↩