ChatGPT-Desktop-App läuft jetzt auf Amazon Bedrock in AWS GovCloud (US)

Die ChatGPT-Desktop-App ist laut AWS jetzt auf Amazon Bedrock in AWS GovCloud (US) verfügbar. Eine neue Anleitung zeigt, wie Organisationen Modellanfragen über Amazon Bedrock Mantle in us-gov-west-1 leiten und die App auf genehmigte Endpunkte beschränken können.
- Laut AWS ist die ChatGPT-Desktop-App samt Work und Codex jetzt auf Amazon Bedrock in AWS GovCloud (US) verfügbar.
- Modellanfragen laufen über Amazon Bedrock Mantle in us-gov-west-1 und lassen sich mit IAM und den Netzwerkkontrollen von GovCloud steuern.
- Abgerechnet wird pro Token ohne Seat-Lizenzen, zudem wird Zero Data Retention unterstützt, so AWS.
- Eine grundlegende requirements.toml erlaubt nur den Bedrock-Endpunkt und sperrt OpenAI-Domains.
- AWS betont, dass das Befolgen der Anleitung allein keine Arbeitslast autorisiert.
Was AWS anbietet
Nach Angaben von AWS bietet die ChatGPT-Desktop-App über zwei Komponenten Zugang zu den Frontier-Modellen von OpenAI. Work übernimmt komplexe, mehrstufige Aufgaben und liefert prüfbereite Ergebnisse. Codex ist ein Coding-Agent zum Entwickeln, Testen und Überprüfen von Software.
Die Anleitung richtet sich an Organisationen, deren Sicherheitsarchitektur verlangt, dass die Modellinferenz AWS-GovCloud-(US)-Identitäten, -Endpunkte und regionale Kontrollen nutzt. Sie konfiguriert Codex so, dass Modellanfragen über Amazon Bedrock Mantle in us-gov-west-1 laufen. Dort lässt sich der Zugriff mit AWS Identity and Access Management (IAM) und den bestehenden Netzwerkkontrollen von AWS GovCloud (US) steuern.
Laut AWS können Nutzerinnen und Nutzer mit der ChatGPT-Desktop-App, der Codex CLI sowie mit IDE-Integrationen für Visual Studio Code, JetBrains und Xcode arbeiten. Die Inferenz läuft über die Responses API auf Amazon Bedrock.
Zu den kommerziellen Konditionen erklärt AWS, dass Kunden pro Token zahlen, ohne Seat-Lizenzen und ohne Verpflichtungen pro Entwickler. Für Kunden mit Anforderungen an die Datenresidenz bleibt die Verarbeitung in der von ihnen gewählten Amazon-Bedrock-AWS-Region. Zudem wird Zero Data Retention (ZDR) unterstützt: In diesem konfigurierbaren Modus werden Prompts und Antworten verarbeitet, ohne dass AWS sie dauerhaft speichert oder an Modellanbieter weitergibt.
So ist die Bereitstellung aufgebaut
Der Beitrag beschreibt eine kontrollierte lokale Bereitstellung in AWS GovCloud (US-West). Sie kombiniert die Anmeldung im API-Modus, eine verwaltete Geräterichtlinie, ein benanntes AWS-Profil und Netzwerkbeschränkungen. Diese Beschränkungen erlauben den Zugriff nur auf den genehmigten Amazon-Bedrock-Endpunkt und deaktivieren andere externe Verbindungen sowie netzwerkfähige Funktionen. Das Ergebnis sei ein Setup, das ein Sicherheitsteam einer Behörde testen und dokumentieren könne, bevor es eine breitere Nutzung freigibt, so AWS.
Die Konfiguration umfasst drei Hauptschritte: Authentifizierung einrichten, Konfigurationsdateien erstellen und anschließend die Bereitstellung starten, initialisieren und überprüfen. Zu den Voraussetzungen zählen eine App-Version, die Amazon Bedrock in AWS GovCloud (US) unterstützt, ein genehmigtes AWS-GovCloud-(US)-Konto, eine IAM-Identität mit genehmigten Zugangsdaten sowie Zugriff auf das genehmigte Modell, die Region und den Endpunkt.
Die Authentifizierung kann entweder über einen Amazon-Bedrock-API-Schlüssel oder über die Credential Chain des AWS SDK erfolgen, die auch AWS SSO über AWS IAM Identity Center umfasst. Die App sucht zuerst nach der Variablen AWS_BEARER_TOKEN_BEDROCK; ist sie vorhanden, hat sie Vorrang vor der profilbasierten Authentifizierung. Andernfalls greift die App auf die Standard-Credential-Chain zurück. Die Anleitung verwendet ein benanntes Profil, codex-il5, und rät dazu, Zugangsdaten, Bearer-Token und Sitzungstoken nicht in TOML-Dateien abzulegen.
Konfigurationsdateien und Netzwerkgrenzen
Vor dem Start der App müssen zwei Dateien vorhanden sein: config.toml und requirements.toml. Die erste legt fest, wie die App arbeitet, darunter der Modellanbieter (amazon-bedrock), das Modell und Einstellungen wie Berechtigungen oder Kontextgrenzen. Die zweite ist eine vom Administrator kontrollierte Regeldatei, die Grenzen setzt, die Nutzer nicht überschreiben können.
Die grundlegende requirements.toml im Beitrag erlaubt nur die Anmeldemethode api sowie die Sandbox-Modi read-only und workspace-write. Unter anderem schaltet sie Browser- und Computernutzung, Fernsteuerung, Login-Shells, In-App-Updates, Memories, Plug-ins und Bildgenerierung ab und setzt die Liste der MCP-Server auf leer.
- Die Netzwerk-Allowlist erlaubt ausschließlich bedrock-mantle.us-gov-west-1.api.aws.
- Domains wie api.openai.com, chatgpt.com, auth.openai.com und platform.openai.com werden ausdrücklich gesperrt.
- Ein Windows-spezifischer Abschnitt verlangt die erweiterte Sandbox-Implementierung und einen privaten Desktop, was von der genehmigten Laufzeitumgebung unterstützt werden muss.
AWS weist darauf hin, dass ChatGPT-Workspace-Regeln und Nutzerrollen dieses Setup nicht steuern, da es direkt mit AWS kommuniziert. Die wichtigsten Sicherheitskontrollen sind die Richtlinien des Rechners sowie die verwendete AWS-Identität samt Berechtigungen.
Was das für Behörden bedeutet
AWS stellt klar, dass die Anleitung für sich genommen keine Genehmigung erteilt. Die Nutzung von AWS GovCloud (US) und das Befolgen der Schritte autorisieren eine Arbeitslast nicht von selbst. Jede Organisation bleibt dafür verantwortlich, Modell, AWS-Dienste, Region, Endpunkt, Workstation-Kontrollen, Repositories, Zugangsdaten und Datenflüsse anhand ihres System Security Plan und ihres Autorisierungsprozesses zu prüfen.
Für behördennahe Teams bietet der Beitrag einen dokumentierten Ausgangspunkt: eine stark abgesicherte Konfiguration, die sich intern testen lässt, mit Abrechnung pro Token und der Option auf Zero Data Retention, bevor ein breiterer Rollout erwogen wird.