Zum Hauptinhalt springen
Die sicherste Haltung für einen autonomen Agenten ist Default-Deny: standardmäßig jedes Tool blockieren, dann explizit nur die Handvoll erlauben, die Ihr Agent verwenden soll. Alles Neue, das ein Agent aufnimmt — ein Community-Skill, ein fehlkonfigurierter MCP-Server, ein Tool, zu dem ein Jailbreak das Modell überredet hat — wird abgelehnt, weil Sie es nie hinein geoptet haben, nicht, weil Sie daran gedacht haben, es zu blockieren. Diese Seite ist das Tool-Allow-Listing-für-Agenten-Muster auf api.orcarouter.ai: ein deny-Default-Verdikt plus eine oder mehrere allow-Regeln, gekeyt auf einen tool_name_glob. Für die vollständige Matching-Sprache hinter diesen Regeln siehe Firewall-Regeln.
Allow-Lists werden in der Konsole unter Security → Firewall verfasst oder über die /api/workspace/firewall/*-Management-Routen (Ihre Session bzw. Ihr Access-Token — nicht ein Relay-sk-orca-…-Key). Nur die /v1/*-Aufrufe Ihres Agenten verwenden den Relay-Key. Das Erstellen oder Editieren einer Policy ist eine Developer+-Aktion.

​
1. Warum Default-Deny für Agenten

Eine Block-List („deny shell.exec, deny db.delete, …”) ist nur je so vollständig wie die letzte Bedrohung, an die Sie gedacht haben. Eine Allow-List kehrt die Beweislast um: Das Gateway lehnt alles ab, was die Policy nicht explizit erlaubt, sodass ein unbekanntes Tool per Konstruktion geschlossen ist.

Default-Verdikt = deny

Der Boden der Policy. Ohne matchende Regel wird jeder Tool-Call blockiert.

Allow-Regeln opten Tools zurück hinein

Jede allow-Regel benennt die Tools, die Sie tatsächlich verwenden — per exaktem Namen oder per Glob.
Die Engine durchläuft die Regeln einer Policy in Prioritätsreihenfolge und der erste Treffer gewinnt; wenn nichts matcht, fällt sie auf das default_verdict der Policy. Eine Allow-List ist also nur: hochpriore allow-Regeln für Ihre echten Tools, mit einem deny-Boden, der alles andere abfängt.

​
2. Ein Beispiel: die Tools eines Recherche-Agenten allow-listen

Angenommen, Ihr Agent muss nur je das Web durchsuchen und aus einer Wissensdatenbank lesen — Tools namens web.search und kb.read. Alles andere (Shell, Datei-Writes, Datenbank-Mutationen, jedes Tool, das eine Prompt-Injection herbeizaubern könnte) muss abgelehnt werden. Bauen Sie die Policy als Default deny + zwei allow-Regeln:
1

Die Policy mit einem deny-Default erstellen

Security → Firewall → Policies → New policy. Benennen Sie sie, lassen Sie Enabled an und setzen Sie das Default-Verdikt auf deny. Das ist der geschlossene Boden — siehe Eine Policy erstellen.
2

Eine Allow-Regel pro Tool-Familie hinzufügen

Fügen Sie im Regel-Editor zwei Regeln hinzu, beide verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search ist ein exakter Match; kb.* ist ein Präfix-Glob, der kb.read, kb.search und jedes künftige kb.*-Tool erlaubt, ohne die Policy neu zu editieren.
3

An den Key Ihres Agenten anhängen

Setzen Sie die firewall_policy_id des Keys auf diese Policy (oder machen Sie sie zum Workspace-Default). Der Request-Body Ihres Agenten ist unverändert.
Jetzt passieren web.search und kb.read; ein Aufruf von shell.exec matcht keine Allow-Regel, trifft den deny-Boden und kommt als HTTP 400 mit dem Code firewall_blocked auf der inbound-Surface zurück — siehe wie ein Block aussieht.
Verfassen Sie Allow-Regeln als exakte Namen oder schmale Präfixe (kb.*), nicht als breite Suffixe. Ein loses *.read würde kb.read und secrets.read erlauben — das Gegenteil dessen, wofür eine Allow-List da ist. Halten Sie den Glob so eng, wie die Tool-Benennung es zulässt.

​
3. Der Glob in einem Bildschirm

tool_name_glob ist eine kleine, case-sensitive Grammatik — keine Regex, lineare Zeit. Die Formen, die für eine Allow-List zählen:
MusterErlaubt
web.searchGenau dieses Tool.
kb.*Präfix — kb.read, kb.search (nicht das bloße kb).
*.searchSuffix — web.search, kb.search und das bloße search.
*.tools.*Infix — byo.tools.fetch und ähnliche.
Für die vollständige Grammatik (Infix-Regeln, Edge-Cases, Skill-Namen-Globs) siehe Glob-Syntax und die Firewall-Regeln-Referenz.
Ein *.suffix-Glob matcht auch das bloße, nicht-namespaced Verb — *.search erlaubt ein Tool, das wörtlich search heißt, nicht nur web.search. Provider und nicht-namespacende MCP-Server exponieren Tools unter bloßen Verben, sodass ein allow-gelistetes Suffix breiter ist, als es aussieht. Bevorzugen Sie exakte Namen oder Präfixe, wenn Sie eine enge Allow-List wollen.

​
4. Es ausrollen, ohne Ihren Agenten zu brechen

Default-Deny ist die Haltung, die am wahrscheinlichsten ein Tool blockiert, das Sie vergessen hatten zu brauchen. Stagen Sie es:
Schalten Sie Shadow-Mode ein. Die Policy wertet aus und loggt genau so, wie sie es live täte, stuft aber jedes deny auf audit herab, mit dem Grund-Präfix [shadow] would …. Lassen Sie echten Traffic laufen, lesen Sie dann den Events-Feed.
Discovered Tools listet jedes Tool, das der Workspace gesehen hat, geflaggt als covered oder gap. Die Shadow-Mode-„would-deny”-Events plus die Lücken sagen Ihnen genau, welche Allow-Regeln Sie noch brauchen.
Die Test-Sandbox dry-runnt die Policy gegen einen Beispiel-Tool-Call und gibt das Verdikt, die gematchte Regel und den Grund zurück — nichts dispatcht, nichts persistiert. Bestätigen Sie, dass web.search erlaubt und shell.exec ablehnt, schalten Sie dann Shadow aus.
Ein abgelehnter Inbound-Aufruf kostet keine Modell-Tokens — er wird blockiert, bevor das Upstream-Modell läuft — und ist als skip-retry markiert, sodass ein blockiertes Tool kein Retry-Budget mit erneutem Blockieren verbrennt. Siehe Verdikte.

​
5. Wohin als Nächstes

Bestimmte Tools blockieren

Das Umgekehrte — einen Default-Allow-Boden behalten und benannte Tools ablehnen.

Argumente validieren

Ein Tool erlauben, aber nur mit sicheren Argumenten (db.query, aber nicht DROP TABLE).

Regel-Priorität

Wie First-Match-Wins Ihre Allow-Regeln über den Deny-Boden ordnet.

Verdikte

allow, audit, deny, sanitize, pending_approval, cap_cost.
Für die Bedrohung, die dieses Muster adressiert, siehe übermäßige Handlungsmacht und gefährliche Tool-Calls. Warum Default-Deny die Agenten-Baseline ist, siehe Warum Zero Trust.