von AgentPolicy (LX AI)

AI-Agent-Richtlinienpakete und NIST AI RMF

Ein Richtlinienpaket ist eine wiederverwendbare Menge von Regeln darüber, was ein Agent durchführen darf: welche Tools es aufrufen kann, welche Datenklassen es berühren darf und wann es an einen Menschen eskalieren muss. Die Zuordnung dieser Regeln zu den vier Funktionen des NIST AI Risk Management Frameworks, Govern, Map, Measure und Manage, hält das Paket an einer Struktur fest, die Prüfer bereits erkennen. Das Paket ist ein Entwurf, den Sie genehmigen, nicht ein Konformitätszertifikat.

Govern: Eigentum und Verantwortlichkeit

Festlegung von Regelnbesitzern

Ich beginne jeden Pack, indem ich eine Person oder ein Team für jede Regel verantwortlich mache. Dieser Besitzer bestätigt den Regeltext, überprüft ihn quartalsweise und genehmigt jede Änderung. Ohne einen klaren Besitzer kann eine Regel, die heute ein gefährliches Tool blockiert, vergessen werden, wenn eine neue Integration erscheint, und dem Agenten unbeabsichtigten Zugriff gewähren.

Änderungssteuerungsprozess

Ich behandle den Pack wie eine versionierte Datei. Jede Bearbeitung erstellt einen neuen Commit, enthält eine kurze Begründung und durchläuft eine Überprüfungsliste, die Folgendes abdeckt: (1) Auswirkungen auf zulässige Tools, (2) Auswirkungen auf Datenklassentags, (3) Eskalationspfade und (4) Kompatibilität mit bestehenden Prüfnachweisen. Die Liste befindet sich im gleichen Repository wie der Pack, sodass die Überprüfer die Differenz und die Diskussion an einem Ort sehen können.

Link zur NIST-Govern-Funktion

Das NIST AI RMF beschreibt Govern als die Grundlage, die Rollen, Verantwortlichkeiten und Richtlinien festlegt. Mein Pack spiegelt dies wider, indem es das Eigentum explizit macht und einen leichten Änderungssteuerungs-Workflow integriert, den Prüfer überprüfen können. Wenn ein Prüfer fragt: „Wer ist für diese Regel verantwortlich?“, kann ich auf das Besitzerfeld und die Commit-Historie verweisen.

Karte: Kontext und Datenflüsse

Inventar von Tools und Datenklassen

Ich listen jedes externe Tool auf, das der Agent aufrufen kann, und versehe dann jedes Tool mit den Datenklassen, die es lesen oder schreiben kann. Zum Beispiel erhält ein Summarizer-Tool das Tag „Kundentickets“, da es Tickettexte verarbeiten kann, während ein Mathematik-Rechen-Tool das Tag „keine“ erhält, da es nur Zahlen zurückgibt. Diese zweilagige Ansicht verhindert den häufigen Fehler, ein Tool zuzulassen, ohne zu verstehen, welche Daten es berührt.

Risikobewertung pro Tool

Für jedes Tool-Daten-Paar ordne ich eine einfache Risikobewertung zu: niedrig, mittel oder hoch. Die Bewertung ergibt sich aus drei Fragen: (1) Verarbeitet das Tool personenbezogene Informationen? (2) Kann das Tool andere Dienste aufrufen? (3) Wurde das Tool in öffentlichen Schwachstellen-Datenbanken erwähnt? Ich speichere die Bewertung im Paket, damit die Prüfer sehen, warum ein Tool eingeschränkt oder zugelassen ist.

Link zur NIST-Kartenfunktion

Die Karte im AI-RMF geht um das Verständnis des Kontexts und des potenziellen Auswirkungsbereichs. Mein Inventar und meine Bewertungsliste liefern ein konkretes Artefakt, das zeigt, welche Systeme der Agent erreicht, welche Daten durch ihn fließen und was ein Ausfall kosten würde. Dies erfüllt die Anforderung der Karte, „Risiken zu identifizieren und zu kategorisieren“, bevor Kontrollen angewendet werden.

Maßnahme: Telemetrie und Beweise

Protokollierung von Regeltreffer

Ich konfiguriere den Agenten so, dass er bei jeder Auswertung einer Regel einen strukturierten Log-Eintrag ausgibt. Der Eintrag enthält: Timestamp, Agenten-ID, Regeln-ID, Toolname, Datenklasse, Entscheidung (zulassen/verweigern/ eskalieren) und den Risikowert aus dem Map-Schritt. Diese Logs fließen in einen zentralen Speicher, in dem ich einfache Abfragen wie „zeigen Sie alle Verweigerungen für das Summarizer-Tool in der letzten Woche“ ausführen kann.

Eskalationstracking

Jedes Mal, wenn der Pack eine Eskalation auslöst, protokolliere ich den Grund und den menschlichen Respondenten. Im Laufe der Zeit berechne ich zwei Metriken: (1) Eskalationsrate pro Tool und (2) durchschnittliche Zeit bis zur menschlichen Auflösung. Diese Zahlen werden zu den Beweisen, die ich während einer Überprüfung vorlege, um zu beweisen, dass Grenzen nicht nur geschrieben, sondern tatsächlich durchgesetzt werden.

Link zur NIST-Maßnahmenfunktion

Die Maßnahmenfunktion fordert quantitative Indikatoren, die zeigen, ob Kontrollen wirken. Meine logbasierten Metriken geben Auditoren eine wiederholbare Möglichkeit, die Regelfektivität, Eskalationshäufigkeit und Reaktionsverzögerung zu sehen. Wenn die Metriken einen plötzlichen Anstieg der Verweigerungen für ein Tool zeigen, weiß ich, dass der Pack eine Map-Aktualisierung benötigt.

Verwalten: Reaktion und Iteration

Vorfall-gesteuerte Updates

Wenn ein Log-Eintrag eine Richtlinienverletzung aufzeigt - sagen wir, der Agent hat ein verbotenes Tool aufgerufen - eröffne ich ein Ticket, das auf die genaue Log-Zeile verweist. Das Ticket treibt einen kurzen Workflow an: (1) Verifizierung der Verletzung, (2) Entscheidung, ob die Tool-Definition verschärft, eine Egress-Zulassungsliste hinzugefügt oder eine Bestätigung erforderlich ist, (3) Bearbeitung des Packs, (4) Versionsnummer erhöhen und (5) Ticket mit einem Link zum neuen Commit schließen.

Versionierung wie Code

Ich speichere das Pack in einem Git-Repository. Jede Veröffentlichung erhält eine semantische Version (z. B. 1.2.0). Die Commit-Nachricht enthält die geänderte Regel, den Grund und die zugehörige Ticket-Nummer. Dies macht es einfach, einem Auditor die genauen Unterschiede zwischen der Version, die letzten Monat überprüft wurde, und der Version, die heute in Produktion ist, zu zeigen.

Link zur NIST-Verwalten-Funktion

Verwalten im AI-RMF geht darum, auf erkannte Probleme zu reagieren und Kontrollen zu verbessern. Mein vorfall-gesteuerter Ticket-Fluss und mein versioniertes Pack bieten einen konkreten Mechanismus, um zu erkennen, zu reagieren und Verbesserungen zu überprüfen - genau das, was Verwalten erwartet.

Schritt-für-Schritt-Erstellung eines Richtlinienpakets

Beginnen Sie mit einer Tool-Zulassungsliste

Ich beginne damit, jede API, CLI oder Webhook zu sammeln, die der Agent möglicherweise benötigt. Ich schreibe jeden Eintrag in einer einfachen YAML-Liste auf und notiere den Hersteller, die Version und den Zweck des Tools. In diesem Stadium kümmere ich mich nicht um Datenklassen; ich möchte nur ein vollständiges Inventar haben.

Fügen Sie Datenklasse-Tags hinzu

Als Nächstes gehe ich durch die Zulassungsliste und frage: welche Daten liest oder schreibt dieses Tool? Ich füge ein Tag wie „finanzielle Aufzeichnungen“, „Gesundheitsinformationen“ oder „öffentliche Website“ hinzu. Wenn ein Tool mehrere Klassen berührt, füge ich mehrere Tags hinzu. Dieser Schritt verwandelt eine nackte Liste in eine Karte, die für die Risikobewertung verwendet werden kann.

Legen Sie Eskalations-Schwellenwerte fest

Für jedes Tool-Daten-Paar entscheide ich, wann der Agent an einen Menschen übergeben werden sollte. Ich verwende die Risikobewertung aus dem Karten-Schritt: niedrige Bewertungen erhalten automatische Genehmigung, mittlere Bewertungen erhalten Genehmigung mit Audit-Protokollierung und hohe Bewertungen erzwingen eine Eskalation. Ich kodiere diese Schwellenwerte als Entscheidungstabelle im Paket.

Validieren Sie mit Test-Szenarien

Bevor ich das Paket als „bereit“ bezeichne, führe ich eine Reihe von skriptgesteuerten Interaktionen aus, die versuchen, jede Regel auszulösen. Ich überprüfe, ob die Protokolle die erwartete Entscheidung erfassen, dass Eskalationen ausgelöst werden, wenn sie sollten, und dass keine Regel stillschweigend fehlschlägt. Wenn ein Test eine Abweichung zeigt, kehre ich zum Karten- oder Verwalten-Schritt zurück, um das Paket zu korrigieren.

Was dies nicht ist

Ich möchte klarstellen, was die Grenzen eines Policy-Packs sind. Es ist keine Garantie dafür, dass der Agent niemals gegen eine Regel verstoßen wird. Es ist kein 100-%-Schutzschild gegen neue Angriffsmethoden, die zum Zeitpunkt der Erstellung des Packs unbekannt waren. Es ersetzt keine formale rechtliche Überprüfung, keine Bewertung durch eine benannte Stelle oder Ihre eigene Risikobewertung. Das Pack ist ein Entscheidungshilfswerkzeug, das Regeln sichtbar, testbar und änderbar macht, aber die endgültige Verantwortung liegt immer noch bei den Menschen, die das System besitzen.

Checkliste für Betreiber für AI-Agent-Richtlinienpakete durch die Linse des NIST AI RMF

Ich halte eine schriftliche Checkliste neben jedem Release, der dieses Thema betrifft. Die Liste ist absichtlich langweilig: Benennen Sie den Besitzer, benennen Sie das Beweisartefakt und benennen Sie die Rückgängigstellung. Wenn ein Schritt keine Datei, kein Ticket oder keine Protokollzeile produzieren kann, ist es kein Schritt - es ist ein Wunsch.

Bevor Sie die Produktion ändern

- Frieren Sie den Branch oder die Konfigurationsrevision ein, gegen die Sie messen werden. - Zeichnen Sie den aktuellen Fehlermodus mit einer konkreten Eingabe und einer konkreten Ausgabe auf. - Bestätigen Sie, welche Identität der Job ausführt und ob diese Identität auf Daten zugreifen kann, die sie nicht sollte. - Öffnen Sie die primären Referenzen, die Sie zitieren werden: https://genai.owasp.org/llmrisk/llm01-prompt-injection, https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene.

Während Sie den Check durchführen

- bevorzugen Sie einen reproduzierbaren Pfad gegenüber zehn anekdotischen Screenshots. - Schreiben Sie das erwartete sichere Ergebnis, bevor Sie das Tool oder die Abfrage auslösen. - Erfassen Sie den genauen Befehl, Prompt, Schema oder Regex, der getestet wird - nicht eine Paraphrase. - Wenn das System handeln kann (senden, schreiben, löschen, übertragen), erfordern Sie eine Bestätigungsgrenze im gleichen Durchgang.

Nachdem Sie fertig sind

- Akten Sie das residuale Risiko mit einem Besitzer und einem Datum, auch wenn der Scan sauber ist. - Konvertieren Sie kein grünes Häkchen in Verkaufssprache, die Vollständigkeit beansprucht. - Führen Sie die gleiche Checkliste erneut aus, wenn sich das Modell, das Tool-Schema oder die Validierungsregeln ändern.

AgentPolicy hilft bei dem messbaren ersten Durchgang. Architekturentscheidungen, rechtliche Abzeichnung und kundenorientierte Behauptungen benötigen immer noch einen menschlichen Besitzer. Behandeln Sie jede Checklistenzeile als Entscheidungshilfe, nicht als Zertifikat.

Wie ich Käufern Grenzen erkläre

Wenn ein Interessent fragt, ob das Produkt „alles abdeckt“, antworte ich mit der Grenze: Automatisierte Checks erfassen bekannte Muster; neue Ketten und Richtlinienurteile benötigen immer noch eine Überprüfung. Diese Ehrlichkeit hält die Supportbelastung niedrig und hält den Blog mit dem überein, was das Produkt tatsächlich tut.

Wenn Sie eine zweite Meinung benötigen, kombinieren Sie diesen Text mit den unten aufgeführten Referenzen und mit Ihrer eigenen Staging-Reproduktion. Überspringen Sie nicht den Reproduktionsschritt, nur weil ein Modell eine zuversichtliche Zusammenfassung geschrieben hat.

Referenzen

- https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html