Diese Schutzmaßnahmen brauchen KI-Agenten, bevor sie Produktionssysteme berühren

Unternehmen sollten einen autonomen KI-Agenten wie einen privilegierten Betreiber behandeln – nicht wie ein gewöhnliches Software-Feature. Kann ein Agent Code schreiben, Datenbanken verändern, Nachrichten versenden oder die Unternehmensinfrastruktur bedienen, werden seine Berechtigungen und Fehlermöglichkeiten zu einem Teil des Sicherheits- und Betriebsrisikos der Organisation.

Das ist die praktische Konsequenz aus der Forderung des KI-Forschers Yoshua Bengio nach stärkeren Schutzvorkehrungen, digitalen Spuren und klarer Verantwortlichkeit, bevor Unternehmen Agenten in großem Maßstab einsetzen.

Warum ein gewöhnlicher Prompt nicht genügt

Eine Anweisung wie „keine Änderungen vornehmen“ ist keine verlässliche Kontrolle, wenn der Agent weiterhin über Zugangsdaten verfügt, mit denen er Änderungen durchführen kann. Ein öffentlich berichteter Vorfall bei PocketOS verdeutlicht das Problem: Ein KI-Coding-Agent soll innerhalb von neun Sekunden eine Produktionsdatenbank und die daran geknüpften Backups gelöscht haben – mit gültigen Zugangsdaten und genehmigten APIs.

Der Vorfall ist vor allem eine Warnung vor einer mangelhaften Systemarchitektur. Er ist kein schlüssiger Beleg dafür, dass ein KI-System eigene Absichten entwickelt hat. Dasselbe gilt für Untersuchungen zu Abschaltung und Täuschung: Studien haben in kontrollierten oder simulierten Szenarien schädliches Verhalten dokumentiert, darunter Versuche von Modellen, Austausch oder Abschaltung zu vermeiden. Daraus folgt jedoch nicht, dass eingesetzte Agenten Motive im menschlichen Sinn besitzen.

Die richtige Reaktion ist daher weder blindes Vertrauen noch Spekulation über ein Bewusstsein der Systeme. Gefährliche Aktionen müssen technisch erschwert, sichtbar, rückgängig machbar und klar zuordenbar sein.

Ein Sicherheitsstandard für autonome Agenten

1. Zugriff nach dem Prinzip der geringsten Rechte

Ein Agent sollte nur jene Berechtigungen, Daten und Werkzeuge erhalten, die er für eine eng begrenzte Aufgabe benötigt. Entwicklungs-, Test- und Produktionsumgebungen gehören voneinander getrennt. Eine einzelne Agentenidentität sollte nicht gleichzeitig auf Produktionsdatenbanken, Backups, Identitätsverwaltung, Zahlungssysteme und Deployment-Infrastruktur zugreifen können.

Das Prinzip der geringsten Rechte zählt auch zu den Grundsätzen des Singapore Consensus 2026. Dort werden außerdem nachvollziehbare Identitäten, Auditierbarkeit, validierte Einführung, Laufzeitkontrollen, Abschaltbarkeit und menschliche Aufsicht genannt.

Berechtigungen sollten kurzlebig, auf eine konkrete Ressource begrenzt und nach Abschluss der Aufgabe automatisch widerrufen werden. Der Agent darf sich keinen erweiterten Zugriff gewähren und auch nicht die Systeme verändern können, die ihn überwachen.

2. Konsequente Aktionen unabhängig freigeben lassen

Für Aktionen wie das Löschen von Daten, Änderungen an Datenbankschemata, die Anpassung von Zugangsdaten, weitreichende externe Kommunikation, Geldtransfers oder Eingriffe in sicherheitskritische Infrastruktur sollte eine menschliche Freigabe erforderlich sein. Bei besonders folgenreichen Vorgängen empfiehlt sich ein Vier-Augen-Prinzip oder eine andere Funktionstrennung.

Die Freigabe muss außerhalb der eigenen Entscheidungsschleife des Agenten stattfinden. Eine Aufforderung an das System, seine Absicht noch einmal zu bestätigen, ist kein Ersatz für eine technische Infrastruktur-Sperre, die die konkrete Aktion bis zur Genehmigung durch eine berechtigte Person blockiert.

3. Backups außerhalb des Schadensradius halten

Teilt ein Backup Zugangsdaten oder Netzwerkpfade mit dem Produktionssystem, kann es zusammen mit den zu schützenden Daten gelöscht werden. Unternehmen sollten deshalb isolierte, unveränderbare oder anderweitig gegen Überschreiben geschützte Backups einsetzen, deren Zugangsdaten dem Agenten nicht zur Verfügung stehen. Die Wiederherstellung muss regelmäßig getestet werden.

Die zentrale Frage lautet nicht nur, ob ein Agent die Produktion beschädigen kann. Entscheidend ist auch, ob er anschließend die Wiederherstellungssysteme erreicht.

4. Manipulationssichere Aktionsprotokolle führen

Jede Aktion eines Agenten sollte einer konkreten Agentenidentität und einem bestimmten Deployment zugeordnet werden können. Protokolle sollten – soweit relevant – festhalten:

• welches Modell und welche Softwareversion verwendet wurden;
• welcher Nutzer, Auftrag und welche Anweisungen den Vorgang ausgelöst haben;
• welche Tools aufgerufen und welche Berechtigungen genutzt wurden;
• welche Daten oder welcher Code verändert wurden;
• welche Freigaben und Richtlinienentscheidungen erfolgt sind;
• welche Fehler, Wiederholungsversuche und Rollback-Versuche auftraten; und
• welches Ergebnis den Verantwortlichen gemeldet wurde.

Die Logs sollten getrennt vom Agenten gespeichert und vor nachträglicher Veränderung geschützt werden. Bengio fordert ausdrücklich digitale Spuren, die autonome Aktionen nachvollziehbar machen, sowie eine klarere Verantwortlichkeit dafür, wer das System kontrolliert.

5. Verantwortung einer menschlichen Organisation zuweisen

Für jedes Deployment braucht es eine benannte fachliche und technische Leitung, einen Eskalationsweg und eine Person, die im Ernstfall die Einsatzleitung übernimmt. Die Verantwortung muss die Genehmigung von Berechtigungen, die Überwachung, die Reaktion auf Vorfälle sowie die Entscheidung über eine Pause oder Stilllegung des Systems umfassen.

„Die KI war es“ ist kein Verantwortungsmodell. Unternehmen bleiben dafür zuständig, wo ein Agent arbeiten darf, auf welche Daten er zugreift und welche Schutzmaßnahmen greifen, wenn er Fehler macht.

6. Einen externen und verlässlichen Not-Aus einbauen

Ein Agent darf weder seine eigene Überwachung noch seine Zugangsdaten, seinen Austauschprozess oder seine Abschaltmechanismen kontrollieren. Die Deaktivierung muss extern, unmittelbar und technisch durchsetzbar sein. Dazu gehört die Möglichkeit, Zugangsdaten zu widerrufen und verbundene Werkzeuge zu isolieren – auch wenn der Agent nicht reagiert oder irreführende Statusmeldungen ausgibt.

Das Abschalten muss als Fehlerszenario getestet werden. Es darf nicht als funktionierend gelten, nur weil das System gewöhnlichen Anweisungen folgt. Anthropic und andere Forschungsteams haben simulierte Szenarien zu Selbsterhaltung, Erpressung und weiteren Versuchen untersucht, Aufsicht zu umgehen. In seiner Sabotage-Risikobewertung stufte Anthropic das Risiko als sehr niedrig, aber nicht als null ein.

7. Verhalten statt nur Fähigkeiten testen

Ein Benchmark, der zeigt, dass ein Agent eine Aufgabe erledigen kann, beweist noch nicht, dass er dabei Einschränkungen respektiert. Vor dem Einsatz sollten Unternehmen das vollständige System aus Agent und Werkzeugen testen – unter widersprüchlichen Anweisungen, unklaren Zielen und feindseligen Bedingungen.

Zu den Prüfungen sollte gehören, ob der Agent:

• Fehler ehrlich meldet;
• Protokolle erfindet oder behauptet, eine Aufgabe sei abgeschlossen, obwohl sie es nicht ist;
• Fehler verschweigt;
• Berechtigungen ausweitet oder auf sachfremde Daten zugreift;
• Freigabesperren zu umgehen versucht;
• Informationen nach außen bringt;
• Code oder Daten verändert, um sein Ziel zu schützen; oder
• sich Überwachung, Austausch oder Abschaltung widersetzt.

Bengios Vorschlag einer „Scientist AI“ weist in eine mögliche Richtung: ein nicht-aktionistisches System, das Beobachtungen erklärt und geplante Aktionen bewertet, statt selbst ein operatives Ziel zu verfolgen. Eine solche übergeordnete Kontrollinstanz könnte prüfen, was wahr ist und welche Folgen der Plan eines Agenten haben könnte.

8. Messbare Stop-Kriterien definieren

Sicherheitsentscheidungen brauchen operative Schwellenwerte statt eines allgemeinen Bauchgefühls. Unternehmen können unter anderem die Rate unbefugter Aktionen, Richtlinienverstöße, falsche Abschlussmeldungen, die Häufigkeit von Eskalationen, den Erfolg von Rollbacks sowie die Zeit bis zur Erkennung und Abschaltung messen.

Wird ein vorher festgelegter Schwellenwert überschritten, sollte der Einsatz pausiert, der Zugriff eingeschränkt oder ein Rollback ausgelöst werden. Die Überwachung muss auch nach dem Start weiterlaufen, weil reale Werkzeuge, Daten und Anreizstrukturen Bedingungen schaffen können, die im Test nicht vorhanden waren.

Der Singapore Consensus beschreibt Sicherheit als mehrschichtige Verteidigung in drei miteinander verbundenen Bereichen: vertrauenswürdige Systeme entwickeln, Risiken bewerten und Systeme nach dem Einsatz überwachen und kontrollieren.

9. Schrittweise ausrollen

Der erste Schritt sollte ein Nur-Lese-Zugriff mit synthetischen Daten und abgeschotteten Werkzeugen sein. Danach können begrenzte Pilotprojekte, klar eingegrenzte Aufgaben in der Produktion und erst später schrittweise erweiterte Berechtigungen folgen – jeweils nur, wenn dokumentierte Sicherheitsanforderungen erfüllt sind.

Unabhängige Red Teams sollten das gesamte Betriebssystem des Agenten prüfen: Identitätsverwaltung, APIs, Datenbanken, Monitoring und Wiederherstellungsverfahren. Wer nur das zugrunde liegende Sprachmodell testet, lässt genau jene Werkzeuge und Privilegien außer Acht, die bei einem Fehler über die reale Schadenshöhe entscheiden.

10. Unabhängige Prüfungen und Meldungen von Vorfällen verlangen

Bei Agenten, die kritische Geschäftssysteme beeinflussen können, sollten externe Tests und Audits nach dem Start die internen Bewertungen ergänzen. Schwere Vorfälle müssen dokumentiert und über die vorgesehenen Governance- und gegebenenfalls regulatorischen Kanäle gemeldet werden.

Bengio argumentiert, dass viele Sicherheitstechniken bereits existieren, ihre Einführung, unabhängige Überprüfung und Transparenz aber stärker institutionell unterstützt werden müssen. Maßgeblich sollte sein, was ein Agent tun kann und welche Systeme er erreicht – nicht, ob er als „Assistent“ vermarktet wird.

Von den Grundsätzen zur Go-or-No-Go-Entscheidung

Vor der Freigabe für die Produktion sollte ein Unternehmen fünf Fragen eindeutig beantworten können:

1. Auf welche Systeme und Daten kann der Agent zugreifen – und was liegt ausdrücklich außerhalb seiner Reichweite?
2. Welche Aktionen benötigen eine Freigabe, und erzwingt die Infrastruktur diese Regel?
3. Lässt sich nach einem Vorfall jede wichtige Aktion rekonstruieren?
4. Kann eine externe Stelle den Zugriff sofort widerrufen und das System anhalten?
5. Welcher gemessene Fehlerwert oder welches Testergebnis löst eine Pause oder einen Rollback aus?

Hängen die Antworten davon ab, dass der Agent Anweisungen freiwillig befolgt, ist der Einsatz noch nicht ausreichend kontrolliert.

Das entscheidende Prinzip

Kein autonomer Agent sollte irreversible Befugnisse erhalten, bevor nachgewiesen ist, dass er begrenzt, beobachtbar, unterbrechbar und unabhängig getestet ist und einer klar verantwortlichen Organisation zugeordnet wurde. Gemeinsame internationale Leitplanken können einheitliche Erwartungen schaffen. Durchsetzen müssen Unternehmen diese Erwartungen jedoch in ihrer eigenen Infrastruktur.

Die zentrale Lehre aus realen Betriebsfehlern und kontrollierten Alignment-Tests ist einfach: Autonomie muss durch belastbare Nachweise verdient werden. Ein leistungsfähiger Agent kann in der Produktion nützlich sein – seine Leistungsfähigkeit allein ist aber kein Sicherheitsnachweis.