MCP-Tools per Policy in die Allow-List aufnehmen

Ein registrierter MCP-Server bewirbt, welche Tools er will — und ein Agent ruft bereitwillig jedes davon auf. Die sichere Haltung ist die Umkehrung: entscheiden Sie die kurze Liste der Tools, die Sie tatsächlich brauchen, erlauben Sie genau diese und verweigern Sie den Rest. Das ist eine Allow-List, und auf OrcaRouter bauen Sie sie aus tool_name_glob-Regeln, die auf der mcp-Oberfläche ausgewertet werden. Jeder tools/call, der das MCP-Gateway quert, wird durch Ihre Firewall-Policy geführt, bevor er den echten Server erreicht. Die Allow-List ist also nicht beratend — ein Aufruf eines Tools, das Sie nicht erlaubt haben, dispatcht nie.

​

1. Warum eine Default-Deny-Allow-List für sichere mcp-Tools

Eine Deny-List — „blockiere die gefährlichen Tools” — versagt in dem Moment, in dem ein Server ein neues Tool hinzufügt, eines umbenennt oder Sie einen zweiten Server verbinden. Der Satz gefährlicher Tools ist offen; der Satz, den Sie nutzen wollten, ist klein und bekannt. Eine Allow-List kehrt den Default um, sodass das Unbekannte verweigert wird, nicht zugelassen:

• Neue Tools werden standardmäßig verweigert. Ein Server, dem nach Ihrer Verbindung ein delete_repo-Tool wächst, kann nicht aufgerufen werden, bis Sie es zur Allow-List hinzufügen.
• Der Scope ist pro Server. Der <server>.<tool>-Namespace lässt Sie github.create_issue erlauben, während Sie alles andere unter github.* verweigern.
• Ein Engpass. Dieselbe Policy steuert den mitgelieferten Server und jeden BYO-Server hinter dem Gateway, sodass es einen Ort gibt, um die Allow-List zu lesen.

​

2. Die zwei Teile

Eine Allow-List ist ein default_verdict plus ein geordneter Satz von Regeln. Der Glob wird gegen den namespaced Tool-Namen gematcht — github.create_issue, shell.exec. * matcht jedes Tool (verwenden Sie es sparsam; eine allow-Regel mit * hebt die gesamte Allow-List auf). Ein führendes <server>. scopt den Glob auf einen Server.

​

3. Ein konkretes Beispiel

Sie haben einen github-Server verbunden und wollen, dass Agenten nur lesen und Issues öffnen — nie etwas löschen oder administrieren. Öffnen Sie in der Konsole Firewall → Policies, setzen Sie das Default-Verdikt der Policy auf deny und fügen Sie zwei allow-Regeln hinzu: Das ist die ganze Allow-List. Mit dem Default auf deny:

• github.create_issue → matcht Regel 1 → allow, dispatcht.
• github.delete_repo → matcht nichts → deny standardmäßig.

Ein verweigerter MCP-Aufruf kommt zum Modell zurück als Tool-Fehler (firewall deny: …) — dieselbe Form, die jedes fehlschlagende Tool zurückgibt — sodass der Agent sich anpassen kann statt abzustürzen. (Auf der inbound-Oberfläche ist ein deny stattdessen ein HTTP 400 mit dem Error-Code firewall_blocked.)

​

4. Mit Argumenten verschärfen

Ein Tool-Name auf der Allow-List kann immer noch mit schlechten Argumenten aufgerufen werden. Engen Sie weiter ein, indem Sie eine args_match-Klausel (JSONPath + einen Operator wie eq, contains, regex, in oder cidr_match) zur Regel hinzufügen, oder indem Sie eine deny-Regel über das allow für eine spezifische Argument-Form schichten — zum Beispiel github.create_issue erlauben, es aber denyen, wenn das Ziel-Repo nicht auf einer genehmigten Liste steht. Siehe die Firewall-Regel-Referenz für den vollständigen Operator-Satz.

​

5. Sicher ausrollen

Kippen Sie ein Whole-Server-Default-Deny in der Produktion, und Sie riskieren, einen Agenten zu brechen, der still von einem Tool abhing, das Sie vergessen haben. Zwei Einstellungen entschärfen das: Sobald das Shadow-Log sauber ist — kein legitimer Aufruf wäre verweigert worden — löschen Sie shadow_mode, und die Allow-List setzt durch.

​

6. Verifizieren, dass es funktioniert

Bestätigen Sie nach der Durchsetzung, dass verweigerte Tools tatsächlich abgelehnt werden:

• Dry-run Sie einen tools/call gegen die Policy (Developer+), um das Verdikt zu sehen und welche Regel — oder der Default — es erzeugt hat, ohne echten Traffic zu senden. Übergeben Sie einen Tool-Namen, eine Oberfläche und Beispiel-Args; die Engine wertet sie aus und gibt die Verdikt-Spur zurück, ohne ein Event aufzuzeichnen.
• Beobachten Sie die Events. Jeder blockierte Aufruf zeichnet ein Firewall-Event auf, das ein Developer+ in der Konsole lesen kann; die Audit-Events-Seite behandelt den Feed und seine Felder.

​

Verwandt