Die Sandbox bewusst verlassen

Einen Agenten in eine Sandbox zu stecken, ist schnell entschieden und im Alltag schwieriger, denn sobald eine echte Aufgabe etwas außerhalb der Box braucht, benötigen Sie einen Weg, ihn herauszulassen, der bewusst und nicht zufällig ist. Der Elevated-Modus ist die Antwort von OpenClaw darauf. Für einen Agenten, der nie in einer Sandbox lief, ändert er nichts, und für einen, der in einer läuft, öffnet er einen schmalen, abgesicherten Weg zum Host. Die Schranken verdienen einen genauen Blick, denn mehrere von ihnen müssen übereinstimmen, bevor sich ein einziger Befehl bewegt.

Was der Elevated-Modus bewirkt

• Der Elevated-Modus lässt einen Agenten in der Sandbox aus dem gewöhnlichen, pro Agent konfigurierten Sandboxing ausbrechen und Befehle stattdessen außerhalb der Sandbox ausführen, mit Freigabeschranken, die konfigurierbar bleiben.
• Er ändert das Verhalten nur, wenn der Agent in einer Sandbox läuft, denn ein Agent ohne Sandbox führt seine Shell-Befehle ohnehin auf dem Host aus.
• Der effektive Host ist standardmäßig das Gateway und wird nur dann zum Node, wenn das konfigurierte oder sitzungsbezogene Exec-Ziel bereits ein Node ist, sodass die Erhöhung keine hostübergreifende Überschreibung ist.
• Pro Sitzung stehen vier Direktiven zur Verfügung: eine Stufe on, die Freigaben beibehält, eine Stufe ask als deren Alias, eine Stufe full, die Freigaben überspringen kann, und eine Stufe off, die zur auf die Sandbox beschränkten Ausführung zurückkehrt.

Sitzungen, deren Ersteller-Rolle Sandboxing vorschreibt, können den Elevated-Modus nicht zum Ausbrechen nutzen.

Die Schranken, die übereinstimmen müssen

Die Verfügbarkeit ist eine Konjunktion, kein Schalter. Die globale Schranke muss aktiviert sein, und der Absender muss auf der Zulassungsliste für seinen Kanal stehen, die als Listen von Kennungen pro Kanal geführt wird. Eine Schranke pro Agent kann die Dinge nur weiter einschränken, daher müssen sowohl die globale als auch die agentenspezifische Schranke aktiviert sein, damit ein Agent infrage kommt. Die Zulassungsliste pro Agent funktioniert genauso, und ein Absender muss sowohl auf der globalen als auch auf der agentenspezifischen Liste stehen. Kanal-Plugins können über einen Adapter-Hook im SDK eine Fallback-Zulassungsliste liefern, doch derzeit implementiert kein mitgelieferter Kanal diesen Hook, sodass in der Praxis jeder Anbieter seinen eigenen expliziten Zulassungslisten-Eintrag braucht. Schlägt eine Schranke fehl, gilt Elevated als nicht verfügbar statt als teilweise gewährt. Die Einträge selbst können einfache Kennungen sein, die auf eine Absender-ID, eine E.164-Nummer oder ein From-Feld passen, oder sie tragen ein Präfix, das auf einen Anzeigenamen, einen Nutzernamen oder ein Tag zielt, wobei explizite Identitätspräfixe verfügbar sind, wenn Sie eindeutig sein müssen. Es gibt außerdem eine unauffälligere Abhängigkeit: Der bash-Chatbefehl liegt hinter einem eigenen Flag und setzt zusätzlich voraus, dass Elevated aktiviert ist, sodass das Abschalten von Elevated auch diese Shell-Nachrichten aussperrt.

Stufen und Vorrang

• Eine Nachricht, die nur aus der Direktive besteht, setzt den Standard der Sitzung, während dieselbe Direktive inline vor einer Anfrage nur für diese eine Nachricht gilt.
• Die Auflösung beginnt bei der Inline-Direktive, dann folgt die Sitzungsüberschreibung, dann der in der Konfiguration gesetzte globale Standard.
• In der Stufe full werden Freigaben nur übersprungen, wenn der aufgelöste Exec-Modus und die Host-Freigaberichtlinie bereits vollständig permissiv sind, und in den Stufen on und ask gelten die konfigurierten Freigaberegeln immer.

Der Elevated-Modus setzt voraus, dass Sie bereits ein Gateway-Sandboxing eingerichtet haben, das sich zu verlassen lohnt, und dass Sie entschieden haben, was ein Befehl tun darf, sobald er ankommt, was die Aufgabe der Exec-Freigaben ist. Keines von beiden ersetzt die Erhöhung.

Warum die Grenzen halten

Das Design behandelt die Erhöhung als Hebel auf nur einer Achse und verhindert, dass sie zu einer allgemeinen Überschreibung wird. Wenn die Tool-Richtlinie das Exec-Tool rundweg verweigert, kann die Erhöhung es nicht zurückholen, denn beide beantworten unterschiedliche Fragen, und die restriktivere gewinnt. Wenn die Operator-Rolle des authentifizierten Sitzungserstellers eine Sandbox vorschrieb, kann die Erhöhung überhaupt keine Befehle auf dem Gateway oder einem Node ausführen, was eine Operator-Entscheidung über eine Chat-Direktive stellt. Die Host-Auswahl wird genauso behandelt, sodass ein automatisches Ziel nicht in eine freie Wahl der Maschine umgewandelt wird. Diese Schranken getrennt zu halten, macht die Zusammensetzung vorhersehbar, und die Dokumentation hat eine Seite dazu, wie die drei im Moment eines Tool-Aufrufs zusammenwirken, die sich einmal vollständig zu lesen lohnt (Wie die drei Schranken zusammenwirken). Die verwandte exec-Direktive ist wiederum ein anderer Hebel: Sie passt die Exec-Standards pro Sitzung für autorisierte Absender an, ganz ohne Erhöhung. Zusammengenommen bedeuten die Regeln, dass das Einschalten der Erhöhung genau eine Sache erweitert und jede andere Grenze dort lässt, wo sie war.

Bei Diali

Bei Diali betreibt jeder Kunde seinen eigenen Assistenten, und die Laufzeitkonfiguration für gehostetes OpenClaw bei Diali wird aus dem Dashboard erzeugt und bei jedem Release ersetzt. Wenn Sie sehen möchten, wo die Grenzen liegen, bevor Sie eine davon erweitern, beginnen Sie mit unserer Seite zur Sicherheit bei Diali.

• Elevated ändert nichts, solange der Agent nicht tatsächlich in einer Sandbox läuft.
• Jede Schranke muss bestehen: global, pro Agent und die Zulassungsliste für diesen Kanal.
• Nur die Stufe full überspringt Freigaben, und nur wenn die Richtlinie bereits permissiv ist.