Werkzeuge mit Schema.

Ein Werkzeug hat einen Namen, eine Beschreibung und ein Eingabeschema nach JSON Schema: welche Parameter, welche Typen, welche Pflichtfelder, welche Wertebereiche, und keine Felder darüber hinaus (additionalProperties: false). Hinter dem Werkzeug steht genau eine Handlung der Ontologie mit ihren Vorbedingungen und dem Recht, das sie verlangt.

Freie Befehle gibt es nicht: kein Werkzeug, das beliebiges SQL, beliebige Shell-Befehle oder beliebige Adressen annimmt. Was ein Werkzeug bewirken kann, steht vollständig in seinem Schema und seiner Handlung, und beides lässt sich vor dem Einsatz lesen und prüfen.

Für die Anbindung an Sprachmodelle eignen sich offene Formate wie das Model Context Protocol. Die Prüfung bleibt in jedem Fall in der Laufzeit von AXON und wandert nicht in das Sprachmodell oder zu seinem Anbieter.

Das Sprachmodell erzeugt nur einen Vorschlag: Werkzeugname und Argumente als strukturierte Daten. Die Laufzeit prüft zuerst die Form gegen das Schema. Was nicht passt, geht mit der Fehlermeldung an das Sprachmodell zurück und wird nicht ausgeführt.

Dann das Recht: Darf dieser Agent in diesem Auftrag diese Handlung an diesem Objekt zu diesem Zweck ausführen? Dann die Vorbedingungen am aktuellen Zustand. Liegt die Handlung über der Grenze der Rolle, wartet sie auf eine Freigabe. Erst danach ruft die Laufzeit die Handlung auf, mit den Zugangsdaten des Auftrags, die das Sprachmodell nie sieht.

Das Ergebnis geht als Daten zurück in den Kontext, und der Aufruf steht mit Vorschlag, Prüfergebnissen und Antwort im Verlauf.

Ein Agent liest E-Mails, Dokumente, Webseiten und Formulare. Solche Inhalte können Sätze enthalten, die wie Anweisungen aussehen, etwa die Aufforderung, alle bisherigen Regeln zu vergessen. Das ist Prompt Injection, direkt im Eingabetext oder indirekt über eingebettete Inhalte; die OWASP-Liste der Risiken für Anwendungen mit Sprachmodellen führt sie als ersten Punkt (LLM01).

AXON trennt darum Anweisung und Inhalt. Auftrag und Regeln kommen aus dem System; Eingangstexte stehen getrennt davon und gekennzeichnet als Daten aus einer Quelle mit niedrigem Vertrauen. Ein Sprachmodell kann trotzdem auf einen solchen Satz hereinfallen. Deshalb hängt die Sicherheit nicht an der Trennung allein, sondern an den Schichten im nächsten Abschnitt.

Erstens Rechte an der Handlung. Selbst ein getäuschtes Sprachmodell kann nur Werkzeuge vorschlagen, die der Auftrag erlaubt, und nur mit Argumenten, die das Schema zulässt. Einem Agenten, der nur intern arbeitet, fehlt ein Werkzeug zum Versenden nach außen ganz.

Zweitens Freigabe vor Wirkung. Handlungen mit Wirkung außerhalb des Systems oder über der Grenze der Rolle warten auf eine berechtigte Person, die genau diese Handlung mit ihren Parametern sieht, bevor sie entscheidet.

Drittens eine Begrenzung des Datenflusses, die vorgesehen ist: Hat ein Agent in einer Sitzung Inhalte aus einer Quelle mit niedrigem Vertrauen gelesen, verliert er für diese Sitzung die Werkzeuge, die Daten nach außen geben könnten. Die Herkunft der Daten wird so zu einer Bedingung der Handlung.

Was ein Agent schreiben will, wird vor der Ausführung geprüft: gegen das Schema, gegen die Regeln der Ontologie wie Wertebereiche und Pflichtverweise, und auf Inhalte, die nicht ins Ziel gehören, etwa Felder mit einer Markierung, die der Empfänger nicht lesen darf. Texte an Empfänger außerhalb des Systems gehen erst als Entwurf an eine berechtigte Person, bevor sie das System verlassen.

Ausgaben in Oberflächen werden als Text kodiert und nie als Code oder Markup ausgeführt. Verweise auf fremde Adressen lädt die Oberfläche nicht von selbst, damit kein Inhalt über eine Bildadresse Daten nach außen trägt.