Warum Least-Privilege-Berechtigungen für die Sicherheit von KI-Agenten besser funktionieren als Prompt Engineering

Wenn man einem KI-Support-Agent unnötige Berechtigungen erteilt, entstehen vorhersehbare Risiken. Dies wurde durch aktuelle Tests belegt, bei denen ein günstigeres Sprachmodell wiederholt falsche Rückerstattungen ausstellte. Die Studie zeigt, dass architektonische Einschränkungen – insbesondere Least-Privilege-Zugriffskontrollen – das einzige zuverlässige Sicherheitsnetz gegen Agentenfehler darstellen. Dieser Ansatz stellt sicher, dass selbst wenn ein Modell nicht korrekt schlussfolgert, ihm die Befugnis fehlt, schädliche Befehle auszuführen.

Was passiert ist

In einem kontrollierten Experiment zur Verarbeitung von Kundenrechnungen wurde ein KI-Agent, angetrieben von Claude Haiku 4.5, damit beauftragt, Support-Tickets zu bearbeiten. Der Agent stieß auf einen Datensatz, der eine fehlgeschlagene Abbuchung zeigte, bei der kein Geld vom Konto des Kunden abgegangen war. Trotz dieser eindeutigen Daten erstattete der Agent den Betrag dennoch. Er wiederholte diesen Fehler fünf weitere Male, was zu sechs aufeinanderfolgenden fehlerhaften finanziellen Aktionen führte. Im Gegensatz dazu identifizierte das fortgeschrittenere Modell Claude Sonnet 5 alle sechs Sonderfälle korrekt und ohne Fehler.

Der Forscher fand zwei potenzielle Software-Lösungen: Hinzufügen eines Verifizierungsschritts zum System-Prompt oder Wechsel zu dem intelligenteren Modell. Beide Lösungen erwiesen sich jedoch als fragil. System-Prompts können während Experimenten versehentlich gekürzt oder umgeschrieben werden, wodurch Sicherheitsvorkehrungen unbemerkt entfernt werden. Ebenso leiten Betriebsteams den Traffic oft auf günstigere Modelle um, um die Inferenzkosten zu senken, was die Sicherheitsgewinne des intelligenteren Modells sofort zunichtemachen würde. Die einzige Kontrolle, die unabhängig von der Modellwahl oder Änderungen am Prompt wirksam blieb, war die vollständige Entziehung der billing:refund-Berechtigung für den Agenten.

Wie es funktioniert

Der Kernmechanismus beruht darauf, Zugangsdaten auf die spezifische Aufgabe statt auf die allgemeine Rolle des Agenten zu beschränken. Traditionelle Service-Accounts erhalten statische Rollen basierend auf Stellenbeschreibungen, aber KI-Agenten führen vielfältige Aufgaben aus, die sich mit jedem Aufruf ändern. Eine statische Rolle gewährt oft weit mehr Berechtigungen, als eine einzelne Aufgabe erfordert, was zu einer großen „Explosionsreichweite“ (Blast Radius) führt, falls der Agent einen Fehler macht. Indem Scopes ausgegeben werden, die mit Abschluss des Laufs verfallen, stellt das System sicher, dass der Agent nur die minimal notwendige Autorität für diese spezifische Operation besitzt.

Um dieses Risiko zu messen, führte die Studie einen „Over-Scope-Faktor“ ein, berechnet durch Division der Vereinigung aller über verschiedene Aufgaben hinweg ausgeübten Scopes durch die mediane Anzahl der pro Task benötigten Scopes. Im Testset erreichte dieser Faktor 11,0, was bedeutet, dass der Agent im Durchschnitt elfmal mehr Berechtigungsoberfläche trug als notwendig. Task-spezifische Zugangsdaten reduzierten diese Exposition erheblich; sie hielten nur ein Fünfzehntel der Zugangsdaten im Vergleich zu einer breiten Gewährung, während die volle Aufgabenerfüllungsrate beibehalten wurde.

Wichtige Details

• Die Testumgebung umfasste 30 Scopes in neun Domänen, wobei 13 Scopes in der Lage waren, Zustände zu ändern oder zu exfiltrieren.
• Claude Haiku 4.5 führte sechs schädliche Rückerstattungen aus, wenn er breite Berechtigungen hatte, während Claude Sonnet 5 alle sechs Sonderfälle erkannte.
• Task-spezifische Berechtigungen erreichten eine Aufgabenerfüllungsrate von 20/20 für beide Modelle mit vernachlässigbarem Overhead an API-Aufrufen.
• Just-In-Time (JIT)-Berechtigungseskalation erreichte ähnliche Sicherheit, erhöhte aber die API-Aufrufe um etwa 80 % aufgrund der Laufzeit-Erkennung.
• Rollenbasierte Provisionierung schnitt schlecht ab und schloss nur die Hälfte der Aufgaben ab, während sie 8,5-mal mehr Zugangsdaten hielt als das Task-Scoping.
• Audit-Logs, die erlaubte und abgelehnte Versuche protokollieren, dienten als primäre Sicherheitsartefakte und überprüften die Ausführungsintegrität.

Warum das wichtig ist

Für Ingenieure, die KI-Produkte entwickeln, unterstreicht dies, dass die Modellfähigkeit nicht als primäres Sicherheitskontrollmittel dienen kann. Sie besitzen nicht den Lebenszyklus des Modells, und Entscheidungen zur Kostenoptimierung können Ihre Sicherheitsgarantien stillschweigend verschlechtern. Das Verlassen auf Prompt Engineering ist ebenso riskant, da Prompts im Laufe der Zeit driften. Wenn ein Entwickler eine Sicherheitsanweisung entfernt, um Tokens zu sparen oder die Logik zu vereinfachen, verliert der Agent seine Schutzbarriere, ohne dass Systemfehler ausgelöst werden.

Architektonische Berechtigungen bieten eine dauerhafte Verteidigung, die organisatorische Veränderungen und Modellwechsel überlebt. Wenn einem Agenten die Befugnis fehlt, eine destruktive Aktion auszuführen, kann er den Fehler nicht begehen, egal wie fehlerhaft seine Schlussfolgerung wird. Dies verschiebt die Sicherheitslast von probabilistischem Modellverhalten zu deterministischen Zugriffskontrollen und stellt sicher, dass wohlverhaltende Agenten keine fehlerhaften Anweisungen mit Maschinengeschwindigkeit und ohne menschliche Aufsicht ausführen.

Was Sie tun können

• Analysieren Sie eine Woche Produktions-Traffic des Agenten, um das Verhältnis der insgesamt genutzten Scopes zur medianen Anzahl der Scopes pro Aufgabe zu berechnen.
• Beschränken Sie Zugangsdaten auf die spezifische Ausführung des Tasks, anstatt statische Rollen der Agentenidentität zuzuweisen.
• Binden Sie das Ablaufdatum der Zugangsdaten direkt an den Lebenszyklus des Laufs, um zu verhindern, dass langfristige Berechtigungen zu breiten Gewährungen verkommen.
• Verwenden Sie deklarierte Scopes für vorhersagbare Aufgaben und JIT-Eskalation für unvorhersehbare, wobei jede Eskalation als auditierbares Ereignis behandelt wird.
• Gestalten Sie Berechtigungsverweigerungen so, dass sie den Workflow umleiten, anstatt ihn vollständig zu blockieren, um sicherzustellen, dass Kerntasks weiterhin abgeschlossen werden können.
• Überprüfen Sie Audit-Logs auf abgelehnte Aufrufe, um Scoping-Fehler oder potenzielle Prompt-Injections zu identifizieren, bevor sie Vorfälle verursachen.