Lokale Sicherheit von ChatGPT Work

ChatGPT Work kann genehmigte Dateien, Anwendungen und Browsersitzungen auf dem Computer eines Benutzers verwenden, um lokale Aufgaben zu erledigen. Der Zugriff hängt von den Berechtigungen des Workspace, dem bestehenden Kontozugriff des Benutzers, den Berechtigungen des Betriebssystems, den Anwendungsfreigaben und den unterstützten Geräterichtlinien ab.

Einen Überblick über die Sicherheitsmaßnahmen finden Sie im Whitepaper zur Unternehmenssicherheit von ChatGPT Work.

Lokale Funktionen hängen von der unterstützten Desktop-App, dem Betriebssystem, der Berechtigung des Workspace, den Rollenberechtigungen, der Geräterichtlinie und der Produkteinführung ab.

Sicherheit im Überblick

• Lokale Schritte werden über die ChatGPT-Desktop-App ausgeführt. Beim lokalen Computerzugriff mit Work Cloud koordiniert die Cloud von OpenAI die Aufgabe, während der verbundene Computer die Schritte ausführt, für die er benötigt wird.

• Die verfügbaren lokalen und gehosteten Work-Steuerelemente hängen von der Workspace-Konfiguration und der Einführung ab.

• Dateizugriff, Computer Use, Browser und verbundene Apps verwenden unterschiedliche Berechtigungen und Freigaben.

• Ein Browser oder eine Anwendung, in dem bzw. der bereits eine Anmeldung bei einem Unternehmenssystem besteht, kann die Berechtigungen dieses bestehenden Kontos verfügbar machen.

• Unterstützte Richtlinien für verwaltete Geräte können lokale Funktionen einschränken, ohne die Zugriffskontrollen des Workspace zu ersetzen.

• Daten aus Business-, Enterprise- und Edu-Workspaces, die von abgedeckten OpenAI-Diensten verarbeitet werden, sind bei der Übertragung und im Ruhezustand verschlüsselt und werden standardmäßig nicht zum Trainieren von OpenAI-Modellen verwendet.

• Für lokale Dateien, Aufgabenkontext, Browserdaten, Datensätze verbundener Systeme und Überwachungsereignisse können unterschiedliche Speicherungs- und Aufbewahrungsregeln gelten.

Wo lokale Aufgaben ausgeführt werden

Bei der lokalen Ausführung erfolgt der Zugriff auf genehmigte Ressourcen über die Desktop-App auf dem Computer des Nutzers. Wenn der lokale Computerzugriff mit Work Cloud aktiviert ist, koordiniert die Cloud von OpenAI die Aufgabe und ruft den verbundenen Computer auf, sobald ein Schritt eine lokale Ausführung erfordert. Für diese Schritte muss der Computer online und verbunden sein.

Der lokale Computerzugriff mit Work Cloud gilt nur für Aufgaben, die nach der Aktivierung der Synchronisierung erstellt werden. Bestehende Aufgaben, einschließlich Aufgaben in Projekten, behalten ihren ursprünglichen Modus bei: ausschließlich lokal oder in der Cloud ohne Zugriff auf lokale Dateien. Starten Sie eine neue Aufgabe, um diese Funktion zu nutzen.

Wenn der Computer zu Beginn eines neuen Gesprächsschritts nicht verfügbar ist, kann eine bestehende, dafür geeignete Aufgabe, die den lokalen Computerzugriff mit Work Cloud nutzt, in einem Cloud-Container fortgesetzt werden. Der Cloud-Container kann nicht auf Dateien oder Tools auf dem nicht verfügbaren Computer zugreifen. Er setzt auch keine Unternehmensanforderungen aus der lokalen Ausführung durch. Während eines Gesprächsschritts kann eine Aufgabe nicht von der lokalen Ausführung in die Cloud wechseln.

Lokale Dateien können auf dem Gerät verbleiben. Relevante Dateiauszüge, Prompts, Screenshots, Browserinhalte oder Werkzeugergebnisse können jedoch an OpenAI-Dienste gesendet werden, um eine Aufgabe zu erledigen. Lokale Ausführung bedeutet nicht, dass die Modellinferenz offline oder ausschließlich auf dem Gerät erfolgt.

Datei- und Gerätezugriff

Eine lokale Aufgabe kann mit Informationen arbeiten, die der Benutzer bereitstellt oder verfügbar macht, einschließlich unterstützter Dateien, Anwendungsinhalte, Browsersitzungen und autorisierter verbundener Systeme. Der Zugriff hängt von den bestehenden Berechtigungen des Benutzers und den Steuerelementen für die jeweilige Funktion ab.

Die Gewährung des lokalen Work-Zugriffs genehmigt nicht automatisch jede Anwendung, erteilt keine Administratorrechte und umgeht nicht die Berechtigungen des Kontos, das für den Zugriff auf ein anderes System verwendet wird. Eine genehmigte freigegebene Verbindung kann andere Berechtigungen als das persönliche Konto des Benutzers haben.

Direktes Lesen und Bearbeiten von Dateien sowie Shell-Befehle unterliegen den Sandbox- und Genehmigungseinstellungen der Aufgabe. Computer Use greift über eine genehmigte native Anwendung und mit deren Berechtigungen auf Inhalte zu. Eine Beschränkung des direkten Dateizugriffs bewirkt für sich genommen keine entsprechende Beschränkung für Dateien, die die Anwendung öffnen kann.

Computer Use und Anwendungsfreigaben

Die Berechtigungen des Arbeitsbereichs bestimmen, wer Work Local nutzen kann. Administratorrichtlinien können zusätzlich einschränken, welche nativen Anwendungen Computer Use bedienen darf und ob Anwendungsgenehmigungen für künftige Sitzungen gespeichert werden können. Erforderliche Betriebssystemberechtigungen und Anwendungsgenehmigungen gelten weiterhin. Wenn eine Aufgabe eine Anwendung oder ein angemeldetes Konto nutzt, bestimmen die Berechtigungen dieses Kontos, welche Informationen und Aktionen verfügbar sind.

Die Zulassung einer Anwendung durch eine Administratorrichtlinie installiert weder das erforderliche Plugin noch erteilt sie Betriebssystemberechtigungen oder genehmigt eine Aktion, die weiterhin geprüft werden muss. Unterstützte Steuerungsmöglichkeiten und Konfigurationsbeispiele finden Sie unter Verwaltete Steuerungsmöglichkeiten für Browser und Computer Use.

Unter macOS ermöglicht die Bildschirmaufnahme Computer Use, Anwendungsinhalte zu sehen, während die Bedienungshilfen das Klicken, Tippen und Navigieren ermöglichen. Unterstützte macOS-Aufgaben können im Hintergrund ausgeführt werden. Unter Windows arbeitet Computer Use auf dem aktiven, sichtbaren Desktop und kann nicht im Hintergrund ausgeführt werden, während der Benutzer dieselbe Sitzung weiter verwendet.

Benutzer können eine Aufgabe jederzeit beenden. Computer Use kann keine Sicherheitsabfragen des Betriebssystems bestätigen, sich nicht als Administrator authentifizieren und weder Terminal-Anwendungen noch ChatGPT selbst automatisieren.

Gesperrte Geräte

Unterstützte macOS-Konfigurationen können optional zulassen, dass eine genehmigte Computer Use-Aufgabe nach dem Sperren des Mac fortgesetzt wird. Die Verfügbarkeit hängt von der App-Version, der schrittweisen Bereitstellung der Funktion, den geltenden Vorgaben und der Berechtigung zur Fernsteuerung ab.

Beim Aktivieren von Locked Use wird ein macOS-Autorisierungsplugin installiert, das den Mac für einen aktiven, vertrauenswürdigen Computer Use-Durchlauf vorübergehend entsperren kann. ChatGPT verdeckt während der vorübergehenden Entsperrung alle Bildschirme. Wenn lokale Tastatur- oder Zeigereingaben erkannt werden, sperrt ChatGPT den Mac erneut und setzt die automatische Entsperrung aus, bis der Benutzer ihn manuell entsperrt. Siehe So funktioniert Locked Use.

Administratoren können verhindern, dass Benutzer Locked Use auf verwalteten Macs aktivieren. Diese Vorgabe deaktiviert Locked Use nicht, wenn es bereits aktiviert ist. Computer Use unter Windows erfordert einen aktiven, entsperrten Desktop. Siehe Beschränkungen für Locked Use.

Browsersitzungen und bestehende Anmeldungen

Work Local erhält nicht automatisch Zugriff auf jeden Browser oder jedes Unternehmenskonto. Der Zugriff hängt vom verwendeten Browser, dem angemeldeten Konto und den für das jeweilige Browsererlebnis erforderlichen Freigaben ab.

Unterstützte Browser Use-Richtlinien können den Websitezugriff, Uploads, Downloads, den Zugriff auf den Browserverlauf und den vollständigen Zugriff auf das Chrome DevTools Protocol (CDP) zur Browser-Fehlersuche einschränken. Administratoren können außerdem die automatische Genehmigungsprüfung, gespeicherte Genehmigungen und die Gültigkeitsdauer von Websitezugriffsgenehmigungen einschränken. Eine Benutzergenehmigung kann eine Ablehnung durch einen Administrator nicht außer Kraft setzen. Siehe Verwaltete Browser-Steuerungsmöglichkeiten.

Ein gehosteter Cloud-Browser ist von den lokalen Browsern des Benutzers getrennt und übernimmt deren bestehende Anmeldungen nicht automatisch. Die Anmeldung bei Websites über den Cloud-Browser ist in Enterprise- oder Edu-Arbeitsbereichen nicht verfügbar.

Apps, Plugins und verbundene Konten

Eine verbundene App kann Zugriff auf Informationen oder Aktionen in einem anderen System bereitstellen. Ein Plugin kann eine App als zugrunde liegendes Werkzeug verwenden. Wenn ein Plugin verfügbar gemacht wird, aktiviert dies nicht automatisch die erforderliche App, autorisiert kein Konto und erlaubt nicht jede Aktion.

Die Standardeinstellungen für Plugins und Apps hängen vom Tarif und davon ab, ob der Arbeitsbereich neu ist oder bereits besteht. In neuen Enterprise- und Edu-Arbeitsbereichen ist zunächst eine ausgewählte Gruppe von Apps aktiviert; diese Standardeinstellungen ändern keine Einstellungen bestehender Arbeitsbereiche und gelten nicht für Healthcare-Arbeitsbereiche. Im Allgemeinen sind neue Plugins und Apps in Enterprise und Edu standardmäßig deaktiviert. In Business sind Apps standardmäßig aktiviert. Administratoren können die Verfügbarkeit ändern. Siehe die aktuellen Standardeinstellungen für Plugins und Apps und die Übersicht über ChatGPT Work.

Bevor eine Aufgabe ein verbundenes System verwendet, vergewissern Sie sich, dass der Workspace die App und alle erforderlichen Plugins zulässt, die Verbindung autorisiert ist und das verbundene Konto auf die angeforderten Informationen oder Aktionen zugreifen kann. Schreibgeschützte Einstellungen, zulässige Aktionen und Bestätigungsanforderungen unterscheiden sich je nach Integration.

Plugins, die Browser- oder Computer Use-Funktionen bereitstellen, erfordern eine eigene Prüfung ihrer Verfügbarkeit und Installation. Die Bereitstellung eines Plugins setzt weder verwaltete Browserrichtlinien oder Richtlinien für native Anwendungen noch Betriebssystemberechtigungen oder erforderliche Genehmigungen außer Kraft. Reine Desktop-Plugins und lokal bereitgestellte Tools können andere Installationswege verwenden. Siehe Plugin-Steuerungsmöglichkeiten.

Persönliche und freigegebene Verbindungen

Eine persönliche Verbindung verwendet die Berechtigungen des verbundenen Benutzers im Quellsystem. Eine freigegebene oder einem Agenten gehörende Verbindung verwendet die Berechtigungen des verbundenen Kontos, die umfassender als der eigene Zugriff des Benutzers sein können.

Beschränken Sie freigegebene Konten auf die erforderlichen Daten und Aktionen, begrenzen Sie ihren Benutzerkreis und wenden Sie unterstützte Aktions- oder Bestätigungssteuerelemente an. Datensätze im verbundenen System unterliegen weiterhin den Berechtigungen und Aufbewahrungsrichtlinien dieses Systems.

Administratorzugriff und Richtlinien für verwaltete Geräte

Prüfen Sie für den lokalen Computerzugriff mit Work Cloud sowohl die Synchronisierungsberechtigung des Arbeitsbereichs als auch die Anforderungen von Agent Security für die lokale Ausführung.

Bei der lokalen Ausführung haben MDM-Anforderungen und ältere Anforderungen für verwaltete Geräte Vorrang vor Agent Security. Die Systemanforderungsdatei des Geräts hat eine niedrigere Priorität als Agent Security. Innerhalb einer Richtlinie haben betriebssystemspezifische Umgebungsüberschreibungen Vorrang vor Umgebungsüberschreibungen für alle Betriebssysteme, gefolgt von Global. Eine Richtlinie mit höherer Priorität hat auch dann Vorrang, wenn eine Richtlinie mit niedrigerer Priorität spezifischer ist. Für einige Anforderungen gelten feldspezifische Zusammenführungsregeln.

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

Für Work mit lokalem Zugriff und dots gelten unterstützte Global-Richtlinien über den gemeinsamen Cloud-Orchestrator, wenn verwaltete Richtlinien aktiviert sind. Die anwendbaren lokalen Anforderungen aus requirements.toml regeln die Ausführung auf einem verbundenen Computer. Cloud-Container von Work und Cloud-Computer von dots verwenden ihre eigene Ausführungskonfiguration und eigene Anforderungen anstelle des verwalteten Umgebungspakets, das andere Ausführungstypen verwenden. Einschränkungen für die lokale Ausführung gelten nicht automatisch für diese Cloud-Computer. Prüfen Sie die Berechtigungen für Cloud-Funktionen und testen Sie die lokale Ausführung und die Cloud-Ausführung getrennt.

Prüfen Sie vor dem Aktivieren der Synchronisierung diese Anforderungen:

• Ausschließlich über MDM bereitgestellte Richtlinien. MDM stellt Richtlinien auf Geräten bereit. Erstellen Sie vor dem Aktivieren der Synchronisierung eine Basiskonfiguration in Agent Security für unterstützte Anforderungen an die lokale Ausführung.

• Unternehmens-Hooks. Sofern dies für Ihren Arbeitsbereich aktiviert ist, unterstützt der lokale Computerzugriff mit Work Cloud administratordefinierte MCP-Hooks, die bei unterstützten Lebenszyklus- und Tool-Ereignissen auf dem Cloud-Koordinator (Orchestrator) ausgeführt werden. Befehls-Hooks und Hooks aus der lokalen Konfiguration oder aus Plugins werden bei der Cloud-Orchestrierung nicht unterstützt, auch wenn Tools lokal ausgeführt werden. Wenn sowohl die Orchestrierung als auch die Ausführung lokal erfolgen, funktionieren bestehende unterstützte Hooks weiterhin in rein lokalen Work- und Codex-Threads. Administratoren können für diese Workflows weiterhin unterstützte verwaltete Hooks in Agent Security konfigurieren.

• Auditierung. Bevor Sie sich auf diese Hooks verlassen, testen Sie die Callback-Verbindung, prüfen Sie die empfangenen Ereignisse und kontrollieren Sie, wie sich Fehler auf die Aufgabe auswirken. MCP-Hooks bieten kein vollständiges Auditprotokoll über die Compliance API.

Prüfen Sie die unter Workspace settings > Permissions & roles verfügbaren Steuerelemente für Work. Ob lokales und gehostetes Work als separate Berechtigungen angezeigt werden, hängt von der Arbeitsbereichskonfiguration und dem Rollout ab. Weitere Hinweise finden Sie in den FAQ für Work-Administratoren.

Aktivieren Sie für jeden Benutzer oder jede Gruppe nur die genehmigten Ausführungsumgebungen und überprüfen Sie nach Änderungen den tatsächlich wirksamen Zugriff.

Workspace-Berechtigungen bestimmen, wer Work verwenden kann. Administratoren können unterstützte Desktop-Funktionen außerdem durch verbindliche Anforderungen einschränken, die in requirements.toml definiert sind. Je nach Bereitstellung können diese Anforderungen über eine vom Workspace verwaltete Konfiguration, eine Konfigurationsdatei auf Systemebene oder unterstützte Werkzeuge zur Verwaltung mobiler macOS-Geräte bereitgestellt werden.

Verbindliche Anforderungen können von einzelnen Benutzern nicht außer Kraft gesetzt werden. Verwaltete Standardwerte legen hingegen anfängliche Einstellungen fest, die Benutzer möglicherweise ändern können. Keines von beidem ersetzt Workspace-Rollen oder Betriebssystemberechtigungen.

Bei lokalen Clients, die den bestehenden lokalen Konfigurationspfad verwenden, werden verwaltete Vorgaben beim Laden der Konfiguration geladen. Eine Hintergrundaktualisierung kann Cloud-Vorgaben für einen späteren Ladevorgang vorbereiten. Änderungen an macOS-MDM-Einstellungen werden beim nächsten Clientstart eingelesen. Starten Sie nach einer Änderung lokaler Richtlinien den betreffenden lokalen Client neu und überprüfen Sie ihn.

Wenn Sie den lokalen Computerzugriff mit Work Cloud deaktivieren, werden aktuell laufende Interaktionsschritte unterbrochen. Benutzer können in einer bestehenden Cloud-Unterhaltung einen neuen Interaktionsschritt starten. Dieser verwendet automatisch Work Cloud ohne Zugriff auf lokale Dateien.

Aus diesem lokalen Ladeverhalten lässt sich nicht ableiten, wann eine Änderung an Cloud-Richtlinien in einer laufenden Aufgabe mit lokalem Computerzugriff über Work Cloud wirksam wird. Überprüfen Sie die für die Aufgabe tatsächlich geltenden Kontrollen, bevor Sie sich auf die Aktualisierung verlassen.

Dies sind Beispiele für Einschränkungen, keine Liste aktivierter Standardeinstellungen. Wenn Sie eine Funktionsvorgabe weglassen, bleiben die normalen Client-, Plattform-, Rollout- und Benutzereinstellungen wirksam. Feature-Flags für Browser Use, der integrierte Browserbereich und natives Computer Use sind separate Steuerelemente. Prüfen Sie jeden Browserzugriffsweg einzeln.

Die verfügbaren Einstellungen und Bereitstellungsmethoden hängen vom Client, Betriebssystem, Arbeitsbereich und der Bereitstellungskonfiguration ab. Überprüfen Sie Einschränkungen auf einem repräsentativen verwalteten Gerät. Unterstützte Richtlinieneinstellungen, Konfigurationsbeispiele und Anleitungen zur MDM-Einrichtung finden Sie unter Verwaltete Konfiguration.

Lokale Netzwerke und private Ressourcen

Work Local kann über einen Browser, eine native Anwendung, eine verbundene App oder ein anderes unterstütztes Tool auf Unternehmensinformationen zugreifen. Netzwerkkontrollen greifen je nach Zugriffsweg unterschiedlich, und der Zugang zu einem Unternehmens-VPN allein berechtigt eine Aufgabe nicht zur Nutzung einer internen Ressource.

Verwaltete Netzwerkvorgaben und Ursprungsrichtlinien für Browser Use werden getrennt geprüft. Überprüfen Sie beide auf den in Ihrer Bereitstellung eingesetzten App-Versionen und Betriebssystemen, bevor Sie sich darauf verlassen, dass eine Netzwerkeinschränkung Browser Use begrenzt. Prüfungen von Browserrichtlinien bedeuten nicht, dass der Browserverkehr über den Proxy für den Netzwerkverkehr von Befehlen geleitet wird. Browser Use-Richtlinien regeln zudem nicht den Datenverkehr nativer Anwendungen.

Verwaltete Netzwerkvorgaben unter [experimental_network] sind experimentell und können sich ändern. Die Windows-Unterstützung ist eingeschränkt; testen Sie den konkreten Client und die konkrete Umgebung, bevor Sie diese Vorgaben auf Windows-Benutzer anwenden. Domainregeln allein aktivieren den verwalteten Proxy nicht; experimental_network.enabled = true ist erforderlich und setzt eine Sandbox, in der der Netzwerkzugriff deaktiviert bleibt, nicht außer Kraft.

Prüfen Sie die Verbindung, das angemeldete Konto, das Ziel und die für den Workflow erforderliche Aktion. Konfigurationsdetails und plattformspezifische Einschränkungen finden Sie unter Vorgaben für den Netzwerkzugriff.

Datenverarbeitung und Aufbewahrung

Beim lokalen Computerzugriff mit Work Cloud ist die Cloud-Koordination auch dann Teil des Workflows, wenn ein Schritt auf dem Computer ausgeführt wird. Prüfen Sie Unterhaltungsdaten und Aufgabenkontext getrennt von den lokalen Dateien, die ein Tool verwendet. Gehen Sie nicht davon aus, dass lokale Ausführung eine ausschließlich gerätebasierte Speicherung bedeutet oder dass jede Datei in einem Ordner hochgeladen wird.

Der lokale Computerzugriff mit Work Cloud bietet keine strikte Zero Data Retention. Datenresidenz und Inferenzresidenz gelten nur für berechtigte Inhalte sowie unterstützte Workloads, Regionen und Konfigurationen. Enterprise Key Management (EKM) deckt unterstützte gespeicherte Inhalte in berechtigten Arbeitsbereichen ab. Work wird mit Inferenzresidenz in den VAE nicht unterstützt. Prüfen Sie vor dem Rollout, welche Speicherung, Aufbewahrung und Auditierung für den Arbeitsbereich abgedeckt sind. Wenn Ihre Organisation ZDR erfordert, aktivieren Sie diese Funktion nicht. Wenn enforce_residency in einer 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 Residenz des Arbeitsbereichs noch deaktiviert sie für sich genommen Work Cloud oder dots.

Wenden Sie die Endpunkt-, Dateizugriffs-, Proxy- und Data-Loss-Prevention-Kontrollen Ihrer Organisation auf das jeweilige Gerät und den jeweiligen Workflow an. Prüfen Sie, ob diese Kontrollen verhindern können, dass sensible Informationen vor der Verarbeitung in die Aufgabe gelangen. Überwachungsprotokolle und Compliance-Exporte unterstützen Überwachung und Untersuchungen, blockieren die Verarbeitung jedoch nicht selbst.

Speicherung und Aufbewahrung hängen von der Informationskategorie und dem Speicherort ab.

Für unterstützte Business-, Enterprise- und Edu-Workspaces werden Geschäftsdaten, die von abgedeckten OpenAI-Diensten verarbeitet werden, bei der Übertragung und im Ruhezustand verschlüsselt und standardmäßig nicht zum Trainieren oder Verbessern von OpenAI-Modellen verwendet. Diese Schutzmaßnahmen bedeuten nicht, dass OpenAI jede Gerätedatei, Drittanbieteranwendung, jedes Browserprofil oder jeden Datensatz eines Quellsystems verwaltet.

Wenden Sie einen Aufbewahrungszeitraum für gehostete Unterhaltungen, temporäre Uploads oder Compliance-Protokolle nicht auf lokale Datensätze an, ohne zu prüfen, ob er für die jeweilige Datenkategorie gilt.

Sichtbarkeit für Überwachung und Compliance

Wenn Sie den lokalen Computerzugriff mit Work Cloud aktivieren, ändert sich, welche Ereignisse Ihr bestehender OpenTelemetry-Collector (OTel) empfängt. Ihre lokale Ausführungskomponente kann weiterhin unterstützte Ausführungsereignisse exportieren. Ereignisse der Cloud-Orchestrierung erreichen Ihren bestehenden OpenTelemetry-Collector nicht.

Verwenden Sie die Compliance API für unterstützte Cloud-Aufzeichnungen. Eine Änderung des Collector-Endpunkts stellt die Übermittlung von Cloud-Orchestrierungsereignissen nicht wieder her. Aufzeichnungen der Compliance API ersetzen nicht jedes Ereignis im bisherigen OpenTelemetry-Datenstrom. Siehe OpenTelemetry und Auditabdeckung prüfen.

Die verfügbare Berichterstattung hängt vom Workspace-Tarif, Produkterlebnis, Ereignis, der verbundenen Anwendung und der bereitgestellten Konfiguration ab. Überprüfen Sie die Abdeckung von Work Local, bevor Sie sich bei der Reaktion auf Vorfälle oder einer regulatorischen Prüfung auf einen Workspace-Export verlassen.

In unterstützten Versionen kann Browser Use OpenTelemetry-Ereignisse für Funktionsprüfungen ausgeben, darunter Websitezugriffe, Uploads und Downloads. Diese Ereignisse erfassen die Entscheidung und deren Quelle sowie Richtliniendetails, sofern verfügbar. Die Entscheidungsquelle kann unbekannt sein. Wenn der Export konfiguriert ist, werden sie zusammen mit weiteren Telemetriedaten der lokalen Laufzeit an den OpenTelemetry-Endpunkt des Kunden gesendet.

Konfigurieren Sie den OpenTelemetry-Export getrennt von den Aufzeichnungen der Compliance API. Diese Ereignisse bilden kein vollständiges Protokoll aller Aktionen im Browser oder in nativen Apps. Siehe OpenTelemetry-Konfiguration.

Ermitteln Sie, ob die relevanten Systeme die Aufgabenidentität, unterstützte Prompts und Antworten, Aufrufe verbundener Apps, Browserfreigaben, Anwendungsaktionen, lokale Dateiaktivitäten oder Endpunktereignisse erfassen. Datensätze von Quellsystemen und Geräten können eine andere Sichtbarkeit als Datensätze des ChatGPT-Workspace bieten.

OpenAI speichert keinen separaten vollständigen Datensatz der über die Erweiterung ausgeführten Chrome-Aktionen. Gehen Sie nicht davon aus, dass jeder lokale Dateivorgang, Screenshot, jede Browseraktion, Freigabe oder externe Aktualisierung in der Compliance API erscheint.

Beginnen Sie mit einer genehmigten Aufgabe

Überprüfen Sie lokales Work auf den verwalteten Geräten, die Ihre Teams verwenden. Führen Sie eine genehmigte Aufgabe aus, beispielsweise den Vergleich ausgewählter Finanzarbeitsmappen. Bestätigen Sie den Work-Zugriff jedes Benutzers und stellen Sie nur die Dateien, Anwendungen, Browsersitzungen oder verbundenen Konten bereit, die für die Aufgabe erforderlich sind.

Prüfen Sie, ob genehmigte Aktionen funktionieren, eingeschränkte Aktionen blockiert werden und die verfügbaren Aufzeichnungen Ihre Überwachungsanforderungen erfüllen. Lassen Sie den Benutzer die Ergebnisse prüfen und bestätigen, dass alle Änderungen an Dateien oder verbundenen Systemen der Anfrage entsprechen.