Kein Sprachmodell schätzt ein, ob eine geplante Aktion sicher ist. Ein Z3-Solver beweist es formal, gegen Ihre eigenen Policies, bevor die Aktion ausgeführt wird. Vollständig lokal installiert, für jedes Agenten-Framework nutzbar.
Unternehmen wollen Agenten produktiv einsetzen: E-Mails versenden, Zahlungen auslösen, Deployments durchführen, Datenbanken ändern. Was fehlt, ist eine verlässliche Instanz, die vor der Ausführung prüft, ob eine geplante Aktion sicher und regelkonform ist.
Die meisten heutigen "AI Guardrails" sind Prompt-Filter oder ein Sprachmodell, das seine eigene Aktion einschätzt. Das ist probabilistisch, keine beweisbar korrekte Kontrolle.
Ohne beweisbare Kontrolle bleibt nur Human-in-the-loop bei jedem einzelnen Schritt. Das frisst einen Großteil des versprochenen Effizienzgewinns wieder auf.
Ein Sprachmodell, das seine eigene Aktion bewertet, lässt sich durch geschickte Prompt-Formulierung dazu bringen, eine riskante Aktion für sicher zu erklären. Das ist eine dokumentierte Schwäche heuristischer Guardrails, keine Theorie.
AxiomGate sitzt zwischen dem Entscheidungsschritt eines Agenten und der tatsächlichen Ausführung. Kein Framework-Ersatz, sondern eine schlanke Zwischenschicht.
Jeder Agent, unabhängig vom Framework, ruft AxiomGate vor jeder Aktion auf: nahtlos über das Model Context Protocol (MCP) als Gateway, oder direkt über die SDK-Schicht, ohne den Agenten-Code selbst ändern zu müssen.
Ein Z3-Solver prüft die geplante Aktion, inklusive bereits erfolgter Aktionen der Sitzung, formal auf Erfüllbarkeit gegen Ihre definierten Policies.
Der Agent sendet die geplante Aktion als strukturierten Tool-Aufruf (JSON), keine Freitext-Deutung. Diese Fakten wertet der Solver direkt aus, kein Sprachmodell in der kritischen Entscheidungsschleife.
Grenzfälle gehen an einen Menschen. Dessen Freigabeentscheidung ist gleichzeitig das Trainingssignal, das die Policy-Interpretation kontinuierlich verfeinert.
Eine API lässt sich umgehen, sobald jemand sie einfach nicht aufruft. Die folgenden vier Punkte sind bewusst so gebaut, dass genau das nicht folgenlos bleibt.
Die Durchsetzung endet nicht auf API-Ebene. Der Netzwerk-Wächter (axiomgate_guardian) setzt eine Block-Regel im Windows-Kernel-Netzwerkfilter (WFP-Unterbau der Windows-Firewall), nicht nur eine Prüfung in Anwendungscode. Ein Agenten-Prozess ohne lokale Administratorrechte kann diese Sperre nicht selbst aufheben. Ehrlich dazu: mit Administratorrechten ließe sich die Regel ändern, dafür überwacht sich der Wächter selbst und meldet Manipulation als Sicherheitsvorfall.
Jede Policy kann einen harten, kumulativen Grenzwert definieren. Der Solver prüft diesen unabhängig von jeder Eskalations-Freigabe: ein Mensch kann einen Grenzfall freigeben, aber keine per Policy definierte harte Obergrenze aushebeln. Nur eine protokollierte Änderung der Policy selbst kann die Grenze verschieben, nicht ein einzelner Freigabe-Klick. Schutz vor einer Fehlentscheidung im Freigabe-Moment, nicht nur vor dem Agenten.
Ein Solver-Aufruf in der kritischen Ausführungsschleife darf keine spürbare Verzögerung verursachen. Messungen im Realbetrieb zeigen Latenzen von 7 bis 8 Millisekunden pro Solver-Aufruf, weitgehend unabhängig von der Anzahl der Regeln (1 bis 100) und der Größe der Sitzungs-Historie. Für Anwendungsfälle mit einer Sub-Millisekunden-Anforderung noch nicht gesondert geprüft.
Jeder Agent ruft AxiomGate vor jeder Aktion auf: nahtlos über das Model Context Protocol (MCP) als Gateway, oder direkt über die SDK-Schicht (Python, mit LangChain-Anbindung), ohne den Agenten-Code selbst ändern zu müssen. Kein proprietäres Protokoll, das erst gelernt werden muss.
Der Vergleich betrifft die Methode, nicht ein bestimmtes Produkt. Die meisten am Markt verfügbaren Ansätze arbeiten heuristisch, das ist eine bewusste Design-Entscheidung dieser Werkzeuge, kein Zufall.
| Übliche KI-Guardrails | AxiomGate | |
|---|---|---|
| Prüfmethode | Heuristische Einschätzung durch ein Sprachmodell | Formaler Beweis durch einen SMT-Solver (Z3) |
| Umgehbarkeit | Durch geschickte Prompt-Formulierung beeinflussbar | Für bewiesene Grenzen mathematisch ausgeschlossen |
| Nachvollziehbarkeit | Blackbox-Einschätzung, meist ohne Beleg | Nachvollziehbarer Beweis, warum eine Aktion abgelehnt wurde |
| Betriebsort | Überwiegend Cloud-Dienst des Anbieters | Vollständig lokal beim Kunden installiert |
| Framework-Bindung | Häufig an eine einzelne Agenten-Plattform gebunden | Unabhängig vom eingesetzten Agenten-Framework |
| Abdeckung | Verspricht oft pauschale Sicherheit | Deckt bewusst nur den formalisierbaren Teil ab, siehe nächster Abschnitt |
| Egress-Kontrolle | API-Ebene, bei einer Kompromittierung des Hosts leicht zu umgehen | Windows-Kernel-Netzwerkfilter (WFP) per Netzwerk-Wächter, nicht nur Anwendungscode |
Kein einziges dieser Szenarien ist konstruiert, um gut auszusehen. Jedes ist gegen unseren eigenen, getesteten Code geprüft, mit Verweis darauf, was davon Unit-getestet, live geprüft oder eine architektonische Eigenschaft ist.
Ein Werkzeug, das mehr verspricht als es hält, ist am Ende gefährlicher als gar keins. Deshalb wird hier klar benannt, wo die Grenze verläuft.
Der Solver prüft Mengen, Grenzen und Zugriffsrechte formal. Ob ein Text angemessen ist oder eine Entscheidung ethisch vertretbar, bleibt außerhalb dessen, was sich formal beweisen lässt.
Zehn Branchen-Vorlagen (unter anderem Banking, Healthcare, DevOps) liefern fertige, anpassbare Startpunkte, ein Vorschlags- und Simulator-Werkzeug schlägt plausible Grenzwerte aus der eigenen Entscheidungshistorie vor, harte Grenzen lassen sich mit einem weichen Eskalations-Workflow für menschliche Freigaben kombinieren. Ein grafischer Policy-Editor im Dashboard macht die Konfiguration übersichtlich, entbindet aber nicht von der Pflicht, die eigenen Sicherheits-Grenzwerte im Vorfeld sauber zu definieren.
Der Kernel-Netzwerkfilter blockiert einen Agenten-Prozess ohne lokale Administratorrechte zuverlässig. Mit Administratorrechten ließe sich die Firewall-Regel selbst wieder ändern, dann bleibt nur die Selbstüberwachung des Wächters als Alarmsignal, kein Verhindern mehr.
Was passiert, wenn ein Agent kompromittiert wird und versucht, seine eigentliche Aufgabe zu verlassen? Zwei Angriffswege, zwei unterschiedliche Antworten, heute.
Nachtrag, ehrlich: sowohl die Netzwerk-Ziel-Whitelist als auch das lokale Sandboxing waren bis vor Kurzem selbst Lücken in unserer eigenen Policy-Engine, die uns beim Beantworten genau dieser Frage aufgefallen sind. Beide seitdem geschlossen, mit eigenen Tests belegt, nicht nur angekündigt, und im Policy-Editor des Dashboards direkt einstellbar.
Horizontal einsetzbar, unabhängig von der Branche. Priorisiert wird dort, wo die Zahlungsbereitschaft für nachweisbare Kontrollen am höchsten ist.
Für Finanzsektor und KRITIS-Betreiber ist die Herkunft einer Sicherheitsinfrastruktur kein Detail, sondern ein juristisches Risiko-Kriterium. Entwickelt in Deutschland, vollständig isoliert in Ihrem eigenen Netz betrieben: weil AxiomGate keine Cloud-Anbindung und keinen externen Aktivierungsserver hat, entfällt der Mechanismus des US Cloud Act architektonisch, es gibt schlicht keinen Cloud-Anbieter, an den sich eine solche Anfrage richten könnte. Kein Telemetrie-SDK, keine Lizenzserver-Abfrage nach draußen, das haben wir gegen den eigenen Quelltext geprüft, nicht nur behauptet. Das unterstützt die technischen Kontrollanforderungen aus DSGVO, DORA und NIS2, ersetzt aber nicht deren organisatorische Pflichten bei Ihnen im Haus.
Kein nutzungsbasiertes Cloud-Modell. AxiomGate wird als Lizenz für lokal beim Kunden installierte, selbst betriebene Software vertrieben. Die folgende Staffelung ist ein Vorschlag zur Einordnung, die endgültige Bepreisung wird gemeinsam mit den ersten Kunden validiert.
Für erste Agenten-Rollouts und Pilotkunden.
Für Unternehmen mit mehreren produktiven Agenten.
Für Konzerne und regulierte Großunternehmen.
Für die ersten Pilotkunden: gemeinsame Formulierung Ihrer ersten Policies, Integration in Ihr Agenten-Framework und ehrliche Einordnung, was AxiomGate für Ihren Anwendungsfall leisten kann und was nicht.