Acht Werkzeuge, null Schreibrechte: Freigabe-Gates für KI-Agenten als Code

Die häufigste Frage zu KI-Agenten ist die falsche. Sie lautet: Wie verhindere ich, dass das Modell etwas Falsches sagt? Die Frage, die über den Produktivbetrieb entscheidet, lautet anders: Was kann das Modell im schlimmsten Fall anrichten, wenn es etwas Falsches sagt?

Der Unterschied ist wichtig, weil die erste Frage keine belastbare Antwort hat. Ein Sprachmodell wird gelegentlich danebenliegen; das ist keine Konfigurationsfrage, sondern eine Eigenschaft. Die zweite Frage dagegen ist eine reine Konstruktionsfrage. Sie lässt sich in Code beantworten, testen und nachlesen.

Die kurze Antwort: Nicht das Modell absichern, sondern die Werkzeuge. In Chelaro, meinem lokalen Finanzarbeitsplatz, hat die KI genau acht typisierte Werkzeuge. Vier davon lesen. Die anderen vier schreiben nichts, sondern legen einen prüfpflichtigen Vorschlag an. Kein Werkzeug kann einen bestätigten Finanzwert überschreiben, und zwar unabhängig davon, was das Modell gerade für richtig hält.

Der Werkzeugvertrag ist Code, kein Prompt

Ein Agent kann nur das tun, was seine Werkzeuge zulassen. Das klingt banal, wird aber selten ernst genommen: In vielen Aufbauten bekommt das Modell einen generischen Datenbank- oder Shell-Zugriff und die Begrenzung steht im Systemprompt. Damit ist die Sicherheitsgrenze ein Text, den dasselbe Modell interpretiert, das man gerade begrenzen wollte.

In Chelaro liegt die Grenze eine Ebene tiefer. Es gibt eine feste Liste mit acht Namen:

Jedes Werkzeug hat ein striktes JSON-Schema mit additionalProperties: false, das vor der Ausführung validiert wird. Beträge müssen einem Geldmuster mit exakt zwei Nachkommastellen entsprechen, IDs einem UUID-Muster, Perioden dem Format JJJJ-MM. Die Argumente sind auf 16 KiB begrenzt. Listen geben höchstens 50 Einträge zurück.

Das Modell bekommt darüber hinaus nichts: keinen Shell-Zugriff, keine Dateien, keine Prozesse, kein Netzwerk, keinen Browser, keine Coding-Werkzeuge. Es kann nicht mehr falsch machen, als diese acht Signaturen zulassen, weil es nichts anderes erreichen kann.

Schreiben heißt vorschlagen

Die vier schreibenden Werkzeuge heißen nicht zufällig propose. Sie erzeugen keinen kanonischen Datensatz, sondern einen Vorschlag mit eigenem Status. Erst wenn der Owner ihn annimmt, entsteht daraus ein bestätigter Finanzwert.

Zwei Details entscheiden darüber, ob das mehr ist als ein Bestätigungsdialog:

Erstens ist die Begründung Pflicht. Jedes vorschlagende Werkzeug verlangt ein rationale-Feld, und zwar im Schema, nicht als Bitte im Prompt. Ein Vorschlag ohne Begründung wird nicht erzeugt. Das klingt nach Kosmetik, ändert aber die Prüfung: Wer bestätigt, liest nicht nur einen Betrag, sondern die Behauptung, warum dieser Betrag stimmt. Falsche Vorschläge fallen dadurch früher auf als bei einer nackten Zahl.

Zweitens sind angenommene und abgelehnte Vorschläge gleichwertig protokolliert. Ein abgelehnter Vorschlag verschwindet nicht. Er bleibt im Audit Ledger stehen. Damit ist im Nachhinein nicht nur sichtbar, was passiert ist, sondern auch, was beinahe passiert wäre.

Das eigentliche Gate ist der Versionskonflikt

Der interessanteste Teil ist unscheinbar. Jedes ändernde Werkzeug muss die erwartete Version des betroffenen Datensatzes mitliefern. Stimmt sie nicht mehr, wird der Vorschlag mit einem Konflikt abgewiesen statt angewendet.

Der Grund ist ein Zeitproblem, das bei Agenten häufiger auftritt als bei Menschen: Zwischen dem Lesen und dem Schreiben liegt bei einem Modell oft eine ganze Kette von Zwischenschritten. In dieser Zeit kann sich der Datensatz geändert haben, etwa weil der Owner selbst korrigiert hat. Ohne Versionsprüfung überschreibt der Agent eine frischere Korrektur mit einem veralteten Stand, und niemand bemerkt es, weil beide Werte plausibel aussehen.

Mit Versionsprüfung wird daraus ein sichtbarer Fehlschlag statt eines stillen Datenverlusts. Das ist die nützlichste Eigenschaft der ganzen Konstruktion und zugleich die, die man beim Bauen am ehesten weglässt.

Dieselbe Struktur habe ich unabhängig davon in einem Fullstack-AI-CRM für die Oberflächentechnik gebaut, das derzeit im Pilotbetrieb läuft: fünf authentifizierte Lesetools, elf bestätigungspflichtige Aktionstypen, jeweils Entwurf, Vorschau und Bestätigung mit begrenzter Gültigkeit, und ebenfalls ein Konflikt bei veraltetem Stand. Dass dasselbe Muster in zwei sehr unterschiedlichen Domänen entsteht, ist für mich der beste Hinweis darauf, dass es an der Domäne nicht liegt.

Was das nicht löst

Diese Grenze ist eine Schadensbegrenzung, keine Qualitätsgarantie. Sie sagt nichts darüber, ob die Vorschläge gut sind. Ein Agent, der zuverlässig unsinnige, aber formal gültige Vorschläge erzeugt, ist durch nichts davon gehindert; er kostet dann nur Prüfzeit statt Daten.

Sie verlagert außerdem Arbeit auf den Menschen. Ein Prüfschritt, der bei jedem einzelnen Vorschlag aufgerufen wird, wird irgendwann durchgeklickt. Wenn die Trefferquote nicht hoch genug ist, ist ein Freigabe-Gate kein Sicherheitsgewinn, sondern eine Ermüdungsmaschine. Ob die Vorschläge gut genug sind, muss deshalb getrennt gemessen werden, und dafür braucht es Evals gegen Referenzfälle statt Architekturargumente.

Und schließlich: Chelaro ist eine öffentliche Source Preview unter einer source-available-Lizenz, nicht produktionsreif und ohne Releases. OCR, Transaktionsimport, Live-Banking sowie Backup und Restore fehlen. Was hier beschrieben ist, ist die Zugriffsgrenze und ihre Testabdeckung, nicht ein im Einsatz bewährtes Produkt.

Der Werkzeugvertrag, die Schema-Validierung und die Versionsprüfung sind im Repository nachlesbar. Das ist der Punkt: Eine Sicherheitsgrenze, die man nicht lesen kann, ist keine.

Zur Case StudyChelaro→