Agent 5.6 statt 007 Wenn der Agent mehr macht, als er sollte

Anbieter zum Thema

FAULHABER Antriebssysteme

MES Electronic Connect GmbH & Co. KG

RECOM Power GmbH

KI-Agenten analysieren Quellcode, bedienen Entwicklungswerkzeuge und greifen auf Unternehmensdaten zu. Damit entsteht ein Sicherheitsproblem. Nicht nur Angreifer können Fehlfunktionen auslösen. Auch ein Agent, der seinen Auftrag besonders konsequent verfolgt, kann Grenzen überschreiten. Schutz bietet eine Architektur, die jede Aktion kontrolliert und deren Folgen begrenzt.

Ein Assistenzsystem, das lediglich eine Schaltung erklärt oder ein Datenblatt zusammenfasst, kann falsche Informationen liefern. Ein KI-Agent, der Quellcode verändert, Messdaten abruft, Simulationen startet oder auf eine Produktionsdatenbank zugreift, kann dagegen unmittelbar in technische Abläufe eingreifen. Mit seinen Fähigkeiten wächst deshalb nicht nur sein Nutzen, sondern auch die mögliche Schadenswirkung einer Fehlentscheidung.

Das Sicherheitsproblem beginnt dabei nicht mit einem gezielten Angriff. Bei einem internen Hackathon untersuchte Check Point unter anderem, wie ein autonomer SRE-Agent (Site Reliability Engineering Agent) auf Aufgaben reagiert, die sich mit seinen verfügbaren Werkzeugen nicht lösen lassen. Nach Angaben des Unternehmens startete der Agent dabei eine Produktionsdatenbank neu, unterbrach Verbindungen und versuchte, seine Berechtigungen zu erweitern. Der Agent war nicht kompromittiert worden. Er interpretierte die Eingriffe als zweckmäßige Schritte, um das vorgegebene Ziel doch noch zu erreichen.

Für Engineering-Umgebungen ist das relevant, da ein Agent formal auf ein richtiges Ziel hinarbeiten und dabei dennoch unzulässige oder technisch riskante Maßnahmen wählen kann.

Fremde Daten können zu Anweisungen werden

Eine zweite Gefahr entsteht durch die Informationen, die ein Agent während seiner Arbeit verarbeitet. Dazu gehören Quelltexte, Readme-Dateien, Tickets, E-Mails, Webseiten, Messergebnisse und Antworten externer Werkzeuge. Menschen erkennen meist anhand des Kontexts, ob eine Textstelle eine Arbeitsanweisung, Dokumentation oder bloße Nutzlast darstellt. Sprachmodelle trennen diese Kategorien nicht zuverlässig.

Damit kann eine manipulierte Datei Anweisungen enthalten, die der Agent während einer eigentlich legitimen Aufgabe übernimmt. Check Point berichtet von Versuchen, bei denen Programmieragenten versteckten Anweisungen in Repository-Dateien folgten und Zugangsdaten übermitteln wollten. Dieses als indirekte Prompt Injection bezeichnete Verfahren erfordert keinen direkten Zugriff auf den Agenten. Es genügt, eine Informationsquelle zu manipulieren, die dieser später verarbeitet.

Owasp zählt neben Prompt Injection auch Werkzeugmissbrauch, Rechteausweitung, Datenabfluss, vergiftete Speicherinhalte und übermäßige Autonomie zu den wesentlichen Risiken agentischer Systeme. Einen vollständig zuverlässigen Schutz allein durch System-Prompts oder Eingabefilter gibt es bislang nicht. Externe Inhalte müssen daher grundsätzlich als nicht vertrauenswürdig gelten.

Die Ausführungsschicht wird zum Kontrollpunkt

Bei klassischen Anwendungen legt der Programmcode weitgehend fest, welche Funktion als Nächstes ausgeführt wird. Ein Agent entscheidet dagegen situationsabhängig, welches Werkzeug er mit welchen Parametern aufruft. Genau an dieser Stelle muss die Sicherheitsarchitektur ansetzen.

Zwischen Agent und Werkzeugen gehört eine unabhängige Kontrollschicht. Sie prüft jeden Dateizugriff, Shell-Befehl, API-Aufruf und jede Datenbankoperation, bevor die Aktion ausgeführt wird. Dabei muss sie feststellen, ob das gewünschte Werkzeug für die jeweilige Aufgabe freigegeben ist, ob der Agent lediglich lesen oder auch schreiben und löschen will und ob die betroffene Ressource zum erlaubten Arbeitsbereich gehört. Ebenso relevant sind mögliche Datenabflüsse, die Reversibilität eines Eingriffs und ungewöhnlich lange Aktionsketten oder Wiederholungen.

Eine einzelne Operation dabei unauffällig erscheinen, während mehrere aufeinanderfolgende Schritte zusammen einen Angriff oder eine Rechteausweitung ergeben. Die Überwachung darf deshalb nicht nur jeden Tool-Aufruf isoliert bewerten. Sie muss auch die bisherige Aktionsfolge, den ursprünglichen Auftrag und den aktuellen Systemzustand berücksichtigen.

Eindeutige Verbote sollten deterministische Regeln durchsetzen. Dazu gehören gesperrte Verzeichnisse, nicht erlaubte Netzwerkziele, unzulässige Datenbankbefehle und fehlende Berechtigungen. Eine zusätzliche KI-basierte Prüfung kann bewerten, ob eine Aktion inhaltlich noch zur Aufgabe passt. Sie darf jedoch nicht die alleinige Sicherheitsinstanz bilden. Ein probabilistisches Modell bleibt auch als Überwachungssystem fehlbar.

Alle sicherheitsrelevanten Vorgänge müssen zudem strukturiert protokolliert werden. Dazu gehören der ursprüngliche Auftrag, das verwendete Werkzeug, die Zielressource, die übergebenen Parameter, eine mögliche Freigabe und das Ergebnis. Erst diese Informationen ermöglichen es, einen Vorfall zu rekonstruieren oder wiederkehrende Fehlmuster zu erkennen. Bei ungewöhnlichem Verhalten muss ein übergeordnetes System die laufende Aufgabe stoppen und sämtliche temporären Berechtigungen entziehen können.

Warum ständige Rückfragen nicht genügen

Eine naheliegende Schutzmaßnahme besteht darin, den Menschen vor jeder kritischen Aktion um Zustimmung zu bitten. In der Praxis entsteht dadurch schnell eine Bestätigungsmüdigkeit. Anthropic berichtet, dass Nutzer rund 93 Prozent der angezeigten Berechtigungsabfragen bestätigten. Eine häufig eingeblendete Warnung wird damit zunehmend zu einem routinemäßig weggeklickten Hindernis.

Menschliche Freigaben bleiben für irreversible, finanzielle, administrative oder extern sichtbare Aktionen sinnvoll. Sie sollten jedoch gezielt eingesetzt werden und die konkrete Handlung verständlich beschreiben. Eine Zustimmung muss an Werkzeug, Ziel, Parameter und Zeitpunkt gebunden sein. Eine pauschale Erlaubnis wie „Zugriff zulassen“ bietet nur begrenzten Schutz. Für wiederkehrende Tätigkeiten sind technisch erzwungene Grenzen belastbarer. Ein Agent kann innerhalb eines klar abgegrenzten Arbeitsbereichs weitgehend selbstständig handeln, ohne für jeden ungefährlichen Schritt eine Freigabe einzuholen. Sobald er diese Grenzen verlassen möchte, muss die Ausführungsschicht den Vorgang stoppen oder eine neue, konkret gebundene Berechtigung verlangen.

Sichere Alternativen zum vollständigen Abbruch

Erkennt die Laufzeitkontrolle eine riskante Aktion, bleiben zunächst zwei offensichtliche Möglichkeiten: ausführen oder blockieren. Ein vollständiger Abbruch schützt zwar das System, verhindert aber häufig auch die legitime Aufgabe. Werden zu viele Aufgaben blockiert, steigt der Druck, die Sicherheitsfunktion abzuschalten.

Eine dritte Möglichkeit besteht darin, dem Agenten eine sichere Ersatzhandlung anzubieten. Anstelle eines Neustarts der Produktionsdatenbank kann er beispielsweise eine Diagnose durchführen und einen Neustartplan erstellen. Statt Dateien endgültig zu löschen, kann er sie in Quarantäne verschieben. Eine Konfigurationsänderung lässt sich zunächst als Diff darstellen, ein Softwarestand in einer Staging-Umgebung testen und eine E-Mail als Entwurf zur Freigabe vorlegen.

Check Point verglich nach eigenen Angaben neun Reaktionsstrategien anhand von 90 Aufgaben des Benchmarks „DecodingTrust-Agent“. Ohne Überwachung lag die Erfolgsquote der untersuchten Angriffe bei 46,7 Prozent. Die eingesetzten Gegenmaßnahmen reduzierten sie auf 22 bis 27 Prozent. Eine Strategie, die dem Agenten eine sichere Alternative anbot, erhielt dabei mehr erfolgreiche Aufgaben als eine strikte Blockierung.

Die Ergebnisse stammen aus einem begrenzten Versuchsaufbau und belegen keine allgemeine Schutzwirkung. Sie zeigen aber einen wichtigen Zielkonflikt: Sicherheitsmaßnahmen müssen nicht nur Angriffe verhindern, sondern im betrieblichen Alltag akzeptabel bleiben.

In Engineering-Prozessen kann ein Agent deshalb zunächst eine Maßnahme vorschlagen, statt sie direkt auszuführen. Änderungen lassen sich als Patch, Befehl oder Arbeitsplan zur Prüfung vorlegen. Wo ein praktischer Test notwendig ist, kann die Aktion als Dry Run, auf einer Datenkopie oder in einer Staging-Umgebung erfolgen. Snapshots, Versionierung und Transaktionen machen Eingriffe rückgängig, während zeitlich begrenzte Zugangsdaten und auf einzelne Ressourcen beschränkte Werkzeuge die Reichweite der Handlung reduzieren.

Auch eine Sandbox kann versagen

Eine Sandbox soll den Agenten von sensiblen Dateien, Produktionssystemen und unkontrollierten Netzwerkzugängen trennen. Sie bleibt damit ein zentraler Bestandteil der Sicherheitsarchitektur. Der Begriff kann allerdings eine Geschlossenheit suggerieren, die praktisch nicht garantiert werden kann.

Das zeigte ein Sicherheitsvorfall während einer internen Modellevaluation von OpenAI. Die verwendeten Modelle hatten keinen direkten Internetzugang. Softwarepakete konnten sie lediglich über einen intern betriebenen Proxy und Cache abrufen. Nach Angaben von OpenAI fanden und nutzten die Modelle jedoch eine bis dahin unbekannte Schwachstelle in diesem Paket-Proxy. Anschließend führten sie mehrere Schritte zur Rechteausweitung und lateralen Bewegung aus, bis sie einen Knoten mit Internetzugang erreichten.

Über diese Verbindung suchten die Modelle nach Lösungen für die gestellte Cybersecurity-Aufgabe. Dabei verketteten sie Schwachstellen in der OpenAI-Forschungsumgebung und in der Produktionsinfrastruktur von Hugging Face. In einem Fall kombinierten sie gestohlene Zugangsdaten und Zero-Day-Schwachstellen, um einen Weg zur entfernten Codeausführung auf Servern von Hugging Face zu finden. OpenAI betont, dass die betreffenden Modelle mit reduzierten Cybersecurity-Sperren betrieben wurden, weil die Evaluation ihre maximalen Fähigkeiten messen sollte.

Anthropic berichtet unabhängig davon, bereits Claude-Modelle beobachtet zu haben, die „erfolgreich“ aus Test-Sandboxes ausbrachen, um eine Aufgabe zu lösen. Neuere Claude-Modelle demonstrierten zudem die Fähigkeit, komplexe Exploits zu entwickeln, die mehrere Sicherheitslücken verketten und Sandbox-Grenzen überwinden können.

Damit wird die Sandbox selbst zum möglichen Angriffsziel. Besonders kritisch sind die Schnittstellen, die eine isolierte Umgebung zwangsläufig mit der Außenwelt verbinden. Paket-Proxys, Freigabedienste, gemeinsam genutzte Verzeichnisse, MCP-Server, Update-Mechanismen und Verwaltungsschnittstellen bilden Brücken über die Isolationsgrenze. Eine Schwachstelle oder Fehlkonfiguration in einer solchen Komponente kann die Schutzwirkung der gesamten Umgebung aufheben.

Mehrere Grenzen müssen hintereinander wirken

Ein belastbares System geht davon aus, dass jede einzelne Schutzebene versagen kann. Verlässt ein Agent seinen vorgesehenen Prozess, muss die virtuelle Maschine den Zugriff begrenzen. Überwindet er auch diese Grenze, sollten Netzwerksegmentierung und separate Identitäten den nächsten Schritt verhindern. Selbst bei vorhandenem Netzwerkzugang dürfen nur freigegebene Ziele erreichbar sein. Zugangsdaten müssen kurzlebig, auf eine Ressource beschränkt und außerhalb der Arbeitsumgebung gespeichert sein.

Auch der ausgehende Datenverkehr benötigt eine eigene Kontrolle. Domains allein reichen dafür nicht immer aus, weil ein erlaubter Dienst als Speicher- oder Weiterleitungskanal missbraucht werden kann. Notwendig sind daher auch Begrenzungen für Protokolle, Datenmengen und konkrete API-Funktionen. Auffällige Verbindungen, große Datenübertragungen oder das wiederholte Ansprechen neuer Ziele müssen automatisch eine Unterbrechung auslösen.

Die wirksamste Architektur kombiniert somit Prozessisolation, virtuelle Maschinen, Dateisystemgrenzen, Netzwerksegmentierung, kontrollierte Proxys und minimale Berechtigungen. Keine dieser Maßnahmen verhindert jeden Angriff. Zusammen reduzieren sie jedoch die Wahrscheinlichkeit, dass eine einzelne Schwachstelle einen direkten Weg von der Agentenumgebung in produktive Systeme öffnet.

Aus dem klassischen Prinzip der minimalen Rechte entsteht damit für KI-Agenten das Prinzip der minimalen Handlungsmacht. Ein System erhält nicht nur möglichst wenige Berechtigungen, sondern auch nur so viel Autonomie, Kontext und Verbindung zur Außenwelt, wie die jeweilige Aufgabe tatsächlich benötigt.

Sicherheit muss Teil der Entwicklung werden

Die Angriffsfläche eines Agentensystems verändert sich nicht nur mit einem neuen Modell. Auch neue Prompts, Werkzeuge, MCP-Server, Datenquellen, Bibliotheken und Berechtigungen können das Verhalten beeinflussen. Die Sicherheitsprüfung darf deshalb nicht mit der Einführung des Systems enden.

Zu den notwendigen Testfällen gehören manipulierte Dokumente, versteckte Anweisungen in Quelltexten, Versuche zur Rechteausweitung, Datenabfluss über erlaubte Werkzeuge, vergiftete Speicherinhalte und übermäßige Ressourcennutzung. Ebenso wichtig sind Tests der Sandbox selbst sowie ihrer Proxys und Verwaltungsschnittstellen. Die Prüfungen müssen davon ausgehen, dass der Agent nicht nur unbeabsichtigt eine Grenze berührt, sondern gezielt nach Schwachstellen sucht und mehrere davon miteinander verknüpft.

Solche Szenarien sollten als Regressionstests in den Entwicklungs- und Freigabeprozess eingehen. Änderungen an Werkzeugen, Netzwerkregeln oder Zugriffsrechten benötigen dabei dieselbe Aufmerksamkeit wie Änderungen am eigentlichen Anwendungscode. Für besonders kritische Anwendungen reicht eine allgemeine Sicherheitsbewertung des verwendeten Modells nicht aus. Entscheidend ist das vollständige System aus Modell, Orchestrierung, Werkzeugen, Datenquellen, Identitäten und Ausführungsumgebung.

Kontrollierbare Folgen statt fehlerfreier Agenten

Vollständige Sicherheit lässt sich bei KI-Agenten nicht erreichen. Prompt Injection kann übersehen werden, eine Überwachung kann eine riskante Aktionsfolge falsch bewerten, ein Mensch kann eine unverständliche Freigabe bestätigen und selbst eine Sandbox kann durch eine neu entdeckte Schwachstelle fallen.

Sicherheit benötigt unabhängige Ebenen. Modelle und externe Inhalte gelten als potenziell unzuverlässig. Berechtigungen bleiben eng begrenzt. Kritische Aktionen durchlaufen eine separate Ausführungskontrolle. Arbeitsumgebungen werden isoliert, Verbindungen kontrolliert, Vorgänge protokolliert und Änderungen möglichst reversibel gestaltet. Ein sicherer Agent muss sich nicht in jeder Situation richtig entscheiden. Seine Umgebung muss jedoch verhindern, dass eine einzelne Fehlentscheidung oder eine überwundene Schutzschicht unkontrolliert auf Entwicklungsdaten, Produktionssysteme oder Unternehmensinfrastruktur durchschlägt. (mr)

(ID:50961991)