ChatGPT-Dokumentation
Deutsch
Kontakt goolvyouyou@gmail.com

Agent Security

Verwalten Sie globale Richtlinien und Umgebungseinstellungen für ChatGPT Work und Codex

Verwenden Sie Agent Security in der Admin-Konsole, um Richtlinien und Konfigurationen zu verwalten. Es ersetzt „Richtlinien & Konfiguration“. Die Einführung erfolgt unabhängig vom lokalen Computerzugriff für Work und dots.

Wenn geeignete bisherige Cloud-Richtlinien migriert werden, werden ihre Einstellungen in Global übernommen. Richtlinienzuweisungen und Reihenfolge bleiben dabei erhalten. Prüfen Sie die migrierten Richtlinien in Agent Security. Der lokale Computerzugriff muss für Work und für dots jeweils separat aktiviert werden.

Wo Einstellungen gelten

Jede Richtlinie beginnt mit einer globalen Basiskonfiguration. Umgebungsüberschreibungen ändern unterstützte Ausführungseinstellungen für Local oder Codex Cloud. Wo eine Umgebung keine Überschreibung hat, erbt sie die geltenden globalen Einstellungen dieser Richtlinie.

  • Global: Legen Sie Orchestrator-Steuerungen fest, einschließlich Genehmigungen und Websuche, sowie gemeinsame Ausführungseinstellungen.

  • Local: Passen Sie unterstützte Ausführungseinstellungen für Arbeit an, die auf einem verbundenen Computer ausgeführt wird.

  • Codex Cloud: Passen Sie unterstützte Ausführungseinstellungen für Codex-Cloud-Aufgaben an. Sie können diese Richtlinien konfigurieren, bevor Sie Codex Cloud aktivieren. Sie gelten jedoch erst, nachdem Sie Codex Cloud auf der Berechtigungsseite aktiviert haben. Work Cloud verfügt über separate Funktionsberechtigungen, die unter So gilt Agent Security für Work Cloud beschrieben werden.

Basiskonfiguration festlegen und Umgebungseinstellungen hinzufügen

  1. Öffnen Sie Agent Security und prüfen Sie Ihre vorhandenen globalen Richtlinien, Zuweisungen und deren Reihenfolge. Gleichen Sie sie mit den vorgesehenen Steuerungen Ihrer Organisation ab. Diese Prüfung aktiviert den lokalen Computerzugriff mit Work Cloud nicht.

  2. Prüfen Sie Anforderungen und Standardwerte separat. Anforderungen legen Grenzen fest, die Benutzer nicht überschreiben können. Standardwerte legen die Ausgangswerte innerhalb dieser Grenzen fest.

  3. Belassen Sie Orchestrator-Steuerungen in Global. Dazu gehören Genehmigungsanforderungen, zulässige Websuchmodi und verwaltete Tool-Steuerungen.

  4. Fügen Sie Umgebungseinstellungen für Local oder Codex Cloud für unterstützte Ausführungssteuerungen hinzu, etwa Sandboxing, Dateisystemberechtigungen und verwalteten Netzwerkzugriff bei der Ausführung. Verwenden Sie bei Bedarf eine betriebssystemspezifische Überschreibung.

  5. Speichern Sie die Richtlinie und prüfen Sie etwaige Validierungsmeldungen zu den eingegebenen Einstellungen.

Steuerungen und Konfigurationsfelder auswählen

Der Orchestrator koordiniert die Aufgabe. Ein Executor ist der Computer oder Cloud-Container, der einen Ausführungsschritt ausführt. Konfigurieren Sie Orchestrator-Steuerungen in Global. Die Umgebungseinstellungen für requirements.toml unterstützen ausschließlich Ausführungssteuerungen. Orchestrator-Einstellungen wie Genehmigungsrichtlinie und Websuche bleiben in Global und können nicht durch eine Umgebung überschrieben werden.

Orchestrator-Steuerungen

Konfigurieren Sie diese Steuerungen in Global. Für Work mit lokalem Zugriff und dots gelten unterstützte globale Richtlinien über den gemeinsamen Cloud-Orchestrator, wenn verwaltete Richtlinien aktiviert sind. Umgebungsüberschreibungen gelten für unterstützte Ausführungseinstellungen und können Orchestrator-Steuerungen nicht überschreiben. Von den unten aufgeführten Anforderungen für Genehmigungen, Websuche, Apps, MCP, Plugins und Regeln verfügen nur Allowed approval policies und Allowed web search modes über eigene Steuerelemente in der Agent-Security-Oberfläche. Konfigurieren Sie die anderen Felder über TOML.

Steuerung Was damit gesteuert wird Felder in requirements.toml
Genehmigungsrichtlinien und Prüfung Wann der Agent eine Genehmigung benötigt und wer die Prüfung durchführt, einschließlich automatischer Prüfung. allowed_approval_policies
allowed_approvals_reviewers
auto_review
guardian_policy_config
Websuchmodi Welche Websuchmodi der Agent verwenden darf. allowed_web_search_modes
Apps, MCP server und plugins Verfügbare Apps, MCP server und Plugins sowie deren Konfiguration. apps
mcp_servers
plugins
Befehlsregeln mit rules Welche Befehle der Agent ausführen kann, welche eine Genehmigung erfordern und welche er nicht ausführen darf. rules
Verwaltete hooks Von Administratoren definierte Aktionen bei unterstützten Aufgaben- und Tool-Ereignissen. hooks
allow_managed_hooks_only

Hooks beim lokalen Computerzugriff mit Work Cloud

Wenn verwaltete Richtlinien und Remote-Hooks aktiviert sind, verwenden Work Cloud mit lokalem Zugriff und dots administrativ verwaltete Remote-MCP-Hooks auf dem Cloud-Orchestrator. Konfigurieren Sie mcp_tool-Handler in den globalen requirements.toml. Work Cloud ohne lokalen Zugriff und persönliche Konten verwenden diese Enterprise-Hooks nicht. Befehls-/Shell-, Prompt- und Agent-Handler; Hooks aus lokaler Konfiguration, Plugins oder lokalen Verzeichnissen; umgebungsbezogene Hooks sowie SessionEnd-MCP-Hooks werden bei Cloud-Orchestrierung nicht unterstützt, auch wenn Tools lokal ausgeführt werden. Wenn sowohl Orchestrierung als auch Ausführung lokal erfolgen, funktionieren bestehende unterstützte Hooks weiterhin in ausschließlich lokalen Work- und Codex-Threads. Administratoren können für diese Arbeitsabläufe weiterhin unterstützte verwaltete Hooks in Agent Security konfigurieren.

Bevor Sie sich auf diese Hooks verlassen, testen Sie die Callback-Konnektivität, erforderliche Ereignisse und das Fehlerverhalten. Eine explizite unterstützte Ablehnung kann eine Aktion blockieren. Ein PreToolUse-Callback-Fehler, eine Zeitüberschreitung oder eine fehlerhafte Antwort kann jedoch zum Fehlschlagen des Hooks führen, ohne das Tool zu blockieren. MCP-Hooks bieten kein vollständiges Audit-Protokoll über die Compliance API.

Global enthält auch Desktop- und Client-Einstellungen. Einige dieser Einstellungen gelten nur für die Desktop-App. Eine Einstellung in Global zu konfigurieren bedeutet nicht, dass sie überall gilt. Informationen zur unterstützten Verwendung der einzelnen Felder finden Sie in der Konfigurationsreferenz.

Ausführungssteuerungen (Executor)

Diese Felder steuern, wie Arbeit auf einem Computer oder in einem Cloud-Container ausgeführt wird. Legen Sie gemeinsame Werte in Global fest. Verwenden Sie Local- oder Codex-Cloud-Überschreibungen für unterstützte Einstellungen, die in der jeweiligen Umgebung abweichen müssen.

Steuerung Was damit gesteuert wird Felder in requirements.toml
Verwendung einer Login-Shell Ob Shell-Tools eine Login-Shell starten können. allow_login_shell
Zulässige Sandbox-Modi Welche Sandbox-Modi der Executor verwenden kann. allowed_sandbox_modes
Berechtigungsprofile und Standardwerte Zulässige Berechtigungsprofile, deren Zugriffsgrenzen und das Standardprofil. allowed_permission_profiles
default_permissions
permissions
Remote-Sandbox-Konfiguration Hostspezifische Sandbox-Modi, ausgewählt anhand des Hostnamens. remote_sandbox_config
Verwalteter Netzwerkzugriff bei der Ausführung Verwalteter Netzwerkzugriff, einschließlich erlaubter und gesperrter Ziele. experimental_network
Windows-Ausführungseinstellungen Plattformspezifische Ausführungs- und Sandbox-Einstellungen unter Windows. windows

Die Tabelle zeigt, welche Feldgruppen Umgebungsüberschreibungen unterstützen. Die unterstützten Optionen innerhalb jeder Gruppe können je nach Plattform variieren. Manche Anforderungen werden richtlinienübergreifend kombiniert, statt einander zu ersetzen. Unterstützte Werte finden Sie in der Konfigurationsreferenz, Netzwerkausnahmen unter „Verwaltete Konfiguration“.

Auf unterstützten verwalteten Codex-Cloud-Ausführungswegen begrenzen Agent-Security-Anforderungen den Netzwerkzugriff von Befehlen. Die Interneteinstellungen der Codex-Cloud-Umgebung gelten separat. Eine in Agent Security erlaubte Domain hebt keine Beschränkung in den Interneteinstellungen der Cloud-Umgebung auf. Diese Steuerungen für den Netzwerkzugriff von Befehlen deaktivieren für sich allein weder gehostete Websuche noch Apps oder MCP. ChatGPT Work Cloud verfügt über separate Funktionsberechtigungen und erbt diese Agent-Security-Anforderungen nicht.

Eine verwaltete Befehlsfreigabeliste gilt für Befehle, die den verwalteten Proxy verwenden. Wenn die Richtlinie eine vollständige Sandbox-Eskalation erlaubt und diese genehmigt wird, kann die betreffende Ausführung den Befehlsproxy umgehen. Eine begrenzte Netzwerkfreigabe unterscheidet sich von einer vollständigen Sandbox-Eskalation. Konfigurieren Sie verbindliche Genehmigungs- und Sandbox-Anforderungen entsprechend der gewünschten Grenze und testen Sie sowohl normale als auch eskalierte Befehle.

Netzwerkzugriff in der Oberfläche konfigurieren

  1. Öffnen Sie Admin Console > Agent Security. Wählen Sie eine Richtlinie und dann Global, Local oder Codex Cloud aus. Verwenden Sie Global für die gemeinsame Basiskonfiguration und eine Umgebungsüberschreibung für unterstützte Abweichungen.
  2. Öffnen Sie Requirements und aktivieren Sie Manage Networking. Fügen Sie die erforderlichen Domaineinträge hinzu und wählen Sie jeweils Allow oder Deny. Aktivieren Sie Only allow domains added by admins, wenn die normale Benutzerkonfiguration und Genehmigungen für einzelne Domains die Freigabeliste des verwalteten Proxys nicht erweitern dürfen.
  3. Prüfen Sie vor dem Speichern die wirksamen Einstellungen und geerbten Regeln. Leere Umgebungseinstellungen erben Global, statt dessen Einstellungen zu löschen. Prüfen Sie die lokale/private Konnektivität für Codex Cloud separat. „Netzwerkzugriff verwalten“ zu deaktivieren ist nicht dasselbe wie den Internetzugriff der Cloud-Umgebung auszuschalten.
  4. Prüfen Sie für Codex Cloud außerdem die Einstellungen der Umgebung für Internetzugriff, Ziele und Methoden. Speichern Sie die Einstellungen und testen Sie jeweils eine Anfrage, die erlaubt sein soll, und eine, die blockiert werden soll. Testen Sie jede erlaubte vollständige Sandbox-Eskalation separat.

Keine wirksam erlaubten Ziele

Wenn Manage Networking und Only allow domains added by admins aktiviert sind, benötigen normale verwaltete Befehle wirksam erlaubte Ziele. Sind keine Einträge vom Typ „Erlauben“ konfiguriert oder geerbt, haben diese Befehle keine erlaubten Ziele. Eine Richtlinie, die ausschließlich Sperren enthält, erlaubt nicht implizit den Rest des Internets. Fügen Sie die erforderlichen Einträge vom Typ „Erlauben“ hinzu und prüfen Sie vor dem Speichern die geerbten Regeln. Diese Beschränkung gilt für den verwalteten Befehlsproxy, nicht für jedes Tool oder eine genehmigte vollständige Sandbox-Eskalation.

Lokale/private Konnektivität von Codex Cloud

Ein expliziter Aus-Wert für lokale/private Konnektivität kann verhindern, dass Codex Cloud seinen vorgeschalteten Proxy erreicht, selbst wenn die Zieldomain erlaubt ist. Prüfen Sie den endgültigen Wert von allow_local_binding und ermitteln Sie, aus welcher Richtlinie oder Einstellung er stammt. Auf dem unterstützten Cloud-Proxy-Pfad ist der Standardwert nur dann true, wenn keine geltende Anforderung, kein ausgewähltes Netzwerkprofil und keine Proxy-Funktionseinstellung einen Wert vorgeben. Ein geerbtes false zählt weiterhin als explizite Einstellung. Legen Sie, sofern unterstützt, eine Cloud-Überschreibung mit höherer Priorität fest, um diesen Wert für Codex Cloud zu ändern, ohne den von Local verwendeten globalen Wert zu ändern. Dadurch werden keine Domaineinträge vom Typ „Erlauben“ hinzugefügt. Prüfen Sie die Unterstützung durch den Executor, bevor Sie sich auf die Überschreibung verlassen. Wenden Sie diesen Cloud-Standardwert nicht auf Local an.

Umgebungsstandardwerte

Der Editor für Standardwerte verwendet config.toml-Felder, die sich von requirements.toml-Beschränkungen unterscheiden. Unterstützte Umgebungsstandardwerte auf oberster Ebene sind:

  • Shell-Verhalten: allow_login_shell und shell_environment_policy.

  • Sandbox und Berechtigungen: sandbox_mode, sandbox_workspace_write, default_permissions und permissions.

  • Windows-Ausführung: windows.

Ein Standardwert überschreibt keine verbindliche Anforderung. Belassen Sie Orchestrator-Standardwerte, einschließlich Genehmigungs- und Websucheinstellungen, in Global.

Zusammenspiel von Richtlinien verstehen

  • Richtlinienübergreifend hat eine Richtlinie mit höherer Priorität Vorrang vor einer mit niedrigerer Priorität, selbst wenn die Richtlinie mit niedrigerer Priorität spezifischer ist.

  • Innerhalb einer Richtlinie werden unterstützte Ausführungseinstellungen in dieser Reihenfolge aufgelöst: eine betriebssystemspezifische Umgebungsüberschreibung, eine Umgebungsüberschreibung für alle Betriebssysteme, dann Global.

  • Bei lokaler Ausführung stehen MDM und bisherige Anforderungen für verwaltete Geräte über Agent Security. Die Systemanforderungsdatei des Geräts steht unter Agent Security.

Für dieselbe Domainregel innerhalb einer Richtlinie kann eine administrative Umgebungsüberschreibung eine in Global gesperrte Domain erlauben oder eine in Global erlaubte Domain sperren. Ohne Umgebungsüberschreibung wird die globale Regel geerbt. Andere wirksame Sperrregeln oder Zugriffskontrollen können eine Anfrage weiterhin blockieren.

Diese Ergebnisse beziehen sich auf denselben Domainschlüssel innerhalb einer Richtlinie, ohne dass eine Richtlinie mit höherer Priorität das Ergebnis verändert. Ein Wert mit höherer Priorität ersetzt denselben Schlüssel. Andere geerbte Schlüssel bleiben erhalten. Eine Freigabe umgeht keine andere zutreffende Sperre, etwa ein geerbtes Platzhaltermuster. Eine leere Umgebungszuordnung löscht keine geerbten Regeln.

So gilt Agent Security für Work Cloud

Konfigurieren Sie Cloud browser use und Cloud network access unter Admin Console > Permissions & roles > Workspace capabilities > Cloud computer capabilities. Diese gemeinsamen Funktionen stehen Work Cloud und dots zur Verfügung und können unabhängig vom Zugriff auf Work Cloud konfiguriert werden. Eine Work-Aufgabe benötigt weiterhin Zugriff auf Work und eine Berechtigung für jede benötigte Funktion. Prüfen Sie Browserzugriff und Netzwerkzugriff über Code oder Shell separat. Das Deaktivieren des einen deaktiviert nicht automatisch das andere.

Work-Cloud-Container und Cloud-Computer von dots verwenden eigene Ausführungskonfigurationen und Anforderungen statt des verwalteten Umgebungspakets, das andere Executor-Typen verwenden. Lokale Datei- und Netzwerkbeschränkungen gelten nicht automatisch für diese Cloud-Computer. Unterstützte globale Orchestrator-Richtlinien haben einen separaten Geltungsbereich. Eine globale Richtlinie oder eine Codex-Cloud-Überschreibung konfiguriert keine gemeinsamen Cloud-Funktionsberechtigungen. Prüfen Sie diese Berechtigungen separat.

Prüfen Sie den Workspace-Standard, alle direkt und über Gruppen zugewiesenen Rollen sowie separat durchgesetzte Beschränkungen wie Lockdown Mode, wenn Sie den effektiven Zugriff eines Mitglieds überprüfen.

Bevor Sie Allow local computer access unter Work Cloud aktivieren, prüfen Sie die globale Basiskonfiguration und deren Kompatibilität mit den Steuerungen, auf die Ihre Organisation angewiesen ist. Use Codex locally on the ChatGPT desktop app ist keine Voraussetzung. Wenn enforce_residency in einer beliebigen Cloud-Richtlinie aktiviert ist, wird Allow local computer access sowohl für Work als auch für dots deaktiviert. Diese Schutzmaßnahme konfiguriert weder die Datenresidenz des Workspace noch deaktiviert sie für sich allein Work Cloud oder dots. Separate Einrichtungsschritte, Voraussetzungen und das Verbindungsverhalten finden Sie unter Lokaler Computerzugriff für Work Cloud und dots.

Richtlinien-API und Terraform

Verwenden Sie die Richtlinien-API, um globale Einstellungen zu verwalten. Verwenden Sie für Local- oder Codex-Cloud-Einstellungen die Agent-Security-Oberfläche. Bestehende API-Workflows für Global bleiben nach der Migration verfügbar. Testen Sie Ihre Skripte und Terraform-Integrationen und vergewissern Sie sich, dass Richtlinienzuweisungen und Reihenfolge unverändert sind.

Die Richtlinienmigration ändert weder die SCIM-Mitgliedschaftssynchronisierung noch RBAC-Rollen.

Weiterführende Anleitungen