Sicherheit von KI-Agenten beginnt mit schlanker Software

Matt Sephton veröffentlichte Fits on a Floppy im April 2026 mit einer bewusst absurden Einschränkung: Nützliche Software sollte versuchen, in 1,44 MB zu passen, also auf eine gewöhnliche 3,5-Zoll-Diskette.¹

Wichtiger als die Größenbegrenzung ist die Haltung dahinter. Sephton plädiert für schnelle Downloads, sofortigen Start, geringen Speicherbedarf, geringe CPU-Last, nativen Code, Unterstützung älterer Systeme und Werkzeuge, die eine Sache gut erledigen.¹ Die naheliegende Lesart lautet: Schlanke Software respektiert den Benutzer. In der Agenten-Ära geht die Aussage weiter: Schlanke Software gibt KI-Coding-Agenten weniger Raum, Fehler zu verstecken.

Sicherheit von KI-Agenten beginnt mit schlanker, prüfbarer Software, weil kleine Systeme den Bereich verkleinern, den ein Agent missverstehen, verändern, autorisieren oder ungetestet scheitern lassen kann. Sandboxes und Berechtigungsabfragen bleiben wichtig. Schlanke Software verlagert die Sicherheitsgrenze weiter nach vorn, in die Form des Artefakts selbst.

Kurzfassung

Coding-Agenten arbeiten am besten, wenn sie die relevanten Dateien lesen, die relevanten Prüfungen ausführen und die relevanten Änderungen erklären können, bevor der Kontext nachlässt. Die Claude Code-Empfehlungen von Anthropic weisen darauf hin, dass sich Kontext schnell füllt und die Leistung nachlässt, sobald er voll wird; derselbe Leitfaden nennt Verifikation die wertvollste Praxis und beschreibt CLI-Tools als kontexteffiziente Schnittstellen.² Die OpenAI-Dokumentation zur lokalen Shell warnt, dass Agenten, die Shell-Befehle ausführen, vor der Ausführung Sandboxing oder strikte Allow- und Deny-Listen brauchen.³

Schlanke Software ersetzt diese Kontrollen nicht. Sie macht sie leichter anwendbar. Ein kleines Werkzeug hat weniger Befehle, die berechtigt werden müssen, weniger Dateien, die zu prüfen sind, weniger Abhängigkeiten, denen man vertrauen muss, weniger Tests, die laufen müssen, und weniger Verzweigungen, in denen sich eine falsche Annahme verstecken kann. Die alte Unix-Lektion ist nicht überholt: McIlroy führte „do one thing“ auf frühe Größenbeschränkungen zurück und erklärte dann, warum Textströme zu nützlichen universellen Schnittstellen für Programme und Menschen wurden.⁴ Agentensysteme entdecken dasselbe Muster wieder, weil Agenten prüfbare, kombinierbare Oberflächen brauchen.

Wichtigste Erkenntnisse

Für Entwickler von Agenten: - Bevor Sie breite APIs oder große Tool-Schemas hinzufügen, bevorzugen Sie kleine Werkzeuge mit expliziten Eingaben, expliziten Ausgaben und Artefakten in einfachen Dateien. - Behandeln Sie Dateipfade, Diffs, Logs und Tests als Sicherheitsflächen. Der Agent kann sie prüfen, der Reviewer kann sie prüfen, und Automatisierung kann sie als Schranke nutzen.

Für Softwareteams: - Schlanke Software senkt die Review-Kosten. Ein Reviewer kann ein 400-Zeilen-Werkzeug samt Tests in einer Sitzung verstehen; ein ausuferndes Framework erzwingt Vertrauen dort, wo Belege stehen sollten. - Halten Sie den Berechtigungsumfang nah an der Aktion. Ein kleiner Befehl kann read-only laufen, in ein einziges Verzeichnis schreiben oder Netzwerkzugriff verweigern. Ein allgemeiner Befehl verlangt meist mehr Autorität, als die Aufgabe braucht.

Für Produktverantwortliche: - Schlanke Software ist keine Nostalgie. Sie ist ein Governance-Muster für eine Welt, in der Maschinen zu schnell zu viel Code erzeugen können. - Der Maßstab sollte sich von „Kann der Agent das bauen?“ zu „Kann das Team es verifizieren, verantworten und zurückrollen?“ verschieben.

Warum schlanke Software wieder relevant wurde

Software-Bloat wirkte früher vor allem wie ein Problem der Benutzererfahrung: langsame Downloads, hoher Speicherbedarf, verzögerter Start, leere Akkus und alte Geräte, die zurückgelassen wurden. Fits on a Floppy macht diese Kritik durch einen absichtlich physischen Standard sichtbar. Ein 1,44-MB-Abzeichen verwandelt Zurückhaltung in einen Test, den Benutzer verstehen können.¹

KI-Coding-Agenten verändern den Grund, warum Zurückhaltung zählt. Die Maschine kann Dateien schneller erzeugen, als ein Mensch sie lesen kann. Diese Geschwindigkeit schwächt Qualität, wenn das umgebende System Umfang als Fortschritt akzeptiert. Eine Funktion mit 2.000 Zeilen und 4 neuen Abhängigkeiten kann im Transkript beeindruckend wirken und trotzdem die Fehlerfläche stärker vergrößern als den Produktwert.

Schlanke Software gibt dem Agenten ein engeres Ziel und dem Reviewer ein besseres. Der Prompt kann nach einer ausführbaren Datei, einem Datenformat, einer Testdatei und einem Rollback-Pfad fragen. Das Ergebnis lässt weniger Freiheitsgrade offen. Ein Modell kann immer noch einen Fehler machen, aber der Fehler hat weniger Platz, sich zu tarnen.

Niklaus Wirth veröffentlichte 1995, lange bevor Coding-Agenten in Arbeitsabläufe kamen, einen Aufsatz mit dem Titel A Plea for Lean Software.⁵ Der Titel trifft noch immer, weil der zugrunde liegende Fehler überlebt hat: Teams verbrauchen Hardware, Abhängigkeiten und Abstraktionsschichten, um schwierige Designentscheidungen zu vermeiden. Agenten senken den Preis dafür, Code hinzuzufügen. Dadurch wird die Weigerung, Code hinzuzufügen, wertvoller.

Kontext ist ein Sicherheitsbudget

Agentensicherheit wird oft als Berechtigungsproblem beschrieben: Welche Befehle darf der Agent ausführen, welche Dateien darf er bearbeiten, welche Secrets darf er sehen, welche Netzwerkaufrufe darf er machen? Diese Fragen sind wichtig. Sie decken aber nicht die erste Grenze ab, auf die der Agent beim Arbeiten stößt: den Kontext.

Der Best-Practices-Leitfaden von Anthropic zu Claude Code erklärt, dass das Kontextfenster die Konversation, Nachrichten, gelesene Dateien und Befehlsausgaben enthält und dass eine einzige Debugging-Sitzung Zehntausende Tokens verbrauchen kann.² Der Leitfaden warnt außerdem, dass Claude frühere Anweisungen vergessen oder mehr Fehler machen kann, wenn sich das Kontextfenster füllt.²

Damit wird Größe zu einer Sicherheitseigenschaft. Eine kleine Codebasis lässt den Agenten die relevante Oberfläche lesen, ohne die Sitzung in irrelevanten Dateien zu ertränken. Ein kleines Werkzeug erlaubt dem Agenten, Funktion, Tests, Berechtigungsmodell und Randfälle gleichzeitig im Blick zu behalten. Ein kleiner Diff lässt den Reviewer die tatsächliche Änderung finden, statt einen Haufen generierter Bewegung zu durchsuchen.

Das Kontextbudget hat 3 praktische Grenzen:

Auch große Systeme können sicher sein. Sie brauchen stärkere Zerlegung. Wenn eine Codebasis nicht klein sein kann, sollte die agentenseitige Oberfläche klein sein: ein Package, ein begrenztes Subsystem, ein öffentlicher Befehl, ein Testziel, ein verantwortetes Verzeichnis.

Einfache Dateien schlagen versteckten Zustand

McIlroys Oral History gibt der alten Lektion eine scharfe praktische Kante. Er beschrieb „do one thing“ als Prinzip, das daraus entstand, dass schlicht kein Platz für mehr als eine Sache vorhanden war; anschließend blieben Teams bei diesem Muster, auch nachdem die ursprüngliche Beschränkung verschwunden war.⁴ Er erklärte auch, warum Textströme wichtig waren: menschenlesbare Daten machten Debugging weniger mühsam, und sich entwickelnde Textfelder erforderten weniger Arbeit als Änderungen an festen Binärlayouts.⁴

Agenten brauchen dieselbe Art von Oberflächen. Eine Datei lässt sich auflisten, durchsuchen, diffen, abschnittsweise lesen, committen, zurücksetzen, linten und reviewen. Versteckter IDE-Zustand, undurchsichtige lokale Datenbanken und breite gehostete Werkzeuge können nützlich sein, zwingen Agent und Reviewer aber, einer Oberfläche zu vertrauen, die sie nicht leicht prüfen können.

Ein arXiv-Paper vom Januar 2026 verbindet Unix’ Dateiabstraktion mit agentischen KI-Systemen. Das Paper argumentiert, dass dateiähnliche Abstraktionen und codebasierte Spezifikationen verschiedenartige Ressourcen in konsistente, kombinierbare Schnittstellen überführen und Agentensysteme dadurch wartbarer, auditierbarer und betrieblich robuster werden können.⁶ Die Analyse von Oracle zum Agentengedächtnis zieht eine verwandte Unterscheidung: Dateisystemschnittstellen funktionieren gut, weil Modelle entwicklernahe Oberflächen wie Repos, Ordner, Markdown, Logs und CLI-Interaktionen bereits verstehen, während dauerhafte Speicherung weiterhin in eine Datenbank gehören kann.⁷

Diese Unterscheidung ist wichtig. „Dateien verwenden“ heißt nicht: „Alles für immer in losem Text speichern.“ Das sicherere Muster trennt die Agentenschnittstelle vom Speichersubstrat:

Der Agent sollte die kleinste nützliche Schnittstelle sehen. Darunter kann das Produkt die stärkere Speicherebene behalten.

Weniger Werkzeuge bedeuten weniger Berechtigungen

Der Artikel zur Autorisierung von MCP machte die Autorisierungslektion explizit: Die Validierung eines Bearer Tokens beweist nicht, dass ein Benutzer jedes Tool hinter dem Server aufrufen darf.⁸ Schlanke Software wendet dieselbe Idee früher im Design an. Ein kleineres Werkzeug verlangt engere Autorität.

Die OpenAI-Dokumentation zur lokalen Shell benennt die Gefahr klar: Beliebige Shell-Befehle auszuführen kann gefährlich sein, und Entwickler sollten die Ausführung sandboxen oder strikte Allow- und Deny-Listen ergänzen, bevor sie Befehle an die System-Shell weiterreichen.³ Der Claude Code-Leitfaden von Anthropic gibt ein praktisches Beispiel im großen Maßstab: Wenn Arbeit über Dateien aufgefächert wird, sollten Allowed-Tool-Beschränkungen genutzt werden, damit unbeaufsichtigte Läufe nicht mehr tun können, als die Aufgabe verlangt.²

Ein kleiner Befehl lässt sich leichter einschränken:

Breite Werkzeuge sammeln meist breite Berechtigungen an. Ein allgemeiner „publish“-Befehl kann Inhalte, Übersetzungen, Datenbankzeilen, Cache-Purge, Deployment-Logs und Analytics berühren. Manchmal gehört der Release-Befehl genau so ins System. Das sicherere Muster baut den Release aus kleineren Befehlen mit expliziten Schranken dazwischen auf und automatisiert die Sequenz erst, wenn jeder Schritt Belege liefert.

Das Ziel ist nicht, Arbeit langsamer zu machen. Das Ziel ist, Autorität sichtbar zu machen.

Tests sollten zum Werkzeug passen

Der erste Best-Practice-Abschnitt von Anthropic sagt Benutzern, sie sollten Claude eine Möglichkeit geben, die eigene Arbeit zu verifizieren: Tests, Screenshots, erwartete Ausgaben und Befehlsprüfungen.² Schlanke Software macht diesen Rat konkret. Ein kleines Werkzeug kann einen kleinen Verifikationsvertrag mitbringen.

Für agentengebaute Software sollte dieser Vertrag auf einen Bildschirm passen:

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

Der Vertrag zählt, weil Agenten vage Anfragen zu leicht erfüllen können. „Verbessere die Pipeline“ lädt zu Architekturbewegung ein. „Fügen Sie diesem einen Befehl ein Dry-Run-Flag hinzu und beweisen Sie, dass die Ausgabe keine Dateien schreibt“ schafft einen Belegpfad.

Tests werden auch schneller, wenn Werkzeuge klein bleiben. Schnelle Tests verändern das Verhalten des Agenten. Der Agent führt sie häufiger aus, sieht Fehler, während der relevante Code noch im Kontext liegt, und behebt Ursachen, bevor das Transkript wegdriftet. Langsame Tests drängen das Modell zum Raten oder dazu, nur zu erzählen, was es ausgeführt hätte.

Klein bedeutet nicht untergebaut

Schlanke Software kann auf vorhersehbare Weise scheitern:

Das Diskettenabzeichen misst Größe. Agentensicherheit braucht eine andere Messung: Kann ein Reviewer Verhalten, Berechtigungsumfang und Belegpfad verstehen, bevor er die Änderung genehmigt?

Diese Frage erlaubt einem Werkzeug, größer als 1,44 MB zu sein. Sie verweigert den entscheidenden Teil: versehentlichen Umfang. Eine sichere, langweilige native App mit 20 MB kann besser sein als ein 200-KB-Skript, das zu einem ungeprüften Installer shellt. Schlanke Software dient der Sicherheit nur, wenn die Zurückhaltung bis zum tatsächlichen Ausführungspfad reicht.

Eine Schlankheits-Scorecard für Agentenarbeit

Bevor ein Agent ein Werkzeug baut oder ändert, bewerten Sie die Arbeit in 5 Dimensionen. Es geht nicht darum, große Systeme zu bestrafen. Es geht darum, Oberflächen zu finden, die vor dem Schreiben durch den Agenten zerlegt werden müssen.

Eine rote Zelle bedeutet nicht, dass die Arbeit stoppen sollte. Eine rote Zelle bedeutet, dass der Agent eine kleinere Arbeitseinheit braucht. Sicherheit verbessert sich, wenn die Aufgabenform das richtige Verhalten leicht beweisbar macht.

Das praktische Muster

Die sichersten agentengebauten Systeme, denen ich vertraue, haben dieselbe Form:

1. Ein enger Befehl erledigt eine Aufgabe.
2. Einfache Dateien tragen Eingaben, Ausgaben, Logs, Pläne und Review-Pakete.
3. Berechtigungen entsprechen den tatsächlichen Effekten des Befehls.
4. Tests laufen schnell genug, damit der Agent sie während der Sitzung nutzt.
5. Der Diff bleibt klein genug für ein menschliches Review.
6. Der Release-Pfad kombiniert kleine Befehle, statt breite Autorität hinter einer Schaltfläche zu verstecken.

Das No-Build-Manifest beschrieb dieselbe Vorliebe aus Sicht des Web-Stacks: weniger Build-Schichten, weniger generierte Artefakte und weniger Abstand zwischen Quelle und Ausführungsumgebung.⁹ Die Agentensicherheitsversion sagt dasselbe mit einem anderen Leser im Blick. Jede zusätzliche Schicht gibt der Maschine einen weiteren Ort, an dem sie plausible Arbeit erzeugen kann, die der Mensch nicht schnell verifizieren kann.

Schlanke Software verwandelt Zurückhaltung in Infrastruktur. Ein engeres Modul passt besser in den Kontext. Eine einfachere Datei verbessert die Prüfbarkeit. Ein schnellerer Test verbessert Feedback. Ein kleinerer Berechtigungssatz begrenzt den Schadensradius besser. Ein kleinerer Diff stärkt menschliches Urteil.

FAQ: Schlanke Software und Agentensicherheit

Macht schlanke Software KI-Coding-Agenten sicher?

Nein. Schlanke Software verkleinert den Bereich, den Agenten missverstehen oder beschädigen können. Teams brauchen weiterhin Sandboxing, Allow- und Deny-Listen, Tests, Code-Reviews, Credential-Grenzen und Release-Schranken. Schlanke Software macht diese Kontrollen leichter anwendbar und schwerer versehentlich zu umgehen.

Wie klein sollte ein agentenseitiges Werkzeug sein?

Die nützliche Grenze ist Reviewbarkeit, nicht Bytezahl. Ein gutes agentenseitiges Werkzeug hat eine Aufgabe, einen kleinen Eingabe-/Ausgabevertrag, ein klares Berechtigungsprofil, schnelle Tests und einen Diff, den ein Reviewer in einer Sitzung verstehen kann.

Sollte Agentengedächtnis Dateien oder eine Datenbank nutzen?

Nutzen Sie Dateien für die Schnittstelle, wenn der Agent Artefakte prüfen, durchsuchen, diffen und schreiben muss. Nutzen Sie eine Datenbank, wenn das Produkt Nebenläufigkeit, Indizierung, Zugriffskontrolle, Dauerhaftigkeit oder benutzerübergreifenden Zustand braucht. Die sicherere Architektur trennt die agentenseitige Schnittstelle vom Speichersubstrat.⁷

Wo passt MCP hinein?

MCP passt, wenn der Agent eine typisierte Brücke zu externen Tools oder Daten braucht. MCP beseitigt nicht die Notwendigkeit kleiner Befehle, begrenzter Berechtigungen und aktionsbezogener Autorisierung. Der Server muss weiterhin entscheiden, ob das konkrete Subjekt die konkrete Aktion ausführen darf.⁸

Schluss

KI macht Code billig. Billiger Code erhöht den Wert von Verweigerung.

Schlanke Software gibt Verweigerung eine Form, der die Maschine folgen kann: ein Befehl, eine Ausgabe, eine Berechtigungsgrenze, ein Testpfad, ein Diff. Diese Form garantiert keine Qualität. Sie macht schwache Arbeit aber sichtbarer.

Die Diskette ist nicht mehr die Beschränkung. Prüfbarkeit ist es.

Quellen