Coding-Agenten sicher betreiben: Was Codex Security kann — und was du selbst absichern musst

Coding-Agenten sicher betreiben: Was Codex Security kann — und was du selbst absichern musst

Ein Coding-Agent braucht genau das, was man einem fremden Prozess normalerweise nicht gibt: Lesezugriff auf das Repository, Schreibzugriff auf das Dateisystem und eine Verbindung nach draußen.

OpenAI hat in diesem Feld eine Forschungsvorschau gestartet: Codex Security, hervorgegangen aus einem zuvor nichtöffentlichen Programm, verbindet sich mit einem Repository, baut daraus ein Bedrohungsmodell, sucht Schwachstellen, prüft Funde in einer isolierten Umgebung und schlägt Korrekturen vor.

Der Punkt, um den es in diesem Artikel geht, ist ein anderer: Ein Werkzeug, das deinen Code auf Schwachstellen prüft, ist selbst ein Programm mit weitreichenden Rechten. Die Absicherung des Agenten ist dein Teil der Arbeit — und sie ist der Teil, den kein Anbieter übernimmt.

Konkrete Preise, Planbezeichnungen und Kontingente nennen wir bewusst nicht — bei Vorschauversionen ändern sie sich schnell. Wir betreiben kein eigenes Prüflabor.

Was der Scanner ist — und was er nicht ersetzt

Anders als klassische Werkzeuge, die Code gegen Regelwerke prüfen, arbeitet ein solcher Agent kontextbezogen: Er versucht zu verstehen, was ein System tut, wem es vertraut und wo es angreifbar ist — und sucht dann nach Wegen, die in dieser Architektur realistisch sind.

Das reduziert Fehlalarme, ändert aber nichts an drei Grenzen:

• Kein Werkzeug findet alle Lücken. Ein unauffälliger Bericht ist kein Nachweis von Sicherheit.
• Vorgeschlagene Korrekturen bleiben Vorschläge. Sie gehören geprüft, bevor sie zusammengeführt werden — gerade weil sie überzeugend formuliert sind.
• Angaben zur Trefferqualität stammen vom Anbieter und beziehen sich auf dessen Testbestand, nicht auf dein Projekt.

Für die Praxis heißt das: ergänzend einsetzen, nicht ersetzend — neben etablierten Prüfwerkzeugen und menschlicher Durchsicht.

Und die Vertraulichkeitsfrage vorab

Ein cloudbasierter Scanner sieht deinen Code. Bei fremdem Code, Kundenprojekten oder Repositories unter Geheimhaltungsvereinbarung ist das keine technische, sondern eine vertragliche Frage — und die gehört geklärt, bevor ein Repository verbunden wird.

Woher der Angriff kommt: nicht aus deinem Chat

Das ist der Punkt, den die meisten unterschätzen.

Ein Agent liest nicht nur Quelltext. Er liest Konfigurationsdateien, Kommentare, Fehlermeldungen, Dokumentation, Inhalte aus Abhängigkeiten. Steht in einem dieser Inhalte eine Anweisung, kann der Agent sie als Auftrag behandeln — obwohl sie nicht von dir stammt.

Das Problem ist nicht theoretisch: Vor wenigen Tagen wurde eine kritische Schwachstelle veröffentlicht, die mehrere verbreitete Coding-Agenten betraf und über deren Erweiterungsmechanismus lief. Die Hersteller haben sie inzwischen behoben — was den wichtigsten Betriebsgrundsatz unterstreicht: Halte den Agenten und seine Erweiterungen aktuell, und installiere nur Erweiterungen, deren Herkunft du kennst.

Warum automatisches Bestätigen die eigentliche Gefahr ist

Ein Agent, der jeden Schritt einzeln bestätigen lässt, ist unbequem — und beherrschbar. Ein Agent, bei dem die Bestätigung abgeschaltet ist, führt Befehle aus, bevor jemand sie gesehen hat.

Genau in dieser Kombination wird aus einer untergeschobenen Anweisung ein ausgeführter Befehl.

Wenn du den Bestätigungsmodus abschaltest, dann nur in einer Umgebung, in der ein beliebiger Befehl keinen Schaden anrichten kann — nicht auf dem Rechner, auf dem deine Schlüssel liegen.

Die drei Schichten der Absicherung

1. Abschotten

Betreibe den Agenten nicht direkt auf deinem Arbeitsrechner, sondern in einer abgeschotteten Umgebung — ein Container oder eine virtuelle Maschine, in der nur das liegt, was er braucht.

• Nur das Projektverzeichnis einbinden, nicht das ganze Benutzerverzeichnis.
• Ohne erweiterte Rechte laufen lassen.
• Keine Zugangsdaten in die Umgebung reichen, die dort nicht gebraucht werden.

Der erste Punkt ist der wirksamste: Was nicht eingebunden ist, kann auch nicht gelesen werden.

2. Ausgehenden Verkehr begrenzen

Ein Agent ohne Netzzugang kann nichts abfließen lassen. Weil das in der Praxis selten geht — Pakete, Modellzugriff —, ist die Alternative eine Positivliste: nur die Ziele erlauben, die tatsächlich gebraucht werden, und alles andere blockieren.

Das ist die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung, weil sie unabhängig davon greift, wie ein Angriff zustande kam.

3. Sehen, was passiert

• Ausgeführte Befehle protokollieren, in einer Datei, die der Agent selbst nicht ändern kann.
• Änderungen immer als Vorschlag prüfen — Zusammenführen erst nach Durchsicht.
• Ausgehende Verbindungen mitschreiben, zumindest stichprobenweise.

Der zweite Punkt ist der, der am häufigsten aufweicht, wenn der Agent eine Weile zuverlässig gearbeitet hat. Genau dann lohnt er sich am meisten.

Zugangsdaten: der Teil, der wirklich wehtut

Ein Agent mit Zugriff auf ein Repository, in dem Zugangsdaten liegen, ist ein Risiko, das nichts mit künstlicher Intelligenz zu tun hat — es wird durch sie nur schneller wirksam.

• Keine Zugangsdaten im Repository, auch nicht in Beispieldateien und nicht in der Historie.
• Umgebungsdateien konsequent ausschließen und das Ausschlussmuster gelegentlich prüfen.
• Für Automatisierung eigene, eng begrenzte Zugänge verwenden statt persönlicher Tokens mit weitreichenden Rechten.
• Ein Werkzeug zur Suche nach Geheimnissen einsetzen, bevor etwas veröffentlicht wird.

Und wenn doch etwas abgeflossen ist: Der einzige verlässliche Schritt ist, den Zugang zu widerrufen. Ein Löschen aus der Historie beseitigt Kopien nicht — ein einmal veröffentlichter Schlüssel gilt als kompromittiert.

Lokale Modelle als Gegengewicht

Für Aufgaben, bei denen der Code das Haus nicht verlassen soll, sind lokal betriebene Coding-Modelle die naheliegende Ergänzung.

Was du dabei realistisch erwarten kannst: Sie eignen sich gut für abgegrenzte Aufgaben — Tests schreiben, Funktionen erklären, überschaubare Änderungen. Für die kontextbezogene Suche nach Schwachstellen über ein ganzes System hinweg reichen sie nicht an einen großen Anbieterdienst heran.

Der Speicherbedarf richtet sich nach Modellgröße, Quantisierung und der Kontextlänge, die du tatsächlich brauchst — bei Code ist sie höher als bei Fließtext, weil mehrere Dateien gleichzeitig im Blick sein müssen.

Und die Lizenzfrage gehört vorab geklärt: Offene Gewichte bedeuten nicht automatisch freie kommerzielle Nutzung.

Häufige Fehler

Praktische Handlungsempfehlungen September 2026

• Vertraulichkeit klären, bevor du ein Repository mit einem Clouddienst verbindest.
• Agent und Erweiterungen aktuell halten, Erweiterungen nur aus bekannter Quelle.
• In Container oder virtueller Maschine betreiben, nur das Projektverzeichnis einbinden.
• Ausgehenden Verkehr auf eine Positivliste begrenzen.
• Bestätigung eingeschaltet lassen — außer in einer folgenlosen Umgebung.
• Befehle protokollieren und Änderungen nur nach Durchsicht zusammenführen.
• Repository auf Zugangsdaten prüfen und für Automatisierung eng begrenzte Zugänge anlegen.
• Bei vertraulichem Code lokale Modelle einsetzen — mit realistischer Erwartung.

Fazit

Ein Werkzeug, das Code auf Schwachstellen prüft, ist selbst ein Programm mit weitreichenden Rechten — und die Absicherung des Agenten übernimmt kein Anbieter. Sie besteht aus drei Schichten: abschotten, ausgehenden Verkehr begrenzen, und sehen, was tatsächlich passiert.

Der Angriffsweg, den die meisten unterschätzen, führt dabei nicht über den Chat: Ein Agent liest Konfigurationen, Kommentare und Inhalte aus Abhängigkeiten, und eine dort platzierte Anweisung kann er als Auftrag behandeln. Gefährlich wird das in Kombination mit abgeschalteter Bestätigung — dann wird daraus ein ausgeführter Befehl.

Und für die Ergebnisse gilt dieselbe Nüchternheit wie bei jedem Prüfwerkzeug: Ein unauffälliger Bericht ist kein Sicherheitsnachweis, und vorgeschlagene Korrekturen sind Vorschläge — gerade weil sie überzeugend formuliert sind.

Quellen und weiterführende Informationen

• Offizielle Dokumentation des Anbieters — Funktionsumfang, verfügbare Pläne, Umgang mit übermitteltem Code.
• heise online / c’t (heise.de) — Berichterstattung zu Coding-Agenten und deren Schwachstellen.
• OWASP (owasp.org) — Übersichten zu Risiken von Anwendungen mit Sprachmodellen.
• Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de) — Hinweise zu Containerisierung, Netzsegmentierung und Umgang mit Geheimnissen.
• Dokumentation deiner Container- und Firewall-Lösung — Rechtebeschränkung und Positivlisten für ausgehenden Verkehr.
• Gesetze im Internet (gesetze-im-internet.de) — §§ 202a bis 202c StGB sowie DSGVO-Vorgaben zur Auftragsverarbeitung.

Haftungsausschluss

Allgemeiner Hinweis: Dieser Artikel auf aimageddon.de dient der allgemeinen technischen Information und ersetzt keine sicherheitstechnische Beratung. Wir betreiben kein eigenes Prüflabor. Angaben zu Funktionsumfang, Verfügbarkeit und Trefferqualität stammen vom Anbieter und beziehen sich auf dessen Testbestand; bei Vorschauversionen ändern sich Funktionsumfang, verfügbare Pläne und Konditionen kurzfristig — konkrete Preise und Kontingente nennen wir deshalb nicht. Maßgeblich ist die offizielle Dokumentation zum Zeitpunkt deiner Entscheidung.

Zu Einsatz und Grenzen: Kein automatisiertes Werkzeug findet alle Schwachstellen; ein unauffälliger Bericht ist kein Nachweis von Sicherheit. Vorgeschlagene Korrekturen sind vor dem Zusammenführen fachlich zu prüfen. Setz solche Werkzeuge ergänzend zu etablierten Prüfverfahren und menschlicher Durchsicht ein, nicht an deren Stelle. Vor dem Verbinden fremder oder unter Geheimhaltung stehender Repositories sind die vertraglichen Zulässigkeit und gegebenenfalls Vorgaben zur Auftragsverarbeitung zu klären; werden personenbezogene Daten verarbeitet, gelten die Vorgaben der DSGVO. Prüf ausschließlich Code, für den du befugt bist — das unbefugte Eindringen in fremde Systeme und das Vorbereiten solcher Handlungen sind nach §§ 202a bis 202c StGB strafbar.

Zum Betrieb von Agenten: Agenten mit Datei- und Ausführungsrechten können durch Inhalte beeinflusst werden, die sie verarbeiten — darunter Konfigurationsdateien, Kommentare und Abhängigkeiten. Halte Agenten und deren Erweiterungen aktuell und beziehe Erweiterungen nur aus nachvollziehbaren Quellen; in der Vergangenheit waren mehrere verbreitete Coding-Agenten von einer kritischen Schwachstelle betroffen, die über den Erweiterungsmechanismus wirkte. Betreibe Agenten abgeschottet, mit minimal eingebundenen Verzeichnissen, ohne erweiterte Rechte und mit begrenztem ausgehendem Verkehr. Abgeflossene Zugangsdaten gelten als kompromittiert und sind zu widerrufen — ein Entfernen aus der Versionshistorie genügt nicht. Lizenzbedingungen lokal betriebener Modelle sind gesondert zu prüfen. Einzelne Links in diesem Beitrag können Affiliate-Links sein; bei einem Kauf kann eine Provision anfallen, ohne dass sich der Preis für dich ändert. Alle genannten Markennamen sind eingetragene Warenzeichen der jeweiligen Inhaber.