Ein Werkzeug, das da ist, ist noch nicht erlaubt
AXYON auf heutigem Stand — und die MCP Control Layer, die gerade entsteht
Wer einen MCP-Server an einen Agenten hängt, bekommt eine Liste von Werkzeugen zurück. Ab diesem Moment kann der Agent sie aufrufen. Zwischen „steht in der Liste“ und „darf benutzt werden“ liegt im Protokoll nichts, das eine Entscheidung träfe. Der Werkzeugname kommt vom Server. Die Beschreibung kommt vom Server. Das Eingabeschema kommt vom Server. Geprüft wird davon nichts.
Das ist kein Versäumnis der Spezifikation. MCP ist ein Verbindungsprotokoll, keine Sicherheitsschicht, und der Herausgeber sagt das auch: Auf die Angaben, mit denen ein Server sich vorstellt, soll man sich bei Sicherheitsentscheidungen ausdrücklich nicht verlassen. Das Problem entsteht erst dort, wo jemand die Kette trotzdem so betreibt, wie sie aus der Packung kommt. Modell plant, Werkzeug liegt bereit, Aufruf geht raus. Der Protokolleintrag entsteht danach.
Das Problem ist diese Reihenfolge, nicht der einzelne Aufruf.
Was Guardrails und Protokolle nicht leisten
Guardrails sitzen vor der Sprache. Sie prüfen, was ein Modell sagen darf, und sie tun das ordentlich. Nur ist der Schaden nicht die Formulierung, sondern der Schreibvorgang im Zielsystem, der Datensatz, der das Haus verlässt, die Löschung, die niemand angefordert hat.
Auditwerkzeuge sitzen dahinter. Sie schreiben auf, was geschehen ist. Auch das ist nützlich, und in einem Prüfungstermin ist es unverzichtbar. Es beantwortet nur die Frage nicht, die im Ernstfall zuerst gestellt wird: Wer hat das freigegeben?
Beides zusammen ergibt eine Kette, in der niemand entscheidet. Der häufigste Denkfehler an dieser Stelle ist, das für eine Lücke in der Dokumentation zu halten. Es ist eine Lücke in der Wirkkette.
Die Frage, auf die AXYON gebaut ist
AXYON ist ein Execution Control Layer. Er beantwortet vor jeder einzelnen Handlung eine Frage: Darf diese Handlung laufen? KI schlägt vor, AXYON entscheidet.
Konkret heißt das: Ein Auftrag trägt seine Werkzeuggrenze mit sich. Eine Freigabe gilt für genau diesen Auftrag, sie gilt einmal, und sie hängt am Inhalt — ändert sich der Inhalt, ist die Freigabe wertlos, nicht nachträglich diskutierbar. Wer freigibt, darf nicht derselbe sein, der beantragt hat. Und seit Ende August prüft die Appliance zusätzlich, ob der Freigebende überhaupt ein Mensch ist. Die Subjektart kommt serverseitig aus der Anmeldung, nicht aus dem Aufruf. Die Voreinstellung ist „Maschine“. Wer sich nicht als Mensch ausweist, gibt nichts frei.
Diese Voreinstellung ist die unbequeme, und das ist Absicht. Eine Regel, die im Zweifel durchlässt, ist keine Regel.
Dazu kommt, was ein Sicherheitsverantwortlicher an einer Laufzeitkontrolle ohnehin erwartet: Widerruf während des Laufs, ein Not-Halt, der wirkt, und eine Aufzeichnung, die nicht der Anwendung gehört. Über die Aufzeichnung reden wir bewusst nüchtern. Sie ist kryptografisch verkettet, keyed signiert und extern bezeugt. Sie ist nicht „revisionssicher“ — das Wort verspricht im DACH-Raum eine Rechtsfolge, die der Mechanismus nicht trägt, und wir verwenden es deshalb nicht. Der mitgelieferte unabhängige Prüfer beweist, dass ein vorgelegter Auszug dem bezeugten Stand entspricht und nichts abgeschnitten wurde. Er beweist nicht die Integrität der geschlüsselten Kette, denn dafür bräuchte ein Prüfer den Schlüssel, und den bekommt er nicht.
AXYON gibt es in zwei Ausführungen, als Container-Appliance im eigenen Netz und als native macOS-App ohne offenen Port. Die Oberflächen dürfen auseinanderlaufen, die Governance nicht. Deshalb trägt der Governance-Stand eine eigene Versionsnummer, die jedes Artefakt ausweist — sonst wäre „in beiden Ausführungen identisch“ eine Behauptung ohne Prüfmöglichkeit.
Warum MCP eine eigene Schicht bekommt
MCP hat in kurzer Zeit das getan, was ein gutes Protokoll tut: Es hat die Anschlusskosten auf fast null gedrückt. Genau das erzeugt das Problem. Ein Haus, das gestern drei fest verdrahtete Integrationen hatte, hat morgen vierzig Werkzeuge aus sechs Servern, von denen zwei nicht im Haus entwickelt wurden.
Wir bauen dafür die AXYON MCP Control Layer — ein eigenständiges, separat lizenziertes Add-on, das an der MCP-Grenze durchsetzt, was die Appliance entscheidet. Der Grundsatz, an dem die gesamte Produktgrenze hängt: AXYON steht allein, MCP steckt an. Die Appliance läuft ohne das Add-on vollständig, sie weiß nichts von MCP, und die Abhängigkeit läuft nur in eine Richtung. Wer das Add-on entfernt, bekommt eine funktionierende Appliance zurück; das ist ein Abnahmetest, kein Versprechen.
Was die Schicht durchsetzt, lässt sich an einer Kette festmachen, die wir vor die Klammer gezogen haben:
Werkzeug vorhanden ist nicht Werkzeug zugelassen. Werkzeug zugelassen ist nicht Handlung autorisiert. Und Handlung autorisiert ist nicht Handlung jetzt autorisiert.
Identität. Ein Werkzeug wird nicht über seinen Namen erkannt. Ein Name ist ein Anzeigetext, den jeder Server frei wählt, und zwei Server dürfen denselben verwenden. Die Schicht führt für jedes Werkzeug eine vierteilige Identität aus Serveridentität, Werkzeugidentität, Schemabindung und der Zuordnung auf die AXYON-Semantik. Ändert ein Server das Eingabeschema, ist es ein anderes Werkzeug, und es fällt zurück in einen Zustand, in dem es nicht benutzt werden darf. Das trifft Namenskollision, Substitution, stille Schemaänderung und Neuregistrierung unter bekanntem Namen mit derselben Regel.
Serveridentität kommt nicht aus dem Protokoll. Sie kann von dort nicht kommen, weil das Protokoll sie nicht prüft. Über HTTP verlangt die Schicht TLS und einen je Server hinterlegten Anker; die Endpunkt-URL ist eine Adresse, keine Identität. Bei lokal gestarteten Servern ist der Prüfstein der Digest des Artefakts zusammen mit der exakten Startspezifikation, geprüft vor dem Start. Ein Pfad ist keine Identität. Ein Name, der plötzlich mit anderer kryptografischer Identität auftaucht, erbt kein Vertrauen — dafür braucht es ein autorisiertes Lebenszyklusereignis.
Fassung. Die unterstützte Protokollfassung ist gepinnt. Es gibt keinen automatischen Rückfall auf eine ältere Revision, weil ein stiller Verfahrensdowngrade genau der Angriff ist, gegen den die Bindung an eine Fassung schützen soll. Eine unbekannte Fassung wird abgelehnt, nicht interpretiert. Die alte SSE-Variante wird nicht unterstützt.
Keine Nebenkanäle. Die aktuelle Spezifikation erlaubt es einem Server, Parameterwerte in HTTP-Kopfzeilen spiegeln zu lassen. Diese Werte gehen bei uns vollständig in den Parameter-Hash ein. Alles andere wäre ein Kanal neben der autorisierten Handlung, und die Freigabe würde für etwas gelten, das so nie beantragt wurde. Aus demselben Grund unterstützen wir die Rückrufwege nicht, mit denen ein Server vom Client eine Modellantwort oder eine menschliche Eingabe verlangen kann. Ein Freigabedialog im Add-on wäre eine zweite Entscheidungsinstanz, und zwei Entscheidungsinstanzen sind schlechter als eine.
Und vor allem: keine eigene Erlaubnis. Die Schicht darf ablehnen, sie darf validieren, sie darf drosseln und Gegendruck erzeugen. Sie darf nichts erlauben. Kein zwischengespeichertes Ja, keine Voreinstellung, kein „war beim letzten Mal auch erlaubt“, kein Weiterlaufen, wenn die Appliance nicht erreichbar ist. Keine Autorität heißt keine neue Ausführung. Sie kann Befugnis verkleinern, niemals vergrößern. Ein Sprachmodell sitzt in diesem Pfad nicht.
Nachweis vor Wirkung. Ab mittlerem Risiko gilt: keine dauerhaft geschriebene Aufzeichnung, keine Ausführung. Bei lesenden Zugriffen mit niedrigem Risiko ist begrenzter Gegendruck erlaubt, aber nichts wird verworfen, um den Durchsatz zu halten. „Best effort logging“ gibt es nicht. Niedriges Risiko heißt nicht, dass der Nachweis optional ist.
Ausgeführt und unbestätigt ist kein Erfolg. Wenn eine Handlung rausging und die Bestätigung fehlt, ist das ein eigener Zustand, kein Häkchen. Die betroffene Ressource wird gesperrt, und aufgehoben wird die Sperre von einem Menschen an der Appliance — nicht vom Add-on, weil ein Add-on, das Sperren aufhebt, sich seine eigene Befugnis vergrößert.
Wo das heute steht
Appliance und macOS-App sind lieferbar, die v1.0-Linie steht. Alles darüber hinaus beschreibe ich lieber selbst, als dass es jemand beim Nachprüfen findet.
Das Autorisierungsfundament — kanonische Kodierung, Autorisierungsobjekt, Bindung an Inhalt und Wirkung, Schutz gegen Wiedereinspielung — ist gebaut und getestet. Die Durchsetzung im Produktivpfad ist damit noch nicht verdrahtet; das ist der nächste Integrationsschritt und wird bei uns als Befund geführt, nicht als Feature.
Die MCP Control Layer ist in Architektur und Grenzen entschieden. Die Verträge zwischen Add-on und Appliance sind in Arbeit und noch nicht eingefroren, und implementiert wird erst danach. Ein Termin steht nicht, und ich nenne keinen.
Was noch fehlt, benennen wir ebenfalls. Die Einzelprüfung sieht die Häufung nicht: Zwanzig einzeln erlaubte Zugriffe können zusammen etwas ergeben, das in einem Antrag niemals durchgegangen wäre. Der Weg dorthin ist entschieden und geplant, gebaut ist er nicht. Das Latenzbudget für die MCP-Schicht ist definiert und nicht gemessen; solange nicht gemessen wurde, steht hier auch keine Zahl.
Kundennamen nennen wir grundsätzlich nicht, auch nicht auf Nachfrage und auch nicht gegen einen Rabatt. In diesem Umfeld ist Diskretion keine Zurückhaltung, sondern Teil der Leistung. Die Beweislast tragen stattdessen Architektur, Prüfwerkzeuge und Lieferkettennachweise.
Der nächste sinnvolle Schritt
Wenn Sie in Ihrem Haus Agenten betreiben oder gerade darüber entscheiden: Nehmen Sie eine reale Agentenstrecke, gehen wir sie in einer Stunde durch, und am Ende steht eine Liste der Handlungen, die heute ohne Freigabe wirksam werden. Die Liste gehört Ihnen, ob wir danach zusammenarbeiten oder nicht.
Every Agent. Every Action. Before Execution