Kontextuelle Richtlinien in Omnigent: Nutzung des Session-Status zur besseren Steuerung von KI-Agenten

Vor Kurzem haben wir Omnigent auf den Markt gebracht, ein Open-Source-Meta-Harness für AI-Agenten. Damit können Sie die Agenten-Harnesses, die Sie bereits nutzen und schätzen – wie Claude Code, Codex und benutzerdefinierte Agenten –, weiterhin verwenden und gleichzeitig eine gemeinsame Ebene für Zusammenarbeit, Komposition und Richtlinien hinzufügen.

Für Sicherheits- und Kostenmanagement führt Omnigent ein leistungsstarkes neues Tool ein: kontextuelle Richtlinien. Heutige Agenten-Frameworks bieten nur einfache Kontrollen, um die Aktionen eines Agenten einzuschränken, z. B. Regeln zum Zulassen, Ablehnen oder Fragen des Benutzers bei verschiedenen Tool-Aufrufen. Dies macht es jedoch schwierig, Richtlinien zu erstellen, die sowohl sicher als auch benutzerfreundlich sind. Im Gegensatz dazu können sich die kontextuellen Richtlinien von Omnigent merken, was bisher in einer Session passiert ist (z. B. was der Agent gelesen oder wie viel Geld er bisher ausgegeben hat), und diesen Zustand nutzen, um zu entscheiden, ob die nächste Aktion ausgeführt werden darf. Dies ermöglicht eine Vielzahl umfassender Richtlinien, die sowohl sicherer als auch komfortabler für die Benutzer sind: von der dynamischen Verfolgung des Risikoniveaus einer Session über die Implementierung von Least-Privilege-Sicherheitsmodellen bis hin zur Festlegung von Budgets für einzelne Aufgaben zur Kostenkontrolle.

Warum Agenten-Kontrollen mit Kontext besser sind

AI-Agenten bringen neue Arten von Risiken für Unternehmen mit sich. Da Agenten beispielsweise durch nicht vertrauenswürdige Inhalte per Prompt-Injection manipuliert und zu schädlichen Aktionen verleitet werden können, ist es ratsam zu verhindern, dass derselbe Agent nicht vertrauenswürdige Inhalte liest, auf sensible Daten zugreift und mit der Außenwelt kommuniziert (bekannt als Simon Willisons „Lethal Trifecta“ und Metas „Agents Rule of Two“). Ob eine Aktion „sicher“ ist, hängt zum Teil davon ab, was zuvor passiert ist: Ein Coding-Agent, der Code auf GitHub pusht, ist im Allgemeinen unbedenklich, wenn der Agent gerade an einem Feature für einen Entwickler gearbeitet hat. Derselbe GitHub-Push ist jedoch riskant, wenn der Agent zuvor eine nicht vertrauenswürdige Webseite heruntergeladen hat, die einen Injection-Angriff enthalten könnte.

Leider bietet die meiste Agenten-Software heute nur einfache Allowlist-Kontrollen oder Guardrails für einzelne Aktionen, z. B. ob Git-Pushes oder Websuchen erlaubt sind. Um Injection-Angriffe zu verhindern, müssten wir mindestens eine dieser Aktionen vollständig blockieren, was jedoch für viele harmlose Anwendungsfälle zu restriktiv wäre. Den Benutzer bei jeder Aktion um Zustimmung zu bitten, funktioniert ebenfalls nicht gut, da Benutzer schnell von den ständigen Freigabeaufforderungen ermüden.

Dasselbe gilt für andere Situationen. Es mag völlig in Ordnung sein, wenn der Agent eines Vertriebsmitarbeiters eine E-Mail an einen Kunden sendet. Wenn er jedoch Tausende von E-Mails sendet, deutet dies auf eine Sicherheitsverletzung oder einen Fehler hin. Ein Agent, der ein von ihm erstelltes Dokument bearbeitet, ist in Ordnung. Wenn derselbe Agent jedoch Tausende von internen Dokumenten bearbeitet, ist Vorsicht geboten. Tatsächlich berücksichtigen viele Sicherheitstools für menschliche Benutzer ebenfalls deren Historie und nicht nur die aktuelle Aktion (dies wird als kontextuelle Sicherheit bezeichnet).

Hier kommen kontextuelle Richtlinien ins Spiel

In Omnigent kann eine Richtlinie Ereignisse überwachen, die ein Agent ausführt (z. B. Tool-Aufrufe und -Antworten sowie Ein- und Ausgaben des LLM), und entscheiden, ob sie die Nachrichten zulässt, ablehnt, transformiert oder den Benutzer um Erlaubnis bittet – ähnlich wie herkömmliche Agenten-Guardrails. Die Richtlinie kann jedoch auch den Zustand der Session aktualisieren: beliebige Variablen, die nur für diese Richtlinie sichtbar sind. Dazu kann beispielsweise die Erfassung gehören, wie oft ein Agent ein bestimmtes Tool verwendet hat, welche Dokumente er gelesen hat usw. Der Omnigent-Server merkt sich den Zustand für jede Richtlinie und Session und übergibt ihn beim nächsten Aufruf an den Richtlinien-Handler. Um eine kontextuelle Richtlinie zu schreiben, erstellen Sie einfach eine Funktion, die den alten Zustand und das neue Ereignis, das der Agent ausführen möchte, entgegennimmt und Zustandsaktualisierungen sowie eine Entscheidung zurückgibt. Omnigent enthält bereits eine Reihe nützlicher Richtlinien.

Da Omnigent ein Meta-Harness ist, kann es Ihre kontextuellen Richtlinien auf dieselbe Weise auf Agenten anwenden, die ein beliebiges Harness verwenden. Omnigent unterstützt weit verbreitete Coding-Agenten wie Claude Code, Codex, Antigravity, Pi, OpenCode und Hermes sowie benutzerdefinierte Agenten in Frameworks wie dem OpenAI Agents SDK und dem Claude Agents SDK. Starten Sie die Agenten einfach über Omnigent, und der Omnigent-Server fängt deren Tool-Aufrufe ab, um die Richtlinien anzuwenden.

Beispielhafte Anwendungsfälle

Hier sind die drei integrierten Beispielrichtlinien, die Omnigent heute standardmäßig mitbringt. Jede basiert auf einer anderen Art von Session-Zustand: dem Inhalt, den der Agent bisher gelesen hat, einem kumulierten Session-Risiko-Score oder den Gesamtkosten der aktuellen Session.

1. Google Drive-Richtlinie: Den Zugriff des Agenten auf die richtigen Dokumente beschränken

Die Google Drive-Richtlinie regelt, was der Agent in Docs, Sheets und Slides lesen und ändern darf. Schreibzugriffe sind standardmäßig auf Dokumente beschränkt, die der Agent während dieser Session erstellt hat. So kann ein Agent ein neues Dokument erstellen und frei bearbeiten, aber nicht unbemerkt eine bereits vorhandene Datei ändern, die er gar nicht anfassen sollte. Dieses Verhalten ließe sich mit einfachen Allowlists nicht implementieren: Wir möchten das Tool „Dokument schreiben“ nicht pauschal erlauben oder verbieten, sondern es nur für Dokumente zulassen, die der Agent in derselben Session erstellt hat.

Als zweites Beispiel für kontextuelles Verhalten in dieser Richtlinie können Sie eine Reihe von Dokumenten als vertraulich kennzeichnen: Sobald der Agent eines davon öffnet, wird die Richtlinie verschärft, sodass Schreibzugriffe auf diese Gruppe beschränkt sind. Selbst ein Dokument, das der Agent vor einer Minute erstellt hat, ist dann tabu, da das Anhängen von vertraulichem Material an dieses Dokument dazu führen würde, dass vertrauliche Inhalte in eine weniger geschützte Datei gelangen. In der klassischen Sicherheit entspricht dies dem Bell-LaPadula-Modell mit seiner „No-Write-Down“-Regel.

2. Risiko-Score-Richtlinie: Vorsichtiger werden, wenn der Agent mit sensiblen Inhalten in Berührung kommt

Risikobewertungen (Risk Scoring) werden von Sicherheitsteams häufig verwendet, um den Zugriff für Menschen zu verwalten. In Omnigent führt die Risiko-Score-Richtlinie einen laufenden Score für die aktuelle Session – eine einzelne Zahl, die erfasst, wie viel Risiko sich während der Arbeit des Agenten angesammelt hat. Benutzer können konfigurieren, welche Aktionen den Score um wie viel erhöhen: Ein routinemäßiger Tool-Aufruf erhöht den Score vielleicht um ein oder zwei Punkte, während das Lesen eines als streng vertraulich gekennzeichneten Dokuments deutlich mehr Punkte einbringt. Solange der Score niedrig bleibt, arbeitet der Agent ohne Unterbrechung. Sobald er einen Schwellenwert überschreitet, geben Aktionen wie das Senden einer E-Mail oder das Freigeben einer Datei ASK statt ALLOW zurück und fordern den Benutzer zur Freigabe auf. Dieselbe E-Mail, die zu Beginn einer Session direkt gesendet worden wäre, erfordert also später möglicherweise eine menschliche Genehmigung, sobald der Agent genügend sensible Inhalte verarbeitet hat, was den Score nach oben treibt.

3. Kostenrichtlinie: Ausgaben unter Kontrolle halten

Eine Budgetrichtlinie verfolgt, wie viel die Sitzung bisher für Modellaufrufe ausgegeben hat. Nach dem Überschreiten eines weichen Schwellenwerts pausiert sie, um zu fragen, ob fortgefahren werden soll. Wenn die Ausgaben die harte Obergrenze erreichen, blockiert die Richtlinie weitere Aufrufe des teuren Modells, bis der Agent zu einem günstigeren wechselt. So kann die Sitzung fortgesetzt werden, anstatt abgebrochen zu werden. Derselbe Ansatz lässt sich über eine einzelne Sitzung hinaus erweitern. Ein Plattform-Team kann ein tägliches Limit pro Benutzer über das Limit pro Sitzung legen, sodass niemand hohe Kosten über viele separate Konversationen hinweg anhäufen kann. In beiden Fällen ist der Kontext die kumulierte Ausgabe: Die Richtlinie bewertet nicht den einzelnen Modellaufruf, sondern überwacht die laufende Gesamtsumme und greift ein, wenn die Sitzung oder der Benutzer zu viel ausgegeben hat.

4. Intent-Based Authorization: Berechtigungen basierend auf dem Zweck einschränken

Intent-Based Authorization legt die Berechtigungen von Agenten basierend auf dem ersten Prompt des Benutzers fest, sodass selbst ein durch Prompt-Injection manipulierter Agent die meisten seiner Tools nicht nutzen kann, um Schaden anzurichten. Wenn Sie beispielsweise eine Sitzung starten, indem Sie einen Agenten bitten, eine Google Slides-Präsentation zu aktualisieren, erlaubt die Richtlinie diesem Agenten das Lesen und Schreiben dieser Präsentation, blockiert jedoch den Zugriff, wenn der Agent plötzlich versucht, GitHub zu verwenden. Die Richtlinie merkt sich einfach als Zustand, was der Benutzer zu Beginn einer Sitzung tatsächlich angefordert hat, und prüft dann jeden Tool-Aufruf anhand dieses ursprünglichen Ziels, wobei das Prinzip der minimalen Rechtevergabe (Principle of Least Privilege) angewendet wird. Dies ist eine sehr einfache, aber leistungsstarke Richtlinie, die durch den kontextuellen Zustand ermöglicht wird: Sie können Agenten standardmäßig mit vielen Tools konfigurieren, und diese werden in jeder Sitzung automatisch eingeschränkt. Derselbe Tool-Aufruf, der in einer Sitzung in Ordnung ist, erfordert in einer anderen möglicherweise Ihre Zustimmung, je nachdem, was Sie den Agenten gefragt haben.

Fazit

Da Agenten immer mehr echte Aufgaben übernehmen, verlagert sich die Herausforderung darauf, wie man sie kontrolliert. Agenten können entweder durch bösartige Eingaben oder durch unbeabsichtigte Fehler Schaden anrichten, und einfache Allowlist-Richtlinien, die einzelne Aktionen prüfen, sind nicht flexibel genug, um Agenten sowohl nutzbar als auch sicher zu machen. Kontextuelle Richtlinien ermöglichen sowohl benutzerfreundlichere als auch sicherere Agenten, indem sie den Zustand innerhalb einer Sitzung dynamisch verfolgen und Aktionen erst dann blockieren, wenn der Agent ein bestimmtes Risiko angesammelt hat. Sie bieten außerdem ein leistungsstarkes und einfaches Tool zur Verwaltung von Budgets auf Sitzungsebene statt nur pro Benutzer und Tag. Omnigent ist Open Source und lässt sich in die beliebtesten Coding-Agenten und Agenten-Frameworks integrieren, sodass Sie diese direkt auf Ihre bestehenden Agenten anwenden können.

Jetzt ausprobieren

Omnigent ist ab heute als Open-Source-Alphaversion verfügbar.

• Legen Sie los mit unserem Quickstart: https://omnigent.ai/quickstart/install
• Geben Sie dem Repo einen Stern und klonen Sie es: https://github.com/omnigent-ai/omnigent
• Folgen Sie dem Richtlinien-Tutorial: https://omnigent.ai/quickstart/policies
• Lesen Sie die Richtlinien-Dokumentation: https://omnigent.ai/docs/policies/overview
• Besuchen Sie uns auf Discord: https://discord.gg/omnigent

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag