{"id":213,"date":"2026-09-01T16:10:18","date_gmt":"2026-09-01T14:10:18","guid":{"rendered":"https:\/\/zeryon-systems.com\/blog\/?p=213"},"modified":"2026-09-01T16:12:43","modified_gmt":"2026-09-01T14:12:43","slug":"ein-werkzeug-das-da-ist-ist-noch-nicht-erlaubt","status":"publish","type":"post","link":"https:\/\/zeryon-systems.com\/blog\/2026\/09\/01\/ein-werkzeug-das-da-ist-ist-noch-nicht-erlaubt\/","title":{"rendered":"Ein Werkzeug das da ist ist noch nicht erlaubt"},"content":{"rendered":"\n

Ein Werkzeug, das da ist, ist noch nicht erlaubt<\/h2>\n\n\n\n

AXYON auf heutigem Stand \u2014 und die MCP Control Layer, die gerade entsteht<\/h3>\n\n\n\n

Wer einen MCP-Server an einen Agenten h\u00e4ngt, bekommt eine Liste von Werkzeugen zur\u00fcck. Ab diesem Moment kann der Agent sie aufrufen. Zwischen \u201esteht in der Liste“ und \u201edarf benutzt werden“ liegt im Protokoll nichts, das eine Entscheidung tr\u00e4fe. Der Werkzeugname kommt vom Server. Die Beschreibung kommt vom Server. Das Eingabeschema kommt vom Server. Gepr\u00fcft wird davon nichts.<\/p>\n\n\n\n

Das ist kein Vers\u00e4umnis 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\u00fccklich 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.<\/p>\n\n\n\n

Das Problem ist diese Reihenfolge, nicht der einzelne Aufruf.<\/p>\n\n\n\n

Was Guardrails und Protokolle nicht leisten<\/h3>\n\n\n\n

Guardrails sitzen vor der Sprache. Sie pr\u00fcfen, 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\u00e4sst, die L\u00f6schung, die niemand angefordert hat.<\/p>\n\n\n\n

Auditwerkzeuge sitzen dahinter. Sie schreiben auf, was geschehen ist. Auch das ist n\u00fctzlich, und in einem Pr\u00fcfungstermin ist es unverzichtbar. Es beantwortet nur die Frage nicht, die im Ernstfall zuerst gestellt wird: Wer hat das freigegeben?<\/p>\n\n\n\n

Beides zusammen ergibt eine Kette, in der niemand entscheidet. Der h\u00e4ufigste Denkfehler an dieser Stelle ist, das f\u00fcr eine L\u00fccke in der Dokumentation zu halten. Es ist eine L\u00fccke in der Wirkkette.<\/p>\n\n\n\n

Die Frage, auf die AXYON gebaut ist<\/h3>\n\n\n\n
\"Ein<\/figure>\n\n\n\n

AXYON ist ein Execution Control Layer. Er beantwortet vor jeder einzelnen Handlung eine Frage: Darf diese Handlung laufen? KI schl\u00e4gt vor, AXYON<\/a> entscheidet.<\/p>\n\n\n\n

Konkret hei\u00dft das: Ein Auftrag tr\u00e4gt seine Werkzeuggrenze mit sich. Eine Freigabe gilt f\u00fcr genau diesen Auftrag, sie gilt einmal, und sie h\u00e4ngt am Inhalt \u2014 \u00e4ndert sich der Inhalt, ist die Freigabe wertlos, nicht nachtr\u00e4glich diskutierbar. Wer freigibt, darf nicht derselbe sein, der beantragt hat. Und seit Ende August pr\u00fcft die Appliance zus\u00e4tzlich, ob der Freigebende \u00fcberhaupt ein Mensch ist. Die Subjektart kommt serverseitig aus der Anmeldung, nicht aus dem Aufruf. Die Voreinstellung ist \u201eMaschine“. Wer sich nicht als Mensch ausweist, gibt nichts frei.<\/p>\n\n\n\n

Diese Voreinstellung ist die unbequeme, und das ist Absicht. Eine Regel, die im Zweifel durchl\u00e4sst, ist keine Regel.<\/p>\n\n\n\n

Dazu kommt, was ein Sicherheitsverantwortlicher an einer Laufzeitkontrolle ohnehin erwartet: Widerruf w\u00e4hrend des Laufs, ein Not-Halt, der wirkt, und eine Aufzeichnung, die nicht der Anwendung geh\u00f6rt. \u00dcber die Aufzeichnung reden wir bewusst n\u00fcchtern. Sie ist kryptografisch verkettet, keyed signiert und extern bezeugt. Sie ist nicht \u201erevisionssicher“ \u2014 das Wort verspricht im DACH-Raum eine Rechtsfolge, die der Mechanismus nicht tr\u00e4gt, und wir verwenden es deshalb nicht. Der mitgelieferte unabh\u00e4ngige Pr\u00fcfer beweist, dass ein vorgelegter Auszug dem bezeugten Stand entspricht und nichts abgeschnitten wurde. Er beweist nicht die Integrit\u00e4t der geschl\u00fcsselten Kette, denn daf\u00fcr br\u00e4uchte ein Pr\u00fcfer den Schl\u00fcssel, und den bekommt er nicht.<\/p>\n\n\n\n

AXYON gibt es in zwei Ausf\u00fchrungen, als Container-Appliance im eigenen Netz und als native macOS-App ohne offenen Port. Die Oberfl\u00e4chen d\u00fcrfen auseinanderlaufen, die Governance nicht. Deshalb tr\u00e4gt der Governance-Stand<\/a> eine eigene Versionsnummer, die jedes Artefakt ausweist \u2014 sonst w\u00e4re \u201ein beiden Ausf\u00fchrungen identisch“ eine Behauptung ohne Pr\u00fcfm\u00f6glichkeit.<\/p>\n\n\n\n

Warum MCP eine eigene Schicht bekommt<\/h3>\n\n\n\n

MCP hat in kurzer Zeit das getan, was ein gutes Protokoll tut: Es hat die Anschlusskosten auf fast null gedr\u00fcckt. 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.<\/p>\n\n\n\n

Wir bauen daf\u00fcr die AXYON MCP Control Layer<\/strong> \u2014 ein eigenst\u00e4ndiges, separat lizenziertes Add-on, das an der MCP-Grenze durchsetzt, was die Appliance entscheidet. Der Grundsatz, an dem die gesamte Produktgrenze h\u00e4ngt: AXYON steht allein, MCP steckt an. Die Appliance l\u00e4uft ohne das Add-on vollst\u00e4ndig, sie wei\u00df nichts von MCP, und die Abh\u00e4ngigkeit l\u00e4uft nur in eine Richtung. Wer das Add-on entfernt, bekommt eine funktionierende Appliance zur\u00fcck; das ist ein Abnahmetest, kein Versprechen.<\/p>\n\n\n\n

Was die Schicht durchsetzt, l\u00e4sst sich an einer Kette festmachen, die wir vor die Klammer gezogen haben:<\/p>\n\n\n\n

Werkzeug vorhanden ist nicht Werkzeug zugelassen. Werkzeug zugelassen ist nicht Handlung autorisiert. Und Handlung autorisiert ist nicht Handlung jetzt autorisiert.<\/p>\n\n\n\n

Identit\u00e4t.<\/strong> Ein Werkzeug wird nicht \u00fcber seinen Namen erkannt. Ein Name ist ein Anzeigetext, den jeder Server frei w\u00e4hlt, und zwei Server d\u00fcrfen denselben verwenden. Die Schicht f\u00fchrt f\u00fcr jedes Werkzeug eine vierteilige Identit\u00e4t aus Serveridentit\u00e4t, Werkzeugidentit\u00e4t, Schemabindung und der Zuordnung auf die AXYON-Semantik. \u00c4ndert ein Server das Eingabeschema, ist es ein anderes Werkzeug, und es f\u00e4llt zur\u00fcck in einen Zustand, in dem es nicht benutzt werden darf. Das trifft Namenskollision, Substitution, stille Schema\u00e4nderung und Neuregistrierung unter bekanntem Namen mit derselben Regel.<\/p>\n\n\n\n

Serveridentit\u00e4t kommt nicht aus dem Protokoll.<\/strong> Sie kann von dort nicht kommen, weil das Protokoll sie nicht pr\u00fcft. \u00dcber HTTP verlangt die Schicht TLS und einen je Server hinterlegten Anker; die Endpunkt-URL ist eine Adresse, keine Identit\u00e4t. Bei lokal gestarteten Servern ist der Pr\u00fcfstein der Digest des Artefakts zusammen mit der exakten Startspezifikation, gepr\u00fcft vor dem Start. Ein Pfad ist keine Identit\u00e4t. Ein Name, der pl\u00f6tzlich mit anderer kryptografischer Identit\u00e4t auftaucht, erbt kein Vertrauen \u2014 daf\u00fcr braucht es ein autorisiertes Lebenszyklusereignis.<\/p>\n\n\n\n

Fassung.<\/strong> Die unterst\u00fctzte Protokollfassung ist gepinnt. Es gibt keinen automatischen R\u00fcckfall auf eine \u00e4ltere Revision, weil ein stiller Verfahrensdowngrade genau der Angriff ist, gegen den die Bindung an eine Fassung sch\u00fctzen soll. Eine unbekannte Fassung wird abgelehnt, nicht interpretiert. Die alte SSE-Variante wird nicht unterst\u00fctzt.<\/p>\n\n\n\n

Keine Nebenkan\u00e4le.<\/strong> Die aktuelle Spezifikation erlaubt es einem Server, Parameterwerte in HTTP-Kopfzeilen spiegeln zu lassen. Diese Werte gehen bei uns vollst\u00e4ndig in den Parameter-Hash ein. Alles andere w\u00e4re ein Kanal neben der autorisierten Handlung, und die Freigabe w\u00fcrde f\u00fcr etwas gelten, das so nie beantragt wurde. Aus demselben Grund unterst\u00fctzen wir die R\u00fcckrufwege nicht, mit denen ein Server vom Client eine Modellantwort oder eine menschliche Eingabe verlangen kann. Ein Freigabedialog im Add-on w\u00e4re eine zweite Entscheidungsinstanz, und zwei Entscheidungsinstanzen sind schlechter als eine.<\/p>\n\n\n\n

Und vor allem: keine eigene Erlaubnis.<\/strong> Die Schicht darf ablehnen, sie darf validieren, sie darf drosseln und Gegendruck erzeugen. Sie darf nichts erlauben. Kein zwischengespeichertes Ja, keine Voreinstellung, kein \u201ewar beim letzten Mal auch erlaubt“, kein Weiterlaufen, wenn die Appliance nicht erreichbar ist. Keine Autorit\u00e4t hei\u00dft keine neue Ausf\u00fchrung. Sie kann Befugnis verkleinern, niemals vergr\u00f6\u00dfern. Ein Sprachmodell sitzt in diesem Pfad nicht.<\/p>\n\n\n\n

Nachweis vor Wirkung.<\/strong> Ab mittlerem Risiko gilt: keine dauerhaft geschriebene Aufzeichnung, keine Ausf\u00fchrung. Bei lesenden Zugriffen mit niedrigem Risiko ist begrenzter Gegendruck erlaubt, aber nichts wird verworfen, um den Durchsatz zu halten. \u201eBest effort logging“ gibt es nicht. Niedriges Risiko hei\u00dft nicht, dass der Nachweis optional ist.<\/p>\n\n\n\n

Ausgef\u00fchrt und unbest\u00e4tigt ist kein Erfolg.<\/strong> Wenn eine Handlung rausging und die Best\u00e4tigung fehlt, ist das ein eigener Zustand, kein H\u00e4kchen. Die betroffene Ressource wird gesperrt, und aufgehoben wird die Sperre von einem Menschen an der Appliance \u2014 nicht vom Add-on, weil ein Add-on, das Sperren aufhebt, sich seine eigene Befugnis vergr\u00f6\u00dfert.<\/p>\n\n\n\n

Wo das heute steht<\/h3>\n\n\n\n

Appliance und macOS-App sind lieferbar, die v1.0-Linie steht. Alles dar\u00fcber hinaus beschreibe ich lieber selbst, als dass es jemand beim Nachpr\u00fcfen findet.<\/p>\n\n\n\n

Das Autorisierungsfundament \u2014 kanonische Kodierung, Autorisierungsobjekt, Bindung an Inhalt und Wirkung, Schutz gegen Wiedereinspielung \u2014 ist gebaut und getestet. Die Durchsetzung im Produktivpfad ist damit noch nicht verdrahtet; das ist der n\u00e4chste Integrationsschritt und wird bei uns als Befund gef\u00fchrt, nicht als Feature.<\/p>\n\n\n\n

Die MCP Control Layer ist in Architektur und Grenzen entschieden. Die Vertr\u00e4ge 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.<\/p>\n\n\n\n

Was noch fehlt, benennen wir ebenfalls. Die Einzelpr\u00fcfung sieht die H\u00e4ufung nicht: Zwanzig einzeln erlaubte Zugriffe k\u00f6nnen zusammen etwas ergeben, das in einem Antrag niemals durchgegangen w\u00e4re. Der Weg dorthin ist entschieden und geplant, gebaut ist er nicht. Das Latenzbudget f\u00fcr die MCP-Schicht ist definiert und nicht gemessen; solange nicht gemessen wurde, steht hier auch keine Zahl.<\/p>\n\n\n\n

Kundennamen nennen wir grunds\u00e4tzlich nicht, auch nicht auf Nachfrage und auch nicht gegen einen Rabatt. In diesem Umfeld ist Diskretion keine Zur\u00fcckhaltung, sondern Teil der Leistung. Die Beweislast tragen stattdessen Architektur, Pr\u00fcfwerkzeuge und Lieferkettennachweise.<\/p>\n\n\n\n

Der n\u00e4chste sinnvolle Schritt<\/h3>\n\n\n\n

Wenn Sie in Ihrem Haus Agenten betreiben oder gerade dar\u00fcber 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\u00f6rt Ihnen, ob wir danach zusammenarbeiten oder nicht.<\/p>\n\n\n\n

Every Agent. Every Action. Before Executio<\/em>n<\/p>\n","protected":false},"excerpt":{"rendered":"

Ein Werkzeug, das da ist, ist noch nicht erlaubt AXYON auf heutigem Stand \u2014 und die MCP Control Layer, die gerade entsteht Wer einen…<\/p>\n","protected":false},"author":1,"featured_media":217,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-213","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-allgemein"],"_links":{"self":[{"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/posts\/213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/comments?post=213"}],"version-history":[{"count":8,"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/posts\/213\/revisions"}],"predecessor-version":[{"id":224,"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/posts\/213\/revisions\/224"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/media\/217"}],"wp:attachment":[{"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/media?parent=213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/categories?post=213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zeryon-systems.com\/blog\/wp-json\/wp\/v2\/tags?post=213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}