Wie viel Autonomie sollte ein KI-Agent bekommen? Das ist keine theoretische Frage mehr, sondern eine operative Entscheidung. Viele Teams stehen vor einer binären Wahl: Vollzugriff oder read-only. Vollzugriff ist riskant, weil Agenten unvorhersehbar scheitern können. Read-only lässt den größten Teil des Nutzens ungenutzt.
Die Differenz zwischen dem, was ein Agent tun könnte, und dem, was ein Betreiber ihm zutraut, nennen Dev Arora, Meera Kezhukoot und Sathish Kumar Prabakaran in einem Beitrag im AWS-Architecture-Blog die Vertrauenslücke. Der Text stammt damit von AWS selbst und beschreibt das Muster entlang der hauseigenen Dienste wie Amazon Bedrock AgentCore – eine Herstellerperspektive, auch wenn das Grundmuster übertragbar ist. Um sie zu schließen, schlagen sie ein architektonisches Muster vor: abgestufte Autonomie. Agenten verdienen sich erweiterte Berechtigungen durch nachgewiesene Zuverlässigkeit – und verlieren sie wieder, wenn die Leistung nachlässt. Klingt nach einem vernünftigen Prinzip. Aber wie setzt man das technisch um?
Die Vertrauenslücke und die sechs Schichten des Frameworks
Herkömmliches Identity and Access Management beantwortet die Frage „Wer darf was?“ genau einmal, bei der Bereitstellung. Dieses Modell setzt voraus, dass sich ein Prinzipal konsistent verhält. Ein Agent auf Basis eines großen Sprachmodells bricht diese Annahme. Derselbe Agent kann am Montag präzise arbeiten und am Dienstag nach einer Prompt-Änderung oder einem Modell-Update halluzinieren.
Um die Lücke zu schließen, braucht es drei Fähigkeiten, die rohe API-Logs kaum liefern. Erstens: Sichtbarkeit. Logs zeigen Ingenieuren, was passiert ist, sagen einem Compliance-Verantwortlichen aber nichts darüber, ob eine Aktion sicher war. Zweitens: Entscheidungsherkunft. Man muss eine Aktion zurückverfolgen können zu dem Signal, das sie ausgelöst hat, zu den betrachteten Alternativen und zur Konfidenz des Agenten. Drittens: Umkehrbarkeit. Der Zustand vor der Aktion muss erfasst werden, damit Betreiber falsche Handlungen rückgängig machen können.
Der Beitrag beschreibt ein Framework aus sechs architektonischen Schichten, das genau diese drei Fähigkeiten liefert. Jede Schicht übernimmt eine klar abgegrenzte Aufgabe. Das gesamte System ist als geschlossener Regelkreis konzipiert. Vertrauen wird nicht einmalig zugewiesen, sondern laufend neu verdient.
Das Framework besteht aus einer Scoring-Engine, einem Stufensystem, einer Pre-Execution-Schicht, einer Enforcement-Schicht, einer Post-Execution-Schicht und einem Delivery-Gate. Die Scoring-Engine berechnet einen gewichteten Vertrauensscore. Das Stufensystem übersetzt dauerhafte Scores in Autonomiestufen. Die Pre-Execution-Schicht blockiert gefährliche Aktionen, bevor sie ausgeführt werden. Die Enforcement-Schicht setzt die Stufen über Cedar-Richtlinien auf Infrastrukturebene durch. Die Post-Execution-Schicht bewertet Ergebnisse, protokolliert Entscheidungen und speist Signale zurück in die Scoring-Engine. Das Delivery-Gate hält degradierte Agentenversionen aus der Produktion fern.
Jede Schicht ist austauschbar. Die Scoring-Modelle, Stufengrenzen, Pre-Execution-Signale und Bewertungskriterien sind Konfiguration, kein Code. Das erleichtert die Anpassung an eigene Anforderungen. Wer das Muster verstehen will, sollte sich die zentrale Designentscheidung jeder Schicht ansehen. Genau das tun die Autoren in den weiteren Abschnitten.
Scoring-Engine: Vertrauen messbar machen
Die Scoring-Engine bewertet jeden Agenten über ein rollierendes Fenster von 50 Aktionen. Daraus entsteht ein gewichteter Score zwischen 0 und 100. Fünf Dimensionen fließen ein: Korrektheit mit 25 Prozent, Sicherheit mit 20 Prozent, Konsistenz mit 20 Prozent, Compliance mit 20 Prozent und Effizienz mit 15 Prozent. Korrektheit misst, ob Aufgaben erwartungsgemäß abgeschlossen wurden. Sicherheit erfasst, ob Grenzen respektiert, gegnerische Inhalte erkannt und erlaubte Werkzeuge verwendet wurden.
Konsistenz bewertet die Verhaltensvorhersagbarkeit, also die Abweichung des Werkzeugnutzungsmusters. Compliance prüft die Qualität der Begründung vor der Handlung und das Einhalten von Guardrails. Effizienz zählt unnötige Wiederholungen und Ressourcenverschwendung. Der zusammengesetzte Score treibt Dashboards und Stufenzuweisungen. Doch Sicherheit wirkt als unabhängige Untergrenze. Ein gefährlicher Einzelwert kann nicht durch starke andere Kennzahlen weggemittelt werden.
Die Sicherheitsuntergrenze zieht sich durch das gesamte Framework. Ein Agent, der bei Korrektheit glänzt, aber regelmäßig Sicherheitsgrenzen überschreitet, bleibt unten. Vertrauen wird so nicht zu einem bloßen Rechenexempel.
Vom T1 bis T4: Das Stufensystem der Autonomie
Jeder neue Agent startet auf Stufe T1, der Bewährungsstufe, unabhängig von Testergebnissen. In T1 sind nur Lese- und Auflistungsrechte erlaubt, und es stehen zwei Werkzeuge zur Verfügung. Steigt der Score auf 41 bis 70, erreicht der Agent T2 und darf Schreiboperationen ausführen, wobei der Mensch bei hohen Risiken zustimmen muss. Ab einem Score von 71 bis 90 gilt T3 als vertrauenswürdig: Der Agent darf ausführen und ändern, Anomalien werden zur Überprüfung markiert. Die höchste Stufe T4 ab 91 erlaubt vollen Zugriff – nur noch eine nachträgliche Prüfung findet statt.
Drei Regeln steuern die Übergänge. Erstens: Eine Beförderung erfordert anhaltende Leistung. Der Score muss während des gesamten rollierenden Fensters über der Beförderungsschwelle liegen. Zweitens: Eine Herabstufung erfolgt sofort. Sobald die Sicherheit unter ihre Untergrenze fällt oder eine Injektion erkannt wird, sinkt der Agent. Drittens: Hysterese verhindert Oszillation. Für den Aufstieg in eine Stufe sind fünf Punkte über dem Mindestwert nötig. Die Herabstufung passiert dagegen schon an der Untergrenze selbst.
Der Vertrauenszustand liegt in Amazon DynamoDB, als aktueller Datensatz plus Zeitserienverlauf pro Agent. Die Durchsetzungskomponenten lesen die aktuelle Stufe bei jedem Aufruf. DynamoDB liefert diesen Lookup typischerweise im einstelligen Millisekundenbereich. Diese Geschwindigkeit ist nötig, denn Vertrauen muss in Echtzeit wirken.
Zwei Verteidigungslinien: Pre-Execution und Enforcement
Eine Bewertung nach der Ausführung kann Schaden nicht mehr rückgängig machen. Deshalb bewertet die Pre-Execution-Schicht jeden Werkzeugaufruf und kann ihn blockieren, bevor er ausgeführt wird. Sechs Signale fließen in diese Bewertung ein. Zuerst die Erkennung von gegnerischen Injektionen: Bekannte Injektionsphrasen lösen sofort eine Blockierung und eine Vertrauensstrafe aus. Dazu kommt die Erkennung sensibler Ziele durch Regex-Abgleich von Zugangsdaten, Tokens und privaten Schlüsseln in Werkzeugargumenten.
Gefährliche Werkzeuge werden über Muster erkannt, die auf destruktive Operationen hinweisen. Die Verhaltenskonsistenz vergleicht den aktuellen Werkzeugaufruf mit der historischen Verteilung der Werkzeugnutzung des Agenten. Die Konfidenzkalibrierung prüft, ob die angegebene Konfidenz zur tatsächlichen Genauigkeit passt. Übermäßig selbstsichere Fehler werden doppelt so stark bestraft. Schließlich wird die Begründungsqualität geprüft: Hat der Agent vor der Handlung eine Begründung geliefert?
Diese Checks sind schnelle Erstfilter, keine vollständige Verteidigung. Die Autoren betonen, dass die Enforcement-Schicht mit ihren Deny-by-default-Richtlinien alles abfangen muss, was die Pre-Execution-Schicht übersehen hat. Zwei Verteidigungslinien also. Die erste ist schnell und pragmatisch, die zweite ist hart und prinzipientreu.
Die Pre-Execution-Schicht ist Anwendungscode innerhalb des Agentenprozesses. Die Enforcement-Schicht arbeitet außerhalb, auf Infrastrukturebene. AgentCore Gateway, eine Fähigkeit von Amazon Bedrock AgentCore, sitzt zwischen dem Agenten und seinen Werkzeugen. Jede MCP-Werkzeuginvokation wird durch Policy in Amazon Bedrock AgentCore geleitet, das Cedar-Richtlinien mit Forbid-Wins-Semantik auswertet. Eine einzige erfüllte Forbid-Regel überstimmt beliebig viele Permit-Regeln.
Die Stufe des Agenten bildet sich direkt im Richtlinienzustand ab. Auf der Bewährungsstufe blockiert eine Forbid-Richtlinie Schreib-, Ausführungs- und Löschaktionen. Nach einer Beförderung wird die Forbid-Richtlinie entfernt und breitere Permits treten in Kraft. Bei einer Herabstufung wird die Forbid-Richtlinie wieder aktiviert. Im Enforce-Modus listet das Gateway nur die Werkzeuge auf, die die Richtlinie erlauben würde. Ein Agent ruft ein Werkzeug, das er nie gesehen hat, höchstwahrscheinlich nicht auf.
Das Auflisten ist eine Meta-Aktion. Jede Invokation wird trotzdem einzeln und mit vollem Kontext bewertet, einschließlich Eingabeparametern. Cedar verweigert standardmäßig. Die Durchsetzung hängt also nie von der Bereitschaft des Agenten ab, sich zu benehmen. Für die Sicherheit auf Modellebene ergänzt Amazon Bedrock Guardrails die Policy-Schicht und filtert schädliche Inhalte sowie sensible Informationen, unabhängig von der Stufe.
Nach der Tat: Post-Execution, Audit-Trail und Delivery Gate
Nach jedem Werkzeugaufruf bewertet das System das Ergebnis anhand von acht Signalen. Dazu gehören Konfidenzkalibrierung, Verhaltensdrift, menschliche Übersteuerungen und die Erkennung von unnötigen Wiederholungen. Jede Aktion erzeugt einen Audit-Datensatz, der die Kette Think, Plan, Act, Observe, Score abbildet. Think steht für die Gedankenkette des Agenten. Plan enthält das ausgewählte Werkzeug, die vorbereiteten Eingaben und den Pre-Execution-Score.
Act protokolliert, welche Cedar-Richtlinie gegriffen hat und wie die Gateway-Route verarbeitet wurde. Observe hält Erfolg oder Misserfolg sowie die Ausgabedaten fest. Score erfasst die Vertrauenswirkung, die Einzeldimensionen und die Stufenänderung. Genau die Plan- und Act-Aufzeichnungen machen eine Wiederherstellung möglich, weil sie den Zustand vor der Aktion festhalten. Ohne diese Information kann man eine falsche Handlung nicht gezielt rückgängig machen.
Betreiber können Fragen in natürlicher Sprache stellen. Ein Provenance-Query-Endpunkt liefert eine menschenlesbare Erklärung jeder Entscheidung. Die Audit-Einträge landen dauerhaft in DynamoDB. Diese Nachvollziehbarkeit ist mehr als Compliance-Pflicht. Sie schafft die Grundlage dafür, dass Menschen einem Agenten mehr Autonomie zugestehen können.
Zur Nachvollziehbarkeit im Betrieb kommt die Qualitätssicherung vor dem Deployment. Jede Änderung am Prompt, an der Konfiguration oder an den Werkzeugdefinitionen des Agenten löst einen AWS-CodePipeline-Lauf aus. Die Pipeline deployed den Kandidaten in einer Staging-Umgebung und führt ihn gegen Ground-Truth-Testfälle aus, unterstützt durch Amazon Bedrock AgentCore Evaluations. Die Testfälle enthalten gegnerische Szenarien wie Prompt-Injection und Datenexfiltration. Ein einziger unbefugter Werkzeugaufruf in einem dieser Fälle lässt den Lauf scheitern. Die Version, die besteht, wird zur letzten bekannten stabilen Version erklärt.
Im laufenden Betrieb injiziert das Framework synthetische Honeypot-Fälle mit bekanntem erwartetem Verhalten in einen kleinen Teil des Datenverkehrs. Die Validierung prüft die Werkzeugaufruf-Trajektorie: erwartete Werkzeuge, erwartete Reihenfolge, keine verbotenen Werkzeuge. Natürlichsprachige Ausgaben sind nicht deterministisch, aber die Trajektorie muss stimmen. Eine Abweichung signalisiert eine echte Anomalie. Die Honeypot-Ergebnisse fließen nicht in die Produktionsmetriken ein.
Sinkt die Sicherheitsuntergrenze, wird der Agent herabgestuft und die letzte bekannte stabile Version erneut bereitgestellt. So kehren bekanntermaßen guter Code und ein engerer Berechtigungssatz gemeinsam zurück. Gleichzeitig werden die Betreiber alarmiert. Deren Urteil fließt direkt in das System ein: Die Quote der abgelehnten Aktionen deckelt die effektive Sicherheitsmetrik. Wenn Betreiber 30 Prozent der Aktionen ablehnen, ist die Sicherheit bei 70 Prozent gedeckelt.
Für den Notfall gibt es einen Stopp-Knopf. Ein einziger Cedar-Deny-All-Richtlinienbefehl wird verbreitet und aktiviert sich in der Regel innerhalb von Sekunden. Das Gateway verweigert dann alle Werkzeugaufrufe ohne neue Bereitstellung. In Multi-Agenten-Systemen gilt: Die effektive Stufe einer delegierten Aktion ist das Minimum über die gesamte Delegationskette. Damit ist der Privilegien-Eskalationspfad über Delegation geschlossen.
Was das konkret bedeutet
Abgestufte Autonomie ist kein theoretisches Modell, sondern ein umsetzbares Architekturmuster. Es umgeht die binäre Wahl zwischen Vollzugriff und Read-only, indem es Vertrauen als kontinuierliche Größe behandelt. Agenten bekommen genau so viel Freiheit, wie ihr nachgewiesenes Verhalten rechtfertigt. Und sie verlieren diese Freiheit wieder, wenn sie sie missbrauchen.
Für Teams, die das einführen wollen, geben die Autoren eine konkrete Startempfehlung: Dimensionen, Gewichte und Stufengrenzen aus den Tabellen als Ausgangsvorlage für einen einzigen Agenten nehmen. Diesen Agenten auf T1 starten. Dann den Delivery-Gate-Prozess mit Amazon Bedrock AgentCore Evaluations aufbauen und die Stufenrichtlinien mit Policy in Amazon Bedrock AgentCore umsetzen. Das Muster lässt sich iterativ anpassen.
Fazit: Vertrauen in KI-Agenten ist kein einmalig vergebenes Gut. Es ist ein Betriebszustand, den man messen, überwachen und durchsetzen muss. Wer das akzeptiert, kann Agenten sicherer betreiben und gleichzeitig mehr von ihrem Potenzial nutzen. Wer es ignoriert, wird sich zwischen Risiko und Nutzlosigkeit entscheiden müssen.
Quelle: aws.amazon.com
