Die Sicherheit eines Agenten hängt in erster Linie davon ab, wo er ausgeführt wird, und nicht davon, wie er sich verhält

Wenn Entwicklerteams KI-Agenten bewerten, drehen sich die ersten Fragen meist um die Performance. Welches Modell schneidet am besten ab? Wie viel schneller kann es programmieren? Wie hoch ist die Kapitalrendite? Das Thema Sicherheit kommt, wenn überhaupt, meist erst später zur Sprache.

Patrick Dawkins, Principal Software Engineer bei Upsun, hält das für verkehrt.

Im letzten Jahr hat er die Infrastruktur aufgebaut, die es KI-Agenten ermöglicht, sicher in Entwicklerteams zu arbeiten. Seine Schlussfolgerung ist nicht, dass KI-Modelle von Natur aus unsicher sind. Vielmehr, dass die meisten Teams sie in Umgebungen einsetzen, die nie für sie konzipiert wurden.

Das Problem mit privaten Computern

Wenn ein Agent auf dem Laptop eines Entwicklers läuft, braucht er in der Regel drei Dinge, um etwas Sinnvolles zu bewirken – und genau dort, wo alle drei gleichzeitig vorhanden sind, beginnt das Risiko. Der Sicherheitsforscher Simon Willison nennt das die „tödliche Dreierkombination“: einem Agenten Zugriff auf nicht vertrauenswürdige Daten zu gewähren, ihm die Fähigkeit zu geben, Nebenwirkungen zu verursachen, und ihm Zugriff auf sensible Informationen wie Anmeldedaten oder Kundendaten zu ermöglichen. „Du befindest dich in einer Gefahrenzone, wenn diese drei Faktoren zusammenkommen“, sagt Dawkins.

Die Herausforderung besteht darin, dass nützliche Agenten in der Regel alle drei benötigen. Ein Code-Review-Agent muss Repository-Daten lesen, Kommentare an GitHub oder GitLab zurücksenden und sich mit den Repository-Anmeldedaten authentifizieren. Genau diese Fähigkeiten machen ihn nützlich – und genau das macht ihn auch riskant.

Die meisten Teams, die Agenten auf privaten Laptops ausführen, befinden sich derzeit in dieser Situation, und die Mehrheit ist sich dessen nicht bewusst.

Was niemand sehen kann

Das größere Problem ist nicht nur, worauf Agenten zugreifen können, sondern was niemand sonst in der Organisation sehen kann.

Wenn ein Agent auf dem Rechner eines Entwicklers läuft, sind seine Aktivitäten unsichtbar. Es gibt kein zentrales Audit-Protokoll, das zeigt, was er gelesen hat, welche Tools er aufgerufen hat, was er auf die Festplatte geschrieben hat oder was er über das Netzwerk gesendet hat. Wenn ein Prompt-Injection-Angriff dazu führt, dass der Agent Daten abzieht oder eine unbeabsichtigte Aktion ausführt, fängt die Untersuchung quasi bei Null an. „Man sieht nicht, ob Kundendaten an den falschen Ort gesendet werden“, sagt Dawkins. „Wir geben Kundendaten überhaupt nicht an KI-Modelle weiter, aber Geheimnisse, Anmeldedaten – da kommt langsam ein ungutes Gefühl auf.“

Lokal ausgeführte Agenten können auf Anmeldedaten, SSH-Schlüssel, Umgebungsvariablen und andere sensible Dateien zugreifen, die bereits auf dem Rechner eines Entwicklers vorhanden sind. Sie sind vielleicht nicht angewiesen, diese zu nutzen. Aber sie sind zugänglich, und ein Agent, der unter einer böswilligen oder schlecht konstruierten Eingabeaufforderung läuft, kann darauf zugreifen.

Bei der Umstellung auf cloudbasierte Tools in den letzten zehn Jahren ging es zum Teil genau darum, dieses Problem für die Infrastruktur zu lösen. Entwicklerteams haben sich davon verabschiedet, Server auf einzelnen Rechnern zu betreiben, weil Governance, Transparenz und die Reaktion auf Vorfälle bei großem Umfang unüberschaubar wurden. Die gleiche Logik gilt für Agenten. Die meisten Teams haben diesen Zusammenhang noch nicht erkannt.

Garantien vor Schutzmaßnahmen

Dawkins macht eine Unterscheidung, die in den meisten Sicherheitsdiskussionen rund um Agenten übersehen wird: den Unterschied zwischen Garantien und Schutzmaßnahmen.

Garantien sind struktureller Natur und werden auf Systemebene durchgesetzt. Einem Agenten ein schreibgeschütztes OAuth-Token zu geben, bedeutet, dass er nicht in dieses System schreiben kann, egal welche Anweisungen er erhält. Die Eingrenzung des Netzwerkzugriffs, die Anwendung des Prinzips der geringsten Berechtigungen auf jedes Tool und jede API, auf die der Agent zugreifen kann, sowie der Betrieb in einer kurzlebigen Sandbox, die nach jedem Durchlauf gelöscht wird – all das sind Garantien. Diese Schutzmaßnahmen gelten auch dann noch, wenn das Modell einen Fehler macht.

Sicherheitsbarrieren sind etwas anderes. Das Kennzeichnen nicht vertrauenswürdiger Eingaben, damit das Modell sie mit angemessener Skepsis behandelt, ist eine Sicherheitsbarriere. Das Filtern der Agentenausgabe, um Anmeldedaten zu erkennen und zu entfernen, bevor irgendetwas irgendwo gepostet wird, ist eine Sicherheitsbarriere. Das Absichern von Prompts, um die Anfälligkeit für Injektionsangriffe zu verringern, ist eine Sicherheitsbarriere. Dawkins macht deutlich, dass diese Maßnahmen das Risiko sinnvoll reduzieren können, aber probabilistische Kontrollen sind nicht dasselbe wie strukturelle. „Sie sind keine Garantien“, sagt er.

Die meisten Teams greifen zuerst auf Schutzmaßnahmen zurück, weil sie sich leichter schrittweise umsetzen lassen. Dawkins argumentiert, dass die Garantien an erster Stelle stehen müssen. Schutzmaßnahmen, die auf einem strukturell zu laxen System aufsetzen, sind kein Fundament. Sie sind nur ein Notbehelf.

Wie eine gute Lösung tatsächlich aussieht

Das Ziel ist nicht, Agenten weniger leistungsfähig zu machen, sondern den Ausmaßbereich dessen einzuschränken, was schiefgehen kann. Ein Agent, der in einer strukturell soliden Umgebung läuft, wird trotzdem auf Randfälle stoßen und unerwartete Ergebnisse liefern. Die Frage ist, ob das System um ihn herum so konzipiert ist, dass es das eindämmt, bevor es zum Problem wird.

Ein Agent, der in einer isolierten, kurzlebigen Sandbox mit begrenzten Zugriffsrechten läuft, dessen Ergebnisse eine Validierungsschicht durchlaufen, bevor sie einen Menschen oder ein externes System erreichen, und der für jede Aktion mit dauerhaften Folgen eine ausdrückliche menschliche Genehmigung benötigt, ist deutlich sicherer als einer, der unbeaufsichtigt auf einem Laptop läuft. Die Fähigkeiten sind dieselben. Der Unterschied liegt darin, wie der Fehlerfall aussieht.

„Man muss es beobachtbar, nachvollziehbar, kontrollierbar und unterbrechbar machen“, sagt Dawkins. „All diese Dinge, um ein gewisses Maß an Vertrauen zu haben.“

Dieses Vertrauen entsteht nicht dadurch, dass man darauf vertraut, dass sich das Modell unter allen Bedingungen korrekt verhält. Es entsteht dadurch, dass das System so konzipiert wird, dass die Folgen von Fehlverhalten – sei es durch eine Halluzination, das Einschleusen einer Eingabeaufforderung oder ein falsch konfiguriertes Tool – eingedämmt werden, bevor sie sich ausbreiten. 

Das ist ein anderes technisches Problem als das, auf das sich die meisten Teams heute konzentrieren, aber es ist dasjenige, das darüber entscheiden wird, ob KI-Agenten Teil der Produktionsinfrastruktur werden oder experimentelle Werkzeuge bleiben.