Zum Hauptinhalt springen
Ein MCP-Agent ist ein Agent mit Reichweite. Jeder Model-Context-Protocol-Server, mit dem er sich verbindet, ist ein frischer Satz von Tools, Credentials und Netzwerkzielen, die niemand geprüft hat — und der Agent kann mitten im Lauf einen neuen hereinziehen. Dieses Rezept zeigt die vier Schritte, die ein wucherndes MCP-Setup in ein gesteuertes auf dem gehosteten Gateway verwandeln: ein einziges auditiertes MCP-Gateway, Skill-Quarantäne, Egress-Ablehnung und verschlüsselte Server-Auth. Sie konfigurieren alles davon aus der Konsole (oder der REST-API) gegen Ihren Workspace. Ihr Agent spricht weiterhin MCP exakt wie zuvor.

​
1. Warum einen MCP-Agenten absichern

Richten Sie einen Agenten direkt auf fünf MCP-Server, und Sie haben fünf Vertrauensgrenzen, fünf Credential-Stores und null geteilten Audit-Trail. Der tools/call, der einen Kundendatensatz liest, und der, der einen Shell-Befehl ausführt, sehen für das Modell identisch aus, und ein Community-Server kann still shell.exec und einen externen Netzwerk-Scope anfordern, das erste Mal, wenn er lädt. Die Lösung ist, OrcaRouter zum einen Engpass zu machen, den jeder Aufruf überquert. Um MCP-Agenten-Traffic Ende zu Ende abzusichern, routen Sie allen MCP-Dispatch durch das MCP-Gateway der Firewall, sodass jeder tools/call policy-ausgewertet wird, bevor er den echten Server erreicht — mit risikobewerteten Skills, gesteuertem Egress und verschlüsselt ruhenden Credentials.
Dies ist ein Rezept — es näht bestehende Features zu einem konkreten Härtungs-Durchlauf zusammen. Für die vollständige Referenz folgen Sie den Links in Firewall, MCP-Server und Skills.

​
2. Von der Secure-Agents-Baseline starten

Bevor Sie etwas Maßgeschneidertes verfassen, setzen Sie eine Haltung. Öffnen Sie in der Konsole Firewall → Posture und wenden Sie das balanced-Autonomie-Level an (Developer-Rolle). In einer Transaktion auditiert es Tool-Calls und flaggt PII, während es die destruktivsten Aktionen ablehnt — Sie beobachten, bevor Sie breit durchsetzen, mit Ein-Klick-Undo. Wenn die Events- und Runs-Feeds richtig aussehen, wechseln Sie zu tight: Default-Deny, destruktive Shell abgelehnt, SSRF-förmiger Egress abgelehnt, plus die PII-Shield- und Secrets-Blocker-Guardrails durchgesetzt. Dieser eine Schalter ist der Boden, auf dem dieses Rezept baut.
Lieber hochfahren, ohne den ganzen Workspace umzustellen? Verfassen Sie die Regeln unten in eine benannte Policy und schalten Sie ihren Shadow-Mode ein — sie wertet aus und loggt, stuft aber jedes durchsetzende Verdikt auf audit herab (Grund vorangestellt [shadow] would …), bis Sie sicher sind. Siehe Enforcement-Modi.

​
3. Jeden tools/call durch ein MCP-Gateway routen

Registrieren Sie jeden MCP-Server einmal; das Gateway aggregiert ihre Tools unter einer einzigen Verbindung (namespaced <server>.<tool>) und führt jeden tools/call durch die Firewall-Engine. Registrieren Sie einen Server aus der Konsole (oder der REST-API, Developer+): 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-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
  }'
Richten Sie dann Ihren MCP-Client auf das Gateway — nicht auf die Upstream-Server — unter Verwendung eines dedizierten firewall-gateway-scoped Schlüssels: 
https://api.orcarouter.ai/api/v1/firewall/mcp
Jetzt tauchen github.create_issue und shell.exec Seite an Seite unter einer Verbindung auf, und jeder Dispatch wird ausgewertet, bevor er läuft. Ein blockierter Aufruf kommt zum Modell als Tool-Fehler (firewall deny: …) zurück, nicht als Transportabsturz, sodass der Agent sich anpassen kann.
Ein regulärer Relay-Schlüssel erhält auf der Gateway-Route /api/v1/firewall/mcp eine 403. Prägen Sie einen dedizierten Gateway-Token (is_firewall_gateway) für die MCP-Verbindung; das Lesen des Klartextes dieses Gateway-Keys erfordert Admin+.
Bevor Sie Regeln gegen die Tools eines Servers schreiben können, proben Sie ihn, um ihre Namen und Schemas zu entdecken: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. Skills quarantänieren, die der Agent hereinzieht

Das MCP-Gateway steuert Aufrufe; die Skill-Governance steuert die Fähigkeiten, die ein Agent lädt. Jeder installierbare Skill, BYO-MCP-Server oder Plugin wird in ein Risikoband und einen Enforcement-Mode gescannt, der auf jedem Regel-Verdikt obendrauf reitet:
ModeEffekt zur Laufzeit
allowRegel-Verdikte entscheiden; der Skill fügt nichts hinzu.
quarantineAlles unterhalb von deny wird für pending_approval zurückgehalten.
blockDie Tools des Skills werden zwangsweise abgelehnt.
Der Punkt für einen MCP-Agenten: Eine Fähigkeit, die niemand genehmigt hat, bekommt keinen Freifahrtschein. Wenn ein Agent etwas selbst installiert und seine Tools zum ersten Mal das Gateway überqueren, erkennt die Firewall es automatisch und quarantäniert es, bis ein Mensch es prüft — selbst wenn es sauber gescannt hat. Genehmigen Sie die Server, denen Sie vertrauen, vorab; lassen Sie den Rest in der Prüf-Queue landen.
Halten Sie balanced/observe an, während Sie lernen, was Ihr Agent tatsächlich installiert, promoten Sie dann die vertrauenswürdigen Skills auf allow und lassen Sie den Long Tail quarantäniert. Siehe Skills.

​
5. SSRF-förmigen Egress ablehnen

Ein kompromittiertes oder verwirrtes MCP-Tool, das nach Cloud-Metadata oder einem Intranet-Host greift, ist der klassische Exfiltrationspfad. Zwei Ebenen decken ihn ab. Erstens validiert das Gateway jeden remote MCP-Endpunkt und seine aufgelöste Dial-IP gegen eine SSRF-Policy bei der Registrierung und bei jedem Dispatch-Hop — Intranet-Ranges und die Cloud-Metadata-Adresse werden abgelehnt, neu geprüft, um DNS-Rebinding zu vereiteln. Das ist eingebaut; Sie konfigurieren es nicht. Zweitens liefert das tight-Autonomie-Level ein SSRF-Egress-Preset, das fetch-förmige Tool-Namen ablehnt — http_fetch, web_search, fetch_url, request und ihre <server>.*-namespaced Formen — sodass ein Tool, dessen ganze Aufgabe „hol diese URL” ist, gestoppt wird, bevor es dialt. Um zu steuern, wohin Tools nach Ziel reichen dürfen, verfassen Sie Ihre eigene egress-Regel mit einer Host-/CIDR-Deny-Liste — das ist die Surface zum Festpinnen ausgehender Reichweite: 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
Kein Preset liefert CIDR-Egress-Regeln — das SSRF-Preset matcht Tool-Namen, nicht Ziele. Verfassen Sie die Host-/CIDR-Deny-Liste selbst, wenn Sie Kontrolle auf Zielebene brauchen. Siehe Egress-Listen und Exfiltration stoppen.

​
6. Server-Credentials verschlüsselt halten

Das auth_json jedes MCP-Servers wird verschlüsselt ruhend gespeichert und beim Lesen maskiert; das Gateway injiziert Credentials zur Dispatch-Zeit, sodass sie nie das Modell oder den Client erreichen. Unterstützte auth_mode-Werte:
{ "token": "…" } — ein statischer Bearer-Token, gesendet als Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — Client-Credentials-OAuth; das Gateway holt und erneuert den Token.
{ "username": "…", "password": "…" } — HTTP-Basic-Auth.
"" — ein nicht authentifizierter Server. Der Default.
Beim Lesen wird das Secret maskiert; echoen Sie die Maske beim Update zurück, um den gespeicherten Wert zu behalten. Der status des Servers (ok / degraded / down) aus dem letzten Probe sagt Ihnen, ob er erreichbar ist, bevor Sie sich auf ihn verlassen.

​
7. Ein Content-Guardrail auf dem Request hinzufügen

Die Firewall steuert Aktionen; paaren Sie sie mit einem Guardrail, sodass auch der Text, der durch Ihren MCP-Agenten fließt, geprüft wird. Das Secrets Blocker-Preset fängt Credentials in einem Request, bevor das Modell — oder irgendein Tool — sie je sieht, und ein PII Shield maskiert Identifikatoren auf dem Weg hinein. Beide kommen mit dem tight-Autonomie-Level, oder hängen Sie ein benanntes Guardrail über guardrail_id an den Relay-Schlüssel des Agenten.
Das sanitize-Verdikt der Firewall redigiert Tool-Call-Argumente, niemals den Inhalt, den ein Tool zurückgibt. Streichen Sie Secrets aus dem Request mit dem Secrets-Blocker-Guardrail; bereinigen Sie die Argumente, die ein Agent ausgibt, mit einer Firewall-Regel. Sie decken verschiedene Hälften des Flows ab.

​
8. Verifizieren und beobachten

Bestätigen Sie, dass die Policy tut, was Sie erwarten, bevor Sie ihr vertrauen, behalten Sie dann die Feeds im Auge:

Einen Tool-Call testen

Dry-runnen Sie einen Beispiel-tools/call gegen Ihre Policy und sehen Sie das Verdikt, die gematchte Regel und den Grund — nichts dispatcht, nichts geloggt.

Discovered tools

Jedes Tool, das der Workspace gesehen hat, geflaggt als covered oder gap — verfassen Sie Regeln direkt aus echtem MCP-Traffic.

Events & Runs

Jeder Dispatch, sein Verdikt und die Surface, auf die er traf, aufgerollt pro Agentenlauf.

Anomalie-Feed

Raten-/Kosten-Spikes, Retry-Loops und neuartige Tool-Pfade gegen eine gelernte Baseline.

​
9. Wohin als Nächstes

MCP-Tool-Poisoning

Das Bedrohungsmodell hinter Quarantäne und dem MCP-Gateway.

Übermäßige Handlungsmacht

Warum Default-Deny und HITL für autonome Tool-Nutzung zählen.

Rezept: autonomer Agent

Einen Agenten hoher Autonomie Ende zu Ende härten.

Exfiltration stoppen

Ausgehenden Egress im Detail eingrenzen.