Wenn die KI nicht nur liest, sondern Dateien verändert

Ein browserbasiertes Sprachmodell arbeitet häufig in einem begrenzten Dialograum. Es liest bereitgestellte Inhalte und erzeugt Text, doch die Übernahme in operative Dateien bleibt beim Menschen. Ein lokal arbeitender Agent kann dagegen Ordner durchsuchen, Dateien anlegen, Inhalte ersetzen, Befehle ausführen und Ergebnisse an andere Systeme übergeben. Diese Fähigkeit ist produktiv: Wiederkehrende Pflege, Transformation und Qualitätssicherung lassen sich direkt im Arbeitsbestand erledigen. Sie verschiebt aber die Grenze zwischen Empfehlung und Wirkung.

Der entscheidende Schritt ist nicht „mehr Intelligenz", sondern mehr Autorität. Wer einem Agenten Schreibzugriff gibt, muss Arbeitsraum, Identität, Berechtigung, Änderungsverfahren, Prüfung und Wiederherstellung als zusammenhängendes System entwerfen. Ein guter Prompt allein begrenzt keine Betriebssystemrechte und macht eine falsche Änderung nicht rückgängig.

Lesen, vorschlagen und anwenden sind verschiedene Betriebsarten

Agentische Systeme sollten nicht nur „an" oder „aus" kennen. Eine belastbare Architektur unterscheidet mindestens vier Modi:

1 · READ durchsucht und analysiert, ohne Dateien zu verändern.

2 · PROPOSE erzeugt Plan, Patch oder neue Dateien in einem isolierten Bereich.

3 · APPLY übernimmt eine freigegebene Änderung in den Arbeitsbestand.

4 · PUBLISH macht das Ergebnis für andere Systeme oder Menschen verbindlich verfügbar.

Diese Modi besitzen unterschiedliche Rechte und Freigaben. Ein Agent kann einen Patch selbstständig vorbereiten, während APPLY eine Bestätigung und PUBLISH eine zusätzliche Qualitätsprüfung verlangt. Dadurch wird Autonomie nicht pauschal gewährt, sondern nach Wirkung abgestuft.

Der Arbeitsraum ist eine Sicherheitsgrenze

Ein lokaler Agent braucht einen expliziten Root-Pfad. Er darf weder das gesamte Benutzerverzeichnis noch unaufgelöste Variablen oder breite Wildcards als Arbeitsbereich interpretieren. Zulässige Pfade werden vor jeder schreibenden Aktion kanonisch aufgelöst und gegen eine Allowlist geprüft. Symbolische Links, gemountete Verzeichnisse und Netzwerkpfade verdienen besondere Aufmerksamkeit, weil ein scheinbar lokaler Pfad außerhalb des erwarteten Bereichs enden kann.

Innerhalb des Arbeitsraums helfen Zonen: sources/ bleibt schreibgeschützt, working/ nimmt Änderungen auf, review/ enthält Vorschauen und published/ nur freigegebene Ergebnisse. Temporäre Dateien erhalten einen eigenen Bereich und ein Ablaufdatum. Diese Struktur macht Rechte verständlich und verhindert, dass eine Rohquelle versehentlich wie ein bearbeitbares Dokument behandelt wird.

Vor der Änderung steht eine Bestandsaufnahme

Bevor der Agent schreibt, erfasst er Ziel, Dateityp, Größe, Prüfsumme, Änderungszeit, Eigentümer, Sensitivität und aktuellen Versionsstand. Er prüft, ob die Datei seit Beginn der Aufgabe durch jemand anderen geändert wurde. Diese Vorbedingung verhindert, dass ein Agent mit veralteter Grundlage eine neuere menschliche Änderung überschreibt.

Die Bestandsaufnahme enthält auch Abhängigkeiten. Wird ein Schema umbenannt, können Abfragen, Links oder Exporte betroffen sein. Wird eine Konfiguration geändert, kann der nächste Prozesslauf anderes Verhalten zeigen. Die Reichweite einer Änderung bestimmt, welche Tests und Freigaben erforderlich sind.

Der Plan muss vor dem Patch verständlich sein

Ein Agent beschreibt zuerst, welche Dateien er warum ändern will, welche Dateien unverändert bleiben und wie Erfolg geprüft wird. Der Plan nennt Annahmen, Risiken und Abbruchbedingungen. Erst danach entsteht ein konkreter Patch oder eine Vorschau.

Der Patch ist die kleinste überprüfbare Einheit. Er zeigt hinzugefügte, entfernte und geänderte Zeilen. Bei strukturierten Daten ergänzt eine semantische Zusammenfassung, welche Datensätze, Felder oder Relationen betroffen sind. Eine bloße Meldung wie „Datei aktualisiert" ist unzureichend, weil sie Umfang und Bedeutung verschweigt.

Sichere Änderungen sind klein, atomar und wiederholbar

Mehrere unabhängige Ziele werden nicht in einer riesigen Mutation vermischt. Kleine Änderungssätze lassen sich besser prüfen, testen und zurücknehmen. Der Agent schreibt neue Inhalte zunächst in eine temporäre Datei, validiert sie und ersetzt das Ziel erst anschließend. Wo Plattform und Dateisystem es unterstützen, reduziert ein atomarer Austausch das Risiko halb geschriebener Dateien.

Idempotenz ist ebenso wichtig: Ein erneut ausgeführter Schritt darf nicht unbemerkt Duplikate erzeugen oder Werte erneut erhöhen. Der Agent prüft den gewünschten Endzustand statt blind dieselbe Operation zu wiederholen. Für nicht idempotente Aktionen braucht es eindeutige Ausführungskennungen und Schutz gegen Doppelverarbeitung.

Parallelität erzeugt Konflikte

Menschen, Agenten und Automationen können dieselbe Datei gleichzeitig bearbeiten. Ein „last write wins"-Verhalten vernichtet Änderungen ohne sichtbaren Fehler. Optimistische Konkurrenzkontrolle vergleicht deshalb vor dem Schreiben Prüfsumme oder Revision. Hat sich das Ziel verändert, stoppt der Agent, erstellt einen neuen Diff und fordert eine Entscheidung an.

Sperren können bei kurzen, klar begrenzten Operationen helfen, müssen aber Ablaufzeit und Recovery besitzen. Eine verwaiste Sperre darf das System nicht dauerhaft blockieren. Für komplexe Arbeit sind getrennte Arbeitszweige oder Worktrees oft verständlicher: Jede Aufgabe erhält einen isolierten Stand, der anschließend geprüft und zusammengeführt wird.

Least Privilege gilt auch lokal

„Lokal" bedeutet nicht „vertrauenswürdig". Ein Prozess mit Schreibrecht auf alle Dateien kann Schlüssel, Konfigurationen oder Backups beschädigen. NIST beschreibt Least Privilege als Beschränkung auf notwendige Rechte. Praktisch erhält der Agent einen eigenen Benutzer oder isolierten Prozess, nur benötigte Pfade und nur erforderliche Werkzeuge.

Lesen, Schreiben, Löschen, Ausführen und Netzwerkzugriff werden getrennt. Ein Formatierungsskill benötigt keinen Internetzugang. Ein Rechercheprozess darf möglicherweise herunterladen, aber nicht in published/ schreiben. Löschung und rekursive Operationen verlangen besonders enge Zielprüfung, Vorschau und Freigabe. Geheimnisse werden nicht in Aufgabenbeschreibungen oder Logdateien gespeichert.

Gelesene Dateien sind nicht automatisch vertrauenswürdige Anweisungen

Dokumente, Webseiten und E-Mails können Text enthalten, der den Agenten zu unerwünschten Aktionen auffordert. Das ist bei schreibenden Systemen besonders gefährlich, weil eine indirekte Prompt Injection vom gelesenen Inhalt zur Dateiveränderung oder Datenübermittlung führen kann.

Die Steuerungsschicht behandelt Arbeitsauftrag und Policy als vertrauenswürdig, Inhalte dagegen als Daten. Inhalte dürfen Berechtigungen, Zielpfade oder Freigaberegeln nicht überschreiben. Toolaufrufe werden unabhängig vom Modell gegen Policies geprüft. OWASP weist darauf hin, dass kein einzelner Prompt dieses Risiko vollständig beseitigt; entscheidend sind minimale Rechte, Ziel-Allowlisting, Ausgabekontrolle und menschliche Bestätigung bei folgenreichen Aktionen.

Freigabe braucht einen konkreten Gegenstand

„Ja, mach weiter" ist nur dann eine belastbare Freigabe, wenn klar ist, welchem Plan, Diff und Versionsstand sie gilt. Eine Approval-ID bindet Person, Zeitpunkt, Änderungssatz, Zielrevision und erlaubte Aktion. Wird der Patch nach der Freigabe verändert, verfällt die Bestätigung.

Freigaben werden nach Wirkung gestaffelt. Rechtschreibkorrekturen in Entwürfen können automatisch angewendet werden. Änderungen an Regeln, Preisen, Berechtigungen, Kundendaten oder veröffentlichten Inhalten verlangen menschliche Prüfung. Irreversible oder externe Aktionen benötigen eine separate Bestätigung direkt vor Ausführung.

Versionsverwaltung ist Kontrollmittel, aber kein vollständiges Backup

Git kann Unterschiede sichtbar machen, Stände markieren und gezielt wiederherstellen. Ein sauberer Commit verbindet Änderung, Zweck, Testergebnis und verantwortliche Identität. Vor dem Commit prüft der Agent, dass keine fremden oder sensiblen Dateien versehentlich einbezogen werden.

Versionsverwaltung schützt jedoch nicht gegen jedes Problem. Ein gemeinsam gelöschtes Repository, beschädigte Historie, große unversionierte Artefakte oder falsch eingecheckte Geheimnisse erfordern unabhängige Backups und Recovery-Verfahren. Wiederherstellung muss geprobt werden. Ein Rollback kann außerdem Folgewirkungen nicht automatisch rückgängig machen, wenn eine Datei bereits exportiert oder ein externer Prozess gestartet wurde.

Nach der Änderung beginnt die Verifikation

Eine syntaktisch gültige Datei kann fachlich falsch sein. Deshalb prüft der Agent mehrere Ebenen: Datei lässt sich lesen, Schema ist gültig, Links und Referenzen funktionieren, Tests bestehen, erwartete Artefakte entstehen und verbotene Nebenwirkungen fehlen. Für Text gehören Quellenbindung, Terminologie, interne Bezeichnungen und Sprachvollständigkeit dazu.

Der Testplan entsteht vor der Änderung. So kann der Agent Erfolg nicht nachträglich passend definieren. Fehlgeschlagene Prüfungen führen nicht zu einem beschönigten Bericht, sondern zu einem klaren Status, Erhalt des Patches und entweder automatischer Rücknahme oder menschlicher Entscheidung.

Jede Wirkung braucht eine Herkunftskette

Ein Run-Report dokumentiert Anfrage, Agentenidentität, Arbeitsraum, Eingangsrevision, Plan, geänderte Dateien, Patch, Werkzeuge, Tests, Freigaben, Ausgangsrevision und Restunsicherheiten. SLSA und W3C PROV liefern übertragbare Prinzipien für die Frage, wo, wann und wie Artefakte entstanden.

Der Bericht speichert nur notwendige Evidenz. Sensible Inhalte können durch Hashes und Referenzen vertreten werden. Ziel ist, später beantworten zu können: Wer oder was änderte welche Datei aufgrund welcher Quelle, mit welcher Freigabe und welchem Ergebnis?

Betrieb braucht Stoppschalter und Fehlerbudget

Ein Agent startet in READ oder PROPOSE. APPLY wird zunächst auf kleine, reversible Fälle begrenzt. Teams messen fehlerhafte Zielwahl, unnötige Änderungen, Konflikte, zurückgenommene Patches, fehlgeschlagene Tests und falsche Freigaben. Wird das Fehlerbudget überschritten, fällt der Prozess in einen weniger autonomen Modus zurück.

Ein Stoppschalter entzieht Schreib- und Netzwerkrechte, ohne Beweise zu löschen. Offene Änderungen bleiben isoliert. Ein manueller Ersatzprozess stellt sicher, dass die Organisation auch ohne Agent arbeitsfähig bleibt. Autonomie darf keine unersetzbare Einzelstelle schaffen.

Methode: SCOPE → INSPECT → PLAN → PATCH → VERIFY → APPROVE → COMMIT → REPORT

SCOPE begrenzt Ziel und Rechte. INSPECT erfasst Zustand und Abhängigkeiten. PLAN erklärt Wirkung und Abbruch. PATCH erzeugt eine kleine Vorschau. VERIFY prüft Syntax, Fachlichkeit und Nebenwirkungen. APPROVE bindet eine Entscheidung an den konkreten Patch. COMMIT übernimmt atomar und versioniert. REPORT dokumentiert Herkunft, Tests und Restunsicherheit.

Der Übergang zum lokalen Agenten ist gelungen, wenn Schreibzugriff nicht unsichtbare Freiheit bedeutet, sondern eine Kette kleiner, überprüfbarer und wiederherstellbarer Zustandsänderungen.

Übungsblatt: Entwirf ein Safe File Mutation Protocol

1. Wähle eine reale Dateiänderung und ordne sie READ, PROPOSE, APPLY oder PUBLISH zu.

2. Definiere Root-Pfad, erlaubte Dateitypen, verbotene Ziele und minimale Rechte.

3. Lege Bestandsaufnahme, Konflikterkennung und Abbruchbedingungen fest.

4. Beschreibe Plan, Diff, semantische Wirkung und erforderliche Freigabe.

5. Definiere sieben Prüfungen vor und nach der Übernahme.

6. Plane Commit, unabhängiges Backup, Rollback und Behandlung externer Folgewirkungen.

7. Entwirf einen Run-Report mit Evidenz, Owner und Restunsicherheit.

Reflexion: Welche heutige Agentenaktion besitzt mehr Rechte als ihr Zweck benötigt? Welche Dateiänderung wäre technisch rücksetzbar, aber fachlich nicht folgenlos?

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Lokaler Betrieb und Versionsverwaltung sind keine automatischen Sicherheits- oder Backupgarantien. Das Modell ist produktunabhängig und muss an Betriebssystem, Datenklasse, Rechtsraum und Wirkung einer Änderung angepasst werden. Redaktionell und technisch geprüft am 17. Juli 2026.