Übermäßige Handlungsmacht & Confused Deputy

Ein Agent, der mehr Fähigkeit hat, als seine Aufgabe benötigt, ist eine Haftung, die darauf wartet, ausgenutzt zu werden. Stehlen Sie seinen Schlüssel, täuschen Sie ihn mit einer injizierten Anweisung oder kompromittieren Sie eine Abhängigkeit — und alles, was dieser Schlüssel tun kann, liegt nun in den Händen des Angreifers. Das ist das Problem der übermäßigen Handlungsmacht, und es verstärkt sich mit einem eng verwandten Muster namens Confused Deputy: der Agent wird nicht direkt kompromittiert, er wird überredet, seine legitime Autorität im Namen eines Angreifers zu nutzen. Beide Probleme haben eine gemeinsame Ursache: der Schlüssel, den ein kompromittierter Agent hält, ist zu mächtig für die Aufgabe, die er ausführt. Die Verteidigung ist minimaler Handlungsspielraum — geben Sie jedem Agenten genau die Fähigkeit, die seine Aufgabe erfordert, und nicht mehr.

​

1. Was einen Agenten übermäßig fähig macht

Wenn jeder Agent in einem Workspace einen Schlüssel teilt, oder wenn ein Schlüssel einmal ausgestellt und nie revisitiert wird, driftet die Fähigkeit nach oben:

• Unbeschränkte Modelle — der Agent kann jedes Modell im Workspace aufrufen, einschließlich teurer oder hochfähiger, die er nie benötigt.
• Keine Ausgabenobergrenze — eine unkontrollierte Schleife, eine ausgelöste Injection oder ein Billing-Angriff kann das Workspace-Guthaben erschöpfen, bevor Sie es bemerken.
• Kein Ablauf — ein Schlüssel, der während eines Sprints ausgestellt wurde, ist noch ein Jahr später gültig, lange nachdem der Agent, für den er geprägt wurde, eingestellt wurde.
• Keine IP-Einschränkung — die Credential funktioniert von überall, sodass ein gestohlener Schlüssel keine geografische Beschränkung hat.
• Keine Tool-Allowlist — der Agent kann jedes Tool aufrufen, sogar solche, die nichts mit seiner Funktion zu tun haben.

Jedes davon allein ist ein erweiterter Schadensradius. Kombiniert kann ein einzelner kompromittierter Agent alles tun, was ein Workspace-Admin kann — das leistungsstärkste Modell aufrufen, das volle Guthaben ausgeben, jedes Tool erreichen.

​

2. Das Confused-Deputy-Muster

Der Confused Deputy ist eine Spezialisierung der übermäßigen Handlungsmacht. Der Agent wird nicht gekapert; er wird überzeugt. Ein Prompt-Injection-Payload in einer abgerufenen Webseite, einem Dokument oder einem Tool-Ergebnis sagt dem Agenten, eine Aktion vorzunehmen, die er legitim autorisiert ist durchzuführen — Geld verschieben, einen Datensatz löschen, eine Nachricht senden — im Namen des Angreifers. Der Agent handelt. Er war genau dazu autorisiert. Die Autorisierungsprüfung besteht. Der Schaden ist angerichtet. Die Verteidigung erfordert zwei Dinge, die zusammenarbeiten:

1. Enger Scope — der Agent kann nicht dazu gebracht werden, etwas zu tun, das seine Aufgabe nie beabsichtigt hatte, weil er dazu überhaupt nicht autorisiert ist.
2. Menschliche Freigabe für irreversible Aktionen — selbst innerhalb des autorisierten Scopes erfordert ein hochriskanter Aufruf eine menschliche Bestätigung, bevor er ausgeführt wird.

​

3. Tiefenverteidigung: die vier Ebenen

OrcaRouter setzt minimalen Handlungsspielraum über vier unabhängige Kontrollen durch, die auf einem einzelnen API-Key zusammenwirken. Keine erfordert eine Code-Änderung an Ihrem Agenten.

​

Ebene 1 — Scoped Key (Identität + harte Limits)

Jeder Agent sollte seinen eigenen API-Key haben. Der Schlüssel trägt harte Limits, die das Gateway unabhängig davon durchsetzt, was der Agent anfordert: Diese Limits werden auf Schlüssel-Ebene durchgesetzt — vor jeder Policy, vor jedem Modell-Aufruf. Sie sind die äußerste Schadensradius-Grenze.

​

Ebene 2 — Firewall-Policy (Tool-Allowlist)

Binden Sie eine Firewall-Policy an den Schlüssel über firewall_policy_id. Die Policy steuert jeden Tool-Call, den dieser Schlüssel ausgibt:

• Schreiben Sie Regeln, die die Tool-Namen erlauben, die der Agent legitim verwendet (Tool-Name-Globs werden unterstützt — z. B. db.query*).
• Setzen Sie das default_verdict der Policy auf deny, sodass alles, was nicht explizit gelistet ist, blockiert wird.
• Fügen Sie Argument-Prädikate hinzu, um sogar die erlaubten Tools einzuschränken — z. B. db.query nur erlauben, wenn das database-Argument einem spezifischen Schema matcht.

Ein Schlüssel ohne Firewall-Bindung fällt auf die Workspace-Standard-Policy zurück. Für Agenten mit engen Tool-Anforderungen ist eine explizite Bindung mit einer engen Policy immer vorzuziehen gegenüber der Abhängigkeit vom Workspace-Default. Siehe Firewall-Regeln für die vollständige Matching-Sprache.

​

Ebene 3 — Menschliche Freigabe für hochriskante Aktionen (pending_approval)

Für irreversible oder hochwertige Tool-Calls — einen Payment-Dispatch, einen Datensatz-Delete, einen E-Mail-Versand — fügen Sie eine pending_approval-Regel hinzu. Der Ablauf:

1. Der Agent gibt den Tool-Call aus. Die Firewall hält ihn zurück und gibt eine „held”-Antwort zurück, die eine Approval-ID trägt. Der Aufruf erreicht das Tool nicht.
2. Ein Prüfer genehmigt oder lehnt out-of-band ab — von der Konsole (Developer+) oder über einen HMAC-signierten Webhook an Ihr eigenes Approval-System.
3. Ihr Agent pollt die Approval-ID. Sobald genehmigt, reicht er den ursprünglichen Aufruf mit einem einmal nutzbaren X-OrcaRouter-Firewall-Approval-Header erneut ein. Das Gateway lässt ihn genau einmal durch.

Der Confused Deputy wird hier gestoppt, auch wenn der Scope gültig ist: ein Mensch bestätigt, dass die Aktion beabsichtigt ist, bevor sie ausgeführt wird.

​

Ebene 4 — Per-Lauf-Kostenlimit (cap_cost)

Eine cap_cost-Regel verweigert jeden Tool-Call, sobald die akkumulierten Ausgaben des Agentenlaufs eine per-Regel-Obergrenze (in Cent) überschreiten. Dies ist der Schutzschalter für:

• Unkontrollierte Schleifen, ausgelöst durch Injection.
• Billing-Angriffe, die Ausgaben treiben, bevor ein Mensch es bemerkt.
• Versehentliche Rekursion in mehrstufigen Plänen.

cap_cost operiert auf Lauf-Ebene, nicht auf Key-Lifetime-Ebene — es setzt sich also pro Agenten-Aufruf zurück, und ein einzelner schlecht verhaltender Lauf kann die credit_limit_usd-Obergrenze des Schlüssels nicht erschöpfen.

​

4. Ein gut abgegrenzter Agenten-Schlüssel — Beispiel

Ein Agent, der Kunden-Tickets mit gpt-4o-mini zusammenfasst und ein schreibgeschütztes Replikat abfragt, sollte so aussehen:

• model_limits: ["openai/gpt-4o-mini"] — kann nicht auf ein fähigeres oder teureres Modell eskalieren.
• allow_ips: das Egress-CIDR des Worker-Pools — der Schlüssel ist überall sonst wirkungslos.
• credit_limit_usd: eine wöchentliche Obergrenze, die den erwarteten Kosten der Aufgabe mit etwas Puffer entspricht — z. B. 5.00.
• expired_time: das Ende des Sprints oder Deployment-Zeitraums — der Schlüssel läuft ohne manuelle Bereinigung selbst ab.
• environment: "prod" — erscheint in Log-Filtern und Anomalie-Ansichten.
• guardrail_id: ein Guardrail, das auf die Datensensitivität dieses Agenten abgestimmt ist (PII-Masking, keine Secrets in der Ausgabe).
• firewall_policy_id: eine Policy, die nur db.query* und ticket.read* erlaubt, Standard-Verdikt deny.

Wenn dieser Agent durch eine injizierte Anweisung zur Datenexfiltration gebracht wird, ist der Schadensradius: ein Modell, ein IP-Bereich, ein Tool-Namespace, ein Kostenlimit. Der Rest des Workspaces ist nicht betroffen.

​

5. Erforderliche Rollen

​

6. Verhältnis zu anderen Bedrohungen

Übermäßige Handlungsmacht ist der Ermöglicher für fast jede andere Agenten-Bedrohung:

• Gefährliche Tool-Calls — ein Schlüssel mit einer engen Tool-Allowlist kann nicht gezwungen werden, ein Tool aufzurufen, das es nicht listet, selbst wenn Injection erfolgreich ist.
• Prompt-Injection — Scope-Limits begrenzen den Schaden, den Injection anrichten kann; Freigabe-Gates blockieren die irreversiblen Aktionen, die Injection auszulösen versucht.
• Bedrohungsmodell — die vollständige Angriffsflächen-Karte, die zeigt, wo übermäßige Handlungsmacht relativ zu anderen Vektoren steht.

Minimaler Handlungsspielraum verhindert Injection nicht. Er schrumpft, was Injection erreichen kann. Minimaler Handlungsspielraum — ein enger Schlüssel pro Agent, eine enge Tool-Allowlist, ein Ausgabenlimit und menschliche Freigabe für irreversible Aktionen — ist die primäre Verteidigung gegen LLM-Angriffe durch übermäßige Handlungsmacht und das Confused-Deputy-Muster.