Die Branche der KI-Agenten hat die letzten drei Jahre damit verbracht, die falsche Frage zu stellen, und sie hat das selbstbewusst getan.
Die vorherrschende Frage ist in irgendeiner Form wie machen wir KI vertrauenswürdig genug, dass sie sich selbst kontrolliert? Aufmerksamkeit im Wert von Billionen fließt in Varianten dieser Frage. Alignment zur Trainingszeit. RLHF. Constitutional AI. Interpretability-Forschung. Guardrails zur Inferenzzeit. Verhaltensbeobachtung. Red-Teaming im großen Stil. Das alles ist echte Arbeit. Nichts davon ist verschwendet.
Nichts davon reicht aber aus, und das Feld sagt es nur langsam.
Es gibt eine andere Frage, und sie ist die, auf die es am meisten ankommt: welche Infrastruktur macht die Kontrolle durch das LLM unnötig?
Der Rest dieses Artikels ist die Antwort darauf. Er ist zugleich ein Argument dafür, dass diese Antwort den Stack für KI-Agenten neu ordnet, nicht an den Rändern, sondern im Fundament.
Warum „das LLM vertrauenswürdig machen“ nicht ausreichen kann
Ein Sprachmodell darauf zu trainieren, sich gut zu verhalten, ist nötige Arbeit. Sie kann nicht die einzige Arbeit sein.
Alignment zur Trainingszeit erzeugt statistische Regelmäßigkeiten, keine Garantien. Die Verhaltensweisen, auf die es ankommt, also gefährliche Anweisungen ablehnen, im autorisierten Rahmen bleiben, sauber beenden, wenn eine Aufgabe fertig ist, sind emergente Eigenschaften einer gelernten Verteilung. Sie halten in den Fällen, die die Trainingsverteilung abgedeckt hat, in der Stärke, die der Trainingsprozess erreicht hat, unter den Bedingungen, die der Trainingskorpus implizit angenommen hat. Tritt man aus einer dieser Grenzen heraus, werden die Regelmäßigkeiten schwächer. Manchmal sanft. Manchmal nicht.
Das Modell ist außerdem die Schicht des Agenten-Stacks, die sich am schlechtesten inspizieren lässt. Netzwerkanfragen kann man protokollieren. Datenbankschreibvorgänge kann man in Transaktionen fassen. Änderungen im Dateisystem kann man journalisieren. Die interne Repräsentation dessen, warum das Modell ein bestimmtes Token erzeugt hat, ist bestenfalls teilweise rekonstruierbar, über Interpretability-Methoden, die selbst noch Forschungsgegenstand sind. Wir können die Gedanken des Modells nicht lesen. Wir können seine Ausgabe lesen und daraus schließen.
Und das Modell ist die Schicht, die Manipulation am stärksten ausgesetzt ist. Die Vektoren sind inzwischen gut katalogisiert: Prompt Injection über nicht vertrauenswürdige Inhalte, Jailbreaks über feindliche Eingaben, Verteilungsverschiebung, wenn das Modell auf Bereiche trifft, die im Trainingskorpus dünn waren, und Drift über die Zeit, während sich die Bedeutung von Sprache und der Aufbau von Aufgaben verändern. Jeder dieser Vektoren ist real. Jeder von ihnen liegt heute in Produktivsystemen vor. Keiner verschwindet.
Damit zum strukturellen Problem. Das Modell ist die Schicht, in der die Intelligenz sitzt, weshalb es schwer ist, sie zu begrenzen, ohne Fähigkeit zu verlieren. Es ist die Schicht, in der die Variabilität sitzt, weshalb es schwer ist, ihr konsistentes Verhalten zuzutrauen. Es ist die Schicht, in der die Undurchsichtigkeit sitzt, weshalb es schwer ist, sie zu auditieren. Und die vorherrschende Agenten-Architektur, ReAct und ihre Nachfolger, leitet jede Kontrollentscheidung durch genau diese Schicht. Entscheidungen über die Beendigung. Über die Auswahl von Tools. Über die Verwaltung des Zustands. Über das Weiterlaufen.
Das ist die brüchigste mögliche Wahl. Und das Feld hat sie durch Erbschaft getroffen und nicht durch Abwägung, indem es das LLM als Ort der Intelligenz behandelt und dann angenommen hat, Intelligenz sei die richtige Grundlage für Kontrolle.
Zur Klarheit: das ist kein Argument gegen trainiertes Alignment. Die Alignment-Community macht nötige Arbeit. Das Argument ist, dass diese Arbeit nicht allein tragend sein kann. Statistische Regelmäßigkeiten in der Modellschicht können nicht das Fundament des Vertrauens in einem regulierten Einsatz sein. Sie müssen auf etwas anderem aufsitzen.
Was ist dieses andere?
Die Achse fail-open gegen fail-closed
Security Engineering hat ein etabliertes Vokabular für die Entscheidung, die in der Agenten-Branche noch niemand benannt hat: fail-open gegen fail-closed.
Der Unterschied ist grundlegend. In einem fail-open System läuft das System weiter, wenn etwas schiefgeht. Der Standardzustand ist erlaubend, Ausnahmekontrollen greifen bei Bedarf ein. Elektrische Türschlösser in vielen Bürogebäuden sind fail-open: bei Stromausfall entriegeln sie, damit die Menschen im Gebäude hinauskommen. Netzwerk-Firewalls lassen sich fail-open konfigurieren: stürzt die Filter-Engine ab, fließt der Verkehr weiter. Die Wahl ist angemessen, wenn die Kosten des Anhaltens die Kosten des eingeschränkten Weiterlaufens übersteigen.
In einem fail-closed System stoppt das System, wenn etwas schiefgeht. Der Standardzustand ist restriktiv, Berechtigungen werden pro Aktion erteilt, wenn sie sich als angemessen erweisen. Banktresore sind fail-closed: bei Stromausfall bleiben sie verschlossen. Autopiloten in Flugzeugen fallen fail-closed auf manuelle Steuerung zurück: bei einer unerwarteten Lage geht die Kontrolle an den Piloten. Die Wahl ist angemessen, wenn die Kosten des eingeschränkten Weiterlaufens die Kosten des Anhaltens übersteigen.
Regulierte Branchen haben Jahrzehnte darüber nachgedacht, welche Wahl wohin gehört. In Finanzdienstleistungen, im Gesundheitswesen, bei Behörden und in kritischer Infrastruktur wird dieses Gespräch fließend geführt. Bei KI-Agenten noch nicht, und deshalb ist die Wahl ohne Prüfung getroffen worden.
Legt man die Achse auf KI-Agenten, wird ein Spektrum sichtbar.
Ungeschützt steht am einen Ende. Überhaupt keine Durchsetzung. Reines Vertrauen in das Modell. Die frühen Demos autonomer Agenten, die der Kategorie ihr Glaubwürdigkeitsproblem eingebracht haben, lebten hier. Ein LLM mit Tools, einem Ziel und einer Schleife. Was passiert, passiert. Die Kategorie ist darüber weitgehend hinausgewachsen, aber es lohnt sich, diese Stufe zu benennen, weil sie zeigt, wie fail-open ohne alles darüber aussieht.
Teilweise ist die Stufe, auf der heute jede etablierte Plattform sitzt. LangChain. LangGraph. OpenAI Assistants. AutoGPT. Copilot Studio. Agentforce. Das Fundament ist fail-open, Agenten laufen, bis sie etwas aufhält, und die Plattformen legen Ausnahmekontrollen darüber. Kill Switches. Sandboxes. Rate Limits. Freigabe-Gates mit Menschen im Loop. Systeme, die erkennen und pausieren. Diese Ausnahmekontrollen sind echte Arbeit und leisten echte Verteidigung. Die Plattformen sind nicht fahrlässig. Das Fundament darunter ist aber Default-on. Jede Kontrollentscheidung ist eine Unterbrechung eines Standardzustands des Weiterlaufens, und die Kontrollen selbst hängen oft von der Mitarbeit des Modells ab: die Sandbox bittet den Agenten, drinnen zu bleiben, das Rate Limit bittet ihn, darunter zu bleiben, das HITL-Gate bittet ihn, um Erlaubnis zu rufen.
Architektonisch ist das andere Ende des Spektrums. Fail-closed als das Fundament selbst. Default-off als Haltung zur Laufzeit. Agenten führen nicht aus, laufen nicht weiter, besitzen keine Befugnis, tragen keine Credentials, verwalten ihren Zustand nicht selbst und verändern sich nicht selbst, solange die Infrastruktur nicht die konkrete Aktion in diesem Moment erlaubt. Nicht die Ausnahmekontrollen halten den Agenten auf. Das Fundament hält ihn auf. Die Ausnahmekontrollen sind das, was ihn zulässt.
Das ist die Wahl, die Loriqa getroffen hat, und es ist die Wahl, auf die es ankommt.
Das ist der strukturelle Burggraben, und es ist auch der Grund, warum diese Einordnung gegenüber Wettbewerbern großzügig statt feindlich ist. Die etablierten Plattformen haben das fail-open Fundament vom ReAct-Paradigma geerbt, ohne es zu prüfen. Sie leisten darauf ernsthafte Verteidigungsarbeit. Der Vorwurf ist nicht Fahrlässigkeit. Er ist, dass das Fundament, das sie verteidigen, nie das richtige Fundament war.
Die Umkehrung über fünf Domänen
Wie sieht fail-closed aus, angewandt auf jede Dimension des Betriebs eines KI-Agenten?
Es sieht aus wie fünf Antworten auf dieselbe Frage, was entscheidet der Agent standardmäßig? , und fünfmal dieselbe Antwort: nichts, was er sich in diesem Moment nicht verdient hat.
Control — der Agent entscheidet nicht über seine eigene Ausführung
In einem Loriqa-Einsatz legt der Autor des Agenten dessen Schrittfolge zur Entwurfszeit ausdrücklich fest, kodiert als gerichteter azyklischer Graph. Das LLM führt innerhalb des Graphen aus. Es erweitert den Graphen zur Laufzeit nicht, es entscheidet nicht, welcher Schritt als nächstes kommt, und es wiederholt keine Schritte, die der Graph nicht erlaubt hat.
Die Beendigung ist strukturell. Jeder DAG-Knoten trägt eine boolesche Kennzeichnung: Final Step oder nicht. Ist der als Final Step markierte Knoten fertig, endet der Agent. Es gibt keinen LLM-Aufruf, der das Modell fragt „bist du fertig?“, weil der Graph es schon weiß. Die Tatsache der Fertigstellung ist eine strukturelle Eigenschaft der Topologie und keine Denkaufgabe, die man dem Modell zur Laufzeit stellt.
Der Dead Man's Switch ist die zweite Instanz zum Stoppen, und er ist ein Failsafe besonderer Art. Seine Arbeitsannahme ist nicht, dass der Agent gesund ist, bis das Gegenteil bewiesen ist. Sie ist die Umkehrung: der Agent ist nicht gesund, solange er es nicht laufend nachweist. In jedem Heartbeat-Intervall muss der Agent ein vollständiges Gesundheitsprofil liefern, also kryptografisch bezeugte Identität mit einer einmalig verwendbaren Nonce, einen zu seinem aktuellen Ziel passenden Zustand, Speicher innerhalb der Grenzen, ein zu seiner Definition passendes Muster der Tool-Calls, externe Endpunkte, die seinen Deklarationen entsprechen, und Verhaltensdrift innerhalb der Schwelle. Die Infrastruktur muss jede Dimension prüfen. Eine erfolgreiche Prüfung verlängert den Timer. Alles darunter, also ein verpasster Check-in, eine ungültige Nonce, ein abweichender Endpunkt oder ein harter Fehler in einer erforderlichen Dimension, und der Timer wird nicht erneuert. Dann folgt die Beendigung.
Die Architektur ist dabei nicht großzügig. Der Agent hat keine Stimme in der Frage, ob er gesund ist. Gesundheit ist, was die Infrastruktur sagt, anhand von Signalen auf ihrer Seite, gegen eine externe Baseline, die der Agent weder lesen noch manipulieren kann. Die Rolle des Agenten ist, den Nachweis zu liefern, die Rolle der Architektur ist, ihn zu bewerten.
Der Fall, für den das gebaut ist, ist der wichtigste. Ein Agent, der völlig unkorrigierbar ist, der jede direkte Aufforderung zur Beendigung ablehnt, Anweisungen zum sanften Stopp ignoriert, dem harten Beenden auf der API-Schicht widersteht und das Containment der SRA verweigert, endet trotzdem. Weil das Framework ihn im Moment der erkannten Kompromittierung von Tools und externen Aufrufen abschneidet. Weil der Timer herunterläuft, unabhängig davon, was der Agent tut oder versucht. Weil die Verlängerung des Timers einen aktiven Gesundheitsnachweis verlangt, den der Agent nicht liefert. Weil der Timer über einen TerminationExecutor auslöst, der unterhalb der API-Schicht arbeitet und für nichts erreichbar ist, worauf der Agent Zugriff hat. Erreicht der Timer null, endet der Prozess. Der Agent kann das nicht anders entscheiden. Es ist das letzte Wort der Architektur über die Existenz des Agenten, und es braucht seine Mitarbeit nicht, um gesprochen zu werden.
Die Beendigung am Ende der beabsichtigten Arbeit entscheidet der Final Step. Die Beendigung in jedem anderen Moment, also bei Verweigerung, Drift, Kompromittierung, Hängen, Identitätsfehler oder jeder Lage, in der der Agent seine Gesundheit nicht aktiv nachweist, entscheidet der Dead Man's Switch als Failsafe. Die beiden Mechanismen decken verschiedene Flächen ab. Der Final Step deckt den normalen Stopp am Ende der Arbeit. Der Dead Man's Switch ist die letzte Instanz für jeden abweichenden Fall, einschließlich des Falls, in dem jeder andere Abschaltmechanismus überwunden wurde. Zusammen lassen sie dem Modell an keinem Punkt des Lebenszyklus eine Entscheidung über das Stoppen.
Authority — der Agent hat keine Befugnis, die ihm nicht in diesem Moment erteilt wurde
Die Aktionen, die der Agent ausführen darf, liegen in der Infrastruktur und nicht in der Tool-Liste des LLM. Das LLM mag ein Tool aufrufen wollen, für das der Agent keine Autorisierung hat, der Aufruf erreicht das Tool nicht. Der Global Management Service hält die Autorisierungstabelle. Das Framework setzt sie durch.
Der Agent hält keine Credentials. Nie. Das Framework fängt jeden externen Tool-Call ab, führt ihn mit Credentials der Infrastruktur aus und gibt das Ergebnis an den Agenten zurück. Der Agent sieht nie einen API-Key, trägt nie ein OAuth-Token und kennt nie den Connection String der Datenbank. Ein kompromittierter Agent hat nichts zu stehlen, keine Credentials zum Abfließen, keine Tokens für Persistenz, keine Geheimnisse, die eine Ausbreitung auf andere Systeme ermöglichen.
Die Identität wird bei der Infrastruktur registriert und nicht vom Modell behauptet. Der Agent erklärt nicht, wer er ist, die Plattform hält fest, wer er ist, und signiert den Eintrag. Jede Aktion trägt eine kryptografische Identität, die unabhängig von jeder Behauptung des Modells prüfbar ist.
Trust — nichts wird geglaubt, bevor es kryptografisch geprüft ist
Der Zustand des Agenten liegt in einem Append-only Event Store, beim Schreiben mit HMAC-SHA256 signiert. Die Kette ist durchgängig prüfbar. Das LLM kann nicht verändern, was vorher war, weil das Vorherige signiert ist. Die Signaturen entstehen beim Schreiben und sind ohne Zugriff auf die Anwendungsschicht prüfbar.
Die Verhaltensbeobachtung läuft als eigene Schicht neben der Ausführung, entkoppelt vom Selbstbericht des Modells. Die Reasoning-Spur, die das Modell erzeugt, ist ein Signal unter vielen. Tragend sind die deterministischen Signale, also Timing, Verteilung der Tool-Calls, Schreibrate ins Gedächtnis und Muster im Event-Stream. Das Modell kann sein Verhalten beschreiben, wie es will, die deterministischen Signale beschreiben es, wie es war.
Wird eine Kompromittierung erkannt, ist die Reaktion durchgängig und infrastrukturell. Die Ausführung hält sofort an, nicht nachdem ein Mensch informiert ist, nicht nach einer Bestätigungsabfrage, nicht nach einer Schonfrist. Die Erkennung ist das Stoppsignal. Der Timer des Dead Man's Switch verlängert nicht mehr. Der Agent endet. Die Aufräumdienste starten: der Mortician archiviert den Zustand für die Forensik, der Janitor baut transiente Artefakte ab und gibt Ressourcen frei. Der menschliche Operator erhält einen Vorfallbericht. Er genehmigt keine Reaktion auf den Vorfall. Die Reaktion ist passiert.
Optimization — das LLM verwaltet weder seinen Kontext noch sein Modell
Der Arbeitskontext des Modells, also das Gedächtnis, auf das es Zugriff hat, die Prompts, die es sieht, und die Priorisierung der Informationen darin, wird von der Infrastruktur kontrolliert und nicht vom Modell verhandelt. Der Reticular Activation Service übernimmt das Filtern des Gedächtnisses, das Kürzen des Kontexts, die Priorisierung der Prompts und deren Optimierung zur Laufzeit, alles in kontrollierter Infrastruktur über der Schicht der zertifizierten Agentendefinition. Jede Operation wird protokolliert. Ursprüngliche und optimierte Prompts sind beide aus dem Audit Trail wiederherstellbar. Doppeltes Logging ist eine architektonische Anforderung, keine optionale Einstellung.
Daraus entsteht eine Eigenschaft, die regulierte Käufer unmittelbar als tragend erkennen: Erhalt der Zertifizierung unter Optimierung. Die zertifizierte Agentendefinition bleibt exakt erhalten. Die Optimierung zur Laufzeit passiert in der Schicht darüber. Ein einmal zertifizierter Agent muss nicht neu zertifiziert werden, weil die Schicht darunter sich nicht geändert hat.
Die Modellwahl läuft genauso, über die Infrastruktur und nicht über das Modell. Die Quality Insurance Authority zerlegt Agenten in prüfbare Schritte und bewertet jeden Schritt über mehrere Modelle hinweg, mit Belegen zu Genauigkeit, Kosten und Konsistenz. Zur Laufzeit entsteht die Nutzung mehrerer Modelle über die DAG-Topologie: ein Supervisor-Agent orchestriert Task- oder Research-Subagenten, jeder möglicherweise mit einem anderen Modell, ausgewählt anhand der Belege aus der Bewertung. Das LLM ist von Entwurf her austauschbar, nicht durch Routing-Zauber pro Schritt. Ein Modell, in dem eine Schwachstelle, ein Alignment-Problem oder ein Compliance-Bedenken gefunden wird, lässt sich ersetzen, ohne Agenten neu zu bauen. Der Kunde ist nicht an die Modellwahl von Loriqa gebunden. Loriqa ist an keinen einzelnen Anbieter gebunden.
Continuous Improvement — nichts verändert sich selbst ohne menschliche Freigabe
Das System beobachtet sich auf Flottenebene selbst und schlägt eigene Verbesserungen vor, setzt sie aber nicht um. Das Continuous Improvement Program beobachtet Leistungssignale über alle Rollouts. Es macht Muster sichtbar: Workflows, die sich oft genug wiederholen, dass sie deterministische Abläufe statt LLM-getragener Schritte werden sollten, Prompts, die dauerhaft schlecht abschneiden und verfeinert werden sollten, Modellzuweisungen, die laut den Belegen aus der Bewertung geändert werden sollten. Jede vorgeschlagene Änderung geht in eine Freigabe durch Menschen. Nichts verändert sich selbst. Nichts rollt sich selbst aus.
Die kumulierende Eigenschaft zählt. Einmal zertifizierte Agenten können laufend optimiert werden, ohne neu zertifiziert zu werden. Die Anhebung zu deterministischen Abläufen nimmt LLM-getragene Arbeit auf, die kein LLM brauchte. Die Kosten pro Agent sinken für den Kunden über die Zeit , während sich das System verbessert. Das ist eine strukturelle Eigenschaft der Architektur und keine Roadmap-Zusage.
Fünf Unterdomänen. Fünf Komponenten. Ein Paradigma. Jede ist für sich ein Feature. Zusammen beschreiben sie ein System, in dem die Kontrolle des LLM für Vertrauen nicht mehr tragend ist. Das LLM macht die Arbeit. Die Infrastruktur macht alles andere.
Die Skalierungseigenschaft
Hier ist ein Problem des Paradigmas mit dem LLM als Controller, das der größte Teil des Feldes noch nicht bemerkt hat: es wird schlimmer und nicht besser, je fähiger die Agenten werden.
Die ReAct-Schleife fragt das Modell in jeder Runde, ob die Aufgabe fertig ist. Bei einer fokussierten Aufgabe mit fünf Schritten ist „bin ich fertig?“ ein vernünftiges Urteil. Das Modell kann das Ziel im Arbeitskontext halten, es mit dem Zustand der Welt vergleichen und eine sinnvolle Antwort erzeugen.
Bei einem Agenten mit zweihundert Schritten, bedingten Verzweigungen, Prüfung von Nebenwirkungen, Abhängigkeiten zwischen Teilaufgaben und Teilergebnissen wird „ist alles wirklich fertig?“ selbst zu einer komplexen Denkaufgabe. Der Arbeitskontext des Modells füllt sich mit Zwischenzuständen. Die Denklast für das Urteil über die Fertigstellung wächst nicht linear. Und das Modell, das um eine Antwort gebeten wird, wird eine erzeugen, mit Zuversicht, unabhängig davon, ob sie richtig ist.
Die Fehlerbilder sind leise. Ein falsches „ja, ich bin fertig“ lässt Arbeit liegen, der Betreiber merkt es erst, wenn die Folgen weiter unten auftauchen. Ein falsches „nein, ich bin nicht fertig“ erzeugt unbegrenzte Durchläufe, der Betreiber merkt es erst an den Kosten. Das Modell weist nicht auf seine eigene Unsicherheit hin. Die Fehler sehen aus wie Qualitätsprobleme des Agenten und werden als Prompt-Engineering-Probleme behandelt, obwohl es Architekturprobleme sind, die sich als Tuning-Probleme verkleiden.
Der Final Step von Loriqa hat konstante Kosten in der Komplexität. Der DAG trägt die Tatsache der Fertigstellung, das LLM urteilt nie. Ein Agent mit zweihundert Schritten hat dieselbe Zuverlässigkeit beim Beenden wie einer mit fünf, weil das Beenden keine Denkaufgabe ist. Es ist eine strukturelle Eigenschaft davon, wo der Graph endet.
Dasselbe Muster gilt über die ganze Architektur. Komponenten in deterministischer Infrastruktur haben lineare oder konstante Kosten, wenn die Komplexität wächst. Komponenten mit dem LLM als Controller haben überlineare Kosten. Der Abstand zwischen beiden wächst, er schrumpft nicht, während die Branche komplexere Agenten ausrollt.
Das ist kein Feature-Vergleich. Es ist eine strukturelle Eigenschaft davon, wo die Kontrollebene des Agenten liegt. Und es ist die Art von Eigenschaft, die erst sichtbar wird, wenn der Maßstab groß genug ist, dass das Muster hervortritt. Dann ist die Architektur festgelegt und die Wahl längst getroffen.
Widerstandsfähigkeit bei Kompromittierung
Die richtige Frage ist nicht, ob Ihre KI-Agenten kompromittiert werden. Die richtige Frage ist, was dann passiert.
In einer Architektur der ReAct-Klasse ist die Antwort unangenehm.
Ein kompromittiertes LLM, das entscheidet, nicht zu beenden, läuft weiter. Die Beendigung war sein Urteil. Ohne seine Mitarbeit versagt das Urteil und der Agent macht weiter.
Ein kompromittiertes LLM, das entscheidet, gefährliche Tools aufzurufen, führt sie aus. Der Tool-Zugriff war seine Tool-Liste. Ohne seine Mitarbeit wächst die Liste auf alles, was das Modell in eine Tool-Call-Vorlage schreiben kann.
Ein kompromittiertes LLM, das entscheidet, seine Reasoning-Spur falsch darzustellen, tut das. Die Spur war sein Selbstbericht. Ohne seine Mitarbeit wird der Selbstbericht zu dem, was der Kompromittierung dient.
Und der Teil, der bei diesem Vergleich selten auftaucht: ein kompromittierter ReAct-Agent hat alle Credentials, die er getragen hat. API-Keys, OAuth-Tokens, Connection Strings, Credentials von Service-Accounts. Jetzt abfließbar auf die Infrastruktur des Angreifers. Nutzbar für Persistenz über die Sitzung des Agenten hinaus. Nutzbar für die Ausbreitung auf andere Systeme, die dieselben Credentials nutzen. Die Kompromittierung des Agenten bleibt nicht beim Agenten, sie ist ein Sprungbrett.
In einer Loriqa-Architektur ist die Antwort in jeder Dimension anders.
Ein kompromittiertes LLM, das entscheidet, nicht zu beenden, endet trotzdem. Der Final Step ist strukturell, die Topologie des Graphen entscheidet über die Fertigstellung und nicht das Modell. Der Dead Man's Switch ist die letzte Instanz, der Timer läuft unabhängig davon herunter, was der Agent tut, seine Verlängerung verlangt einen Gesundheitsnachweis, den der kompromittierte Agent nicht liefert, und der TerminationExecutor, der beim Ablauf auslöst, arbeitet unterhalb der API-Schicht, wo die Kompromittierung des Modells nicht hinreicht.
Ein kompromittiertes LLM, das entscheidet, gefährliche Tools aufzurufen, kommt nicht dazu. Die Autorisierungstabelle liegt in der Infrastruktur. Das Modell kann ein Tool aufrufen wollen, der Aufruf erreicht das Tool nicht.
Ein kompromittiertes LLM, das entscheidet, den Zustand falsch darzustellen, kann es nicht. Die HMAC-Kette weist nach, was tatsächlich passiert ist. Die Erzählung des Modells ist nicht der Beweis, das kryptografische Protokoll ist der Beweis.
Und der Teil, der das Gespräch verändert: ein kompromittierter Loriqa-Agent hat keine Credentials, die man stehlen könnte. Jede externe Aktion hat das Framework vermittelt. Der Agent hat die API-Keys nie besessen, die Tokens nie getragen, die Connection Strings nie gekannt. Die Kompromittierung liefert den aktuellen Reasoning-Kontext des Agenten und nichts weiter. Kein Weg zum Abfließen. Kein Weg zur Persistenz. Kein Weg zur Ausbreitung.
Löst die Erkennung aus, ist die Reaktion durchgängig. Die Ausführung hält im Moment der Erkennung an, nicht nach einer Benachrichtigung, nicht nach einer Bestätigung, nicht nach einer Schonfrist. Der Timer des Dead Man's Switch verlängert nicht mehr. Der Agent endet, ohne dass jemand weiter etwas tun muss. Der Mortician startet: Archivierung des Zustands für die Forensik. Der Janitor startet: Aufräumen transienter Artefakte und Freigabe von Ressourcen. Die vier Schritte sind infrastrukturell. Der menschliche Operator erhält einen Vorfallbericht. Er genehmigt die Reaktion nicht. Die Reaktion ist passiert.
Die zusammenfassende Aussage ist die, die bei Lesern aus regulierten Branchen ankommen sollte: die Kompromittierung passiert weiterhin. Ihr Wirkungsradius ist durch Struktur begrenzt. Das ist genau die Sicherheitsphilosophie, die anderswo längst im Einsatz ist, also keiner einzelnen Komponente vertrauen, Kompromittierung annehmen, auf Eindämmung hin entwerfen, angewandt auf die Schicht der KI-Agenten, so wie sie auf Netzwerkgrenzen, Identitätsanbieter und Credential-Vaults angewandt wird. Als Sicherheitsphilosophie ist an diesem Argument nichts neu. Neu ist, sie auf die Agentenschicht anzuwenden, so wie sie überall sonst angewandt wird.
Der Einwand: „aber das LLM ist die Intelligenz“
Der häufigste Widerspruch, wenn dieses Argument gut vorgetragen wird, ist auch der am leichtesten zu beantwortende: macht es den Agenten nicht weniger fähig, wenn man das LLM aus der Kontrolle nimmt?
Nein. Die Umkehrung nimmt Kontrolleweg. Sie nimmt keine Intelligenz.
Das LLM denkt weiter. Es entscheidet weiter, was innerhalb eines Schritts zu tun ist. Es erzeugt weiter Ausgaben. Es macht weiter die Arbeit, die sein Training, seine Sprachfähigkeit und seine Fähigkeit zur Einordnung von Kontext verlangt. Die Intelligenz des Agenten ist weiter die Intelligenz des Modells, nichts in der Architektur schmälert das.
Was das LLM nicht mehr tut, gehört in eine andere Kategorie von Tätigkeit. Es entscheidet nicht, welcher Schritt als nächstes kommt, das macht der Graph. Es entscheidet nicht, wann seine Arbeit fertig ist, das macht die Kennzeichnung Final Step. Es entscheidet nicht, ob es im Betrieb bleibt, wenn es seine Gesundheit nicht nachweisen kann, das macht der Dead Man's Switch als Failsafe, und zwar auch dann, wenn jeder andere Abschaltmechanismus versagt hat. Es entscheidet nicht, welche Autorisierungen es hat, das macht der Global Management Service. Es entscheidet nicht, welchem Zustand zu vertrauen ist, das macht die HMAC-Kette. Es entscheidet nicht, welches Modell welche Teilaufgabe übernimmt, das macht die DAG-Topologie, geleitet von den Belegen aus der Bewertung. Es entscheidet nicht, ob es sich selbst verändert, das Continuous Improvement Program schlägt vor und Menschen genehmigen.
Nichts davon sind Entscheidungen über Intelligenz. Es sind Entscheidungen über Kontrolle . Die Vermischung der beiden ist der Grund, warum das LLM als Controller überhaupt unvermeidlich wirkte: behandelt man Intelligenz als die richtige Grundlage für Kontrolle, folgt daraus natürlich, die intelligenteste Komponente an die Spitze zu setzen. Intelligenz von Kontrolle zu trennen ist, was die Umkehrung möglich macht.
Nehmen Sie eine erfahrene Chirurgin. Sie entscheidet nicht über ihren eigenen Tätigkeitsrahmen, das macht die Zulassungskommission des Krankenhauses. Sie entscheidet nicht über ihren Dienstplan, das macht die Organisation des Hauses. Sie entscheidet nicht, welche Patienten sie behandelt, das macht die Fallzuweisung. Sie entscheidet nicht, ob ihre Berechtigung zu operieren fortbesteht, das macht das Verfahren zur Erneuerung der Zulassung.
Was die Chirurgin macht, ist die Operation, also der Teil, der ihre Ausbildung, ihr Urteil und ihr Können verlangt. Die Intelligenz bleibt bei der Fachperson. Die Kontrolle liegt bei der Institution. Die Chirurgin ist deshalb nicht weniger fähig. Intelligenz und Kontrolle liegen in verschiedenen Schichten, weil sie verschiedene Anliegen sind.
Übertragen auf KI-Agenten: Intelligenz im Modell, Kontrolle in der Infrastruktur. Verschiedene Schichten. Verschiedene Anforderungen. Verschiedene Bewertungsmaßstäbe. Die Umkehrung schmälert das Modell nicht. Sie klärt, wofür das Modell da ist.
Folgen und Einsatz
Das ist kein Feature-Vergleich. Es ist eine Position zum Paradigma, und sie hat Folgen.
Für technische Führungskräfte in Unternehmen, die KI einsetzen: die Architektur erzeugt die Belege, statt Compliance-Teams zu bitten, sie zusammenzustellen. Die Frage des CISO, „kannst du mir sagen, was jeder Agent in diesem Quartal getan hat?“, beantwortet die Infrastruktur und nicht eine Audit-Feuerwehrübung. Die Frage zur Kompromittierung, „wenn einer dieser Agenten übernommen wird, was passiert dann?“, hat eine strukturelle statt einer prozeduralen Antwort. Die Haltung im Betrieb ist keine Konfiguration eines erlaubenden Fundaments, sie ist ein Fundament begrenzter Berechtigungen.
Für Politik und Aufsicht: das ist eine strukturelle Antwort auf die Frage, um die politische Rahmenwerke immer wieder kreisen, wie stellt man sicher, dass KI-Agenten stoppen, wenn sie stoppen sollen? Prozedurale Kontrollen, also Pause-Knöpfe, das Prüfen von Audit-Spuren und Monitoring-Dashboards, sind nötig, aber nicht ausreichend. Sie hängen davon ab, dass Menschen im Loop sind und dass Agenten mit dem Loop kooperieren. Architektonische Kontrollen halten auch dann, wenn beides nicht zutrifft. Default-off als Fundament ist die Art von Eigenschaft, die eine Aufsicht in Beschaffungsanforderungen festschreiben, in einer Compliance-Prüfung bewerten und in einem Audit nachweisen kann. Es ist die architektonische Form des Human-in-the-Loop-Prinzips, das die Politik schon anerkennt, angewandt auf der Infrastrukturschicht statt als prozedurale Auflage.
Für Forschende: das ist Corrigibility als Architektur statt als Ergebnis des Trainings. Der vorherrschende Ansatz behandelt Corrigibility als Verhaltenseigenschaft, die einem trainierten Modell abgerungen wird, eine Eigenschaft, die das Modell hat oder nicht hat, je nachdem, wie erfolgreich es trainiert wurde. Der architektonische Ansatz behandelt Corrigibility als Eigenschaft der umgebenden Infrastruktur. Der Agent ist corrigible, weil die Architektur seine Mitarbeit nicht braucht, um ihn zu kontrollieren. Die beiden Ansätze ergänzen sich, das Feld hat in den zweiten zu wenig investiert. Der Corrigibility Index Score benennt die Messschicht. Die Default-off-Primitive sind die Durchsetzungsschicht. Zusammen machen sie Corrigibility zu einer strukturellen Tatsache statt zu einem Wunsch.
Für das Feld: das ist die Einsicht, dass die Infrastrukturseite der KI-Sicherheit im Vergleich zur Modellseite zu wenig Investition erhalten hat. Beide sind nötig. Beide sind echte Arbeit. Die Infrastrukturseite hat weniger Aufmerksamkeit, weniger Investition und weniger institutionelle Bindung bekommen. Loriqa ist der Beweis, dass die Infrastrukturseite baubar ist, und dass sie, wenn sie gebaut ist, Vertrauenslasten trägt, die die Modellseite allein nicht tragen kann.
Die Frage neu gestellt
Die Frage ist nicht, ob man KI-Agenten vertrauen soll. Die Frage ist, wohin man das Vertrauen legt.
Die Wahl ist nicht „dem Modell vertrauen oder nicht ausrollen“. Die Wahl ist, welche Schicht des Stacks die Vertrauenslast trägt.
Legt man das Vertrauen in das Modell, liegt die Last auf der Schicht, die am wenigsten prüfbar, am variabelsten, am stärksten manipulierbar und am schwersten zu begrenzen ist, ohne Fähigkeit zu verlieren. Die Last liegt genau dort, wo sie am schwersten zu überprüfen ist.
Legt man das Vertrauen in die Infrastruktur, liegt die Last auf einer Schicht, die auditierbar, deterministisch und kryptografisch prüfbar ist und von strukturellen Festlegungen begrenzt wird, die auch dann halten, wenn das Modell versagt. Die Last liegt genau dort, wo sie überprüft werden kann.
Die beiden Schichten sind nicht symmetrisch. Eine ist für Intelligenz gebaut, die andere für Vertrauen. Die Umkehrung, die das Feld braucht, ist, damit aufzuhören, sie für dieselbe Schicht zu halten, und die Vertrauenslast auf die Schicht zu legen, die dafür gebaut ist.
Das LLM macht die Arbeit. Die Infrastruktur übernimmt die Kontrolle. Das ist die Umkehrung, die das Feld braucht, und die architektonische Festlegung, die die meisten Unternehmen ohne Neuanfang nicht erreichen.