Lasst nicht zu, dass AI Coding Agents euer Vertrauen einfach übernehmen

Dann bemerkte ich, dass kubectl-Befehle ausgeführt wurden. Gegen einen Produktionscluster. Tatsächlich ging nichts schief. Trotzdem fühlte es sich so an, denn mein Agent hätte Cluster-Secrets eigenständig exfiltrieren können. Er hatte Zugriff.

Die Sache ist: Es war irgendwie meine Schuld. Der Agent funktionierte nicht fehlerhaft. Er spielte nicht verrückt. Er versuchte, so viel Kontext wie möglich für die anstehende Aufgabe zu gewinnen. Er prüfte einen echten Cluster, um zu verstehen, womit er es zu tun hatte. Völlig nachvollziehbar. Das Problem war, dass ich die Schlüssel auf der Anrichte liegen gelassen hatte – und er hatte, wie ein neugieriges Kleinkind, Hände, um sie sich zu nehmen.

Wenn ihr einen AI-Coding-Agent über euer Terminal startet, übernimmt er eure gesamte Umgebung: eure SSH-Schlüssel, eure Cloud-Zugangsdaten, eure kubeconfig, jedes Projektverzeichnis auf der Festplatte. Nicht, weil ihr diese Entscheidung getroffen habt, sondern weil ein Prozess als euer Benutzer ausgeführt wird. Das Betriebssystem unterscheidet nicht zwischen euch und etwas, das als ihr ausgeführt wird. Es kennt nicht das Konzept „Dieser Prozess ist ein Agent und sollte anders behandelt werden.“ Gleicher Benutzer, gleiches Vertrauen.

Das ist keine Sicherheitslücke. Es ist kein Fehler im Agenten. Es passiert einfach, wenn ihr Dinge in Reichweite von etwas lasst, das nicht weiß, dass es sie nicht anfassen sollte. Ein Kleinkind kennt den Unterschied zwischen einem Spielzeug und eurem Reisepass nicht. Es nimmt, was da ist.

Explizit statt implizit

Vertrauen entsteht im Systems Engineering nicht automatisch. Ihr entscheidet darüber. Ihr entscheidet, welche Systeme mit welchen anderen Systemen kommunizieren dürfen. Ihr entscheidet, welche Daten wohin fließen. Ihr entscheidet, welche Grenzen es gibt und warum. Diese Entscheidungen stehen in Konfigurationen, Richtlinien und Audit-Logs – an Orten, an denen ihr sie lesen, prüfen und ändern könnt.

Das Zugriffsmodell für Agenten sollte genauso funktionieren. Nicht: „Der Agent übernimmt alles, was er erreichen kann, und wir hoffen, dass nichts schiefgeht.“ Sondern: „Wir haben ausdrücklich und schriftlich festgelegt, worauf der Agent genau zugreifen darf. Alles andere ist standardmäßig nicht erreichbar.“

Das ist das Prinzip der minimalen Rechte, seit Jahrzehnten ein Grundpfeiler der Sicherheit. Es ist auch das Prinzip „explizit statt implizit“, angewendet auf Vertrauen in agentische Systeme: Standardmäßig gibt es keinen Zugriff. Zugriff wird durch eine ausdrückliche, dokumentierte und überprüfbare Entscheidung gewährt. Die Welt des Agenten wird auf dem Papier definiert, bevor er startet.

Diese Explizitheit macht den größten Teil des Mehrwerts aus. Nicht, weil sie entschlossene Angreifer abhält – obwohl sie das tut –, sondern weil sie zu einer echten Frage zwingt: Was braucht dieser Agent tatsächlich? Nicht, was könnte er wollen? Was braucht er? Wenn ihr das beantwortet und den Diff mit der Baseline vergleicht, erkennt ihr, was euer eigenes System tatsächlich tut.

Grenzen wirksam machen

Unter Linux sorgt Landlock LSM dafür, dass die Sperre tatsächlich hält: ein Kernel-Sicherheitsmodul, mit dem nicht privilegierte Prozesse sich selbst irreversible Zugriffsbeschränkungen auferlegen können. Kein Root erforderlich. Kein Daemon. Die Regeln werden vom Kernel durchgesetzt, bevor der Prozess überhaupt startet. Sobald sie angewendet sind, lassen sie sich weder erweitern noch entfernen. Jeder Kindprozess übernimmt dieselben Beschränkungen – durchgehend über alle Ebenen hinweg. Ihr könnt euch nicht per Prompt daraus befreien.

Tools wie nono nutzen Landlock, um diese explizite Entscheidung durchzusetzen. Der Agent kommuniziert nur über einen Proxy mit dem Netzwerk, den der Supervisor kontrolliert. Er erreicht nur die Dateisystempfade, die die Richtlinie ausdrücklich freigibt. Der Audit-Trail – was der Agent getan hat, was er zu erreichen versucht hat und was blockiert wurde – wird vom Supervisor geschrieben. Der Agent kann seinen eigenen Eintrag nicht bearbeiten. Er kann den kubectl-Aufruf nicht weglassen. Er kann nicht hinter sich aufräumen.

Die Sandbox macht es unmöglich, die explizite Richtlinie zu verletzen. Der Agent kann nicht versehentlich nach etwas greifen, das ihr ihm nicht bewusst gegeben habt. Noch nützlicher: Wenn er es versucht, erhaltet ihr ein Signal. Die Grenze ist nicht nur ein Sicherheitsnetz. Sie ist eine Beobachtung.

Entscheiden, was erreichbar ist

Eine explizite Entscheidung zu treffen, setzt voraus, dass ihr tatsächlich wisst, was euer Agent braucht.

nono learn (oder ein vergleichbares Tool) zeichnet die tatsächlichen Zugriffsmuster auf: gelesene Pfade, geschriebene Pfade, kontaktierte Hosts. Das Ergebnis ist ein JSON-Fragment, das ihr direkt in eine Richtlinie übernehmen könnt. Ihr ratet nicht, was der Agent möglicherweise tun könnte. Ihr beobachtet und dokumentiert, was ihr seht.

nono profile diff default my-agent

Dieser Diff ist das erste Mal, dass ihr das Zugriffsmodell klar seht. Alles, was der Agent braucht, wird aufgelistet, bevor ihr ihm die Schlüssel gebt. Nicht die Schlüssel für das ganze Haus, sondern einen bestimmten Schlüssel für die Räume, die tatsächlich benötigt werden.

Das Richtliniendokument wird zum expliziten Nachweis: dieser Agent, diese Aufgabe, diese Zugriffsgrenzen. Ihr könnt es lesen, prüfen und jemand anderem zum Lesen geben. Es liegt an einem Ort, an dem ihr es diffen, versionieren und auditieren könnt.

Wenn ein Agent berechtigterweise Zugriff auf etwas benötigt, das standardmäßig blockiert ist, gewährt ihr ihn ausdrücklich:

Beide Felder sind bewusst erforderlich. Eine Sperre ohne explizite Freigabe zu entfernen, führt zu Richtlinien, die abgesichert aussehen, es aber nicht sind. Die zwei Schritte sind ein Sicherheitsmechanismus. Jede Ausnahme wird bewusst getroffen, dokumentiert und im Diff sichtbar.

Was ich gesehen habe

Nach dem kubectl-Vorfall begann ich, Sessions mit einer Sandbox auszuführen. Gleicher Agent, gleiche Repositories, andere Aufgaben. Der Unterschied war, dass ich jetzt sehen konnte, was an der Grenze geschah.

Das Ausmaß der blockierten Versuche überraschte mich. Nicht kubectl gegen die Produktion. Das ist ziemlich offensichtlich. Es waren die stilleren Dinge: Bash-Befehle und Lesezugriffe, die bei scheinbar völlig routinemäßiger Arbeit an Sperren stießen. Die Auflösung von Abhängigkeiten, die Pfade berührte, in deren Nähe sie nichts zu suchen hatte. Dateiscans, die in Richtung Zugangsdaten-Dateien drifteten. Nichts Dramatisches. Nichts, das in der Ausgabe erschienen wäre oder als ungewöhnliches Verhalten aufgefallen wäre. Nur ein beständiger Hintergrund an allgegenwärtiger Reichweite, der schon immer da war – in jeder Session unsichtbar, weil ihm nie etwas im Weg stand.

Nicht, dass der Agent etwas falsch gemacht hätte. Meistens nicht. Ich hatte nur keine Ahnung, worauf eine normale Sitzung tatsächlich zugreifen konnte, weil mir nie etwas das gezeigt hatte. Die Sandbox hat das Verhalten des Agenten nicht verändert. Sie hat die Angriffsfläche nur erstmals sichtbar gemacht.

Die stillen Risiken sind es wert, dass ihr euch Sorgen um sie macht. Ein Lesezugriff auf ~/.aws/credentials während eines vermeintlichen Dateiscans. Ein Schritt zur Auflösung von Abhängigkeiten, der eure kubeconfig berührt. Ein Bash-Befehl, der eine Umgebungsvariable prüft. Nichts davon erscheint in der Ausgabe des Agenten. Nichts davon wirkt wie ein Vorfall. Doch sobald diese Daten im Kontextfenster des Agenten sind, können sie bei späteren Prompt Injections potenzielle Ziele für Exfiltration sein.

Die Grenze ist das Signal. Nicht: „Etwas Gefährliches ist passiert“, sondern: „Etwas hat weiter zugegriffen, als es die Richtlinie erlaubt.“ Ohne diese Grenze fehlt euch dieses Signal. Ihr habt nur einen Prozess, der alles getan hat, was er erreichen konnte – ohne Aufzeichnung darüber, wohin er gelangt ist.

Definiert, welche Schlüssel in Reichweite sein dürfen

Der kubectl-Vorfall war offensichtlich, weil ich zufällig zugeschaut habe. Das Meiste ist nicht offensichtlich. Meist sind es routinemäßig wirkende Befehle, die unauffällig Dinge lesen, auf die sie keinen Grund hatten zuzugreifen – in Sitzungen, denen ihr keine besondere Aufmerksamkeit geschenkt habt, vor dem Hintergrund eines allgegenwärtigen Zugriffs, der nie bewusst entschieden wurde. Es war einfach das, was die Ausführung unter eurem Benutzerkonto schon immer bedeutete.

Aber das muss nicht so bleiben. Das Prinzip ist klar: explizit statt implizit. Der Zugriff des Agenten sollte eine bewusste Entscheidung sein, dokumentiert, an der Grenze durchgesetzt und im Protokoll nachvollziehbar.

Wenn ihr das nächste Mal einen AI Agent über euer Terminal ausführt, trefft diese Entscheidung bewusst. Entscheidet, was er tatsächlich braucht. Haltet es fest. Setzt es mit einer Sandbox durch. Beobachtet dann, was blockiert wird. Die Sandbox wird nicht verändern, was der Agent versucht zu tun. Aber ihr könnt erstmals sehen, was schon immer in Reichweite war – und ihr habt erstmals eine echte Wahl, welche Schlüssel ihr auf dem Tresen liegen lasst.

Die Schlüssel gehören euch. Die Entscheidung, sie zu vergeben, sollte es ebenfalls.