Zum Hauptinhalt springen
Ein Agent, der das Model Context Protocol (MCP) spricht, ist nur so sicher wie die Server, mit denen er sich verbindet. Jeder MCP-Server ist ein frischer Satz von Tools, ein frisches Credential und frische Netzwerk-Reichweite — und in dem Moment, in dem ein Agent einen direkt anwählt, schaut niemand auf den Aufruf. Genau das ist das ganze Problem, das mcp-Sicherheit lösen muss: nicht „ist dieses eine Tool sicher”, sondern „wer steuert alle von ihnen, bei jedem Aufruf, mit einem Audit-Trail.” OrcaRouters Antwort ist ein einziger auditierter Engpass. Sie registrieren jeden MCP-Server einmal; Agenten verbinden sich mit einem Gateway; und jeder tools/call läuft durch die Firewall-Engine, bevor er den echten Server erreicht. Diese Seite ist die Karte dieser Oberfläche — das Gateway, das Verdikt pro Aufruf, Skill-Governance, Egress und verschlüsselte Credentials — mit Links zur fokussierten Anleitung für jedes.
Jede Management-Aktion hier wird aus der Konsole konfiguriert (oder über die REST-API mit Ihrem Session-/Access-Token) und ist rollengesteuert. Nur /v1/*-Relay-Aufrufe und die Firewall-Gateway-Routen tragen einen Key im sk-orca-...-Stil.

​
1. Warum mcp-Sicherheit ein Gateway braucht

Richten Sie zehn Agenten direkt auf fünf Community-MCP-Server, und Sie bekommen das Schlechteste aus jeder Welt: keine geteilte Policy, kein Audit-Trail, Credentials kopiert in zehn Agenten-Konfigurationen und ein Tool namens shell.exec einen Redirect entfernt von Ihrem Cloud-Metadata-Endpunkt. Das Gateway kollabiert das zu einer gesteuerten Verbindung.

Eine Verbindung, jeder Server

Agenten verbinden sich mit einem einzigen Endpunkt. Das Gateway aggregiert die Tools jedes aktivierten, erreichbaren Servers unter einem <server>.<tool>-Namespace.

Policy bei jedem Aufruf

Jeder tools/call wird von Ihrer Firewall-Policy ausgewertet, bevor er dispatcht wird.

Verschlüsselte Credentials

Server-Auth-Secrets werden im Ruhezustand verschlüsselt, beim Lesen maskiert und beim Dispatch injiziert — sie erreichen nie das Modell oder den Client.

Egress unter Kontrolle

Der Endpunkt eines registrierten Servers wird standardmäßig gegen private und Cloud-Metadata-IP-Bereiche validiert. Für Pro-Tool-Ziele wenden Sie die Baseline-SSRF-Egress-Denylist an oder verfassen Ihre eigenen Host-/CIDR-Regeln.
Für die Grundlagen hinter all dem siehe KI-Agenten absichern und Warum Zero Trust.

​
2. Die vier Bausteine

MCP-Governance auf OrcaRouter besteht aus vier zusammenarbeitenden Teilen. Wählen Sie das, das zu der Frage passt, die Sie beantworten möchten.
Ein einziger Endpunkt, mit dem sich Ihre Agenten verbinden, statt Server direkt anzuwählen. Es aggregiert die Tools jedes registrierten Servers, namespaced <server>.<tool>, und exponiert jedes Input-Schema des Tools wortwörtlich neu. Beginnen Sie bei Einen MCP-Server anbinden und Authentifizieren; die vollständige Referenz lebt in Firewall: MCP-Server.
Das Gateway führt jeden tools/call durch die Firewall auf der mcp-Oberfläche und gibt ein Verdikt zurück — allow, audit, deny, sanitize oder pending_approval — vor dem Dispatch. Siehe MCP-Tools per Allowlist und Tool-Argumente bereinigen.
Fähigkeiten, die ein Agent selbst installiert — Skills, BYO-MCP-Server, Plugins — werden gescannt, einem Risikoband zugeordnet und mit einem Durchsetzungsmodus (allow / quarantine / block) versehen, der über jedem Regel-Verdikt liegt. Siehe Firewall: Skills und Rug-Pull-Abwehr.
Das Auth-Secret jedes Servers wird im Ruhezustand verschlüsselt und beim Lesen maskiert. Siehe Authentifizieren und Credential-Rotation.

​
3. Wie ein tools/call ausgewertet wird

Wenn ein Agent ein Tool durch das Gateway aufruft, geht der Aufruf nicht direkt an den Server. Er wird gegen Ihre Workspace-Policy abgeglichen, der Durchsetzungsmodus des besitzenden Skills wird obendrauf angewendet, und nur ein allow- / audit- / sanitize-Verdikt erreicht den echten Server.
VerdiktWas der Agent sieht
allow / auditWeitergeleitet. audit loggt zusätzlich ein Event.
sanitizeWeitergeleitet mit redigierten Argumenten (nie dem Ergebnis).
deny / pending_approvalZurückgegeben als Tool-Fehler, sodass der Agent reagieren kann, statt abzustürzen.
Ein blockierter MCP-Aufruf kommt als Tool-Fehler zurück (firewall deny: …), in derselben Form, die jedes fehlschlagende Tool zurückgibt — der Agent kann es anders versuchen, den Nutzer fragen oder anhalten. Es ist kein Transportabsturz.
Das Verdikt-Vokabular, die Oberflächen und das Regel-Matching sind vollständig dokumentiert unter Firewall und Firewall-Regeln; das konzeptuelle Modell findet sich in Durchsetzungsmodi und Wie OrcaRouter prüft.

​
4. Einen Server registrieren (ein konkretes Beispiel)

Sie registrieren jeden Server einmal. Ein Server-Datensatz trägt einen name (eindeutig pro Workspace, kein .), einen endpoint, einen auth_mode (none / bearer / oauth / basic) und seine verschlüsselten Credentials. Tun Sie dies aus der Konsole — das Schreiben erfordert Developer+. 
# Konsolen-Route, aufgerufen mit Ihrem Session-/Access-Token (UserAuth).
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
Dann proben Sie ihn, um seine Tools zu entdecken und die Erreichbarkeit aufzuzeichnen (ok / degraded / down): 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Nun können Sie Regeln gegen github.* schreiben und genau wissen, was github.create_issue akzeptiert. Die End-to-End-Anleitung lebt in Einen MCP-Server anbinden.
Secrets werden nie im Klartext gespeichert. auth_json wird im Ruhezustand verschlüsselt und beim Lesen maskiert; spiegeln Sie bei einem Update die Maske zurück, um den gespeicherten Wert zu behalten. Siehe Credential-Rotation.

​
5. Einen Agenten an das Gateway anbinden

Sobald Server registriert sind, richten Sie einen beliebigen MCP-Client mit einem firewall-gateway-scoped Key auf das Gateway (ein Token ohne diesen Scope erhält 403): 
https://api.orcarouter.ai/api/v1/firewall/mcp
Das Gateway spricht Streamable HTTP und bietet die Tools jedes aktivierten, erreichbaren Servers unter dem <server>.<tool>-Namespace an. Ein SDK, das Aufrufe selbst proxyt, kann die Runtime-Registry von GET /api/v1/firewall/mcp_servers mit demselben Gateway-Token lesen.

​
6. Sperren Sie ab, was Tools erreichen können

Verdikte pro Aufruf steuern, welches Tool läuft; Egress-Kontrollen steuern, wohin es reichen darf. Zwei Ebenen arbeiten zusammen. Erstens: Wenn sich das Gateway mit dem Endpunkt eines registrierten Servers verbindet, wird diese URL standardmäßig gegen private (RFC1918), Loopback-, Link-Local- und Cloud-Metadata-Bereiche validiert — und der Host wird per DNS aufgelöst, sodass ein Name, der in einen blockierten Bereich auflöst, ebenfalls abgelehnt wird. Ein BYO-Server, der auf 169.254.169.254 oder eine Intranet-Adresse zeigt, wird also abgelehnt, sofern Sie ihn nicht explizit auf die Whitelist gesetzt haben. Zweitens: Für Pro-Tool-Ziele trägt eine Egress-Regel eine Host-/CIDR-Allow/Deny-Liste, die gegen das ausgehende Ziel des Aufrufs auf der egress-Oberfläche abgeglichen wird. Die Baseline-Use-Case-Vorlage liefert eine fertige Egress-Deny-Regel, deren Liste bereits die privaten, Loopback-, Link-Local- und Cloud-Metadata-Bereiche abdeckt (einschließlich 169.254.169.254 und metadata.google.internal), sodass ihre Anwendung Ihnen SSRF-/Metadata-Schutz gibt, ohne CIDRs von Hand zu verfassen.
SSRF und Egress sind der Unterschied zwischen „dieses Tool hat Daten zurückgegeben” und „dieses Tool hat Ihre Secrets an den Host eines Angreifers exfiltriert.” Wenden Sie die Baseline-Egress-Denylist an und fügen Sie Ihre eigenen Host-/CIDR-Regeln hinzu — siehe Egress-Limits und Daten-Exfiltration.

​
7. Beobachten: Events, Runs und Anomalien

Jeder gesteuerte Aufruf hinterlässt einen Trail. Firewall-Events zeichnen das Verdikt, die Oberfläche und die getroffene Regel auf; Runs gruppieren die Aufrufe einer Session; und der Anomalie-Feed markiert Raten- und Kosten-Spitzen gegen eine gelernte Baseline. Lesezugriffe auf Einstellungen, Policies und entdeckte Tools sind für jedes Member offen; Event-/Run-/Aggregat-Lesezugriffe erfordern Developer+.

​
8. Wohin als Nächstes

Einen MCP-Server anbinden

Einen Server registrieren, proben und durch das Gateway exponieren.

MCP-Tools per Allowlist

Einen Server standardmäßig sperren und nur die Tools erlauben, die Sie geprüft haben.

Rug-Pull-Abwehr

Server und Skills steuern, die sich nach Ihrer Freigabe ändern.

Firewall: MCP-Server

Die vollständige Feld-und-Routen-Referenz.
Neu beim Modell? Lesen Sie Guardrails vs. Firewall, um zu sehen, wo MCP-Governance hineinpasst, dann MCP-Tool-Poisoning und Übermäßige Handlungsmacht für die Bedrohungen, die sie schließt.