Firewall: MCP-Server

Das Model Context Protocol (MCP) lässt Agenten Tools aufrufen, die von externen Servern gehostet werden. Das ist zu gleichen Teilen mächtig und gefährlich: Jeder MCP-Server, mit dem sich ein Agent verbindet, ist ein frischer Satz von Tools, Credentials und Netzwerk-Reichweite, den niemand geprüft hat. Das MCP-Gateway der Firewall stellt einen einzigen auditierten Engpass vor sie alle. Sie registrieren jeden MCP-Server einmal; das Gateway exponiert ihre Tools für Ihre Agenten unter einer Verbindung und führt jeden tools/call durch die Firewall-Engine, bevor er den echten Server erreicht.

1. Was MCP-Governance Ihnen gibt

Ein Gateway, jeder Server. Ihr Agent verbindet sich mit einem Endpunkt. Das Gateway aggregiert die Tools jedes erreichbaren registrierten Servers, namespaced als <server>.<tool>, sodass github.create_issue und shell.exec Seite an Seite unter einer einzigen MCP-Verbindung auftauchen.
Policy bei jedem Aufruf. Jeder tools/call wird zuerst von Ihrer Policy ausgewertet. Ein blockierter Aufruf kommt zum Modell zurück als Tool-Fehler (firewall deny: …), nicht als Transportfehler, sodass der Agent reagieren kann, statt abzustürzen. sanitize schreibt die Argumente vor dem Weiterleiten um; pending_approval hält den Aufruf zurück.
SSRF-geschützt. Remote-Endpunkte werden gegen die SSRF-Policy des Gateways validiert — Intranet-Bereiche und Cloud-Metadata-Adressen werden blockiert, und die aufgelöste Dial-IP wird neu geprüft, um DNS-Rebinding abzuwehren, bei jedem Hop einschließlich Redirects.
Verschlüsselte Credentials. Server-Auth-Secrets werden im Ruhezustand verschlüsselt und beim Lesen maskiert. Das Gateway injiziert sie zur Dispatch-Zeit; sie erreichen nie das Modell oder den Client.

2. Zwei Arten von Server

Art	`endpoint`	Verhalten
BYO (bring-your-own)	Eine Streamable-HTTP-URL	Das Gateway proxyt `tools/call` an Ihren Remote-MCP-Server.
Bundled	leer	Der In-Process-MCP-Server von OrcaRouter. Registriert, damit er sichtbar und steuerbar ist; nicht separat probebar.

3. Einen Server registrieren

Ein Server-Datensatz trägt:

Feld	Notizen
`name`	Business-Key, eindeutig pro Workspace, ≤ 128 Zeichen. Kein `.` — es ist der `<server>.<tool>`-Namespace-Trenner.
`endpoint`	Die MCP-Server-URL (≤ 512 Zeichen). Leer für den mitgelieferten Server.
`auth_mode`	`none` (Default), `bearer`, `oauth` oder `basic`.
`auth_json`	Modus-spezifische Credentials (siehe unten). Erforderlich, wann immer `auth_mode` nicht `none` ist.
`enabled`	Default ist `true`. Ein deaktivierter Server wird gänzlich aus dem Gateway weggelassen.
`status`	Erreichbarkeit — `ok` (Default), `degraded` oder `down`. Gesetzt durch Probing.

Credential-Formen nach Modus:

// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""

Eine Registrierungsanfrage sieht so aus:

curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'

Ein doppelter Name im selben Workspace gibt HTTP 409 zurück (derselbe Name in einem anderen Workspace ist in Ordnung).

Secrets werden nie im Klartext gespeichert. auth_json wird im Ruhezustand mit einem Workspace-Secrets-Key verschlüsselt. Wenn dieser Key nicht konfiguriert ist, wird das Schreiben abgelehnt, statt ein Credential unverschlüsselt zu persistieren. Beim Lesen werden Secrets und der Endpunkt maskiert; spiegeln Sie die Maske bei einem Update zurück, um den gespeicherten Wert zu behalten. Der Wechsel zwischen zwei Credential-tragenden Auth-Modi erfordert frisches auth_json (der Ciphertext ist formgebunden an seinen Modus).

4. Probe — seine Tools entdecken

Bevor Sie Regeln gegen die Tools eines Servers schreiben können, müssen Sie ihre Namen kennen. Proben Sie den Server:

curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."

Das Gateway führt ein MCP-initialize + tools/list gegen den Endpunkt aus (mit den entschlüsselten Credentials, auf 10s begrenzt), zeichnet die Erreichbarkeit status und einen Zeitstempel auf und gibt die angebotenen Tools mit ihren Input-Schemas zurück:

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}

Nun können Sie Regeln wie tool_name_glob: github.* verfassen und genau wissen, was github.create_issue akzeptiert. Der mitgelieferte Server (mit leerem Endpunkt) ist nicht probebar und gibt ein 400 zurück.

5. Lebenszyklus & Durchsetzung

Enabled vs. disabled. Ein deaktivierter Server wird aus der Runtime-Registry entfernt — seine Tools verschwinden aus dem Gateway und seine Credentials werden nie entschlüsselt. Das ist der Aus-Schalter.
Erreichbarkeit. status (ok / degraded / down) spiegelt das letzte Probe wider; ein unerreichbarer Server wird übersprungen, wenn das Gateway seinen Tool-Satz baut.
Verdikt pro Aufruf. Beim Dispatch gibt die Engine ein Verdikt für den spezifischen <server>.<tool>-Aufruf mit seinen Argumenten zurück:
- allow / audit → weitergeleitet (auditiert, erlaubt aber weiterhin).
- sanitize → weitergeleitet mit umgeschriebenen Argumenten.
- deny / pending_approval / alles Unbekannte → blockiert als Tool-Fehler. (Durch das vereinheitlichte Gateway taucht ein zurückgehaltener Aufruf als permanenter Fehler auf, statt die Approval-ID durchzufädeln — verwenden Sie den Evaluate-Hook, wenn Sie den Approval-Handshake brauchen.)
Löschen ist ein Soft-Delete; der Name-Slot wird sofort freigegeben, sodass Sie unter demselben Namen neu registrieren können.

Jede Änderung invalidiert den Pro-Workspace-Tool-Cache des Gateways sofort, sodass ein neu registrierter, deaktivierter oder neu geprobeter Server bei der nächsten Verbindung wirksam wird statt nach einer Cache-TTL.

6. Einen Client anbinden

Richten Sie einen beliebigen MCP-Client mit einem firewall-gateway-scoped Token auf den Gateway-Endpunkt:

https://api.orcarouter.ai/api/v1/firewall/mcp

Das Gateway spricht Streamable HTTP (POST-Messages, GET für den SSE-Stream, DELETE zum Beenden einer Session) und identifiziert sich als orcarouter-firewall-gateway. Es bietet die Tools jedes aktivierten, erreichbaren Servers unter dem <server>.<tool>-Namespace an und exponiert jedes Input-Schema des Tools wortwörtlich neu. Ein Token ohne den firewall-gateway-Scope erhält 403 — prägen Sie dafür einen dedizierten Gateway-Token.

API-Referenz

Konsole (workspace-bezogen, RBAC)

Methode & Pfad	Rolle	Zweck
`GET /api/workspace/firewall/mcp_servers`	Member	Server auflisten (Secrets maskiert, Endpunkt redigiert).
`GET /api/workspace/firewall/mcp_servers/:id`	Member	Einzelner Server, maskiert.
`POST /api/workspace/firewall/mcp_servers`	Developer+	Einen Server registrieren (409 bei doppeltem Namen).
`PUT /api/workspace/firewall/mcp_servers`	Developer+	Einen Server aktualisieren (ID im Body).
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	Soft-Delete; gibt den Namen frei.
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	Erreichbarkeit proben + Tools entdecken.

Gateway (firewall-gateway-scoped Token)

Methode & Pfad	Zweck
`ANY /api/v1/firewall/mcp`	Der vereinheitlichte MCP-Gateway-Dispatch-Endpunkt.
`GET /api/v1/firewall/mcp_servers`	Runtime-Registry (entschlüsselte Auth, nur aktivierte Server) für einen SDK-Proxy.
`POST /api/v1/firewall/evaluate`	Einen einzelnen `tools/call` auswerten, bevor Sie ihn selbst dispatchen.

FAQ

Warum MCP überhaupt durch OrcaRouter routen?

Damit es einen Ort gibt, der jeden Tool-Call sieht. Ohne ein Gateway verbindet sich jeder Agent direkt mit jedem MCP-Server — keine geteilte Policy, kein Audit-Trail, kein SSRF-Schutz und Credentials verstreut über Agenten-Konfigurationen. Das Gateway zentralisiert all das: eine Verbindung, eine Policy, ein auditiertes Log, verschlüsselte Secrets, die beim Dispatch injiziert werden.

Was passiert, wenn ein blockierter MCP-Aufruf zurückkommt?

Das Modell erhält ihn als Tool-Fehler (firewall deny: <reason>), in derselben Form, die es von jedem fehlschlagenden Tool bekäme. Das lässt den Agenten sich anpassen — einen anderen Ansatz versuchen, den Nutzer fragen oder anhalten — statt es als Transportabsturz zu behandeln.

Kann ich dasselbe Tool pro Server unterschiedlich steuern?

Ja — genau dafür ist der <server>.<tool>-Namespace da. Eine Regel mit tool_name_glob: trusted.* kann allow, während community.* auditiert oder pending_approval ist. Kombinieren Sie es mit einem Skill-Namen-Glob für noch feineres Scoping.

Schützt das Gateway gegen SSRF?

Ja. Endpunkt-URLs und ihre aufgelösten Dial-IPs werden gegen die SSRF-Policy bei der Registrierung und bei jedem Dispatch-Hop validiert — Intranet-Bereiche und die Cloud-Metadata-Adresse werden verweigert, und die aufgelöste IP wird neu geprüft, um DNS-Rebinding abzuwehren. Kombinieren Sie es mit einer Egress-Regel, um zu steuern, wohin Tools reichen dürfen.

Siehe auch

Sie möchten tiefer in die Agentensicherheit einsteigen? Die Leitfäden Secure Your Agents (Zero Trust) ordnen dieses Feature in einen Zero-Trust-Workflow ein.

MCP-Server sichern (Zero Trust)

Verbinden, authentifizieren und steuern Sie MCP-Server unter einer Zero-Trust-Haltung.

MCP-Vertrauens-Checkliste

Was Sie überprüfen sollten, bevor Sie einem Drittanbieter-MCP-Server vertrauen.

​1. Was MCP-Governance Ihnen gibt

​2. Zwei Arten von Server

​3. Einen Server registrieren

​4. Probe — seine Tools entdecken

​5. Lebenszyklus & Durchsetzung

​6. Einen Client anbinden

​API-Referenz

​Konsole (workspace-bezogen, RBAC)

​Gateway (firewall-gateway-scoped Token)

​FAQ

​Siehe auch