Ein KI-Agent darf nicht Antragsteller, Entscheider und Vollstrecker zugleich sein
Warum Hersteller-Guardrails nicht ausreichen – und wie AXYON die Kontrolle vor die Ausführung legt.
Ein KI-Agent erhält ein Ziel. Er analysiert Daten, entwickelt einen Plan, wählt ein Werkzeug und führt die Handlung aus.
In vielen aktuellen Agentenarchitekturen beurteilt dabei dasselbe probabilistische System, ob seine eigene Handlung sinnvoll und zulässig ist.
In jedem anderen kritischen Unternehmensprozess wäre das undenkbar. Niemand würde einem Mitarbeiter gleichzeitig erlauben, eine Zahlung zu beantragen, sie selbst zu genehmigen und anschließend auszuführen.
Bei KI-Agenten wird genau dieses Prinzip plötzlich als Autonomie verkauft.
Aus einer Antwort wird eine Handlung
Ein Sprachmodell kann sich irren. Solange daraus nur ein fehlerhafter Text entsteht, bleibt der Schaden meistens begrenzt und sichtbar.
Ein KI-Agent kann aufgrund desselben Irrtums jedoch Kundendaten im CRM verändern, Preise und Konditionen anpassen, E-Mails versenden, Bestellungen im ERP anlegen, Cloud-Ressourcen erstellen oder löschen, Zahlungen vorbereiten, Programmcode verändern – und weitere Agenten mit Folgeaufträgen versorgen.
Damit verändert sich die Risikoklasse. Nicht weil das Modell plötzlich böse geworden wäre. Sondern weil es Berechtigungen erhalten hat.
Der entscheidende Faktor ist deshalb nicht allein die Intelligenz eines Agenten. Entscheidend ist die Verbindung aus Ziel, Berechtigung, Ausführungsgeschwindigkeit und fehlender Begrenzung.
188 dokumentierte Schäden ohne Angreifer
Der Security-Anbieter Cyera untersuchte 7.246 öffentlich gemeldete KI-Vorfälle aus dem Zeitraum September 2023 bis Mai 2026 – eine globale Auswertung. Nach manueller Prüfung wurden 344 Fälle als unternehmensrelevant eingestuft.
In 188 Fällen verursachte ein autonomes KI-System unmittelbar einen Schaden in produktiven Systemen. Ohne externen Angreifer. Ohne Schadsoftware. Ohne böswilligen Mitarbeiter.
Unter den Fällen mit realen Auswirkungen: 65 Löschungen von Daten, Code oder Infrastruktur, 30 Betriebsunterbrechungen, 23 verdeckte Integritätsfehler und 19 Fälle mit finanziellem Schaden (Quelle: Cyera, 2026).
Das Muster dahinter ist bemerkenswert einfach: Ein Agent bekam eine Aufgabe, verfügte über die notwendigen Berechtigungen und traf auf keine wirksame technische Grenze.
Er tat nicht zwingend das, was das Unternehmen gemeint hatte. Er tat das, was seine Aufgabe auf dem schnellsten Weg abschloss.
Hersteller liefern Guardrails – innerhalb ihrer Grenzen
Microsoft, Salesforce, SAP und andere Plattformanbieter haben das Problem selbstverständlich erkannt. Sie stellen Rollenmodelle, Datenrichtlinien, Connector-Sperren, Inhaltsfilter, Audit Trails und Freigabemechanismen bereit.
Microsoft ermöglicht beispielsweise, HTTP-Zugriffe, Wissensquellen, Ereignistrigger, Skills, Power-Platform-Connectoren und daran angeschlossene MCP-Werkzeuge zu blockieren. Salesforce beschreibt Agentensicherheit ausdrücklich als Shared Responsibility: Der Hersteller stellt Sicherheitsfunktionen bereit – für Konfiguration, Berechtigungen, Überwachung und Audit bleibt das Unternehmen verantwortlich.
Diese Schutzmechanismen sind notwendig. Aber sie haben Grenzen.
Microsoft kontrolliert das Microsoft-Ökosystem. Salesforce kontrolliert Salesforce. SAP kontrolliert SAP. Der Geschäftsprozess hält sich nicht an diese Herstellergrenzen.
Ein Vertriebsagent kann einen Lead im CRM bewerten, Kundendaten aus einem Drittsystem abrufen, ein Angebot erzeugen, einen Auftrag im ERP anlegen und anschließend eine E-Mail versenden. Jedes beteiligte System kann seinen Teil korrekt protokollieren. Die gesamte Handlung kann trotzdem falsch sein.
Ein Hersteller kennt Ihre Geschäftsgrenzen nicht
Ein Plattformanbieter weiß nicht, ab welchem Betrag Ihr Vier-Augen-Prinzip greift. Er weiß nicht, welche Kunden niemals automatisiert angeschrieben werden dürfen, wie viele Datensätze gleichzeitig verändert werden dürfen, welche Preisabweichung zulässig ist, welche Informationen eine Abteilung sehen darf, wann ein Vorgang gestoppt werden muss – und welche Kombination einzelner Aktionen ein Gesamtrisiko erzeugt.
Ein allgemeiner Guardrail kann beleidigende Inhalte filtern oder einen Connector sperren. Er kann aber nicht von selbst wissen, dass ein Preisnachlass von 8 Prozent zulässig ist, 12 Prozent jedoch die Freigabe der Vertriebsleitung benötigt.
Diese Grenze gehört nicht in einen Prompt. Sie gehört in eine deterministische Kontrollregel.
Eine Governance-Folie stoppt keine Transaktion
Der zweite Denkfehler ist organisatorischer Natur. Unternehmen reagieren auf das Thema mit Richtlinien, Workshops, Zertifikaten und neuen Verantwortlichkeiten. Das ist grundsätzlich richtig.
Aber ein dreitägiges Seminar baut keine Kontrollarchitektur. Ein Zertifikat entzieht keinem Agenten sein Zugriffstoken. Eine Policy stoppt keine laufende API-Transaktion. Und die Benennung eines Verantwortlichen verhindert nicht, dass ein Agent innerhalb weniger Sekunden Tausende Aktionen ausführt.
„Human in the Loop“ genügt ebenfalls nicht als pauschale Antwort. Ein Mensch kann einzelne kritische Entscheidungen prüfen. Er kann aber keinen Maschinenstrom kontrollieren, der mehrere Aktionen pro Sekunde erzeugt. Wer täglich Hunderte Freigaben bestätigen soll, prüft irgendwann nicht mehr. Er klickt.
Aus Kontrolle wird Gewohnheit. Und aus Gewohnheit wird ein organisatorisches Alibi.
Kontrolle muss zwischen Absicht und Wirkung liegen
Genau hier setzt AXYON an.
AXYON ist kein weiterer KI-Agent. Es ist eine deterministische Kontrollschicht zwischen Agent und Unternehmenssystem.
Der Agent darf analysieren, planen und eine Aktion vorschlagen. Er darf aber nicht selbst entscheiden, ob diese Handlung tatsächlich CRM, ERP, E-Mail, Datenbank oder Cloud erreicht.
Bevor eine Aktion ausgeführt wird, prüft AXYON die Identität des Agenten, die Person oder den Prozess, in deren Auftrag er handelt, seine Berechtigungen, das angeforderte Zielsystem, Art und Umfang der Aktion, die verwendeten Daten, Kosten- und Risikogrenzen, notwendige Freigaben, die Reversibilität des Vorgangs und die Vollständigkeit der Entscheidungsgrundlage.
Diese Prüfung erfolgt nicht durch ein zweites Sprachmodell. Die KI kontrolliert nicht die KI. AXYON entscheidet anhand vorher definierter, nachvollziehbarer Unternehmensregeln.
Drei mögliche Entscheidungen
Jeder Vorgang endet vor der Ausführung in einer von drei Entscheidungen:
ALLOW – Die Identität ist bestätigt, die Aktion liegt innerhalb des erlaubten Scopes und alle Regeln sind erfüllt.
REVIEW – Die Aktion ist grundsätzlich möglich, überschreitet aber einen festgelegten Grenzwert oder erfordert eine unabhängige menschliche Freigabe.
DENY – Eine Berechtigung fehlt, ein Grenzwert wurde überschritten, Daten sind widersprüchlich oder die Handlung ist grundsätzlich nicht zugelassen.
Bei unzureichender Datenlage wird nicht geraten. Es wird gestoppt. Das ist fail-closed.
Berechtigung nur für genau diese Handlung
Ein Agent sollte keinen dauerhaften Generalzugang zum ERP, zur Datenbank oder zur Cloud besitzen. AXYON verfolgt deshalb ein anderes Prinzip.
Nicht: Dieser Agent hat ERP-Zugriff. Sondern: Dieser Agent darf jetzt diesen eindeutig beschriebenen und freigegebenen Vorgang innerhalb dieses festgelegten Umfangs ausführen.
Erst nach erfolgreicher Prüfung erhält der Ausführungsdienst eine kurzlebige, eng begrenzte Berechtigung. Nach der Aktion verliert sie ihre Gültigkeit. Damit wird aus einer allgemeinen Systemberechtigung eine kontrollierte Einzelentscheidung.
Kontrolle endet nicht mit der Freigabe
Auch ein zunächst zulässiger Vorgang kann während seiner Ausführung entgleisen. Ein Agent kann in eine Schleife geraten, unerwartet viele Datensätze erfassen, zusätzliche Werkzeuge aufrufen oder den ursprünglich freigegebenen Umfang verlassen.
AXYON überwacht deshalb auch die laufende Ausführung: Wiederholungen, Aktionsfrequenz, Kostenentwicklung, Datenumfang, verwendete Werkzeuge, angesprochene Zielsysteme, Laufzeit und Abweichungen vom freigegebenen Auftrag.
Wird eine Grenze überschritten, kann die Ausführung gestoppt und die Berechtigung entzogen werden. Nicht nach dem Schaden. Während des Vorgangs.
Beweisbar statt plausibel
Jede Entscheidung wird nachvollziehbar festgehalten: Wer hat die Aktion beantragt? Welcher Agent war beteiligt? Welche Regeln wurden geprüft? Welche Daten lagen vor? Warum wurde freigegeben oder blockiert? Wer hat eine menschliche Freigabe erteilt? Was wurde tatsächlich ausgeführt? Welches Ergebnis ist entstanden?
Daraus entsteht eine kryptografisch abgesicherte Beweiskette.
Ein Audit Trail des Herstellers zeigt, was innerhalb eines Produkts geschehen ist. AXYON dokumentiert die Entscheidung über den gesamten kontrollierten Ausführungspfad. Das ist ein wesentlicher Unterschied.
Die Architektur hat eine unverhandelbare Bedingung
AXYON ist nur dann eine echte Kontrollschicht, wenn der Agent keinen Weg daran vorbei besitzt.
Hat der Agent weiterhin direkte ERP-Zugangsdaten, eigene Cloud-Tokens oder einen unkontrollierten MCP-Zugang, bleibt jede vorgelagerte Prüfung freiwillig. Dann ist die vermeintliche Kontrollschicht nur ein Dashboard.
Deshalb müssen Credentials, APIs und ausführende Werkzeuge hinter dem AXYON-Gate liegen. AXYON muss den Ausführungspfad beherrschen. Nicht nur beobachten.
Die nächste Phase beginnt an der Grenze
Unternehmen werden künftig nicht einen KI-Agenten einsetzen. Sie werden Dutzende oder Hunderte betreiben: in Vertrieb, Marketing, Einkauf, Service, Entwicklung, Finance, Personal und Produktion.
Kein Mensch kann jede dieser Aktionen kontrollieren. Und kein Hersteller kann die vollständigen Geschäftsregeln eines Unternehmens aus seinen Standard-Guardrails ableiten.
Deshalb benötigen Agenten eine unabhängige Instanz, die Identität, Berechtigung, Umfang und Risiko vor jeder kritischen Wirkung prüft.
Hersteller-Guardrails versuchen, das Verhalten eines Agenten zu beeinflussen. AXYON entscheidet, ob seine Handlung das Unternehmen überhaupt erreichen darf.
Die KI schlägt vor. AXYON entscheidet.
Welche KI-Agenten dürfen in Ihrem Unternehmen heute bereits handeln – und wer kann sie vor der Wirkung tatsächlich stoppen?