von AgentPolicy (LX AI)

Erlaubte Tools vs. offene Agenten

Die Attraktivität eines offenen Agenten ist real: Gib ihm eine Shell, einen Browser und ein Mailbox, und er kann Probleme lösen, die du nicht skriptet hast. Die Kosten sind jedoch das Blast-Radius. Jedes Tool, das du hinzufügst, ist ein Pfad, den eine injizierte Anweisung zurücklegen kann. Die Designfrage ist nicht, ob man eine Fähigkeit gewähren soll, sondern wie man sie eng genug gewähren kann, damit ein falscher Schritt eingedämmt bleibt.

Least-privilege-Tool-Definitionen

Ich beginne damit, einen Tool-Vertrag zu schreiben, der genau festlegt, was der Agent tun darf und was nicht. Ein „Lese-Ticket“-Tool sollte nur eine GET-Operation auf eine bestimmte Ticket-ID ausführen, ohne die Möglichkeit, das Ticket zu ändern, Dateien anzuhängen oder andere Endpunkte aufzurufen. Ein „E-Mail senden“-Tool sollte nur eine vordefinierte Empfängerliste, eine feste Betreffzeile und einen Textkörper akzeptieren, der für Zeilenumbruchinjektionen gesichert ist. Durch die Einschränkung des Vertrags wird ein einzelner Fehler in der Ausgabe des Modells zu einem begrenzten Ereignis anstelle eines Kaskadeneffekts.

Definieren Sie die Verb-Set

Listen Sie alle HTTP-Methoden, Datenbankbefehle oder Dateioperationen auf, die das Tool benötigt. Wenn das Tool nur lesen muss, lassen Sie POST, PUT, DELETE und administrative Befehle aus. Ich verwende eine Tabelle, die jedem Toolnamen die zulässigen Verben zuordnet, und überprüfe sie, wenn ein neuer Endpunkt hinzugefügt wird.

Einschränken Sie Argumente

Für jedes Argument spezifiziere ich einen Typ, eine Längenbegrenzung und einen zulässigen Zeichensatz. Eine Ticket-ID könnte beispielsweise eine UUID sein, die auf 36 Zeichen begrenzt ist. Ein Dateipfad könnte auf ein Unterverzeichnis unter /var/agent/data beschränkt sein und darf keine „..“ oder absoluten Pfade enthalten. Ich verwende eine Bibliothek zur Schemavalidierung, die jeden Anfrage ablehnt, der nicht den Vorgaben entspricht, bevor das Tool ausgeführt wird.

Versionieren Sie den Vertrag

Ich speichere die Tool-Definition als JSON-Datei in der Versionskontrolle. Jede Änderung löst eine Pull-Anfrage aus, die die Zustimmung eines Sicherheitsprüfers erfordert. Dies erstellt eine Audit-Trail, die zeigt, wann die Privilegien-Oberfläche erweitert wurde und warum.

Um zu sehen, wie Prompt-Injektionen übermäßig breite Tools missbrauchen können, überprüfen Sie die OWASP-LLM01-Richtlinie: https://genai.owasp.org/llmrisk/llm01-prompt-injection. Die Cheat-Sheet zeigt konkrete Beispiele, in denen ein Modell dazu verleitet wurde, einen Shell-Befehl aufzurufen, weil das Tool unbeschränkten Eingaben akzeptierte.

Tool-Name | Zulässiges Verb | Argument-Beschränkungen | Beispiel für sicheren Aufruf read_ticket | GET | ticket_id: UUID, 36 Zeichen | /tickets/123e4567-e89b-12d3-a456-426614174000 send_email | POST | an: Liste aus approved_domains, Betreff: max. 78 Zeichen, Textkörper: gesichert | {"an":["user@example.com"],"Betreff":"Update","Textkörper":"Bitte überprüfen Sie den angehängten Bericht."} list_files | GET | Pfad: muss mit /var/agent/data/ beginnen, kein „..“ | /var/agent/data/logs/2024-09-01.txt

Bestätigung bei irreversiblen Aktionen

Aktionen, die den Zustand außerhalb des Sandboxes des Agents ändern - wie das Senden einer Nachricht, das Löschen eines Datensatzes oder das Bereitstellen eines Builds - müssen durch einen separaten Genehmigungsschritt gesichert werden, den der Agent nicht selbst aufrufen kann. Ich behandle diese als Einweg-Türen und entwerfe die Richtlinie so, dass ein menschliches Token oder ein kurzlebiges Genehmigungsdienst erforderlich ist, bevor das Tool ausgeführt wird.

Separater Genehmigungsendpunkt

Ich stelle eine interne API bereit, die eine signierte Anfrage vom Agent akzeptiert, die Anfrage protokolliert und dann wartet, bis ein Mensch auf „Genehmigen“ in einer Benutzeroberfläche klickt oder auf einen Chat-Befehl reagiert. Der Agent erhält nur eine ausstehende Kennung; er kann den Genehmigungsendpunkt nicht abfragen, um eine Genehmigung zu erzwingen.

Zeitgebundene Token

Wenn die Genehmigung erteilt wird, stellt das System ein Token aus, das nur für eine einzelne Verwendung gültig ist und nach fünf Minuten abläuft. Der Tool-Endpunkt überprüft die Signatur und das Ablaufdatum des Tokens, bevor er fortfährt. Wenn das Token fehlt oder abgelaufen ist, gibt das Tool einen Fehler zurück und der Versuch wird protokolliert.

Protokollierung des Tores

Jede Genehmigungsanfrage und -entscheidung wird in einem unveränderlichen Protokoll mit Timestamps, der Kennung des Agents, dem Toolnamen und den präsentierten Argumenten geschrieben. Dieses Protokoll ermöglicht es mir, zu rekonstruieren, ob eine vergiftete Anweisung es geschafft hat, das Tor zu umgehen oder ob sie an dem Genehmigungsschritt gestoppt wurde.

Für Richtlinien zur Sicherung der Anmeldedatenhygiene in automatisierten Pipelines siehe das OWASP CI/CD-Sicherheitsrisiko-Blatt: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene. Es unterstreicht das Prinzip, dass Geheimnisse niemals an einem Ort gespeichert werden sollten, an dem ein Agent sie ohne expliziten Genehmigungsfluss lesen kann.

Prüfprotokolle als Kontrolle und nicht als Nachgedanke

Ich betrachte das Prüfungprotokoll als primäre Beweise, dass eine Richtlinie durchgesetzt wird. Ohne ein zuverlässiges Protokoll sind Aussagen über minimale Rechte unüberprüfbare Behauptungen. Ich entwerfe die Protokollebene so, dass sie aus der Sicht des Agents schreibgeschützt ist und in einem System gespeichert wird, das der Agent nicht ändern oder löschen kann.

Was zu protokollieren ist

- Zeitstempel mit Millisekundengenauigkeit - Agenten-Identifikator (Modellversion, Bereitstellungs-ID) - Werkzeugname und der genaue Verb, der aufgerufen wird - Alle an das Werkzeug übergebenen Argumente nach der Validierung - Ergebnis-Statuscode und eine Zusammenfassung der zurückgegebenen Daten (Größe, nicht voller Inhalt) - Quelle der Anfrage (benutzerinitiiert, geplanter Trigger oder Richtlinien-Engine)

Speicher-Garantien

Ich schreibe jeden Protokolleintrag in einen append-only-Speicher wie ein Write-Ahead-Log in einem Cloud-Speicher-Bucket mit aktivierter Objektversionierung. Die Bucket-Richtlinie verwehrt dem Agenten-Servicekonto jede Lösch- oder Überschreibungsoperation. Dies stellt sicher, dass auch im Falle eines Kompromisses des Modells die Historie intakt bleibt.

Abfrage für Untersuchungen

Wenn ein Vorfall gemeldet wird, führe ich eine einfache SQL-ähnliche Abfrage gegen den Protokollindex aus, um alle Ausführungen eines bestimmten Werkzeugs innerhalb eines Zeitfensters zu finden. Ich vermeide komplexe Joins, die langsam sein könnten; stattdessen verlasse ich mich auf partitionierte Tabellen nach Datum und Werkzeugname. Die Abfrage gibt die Liste der Identifikatoren zurück, die ich dann für eine tiefere forensische Analyse abrufe.

Um zu verstehen, wie die Eingabevalidierung verhindern kann, dass bösartige Argumente ein Werkzeug erreichen, konsultieren Sie die SQL-Injection-Präventions-Tabelle: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html. Das Blatt zeigt parameterisierte Abfragen und strenge Typisierung, die den Argument-Validierungsansatz widerspiegeln, den ich für Agenten-Werkzeuge verwende.

Wenn offener Zugriff gerechtfertigt ist

Es gibt berechtigte Fälle, in denen ein Agent eine breitere Reichweite benötigt, wie z.B. bei der exploratorischen Datenanalyse oder der Bedrohungsjagd in einer isolierten Umgebung. In diesen Situationen gewähre ich Offenheit nur nachdem ich den Agent in eine Sandbox gesetzt habe, die jeden Pfad zu Produktionsdaten oder externen Zahlungssystemen blockiert.

Sandbox-Grenzen

Die Sandbox bietet eine Shell, einen Browser-Engine und ein Postfach, das nur Nachrichten an eine dedizierte Testdomäne senden kann. Die Netzwerkrichtlinie blockiert ausgehenden Datenverkehr zu jeder IP-Adresse, die zu den internen CIDR-Bereichen des Unternehmens gehört. Der Ausgang ist nur zu einer Reihe von genehmigten öffentlichen Spiegeln für die Paketinstallation erlaubt.

Isolation von Anmeldeinformationen

Keine Produktionsgeheimnisse werden in das Dateisystem der Sandbox eingebunden. Stattdessen erhält der Agent ein temporäres Token, das aus einem öffentlichen Datensatz-Bucket lesen kann. Wenn der Agent versucht, eine Datei außerhalb des zulässigen Mount-Punkts zu lesen, gibt der Kernel einen Berechtigungsfehler zurück und der Versuch wird protokolliert.

Zeitbegrenzte Sitzungen

Jede Sandbox-Sitzung dauert maximal zwei Stunden. Nach dem Timeout wird die Umgebung abgebaut und ein frisches Image wird gestartet. Dies begrenzt das Zeitfenster, während dem ein fehlerhaftes Verhalten des Agents Daten erkunden oder exfiltrieren könnte.

Ich wende immer noch die Definitionen von Werkzeugen mit den geringsten Rechten innerhalb der Sandbox an; der Unterschied besteht darin, dass die Folgen eines Fehlers auf die entsorgbare Umgebung und nicht auf die Produktionssysteme beschränkt sind. Ich verwende Tools wie MailPilot, AIActRadar, AgentPolicy, AgentRedTeam und Waffo, um die Sicherheit meiner Systeme zu gewährleisten und mich an die Richtlinien von OWASP, NIST und dem EU-AI-Gesetz (Art. 5, 6, 7) zu halten, insbesondere die Regelkataloge wie z.B. die ID 1.1.1.1 von NIST.

Generierte Richtlinien als Entwürfe behandeln

Wenn ein Modell oder ein Junior-Ingenieur eine Richtliniendatei erstellt, überprüfe ich sie genau so, wie ich unzuverlässigen Code überprüfen würde, der kurz vor der Bereitstellung für einen kritischen Dienst steht. Die Überprüfungscheckliste umfasst die Überprüfung jeder Regel gegen die tatsächlichen Tool-Definitionen, die Bestätigung, dass Verwehrpfade existieren, und die Sicherstellung, dass die Datei versioniert ist.

Regel-Tool-Zuordnung

Ich erstelle eine Tabelle, die alle Tools auf einer Achse und alle Richtlinienregeln auf der anderen auflistet. Für jede Zelle markiere ich, ob die Regel die Ausführung des Tools erlaubt, verbietet oder dazu schweigt. Jede schweigende Zelle löst einen Kommentar aus, der den Autor auffordert, die Absicht zu klären.

Verwehr-Standard-Überprüfung

Ich führe ein Skript zur statischen Analyse aus, das versucht, jedes Tool mit einer Reihe von fehlerhaften Argumenten aufzurufen. Wenn das Skript eine Kombination findet, die die Richtlinie erlaubt, aber verwehrt werden sollte (z. B. ein „Löschen“-Tool, das einen Wildcard-Bezeichner akzeptiert), schlägt das Skript den Build fehl und die Richtlinie muss überarbeitet werden.

Versionskontrolle und Überprüfung

Die Richtliniendatei befindet sich in einem Git-Repository mit Branch-Schutz, der zwei Genehmigungen vor der Zusammenführung erfordert. Ich markiere jede veröffentlichte Version mit einer semantischen Nummer (z. B. v1.2.0) und füge die entsprechende Tool-Definitionsschnappschuss hinzu. Dies ermöglicht es, zu einem bekannten guten Zustand zurückzukehren, wenn eine neue Version eine zu permissive Regel einführt.

Ich betrachte eine generierte Richtlinie niemals als endgültig, bis sie diesen Überprüfungszyklus durchlaufen hat. Eine Richtlinie, die nie überprüft wird, erzeugt ein falsches Sicherheitsgefühl und kann Lücken verbergen, die nur unter realen Lasten sichtbar werden.

Was dies nicht ist

Dieser Leitfaden verspricht nicht, dass das Befolgen der Schritte jeden möglichen Fehlermodus eliminieren wird. Ich behaupte nicht, 100 % Schutz gegen Prompt-Injection, Credential-Leakage oder Logikfehler zu bieten. Ich sage auch nicht, dass ein Agent niemals eine bösartige Anweisung übersehen wird; die Erkennung hängt von der Qualität der Protokolle, der Reaktionszeit der menschlichen Überprüfung und der Richtigkeit der Tool-Verträge ab. Behandeln Sie die Muster als Maßnahmen zur Risikoreduzierung, nicht als Garantie für absolute Sicherheit.