Die lokale Unix-Sandbox des OpenAI Agents SDK ist keine Sicherheitsgrenze für Enterprise-Mac-CI: Sie bietet keine Isolation auf Betriebssystemebene für Dateisystem oder Netzwerk. Führen Sie nicht vertrauenswürdige Befehle deshalb in einer tatsächlich isolierten, geprüften Umgebung aus; leiten Sie Xcode-Aufgaben nur an kontrollierte Mac-Build-Knoten weiter und halten Sie Produktionssignaturen getrennt.
Dieser Leitfaden richtet sich an IT- und Plattformverantwortliche, die Agenten in iOS- oder macOS-Pipelines integrieren und die Rechte der ausführenden Prozesse prüfen müssen.
Sicherheitsverantwortliche erhalten Kriterien, um den Zugriff auf Quellcode, interne Abhängigkeiten und Signaturmaterial zu bewerten.
Wenn Sie Mac-Build-Ressourcen planen, können Sie damit unterscheiden, welche Aufgaben wirklich macOS und Xcode benötigen.
OpenAI-Agents-SDK-Sandbox und Enterprise-Mac-CI: Arbeitsbereich ist nicht Host-Isolation
Ein SDK-Arbeitsbereich ordnet Dateien und Aufgaben. Er begrenzt aber nicht automatisch, was ein Prozess auf dem Host lesen, verändern oder über das Netzwerk erreichen kann. Für Ihre Sicherheitsentscheidung sind daher drei Ebenen getrennt zu prüfen: der Arbeitsbereich, die Berechtigungen des ausführenden Benutzerkontos und die Isolation, die das Betriebssystem oder ein Ausführungsbackend tatsächlich durchsetzt.
Die Dokumentation zu den Sandbox-Clients des OpenAI Agents SDK unterscheidet lokale Unix-Sandboxen, Docker-Sandboxen und verwaltete Ausführungsumgebungen. Für die lokale Unix-Ausführung stellt sie ausdrücklich klar, dass diese keine Isolation auf Betriebssystemebene für Dateisystem oder Netzwerk bereitstellt. Ein Sandbox- oder Workspace-Objekt im SDK ist deshalb nicht mit einer vom Host durchgesetzten Sicherheitsgrenze gleichzusetzen.
Das ist für CI relevant, weil ein Agent nicht nur Dateien innerhalb eines Projekts verarbeitet. Ein Shell-Befehl kann mit den Rechten des Benutzers ausgeführt werden, unter dem der lokale Prozess läuft. Ob er auf weitere Verzeichnisse, Zugangsdaten oder Netzwerkziele zugreifen kann, hängt dann von den Host-Rechten und externen Kontrollen ab – nicht allein vom Namen des SDK-Modus.
Beschränkt die lokale Sandbox den Zugriff auf das macOS-Dateisystem und das Netzwerk?
Nicht als Betriebssystem-Isolation. Behandeln Sie Arbeitsverzeichnis- und HOME-Einstellungen nicht als Zugriffssperren. Prüfen Sie stattdessen die tatsächlichen Rechte des Prozesskontos und die vom Host oder Backend erzwungenen Datei- und Netzwerkregeln. Die SDK-Dokumentation zu Arbeitsbereichen und Sitzungen beschreibt die Organisation von Arbeitsbereichen und Sitzungszuständen; daraus folgt nicht automatisch, dass beliebige Shell-Befehle auf diese Bereiche begrenzt sind.
| Ebene | Was sie organisieren oder steuern kann | Was Sie nicht voraussetzen dürfen |
|---|---|---|
| Agent-Arbeitsbereich | Dateien und Aufgaben in einem definierten Projektkontext | Dass jeder Shell-Prozess auf diesen Pfad beschränkt bleibt |
| Lokale Unix-Ausführung | Befehlsausführung auf dem lokalen Host | Betriebssystemweite Datei- oder Netzwerkisolation |
| Host-Benutzerkonto | Rechte des ausführenden Prozesses auf dem Mac | Dass ein eigener Arbeitsordner einem eigenen, eingeschränkten Benutzer entspricht |
| Docker- oder verwaltetes Backend | Ausführung in einer anderen Umgebung, abhängig von Backend und Konfiguration | Eine einheitliche oder automatisch ausreichende Sicherheitsgarantie |
Der Unterschied ist besonders wichtig bei Pfadfreigaben. Eine Berechtigung, die eine SDK-Dateifunktion einschränkt, ist nicht automatisch eine Sperre für beliebige Shell-Kommandos. Ein Agent, der ein Skript starten darf, kann andere Zugriffswege nutzen als die SDK-Datei-API. Prüfen Sie daher nicht nur, welche Pfade die Agent-Konfiguration aufführt, sondern auch, welche Prozesse und Systemaufrufe der Host zulässt.
Mit wessen Rechten laufen Befehle, die ein Agent auf dem Mac startet?
Bei lokaler Ausführung gelten grundsätzlich die Rechte des Host-Benutzers, unter dem der Prozess läuft. Wenn dieser Benutzer auf Repository-Tokens, Schlüsselbundinhalte oder andere Arbeitsverzeichnisse zugreifen darf, können diese Ressourcen innerhalb seiner Berechtigungsgrenzen liegen. Ein gesetztes HOME-Verzeichnis ändert für sich genommen nicht die Identität oder die Rechte des Prozesses.
Sitzung, Arbeitsbereich und macOS-Konto getrennt verwalten
Eine neue Agent-Sitzung oder ein neu angelegter Arbeitsbereich kann helfen, Aufgaben und Daten voneinander zu trennen. Das macht daraus aber noch keine isolierte Betriebssystemumgebung. Für die Risikobewertung sollten Sie drei Lebenszyklen unabhängig voneinander dokumentieren: den Zustand der Agent-Sitzung, die Dateien im Arbeitsbereich und den Zustand des Host-Kontos einschließlich seiner Anmeldedaten.
Das ist entscheidend, wenn ein Mac-Knoten wiederverwendet wird. Ein Arbeitsbereich kann nach einem Auftrag gelöscht werden, während Shell-Verläufe, temporäre Dateien, Prozesse oder Anmeldedaten an anderer Stelle bestehen bleiben. Umgekehrt kann eine Sitzung beendet sein, obwohl die Host-Umgebung unverändert weiterläuft. Die SDK-Beschreibung von Sitzungen und Arbeitsbereichen hilft bei der Einordnung dieser Zustände, ersetzt aber keine Prüfung des tatsächlichen Bereinigungsverhaltens.
Prüfhinweis: Bezeichnen Sie einen Knoten erst dann als „bereinigt“, wenn Sie nach einem Testlauf auch außerhalb des Arbeitsverzeichnisses geprüft haben, welche Dateien, Prozesse und Zugangsdaten zurückbleiben. Ein erfolgreich gelöschter Projektordner belegt keine vollständige Bereinigung des Hosts.
Die Schnellstartanleitung für Sandbox-Agenten zeigt den SDK-Einstieg in die Agentenausführung. Für einen Unternehmenseinsatz sollte Ihre Prüfung darüber hinausgehen: Verifizieren Sie mit absichtlich begrenzten Testkonten, welche Dateien und Netzwerkziele erreichbar sind, und dokumentieren Sie, welches Backend die jeweilige Ausführung tatsächlich nutzt.
Erst den Ausführungsort wählen, dann Xcode-CI anschließen
Nicht jede Agent-Aufgabe benötigt einen Mac. Quelltextanalysen, Textbearbeitung oder andere Schritte ohne macOS-spezifische Werkzeuge können in einer Umgebung ausgeführt werden, deren Isolation und Netzwerkregeln Sie für genau diese Aufgaben geprüft haben. Aufgaben, die einen echten macOS-Unterbau oder die installierte Apple-Toolchain voraussetzen, müssen dagegen auf einen dafür vorgesehenen Mac-Build-Knoten gelangen.
Ein Linux-Container ist nicht deshalb ein Xcode-Build-Knoten, weil er als Container isoliert läuft. Die Apple-Dokumentation zu den Xcode Command Line Tools beschreibt Werkzeuge für Entwicklungs- und Build-Aufgaben auf Apple-Plattformen. Prüfen Sie pro Job, welche Werkzeuge und welche macOS-Umgebung tatsächlich nötig sind. Wählen Sie das Ausführungsbackend nicht allein nach dem Etikett „Sandbox“.
| Aufgabentyp | Geeigneter Ausführungsort | Vor der Freigabe zu prüfen |
|---|---|---|
| Analyse oder Bearbeitung ohne macOS-spezifische Abhängigkeit | Geprüfte isolierte Umgebung, sofern ihre Regeln zur Aufgabe passen | Dateizugriff, Netzwerkrichtlinien und verfügbare Zugangsdaten |
| Build mit erforderlicher Apple-Toolchain | Kontrollierter Mac-Knoten mit freigegebenem Werkzeugbestand | macOS- und Xcode-Anforderungen, Benutzerrechte und Eingaben |
| Produktionseinreichung oder Signierung | Separater, vertrauenswürdiger Signaturbereich | Identität, Schlüsselzugriff, Freigabeprozess und Artefaktübergabe |
| Nicht vertrauenswürdige Agent-Befehle | Umgebung mit nachweislich durchgesetzten Grenzen | Tests auf Datei-, Netzwerk- und Berechtigungszugriff |
Diese Aufteilung verhindert, dass der Agent automatisch dieselben Rechte erhält wie ein produktiver Build- oder Signaturprozess. Lassen Sie den Agenten beispielsweise Quellcode prüfen oder Änderungen vorbereiten, ohne ihm damit zugleich Zugriff auf Produktionsidentitäten zu geben. Übergeben Sie freigegebene Eingaben und Ausgaben kontrolliert an den Mac-Build-Knoten, statt den Agenten auf demselben Konto wie den vertrauenswürdigen Build auszuführen.
Wie trennen Sie den Agent-Arbeitsbereich vom Xcode-Signaturknoten?
Trennen Sie die Ausführungspfade und die Berechtigungen: Der Agent sollte nur die Ressourcen erhalten, die seine Aufgabe benötigt. Der Signaturknoten sollte nur freigegebene Build-Eingaben und die für den Signierschritt erforderlichen Identitäten sehen. Apple beschreibt in der Dokumentation zu Zugriffssteuerungslisten des Schlüsselbunds, wie der Zugriff auf Schlüsselbundobjekte kontrolliert werden kann. Für die Verteilung signierten Codes erläutert Apple außerdem die Anforderungen an signierten macOS-Distributionscode. Nutzen Sie diese Informationen, um die Konfiguration Ihrer Signaturumgebung zu prüfen – nicht als Beleg dafür, dass ein Agent von sich aus keinen Zugriff erhält.
Quellcode, Netzwerk und Signaturschlüssel als getrennte Risiken behandeln
Ein Agent kann mehr als Projektdateien berühren. Prüfen Sie den vollständigen Weg von der Eingabe bis zum Ergebnis: Wo liegen Repository-Zugangsdaten? Welche internen Paketquellen oder Dienste sind erreichbar? Wo werden Build-Artefakte gespeichert? Welche Identität darf den fertigen Code signieren? Die Antworten sollten sich nicht aus Annahmen über den Arbeitsbereich ergeben, sondern aus überprüfbaren Berechtigungen und Tests.
Bei einem geteilten Mac-Konto kann eine Agent-Aufgabe Zugang zu Ressourcen erhalten, die für einen Build oder eine interaktive Sitzung hinterlegt wurden. Selbst ein eigener Arbeitsordner löst das nicht, wenn dasselbe Konto außerhalb dieses Ordners lesen oder schreiben darf. Umgekehrt reicht eine separate Identität allein nicht aus, falls sie über gemeinsame Schlüssel, offene Netzwerkpfade oder weitere Prozesse wieder Zugriff erhält.
| Schutzobjekt | Typischer Fehler in der Abgrenzung | Nachweis, den Ihr Pilot liefern sollte |
|---|---|---|
| Quellcode und Repository-Zugangsdaten | Der Agent benötigt Schreibrechte, obwohl eine Analyse ausreicht | Zugriff mit einem begrenzten Testkonto und Prüfung der erreichbaren Repositories |
| Interne Abhängigkeiten und Netzwerkziele | Der Arbeitsbereich wird mit einer Netzwerkgrenze verwechselt | Test, welche internen und externen Ziele der Prozess tatsächlich erreichen kann |
| Build-Artefakte | Zwischen Agent-Ausgabe und freigegebenem Build gibt es keine kontrollierte Übergabe | Dokumentierter Artefaktpfad und nachvollziehbare Übernahme durch den Build-Prozess |
| Apple-Signaturidentität | Agent- und Signaturprozess teilen denselben Zugriff auf Schlüsselmaterial | Prüfung der Schlüsselbundberechtigungen und ein Signiertest mit der produktionsnahen Konfiguration |
| Temporäre Daten und Sitzungsreste | Das Löschen des Arbeitsbereichs gilt als vollständige Host-Bereinigung | Prüfung des Knotens nach Jobende auf Dateien, Prozesse und verbliebene Zugangsdaten |
Die OpenAI Agents SDK Release Notes sind relevant, wenn sich Sandbox-Funktionen oder unterstützte Ausführungswege ändern. Prüfen Sie bei einem SDK-Upgrade, ob sich die für Sie maßgeblichen Aussagen zur lokalen Ausführung oder zum verwendeten Backend verändert haben. Leiten Sie eine Sicherheitsfreigabe nicht aus einer früheren Konfiguration ab, wenn sich SDK, Backend oder Mac-Ausführungsmodell geändert haben.
Pilotbetrieb als Prüfkette statt als Vertrauensvorschuss
Ein sinnvoller Pilot beantwortet nicht nur die Frage, ob der Agent einen Build starten kann. Er muss belegen, welche Grenzen bei einem realen Auftrag gelten. Halten Sie fest, welche Eingaben verwendet wurden, unter welchem Konto der Prozess lief, welches Backend die Ausführung übernommen hat und welche Ressourcen erreichbar waren. Wenn diese Nachweise fehlen, sollten Sie die Ausführung nicht auf produktive Repositories oder Signaturidentitäten ausweiten.
Arbeiten Sie die Prüfkette in dieser Reihenfolge ab:
- Aufgabe klassifizieren. Trennen Sie Analyse, Quellcodeänderung, Build und Signierung. Notieren Sie, welche Schritte zwingend macOS oder Xcode benötigen.
- Backend eindeutig identifizieren. Dokumentieren Sie, ob der Agent lokal, in Docker oder in einer verwalteten Umgebung ausgeführt wird. Prüfen Sie die Konfiguration des tatsächlichen Backends statt eines allgemeinen Produktetiketts.
- Prozessidentität prüfen. Ermitteln Sie das Host-Konto und seine Dateirechte. Verwenden Sie für den Test keine produktiven Schlüssel, wenn die Berechtigungen noch nicht nachgewiesen sind.
- Datei- und Netzwerkzugriff testen. Prüfen Sie mit Testdaten, ob der Prozess außerhalb des vorgesehenen Arbeitsbereichs lesen oder schreiben kann und welche Netzwerkziele er erreicht.
- Zugangsdaten und Signaturmaterial kontrollieren. Stellen Sie fest, ob Repository-Tokens, interne Abhängigkeiten und Apple-Identitäten sichtbar oder nutzbar sind. Testen Sie die Trennung mit der vorgesehenen Konfiguration.
- Aufräumen und Wiederverwendung verifizieren. Untersuchen Sie den Mac nach dem Job auf zurückgebliebene Dateien, Prozesse und Anmeldedaten. Prüfen Sie gesondert, was eine neue Sitzung tatsächlich zurücksetzt.
- Freigabe anhand der Belege erteilen. Erweitern Sie den Einsatz nur dann, wenn Datei-, Netzwerk-, Konto- und Schlüsselzugriffe den festgelegten Grenzen entsprechen. Andernfalls bleibt der Job in der geprüften Testumgebung.
Die Abnahme lässt sich mit einer unmittelbar ausführbaren Liste dokumentieren:
- [ ] Für jeden Job ist festgelegt, ob er macOS oder Xcode tatsächlich benötigt.
- [ ] Das verwendete Sandbox-Backend und seine aktive Konfiguration sind dokumentiert.
- [ ] Die Identität des ausführenden Prozesses und ihre Host-Rechte sind geprüft.
- [ ] Datei- und Netzwerkzugriff wurden mit geeigneten Testdaten verifiziert.
- [ ] Der Agent kann Produktionssignaturmaterial nicht ohne gesonderte Freigabe verwenden.
- [ ] Die Übergabe von Agent-Ausgabe zu Build und Signierung ist kontrolliert.
- [ ] Die Bereinigung nach Jobende wurde auf dem Host überprüft.
- [ ] Nicht nachgewiesene Grenzen führen dazu, dass der Job nicht für produktive Daten freigegeben wird.
Dürfen nicht vertrauenswürdige Agent-Befehle direkt auf einem Mac-CI-Host laufen?
Nicht allein deshalb, weil der lokale SDK-Modus „Sandbox“ heißt. Führen Sie solche Befehle erst dann auf einem Mac-Knoten aus, wenn externe Kontrollen die benötigten Grenzen nachweislich durchsetzen und Ihr Pilot Datei-, Netzwerk-, Konto- und Schlüsselzugriff geprüft hat. Fehlt dieser Nachweis, gehört die Aufgabe in eine geprüfte isolierte Umgebung oder muss ohne Zugriff auf produktive Ressourcen bleiben.
Meilensteine für die Entscheidung über Enterprise-Mac-CI
Meilenstein: Ausführung klassifizieren. Ordnen Sie jeden Schritt danach ein, ob er überhaupt eine Apple-Toolchain benötigt. Aufgaben ohne Mac-Abhängigkeit sollten nicht automatisch auf dem CI-Host landen.
Meilenstein: Grenzen belegen. Prüfen Sie Prozesskonto, Datei- und Netzwerkzugriff sowie den Zustand nach einem Job. Eine SDK-Arbeitsbereichsdefinition ist dabei ein Organisationsmerkmal, kein Ersatz für diese Tests.
Meilenstein: Vertrauen staffeln. Agent-Ausführung, Mac-Build und Produktionssignierung sollten unterschiedliche Vertrauensstufen erhalten. Geben Sie Signaturmaterial nicht an den Agenten weiter, nur weil ein Build-Schritt es später benötigt.
Meilenstein: Umfang erst nach erfolgreicher Abnahme erweitern. Wenn ein Test außerhalb des Arbeitsbereichs Zugriff zeigt oder die Bereinigung nicht belegt ist, stoppen Sie die Ausweitung und ändern Sie die Host- oder Backend-Kontrollen. Dokumentieren Sie außerdem Änderungen an SDK, Backend und Ausführungsmodell, bevor Sie eine bestehende Freigabe weiterverwenden.
Für die Kapazitätsplanung ist die entscheidende Frage nicht, ob jeder Agent einen eigenen Mac erhält. Entscheidend ist, welche Jobs einen realen Mac benötigen und ob deren Build- und Signaturgrenzen kontrolliert sind. Wenn Sie Mac-Ressourcen für einen Pilotbetrieb prüfen, können Sie die verfügbaren Angaben auf der VMSPIN-Preisseite in Ihre Planung aufnehmen. Damit ersetzen Sie jedoch nicht die Sicherheitsabnahme: Rechte, Isolation und Bereinigung müssen mit Ihrer konkreten Konfiguration getestet werden.
Wenn Ihr Team nach dieser Prüfung einen Mac für Xcode-Aufgaben benötigt, der Agent aber keinen ungeprüften Zugriff auf produktive Schlüssel erhalten soll, ist ein getrennter, kontrollierter Build-Knoten die bessere Architektur als die gemeinsame Ausführung auf einem weitreichend berechtigten Host. Für einen zeitlich begrenzten Pilot oder zusätzlichen Build-Bedarf können Sie die passende Remote-Mac-Nutzung bei VMSPIN prüfen. Bei dauerhaft ausgelasteten Knoten, besonderen Anforderungen an lokale Schnittstellen oder eigenen Compliance-Vorgaben kann ein selbst betriebener Mac die passendere Wahl sein. In jedem Modell gilt: Erst wenn die Ausführungsgrenzen praktisch nachgewiesen sind, sollte der Agent produktive CI-Aufgaben erhalten.