Der Sicherheitsnachweis gehört zur konkreten Codeänderung

Kurzfassung: KI kann Sicherheitskorrekturen vorschlagen und deren Wirkung untersuchen. Daraus entsteht noch kein Recht, die Änderung in geschäftskritische Software zu übernehmen. Für IT-Leitung und Einkauf zählt eine konkrete Eigenschaft: Der technische Nachweis muss zur tatsächlich übernommenen Fassung gehören. Erstellung, Prüfung und Übernahme benötigen dafür getrennte Berechtigungen.

Ein KI-Agent findet eine Schwachstelle, schreibt eine Korrektur und meldet erfolgreiche Tests. Darf er die Änderung damit auch in den maßgeblichen Codebestand übernehmen? OpenAI beschreibt für Codex Security ausdrücklich vorgeschlagene Korrekturen; die Entwicklerdokumentation belässt die Entscheidung zur Anwendung bei einem Ingenieur. Für Unternehmen liegt darin eine konkrete Beschaffungsfrage: Kann das angebotene System diese Trennung technisch erhalten, auch wenn derselbe Agent bereits einen überzeugenden Prüfbericht erstellt hat?

Eine Korrektur ist ein Vorschlag mit Belegen

OpenAI stellte Codex Security am 6. März 2026 als Sicherheitsagenten vor. Der beschriebene Ablauf beginnt mit einem bearbeitbaren Bedrohungsmodell: einer Darstellung dessen, was die Anwendung tut, welchen Komponenten sie vertraut und wo Angriffe ansetzen könnten. Darauf folgen die Untersuchung möglicher Schwachstellen und, soweit möglich, die Validierung in einer abgeschirmten Umgebung. Anschließend schlägt das System Änderungen vor, die zum Verhalten der Anwendung passen sollen.

Diese Herstellerbeschreibung ist keine unabhängige Wirksamkeitsstudie. Sie zeigt aber, dass auch ein weitgehend automatisierter Ablauf unterschiedliche Ergebnisse liefert: einen Befund, einen Änderungsentwurf und Belege für dessen Wirkung. Ein zutreffender Befund beweist nicht, dass jede vorgeschlagene Korrektur geeignet ist. Ebenso beantwortet ein guter Änderungsvorschlag noch nicht, wer ihn übernehmen darf.

Die derzeitige Entwicklerdokumentation konkretisiert die Belege. Wenn möglich, ergänzt Codex Security einen Regressionstest, der vor der Korrektur fehlschlägt und danach besteht. Lässt sich ein verlässlicher Test nicht sicher erstellen, soll die verbleibende Prüflücke dokumentiert werden. Die Dokumentation empfiehlt außerdem, etablierte deterministische Prüfwerkzeuge weiterhin einzusetzen. Ein automatisierter Bericht ist damit ein Beitrag zur technischen Bewertung, kein allgemeines Gütesiegel für den gesamten Codebestand.

Die Prüfung gilt für eine bestimmte Fassung

Die entscheidende Eigenschaft lässt sich an einer kleinen Änderung erklären. Ein Agent korrigiert eine Zugriffsprüfung. Ein Test belegt, dass ein bestimmter unberechtigter Zugriff danach abgewiesen wird. Anschließend verändert der Agent noch eine benachbarte Funktion. Der frühere Testnachweis gehört zur vorherigen Fassung. Ob die überarbeitete Änderung weiterhin geeignet ist, muss erneut beurteilt werden.

Deshalb sollte der Nachweis eindeutig festhalten, welcher Ausgangsstand und welche Änderung geprüft wurden. In der Softwareentwicklung lässt sich eine solche Fassung über eine eindeutige Versionskennung bestimmen. Hinzu kommen die verwendeten Tests, ihr Ergebnis und die bekannten Grenzen der Untersuchung. Die übernehmende Stelle kann dann prüfen, ob genau dieser Stand vorliegt oder ob seitdem weiterer Code hinzugekommen ist.

Ein bestandener Test beantwortet zudem nur seine eigene Frage. Eine Sicherheitskorrektur kann den nachgestellten Angriff verhindern und gleichzeitig einen vorgesehenen Zugriff blockieren. Für eine Anmeldung wären deshalb sowohl der unerlaubte Versuch als auch die zulässigen Anmeldewege relevant. Weitere Prüfungen hängen davon ab, was tatsächlich verändert wurde. Der Umfang folgt der Wirkung des Eingriffs, nicht dem Ruf des erzeugenden Modells.

Diese Bindung an die konkrete Fassung ist eine Empfehlung für die eigene Umsetzung, keine von OpenAI zugesicherte vollständige Kontrollfunktion. Sie macht das gekaufte Ergebnis jedoch genauer beschreibbar: Bestellt wird eine überprüfte Änderung mit benannten Prüflücken, nicht nur ein Text, der erfolgreiche Tests behauptet.

Getrennte Rechte erhalten den Unterschied

Die Trennung bleibt unvollständig, wenn sie nur in einer Arbeitsanweisung steht. Hat der erzeugende Agent zugleich Zugangsdaten, mit denen er die Änderung direkt übernehmen oder die erforderlichen Prüfungen abschalten kann, hängt ihre Einhaltung an seinem Verhalten. Eine technisch getrennte Übernahmebefugnis schafft einen anderen Zustand: Der Agent kann einen Vorschlag vorbereiten, aber nicht selbst die Voraussetzung seiner Annahme beseitigen.

Dafür müssen nicht drei neue Abteilungen entstehen. Ein bestehendes Entwicklungsteam kann die Aufgaben verteilen und unterschiedliche Zugänge verwenden. Der Erzeuger arbeitet in einem separaten Entwicklungszweig. Eine davon getrennte Prüfkomponente führt die vereinbarten Untersuchungen aus. Die berechtigte Person oder ein ausdrücklich dafür konfigurierter Dienst übernimmt anschließend die geprüfte Fassung. Für besonders folgenreiche Änderungen kann zusätzlich ein unabhängiger fachkundiger Prüfer erforderlich sein.

Unabhängigkeit bedeutet hier mehr als einen zweiten Gesprächsaufruf an dasselbe Modell. Entscheidend ist, dass die prüfende Instanz selbst auf Code und Testergebnisse zugreifen kann und nicht ausschließlich die Erklärung des Erzeugers bewertet. Sie braucht außerdem geschützte Prüfbedingungen. Könnte der Agent seine eigenen Prüfungen nachträglich vereinfachen, wäre deren bestandener Zustand weniger aussagekräftig.

In einem gedachten Kundenportal könnte der Softwaredienstleister eine KI-generierte Korrektur der Mandantentrennung liefern. Der Betreiber muss dafür keinen eigenen Sicherheitsagenten entwickeln. Er kann einen nachvollziehbaren Änderungsstand und die Ergebnisse der vereinbarten Zugriffstests verlangen. Die technische Übernahme bleibt bei der zuständigen Stelle. Das Beispiel beschreibt eine mögliche Arbeitsteilung, keinen dokumentierten Kundeneinsatz.

Die Abnahme prüft auch einen veränderten Vorschlag

Bei der Beschaffung lässt sich diese Eigenschaft praktisch testen. Der Anbieter führt eine begrenzte Beispielkorrektur durch und zeigt, welcher Stand geprüft wurde. Danach wird der Vorschlag verändert. Die Abnahme untersucht, ob der alte Nachweis weiterhin zur Übernahme berechtigt oder ob eine erneute Prüfung erforderlich wird. Ein weiterer Versuch klärt, ob der Erzeuger direkt in den geschützten Codebestand schreiben kann.

Diese Versuche prüfen die vereinbarten Rechte und die Gültigkeit der Nachweise. Sie beweisen nicht, dass die Software frei von Schwachstellen ist. Gerade diese engere Aussage macht sie als Abnahmekriterium brauchbar. Auch eine manuelle Kontrolle kann Teil des vereinbarten Verfahrens sein; sie muss dann sichtbar erkennen, welche Fassung tatsächlich bewertet wurde.

Zur Lieferung gehören deshalb neben der Korrektur die nötigen Versionskennungen, Testergebnisse und offenen Punkte. Ebenso wird vereinbart, wer bei einer späteren Überarbeitung erneut prüft und wer die Änderung übernehmen darf. Ein mittelständischer Betreiber kann dadurch Sicherheitskorrekturen schneller vorbereiten lassen, ohne dem Erzeuger automatisch die Kontrolle über den eigenen Änderungsnachweis zu übertragen.