Zwei neue Bausteine für KI-Agenten

OpenAI hat in kurzer Folge zwei Bausteine für Entwickler veröffentlicht, die zusammen viel versprechen: Am 10. September 2026 kam die Agents API als öffentliche Beta, am 29. September – zur DevDay – kam Computer Use hinzu. Damit können Agenten in einem von OpenAI gehosteten Browser Webseiten bedienen, Formulare ausfüllen und Aufgaben erledigen, für die es keine Schnittstelle gibt.

Für Unternehmen klingt das nach dem bequemsten Weg zu einem eigenen Agenten: OpenAI übernimmt Infrastruktur, Sandbox und Browser. Für deutsche Unternehmen, die mit personenbezogenen oder vertraulichen Daten arbeiten, ist genau dieser bequeme Weg derzeit aber der falsche. Wir erklären, warum – und wie der saubere Weg aussieht.

Was die Agents API ist

Die Agents API stellt Entwicklern denselben Unterbau bereit, auf dem auch Codex läuft. OpenAI nennt ihn den „managed Codex harness": OpenAI verwaltet die Sitzungen, die Steuerung des Agenten, das Zusammenfassen von Kontext und die Wiederaufnahme nach Abbrüchen. Der Agent kann Befehle und Code in einer Sandbox ausführen, eigene Werkzeuge und MCP-Server nutzen und über mehrere Durchläufe hinweg weiterarbeiten.

Daneben bietet OpenAI zwei weitere Wege an, Agenten zu bauen: das Agents SDK, das in der eigenen Anwendung läuft, und die Responses API, bei der die eigene Anwendung die Steuerung übernimmt. Die Agents API ist der bequemste der drei Wege – OpenAI erledigt am meisten.

Computer Use: der Agent bedient den Browser

Mit Computer Use bekommt der Agent einen Browser in einer von OpenAI gehosteten Umgebung. Er sieht Bildschirmfotos, klickt, tippt und scrollt. Zwei Sicherheitsmechanismen sind eingebaut:

Drei Punkte, die Unternehmen kennen sollten

1. Daten nur in den USA, keine Zero Data Retention. Die Dokumentation ist hier eindeutig: Die Agents API unterstützt derzeit nur Datenhaltung in den USA und keine Zero Data Retention (ZDR), also kein sofortiges Verwerfen der Daten. Auch eine selbst betriebene Sandbox ändert daran nichts. Laut OpenAIs Übersicht zur Datenhaltung werden Protokolle zur Missbrauchserkennung 30 Tage aufbewahrt, der Anwendungszustand bis zur Löschung. Sitzungen lassen sich löschen, wenn sie nicht mehr gebraucht werden.

2. Freigabe pro Website ist keine Freigabe pro Aktion. OpenAI weist selbst darauf hin: Die Zustimmung zu einer Website erzwingt keine Bestätigung vor einzelnen Aktionen. Ist eine Seite einmal freigegeben, kann der Agent dort handeln, ohne erneut zu fragen. Wer sicherstellen muss, dass Käufe, Löschungen oder andere folgenreiche Aktionen bestätigt werden, soll laut OpenAI den Browser auf Ressourcen beschränken, die solche Aktionen gar nicht erlauben – oder einen Browser verwenden, den er selbst kontrolliert.

3. Netzwerkzugang ist standardmäßig offen. Die gehostete Sandbox darf ab Werk auf beliebige Ziele im Internet zugreifen. Man kann den Zugang sperren oder auf bis zu 100 festgelegte Adressen beschränken – muss das aber aktiv tun.

Hinzu kommt ein Grundproblem jedes Agenten, der Webseiten liest: Prompt Injection. Inhalte auf einer Website können versuchen, dem Agenten Anweisungen unterzuschieben. OpenAI empfiehlt ausdrücklich, Webseiteninhalte als nicht vertrauenswürdig zu behandeln.

Der saubere Weg: Responses API, EU-Endpunkt, eigene VM

Es gibt eine Alternative, die mehr Arbeit macht, aber deutlich besser zu europäischen Anforderungen passt. Die Responses API bietet Computer Use als allgemein verfügbares Werkzeug (computer); die Beispiele der Dokumentation nutzen das Modell GPT-6.1 Sol. Der Unterschied: Den Browser oder Desktop stellen Sie selbst bereit – etwa in einer isolierten virtuellen Maschine oder einem Container.

Das hat drei Vorteile:

OpenAIs eigene Sicherheitsempfehlungen für Computer Use lesen sich dabei wie eine Checkliste:

Und ein Satz aus der Dokumentation, den man sich merken sollte: Die Aufforderung des Modells zu handeln ist keine Erlaubnis des Nutzers.

Für uns ist das nichts Neues: KI-Agenten gehören in isolierte Umgebungen, nicht auf Produktivsysteme. Warum das so wichtig ist, haben wir in Warum KI-Agenten im Unternehmen echte Sandboxes brauchen beschrieben.

flowchart TD
    Q{Personenbezogene oder vertrauliche Daten?}
    Q -->|nein, Prototyp| A["Agents API mit gehostetem Browser<br/>bequem, Datenhaltung in den USA"]
    Q -->|ja| R["Responses API mit dem computer-Werkzeug"]
    R --> E["EU-Endpunkt"]
    R --> Z["Zero Data Retention"]
    R --> V["Eigene, isolierte VM"]

Und mit .NET?

OpenAI stellt in Zusammenarbeit mit Microsoft einen offiziell unterstützten C#-Client bereit (NuGet-Paket OpenAI), der die Responses API abdeckt. Ein .NET-Gegenstück zum Agents SDK gibt es dagegen nicht – das SDK gibt es nur für Python und TypeScript. Die Dokumentation der Agents API zeigt zwar C#-Beispiele, in den veröffentlichten Versionen des NuGet-Pakets konnten wir den passenden Client aber noch nicht finden.

Der naheliegende Weg für .NET-Teams ist deshalb das Microsoft Agent Framework, seit April 2026 in Version 1.0 verfügbar. Es unterstützt OpenAI-Agenten in C#, empfiehlt die Responses API als primären Client und listet Computer Use unter den unterstützten Werkzeugen. Wie wir KI-Agenten mit .NET bauen, beschreiben wir unter KI-Agenten für Unternehmen.

Wer lieber auf Azure setzt: Auch dort gibt es Computer Use, allerdings mit Registrierung für das Modell und in Teilen noch als Preview. Microsoft warnt in seiner Dokumentation ausdrücklich vor erheblichen Sicherheits- und Datenschutzrisiken einschließlich Prompt Injection und empfiehlt, das Werkzeug nur in virtuellen Maschinen ohne Zugriff auf sensible Daten oder kritische Ressourcen einzusetzen.

Nebenbei: Agent Builder wird abgeschaltet

Wer 2025 mit OpenAIs Agent Builder angefangen hat, sollte das Datum kennen: OpenAI stellt Agent Builder ein, die Abschaltung ist für den 30. November 2026 geplant. ChatKit bleibt verfügbar. Als Alternativen nennt OpenAI unter anderem das Agents SDK.

Wie wir es selbst halten

Wir setzen KI-Agenten täglich ein – in der Softwareentwicklung, aber auch für unsere eigene Website: Deren Inhalte pflegen wir unter anderem über einen eigenen MCP-Server für unser CMS. Eine Regel gilt dabei ohne Ausnahme: Agenten arbeiten nicht auf Produktivsystemen. Das gilt bei uns sogar für die Automatisierung ohne KI: Unser Build-Server erstellt nur versionierte Release-Kandidaten, ausgerollt wird von einem Menschen. Genau diese Trennung zwischen „vorbereiten" und „ausführen" vermissen wir bei der Freigabe pro Website in der Agents API.

Unsere Einschätzung

Die Agents API ist technisch beeindruckend und für Prototypen mit unkritischen Daten eine schnelle Option. Für den produktiven Einsatz mit personenbezogenen oder vertraulichen Daten fehlen heute zwei Dinge: EU-Datenhaltung und Zero Data Retention. Dazu kommt die Freigabe pro Website statt pro Aktion.

Wer Computer Use ernsthaft einsetzen will, fährt mit der Responses API, dem EU-Endpunkt, Zero Data Retention und einer eigenen, isolierten Umgebung besser. Das ist mehr Aufwand – aber es ist der Aufwand, der aus einer Demo einen Prozess macht, den man verantworten kann. Ob dabei eine Auftragsverarbeitung vorliegt und welche Verträge nötig sind, sollten Sie mit Ihrem Datenschutzbeauftragten klären; einen Überblick über die Verträge der großen Anbieter geben wir in KI-Abos und DSGVO: Wer bietet einen Auftragsverarbeitungsvertrag?.

Da die Agents API eine Beta ist, kann sich vieles schnell ändern. Dieser Beitrag gibt den Stand vom Oktober 2026 wieder.

Sie möchten einen Agenten mit Computer Use bauen, der in Ihre Sicherheits- und Datenschutzanforderungen passt? Sprechen Sie uns an.

Quellen: OpenAI – Introducing the Agents API · OpenAI API Changelog · OpenAI Docs – Agents API Overview · OpenAI Docs – Computer Use in der Agents API · OpenAI Docs – OpenAI-hosted Environments · OpenAI Docs – Computer Use (Responses API) · OpenAI Docs – Computer Use Integration · OpenAI Docs – Datenkontrollen und Datenhaltung · OpenAI Docs – Preise · OpenAI Docs – Libraries (.NET) · OpenAI Docs – Agent Builder · Microsoft Learn – Agent Framework mit OpenAI · Microsoft Learn – Computer Use in Foundry Agent Service