Zum Hauptinhalt springen
Ein Drittanbieter-MCP-Server ist ein ungeprüftes Bündel von Tools, ein Live-Credential und frische Netzwerk-Reichweite. In dem Moment, in dem ein Agent einen direkt anwählt, sieht niemand dem Aufruf zu — und „der Server hat seine Tools geändert, nachdem Sie ihn genehmigt haben” ist ein echter Angriff, kein hypothetischer. Bevor Sie einen Agenten auf einen Server richten, den jemand anderes betreibt, wollen Sie einen wiederholbaren Pre-Flight. Diese Seite ist dieser Pre-Flight: eine kurze, geordnete Checkliste, um mcp-Server zu prüfen und Verbindungen auf OrcaRouter mit bereits existierenden Controls abzusichern — Auswertung pro Aufruf, Default-Deny-Allow-Listing, Egress-Limits, verschlüsselte Credentials und Skill-Quarantäne. Jeder Schritt verlinkt auf das fokussierte How-to für die Tiefe. Führen Sie sie einmal pro neuem Server aus; führen Sie die drift-sensitiven Schritte erneut aus, wann immer sich der Server ändert.
Jeder Konfigurationsschritt hier wird aus der Konsole erledigt (oder der REST-API mit Ihrer Session/Ihrem Access-Token) und ist rollengesteuert. Nur die Firewall-Gateway-Routen und /v1/*-Relay-Aufrufe tragen einen sk-orca-...-förmigen Key.

1. Die Checkliste, um mcp-Server-Verbindungen zu prüfen

Arbeiten Sie von oben nach unten. Die ersten drei Schritte sind für jeden Server, den Sie nicht selbst betreiben, obligatorisch; der Rest härtet ihn.

1. Proben, bevor Sie vertrauen

Entdecken Sie die echte Tool-Liste und Erreichbarkeit, bevor Sie eine einzige Regel schreiben.

2. Default-Deny, dann Allow-List

Erlauben Sie nur die Tools, die Sie geprüft haben; alles andere wird verweigert.

3. Das Credential verschlüsseln

Speichern Sie Auth so, dass sie im Ruhezustand verschlüsselt, beim Lesen maskiert und nie vom Modell gesehen wird.

4. Egress sperren

Beschränken Sie, wohin die Tools des Servers im Netzwerk reichen dürfen.

5. Selbst installierte Skills quarantänisieren

Halten Sie alles, was der Agent selbst installiert, zurück, bis ein Mensch es prüft.

6. Erst Shadow, dann beobachten

Rollen Sie audit-only aus, lesen Sie dann Events und Anomalien, bevor Sie durchsetzen.

2. Proben, bevor Sie vertrauen

Sie können keine Tools prüfen, die Sie nie gesehen haben, und die beworbene Tool-Liste eines Servers ist das, was sich am wahrscheinlichsten unter Ihnen ändert. Registrieren Sie den Server, dann proben Sie ihn — das Gateway führt ein MCP-initialize + tools/list gegen den Endpunkt aus und gibt die echten Tools mit ihren Input-Schemas zurück, plus einen Erreichbarkeits-status von ok, degraded oder down.
# Console route, called with your session/access token (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Lesen Sie jeden Tool-Namen und was seine Argumente akzeptieren. Ein Server, der ein shell.exec oder ein http_fetch bewirbt, das Sie nicht erwartet haben, ist ein Befund, kein Detail — das ist der ganze Sinn, zuerst zu proben.
Proben Sie erneut, wann immer ein Server den Besitzer wechselt oder Sie Drift vermuten. Ein neues Tool, das in der Liste auftaucht — der „Rug Pull” — ist genau das, wonach Sie Ausschau halten. Siehe Rug-Pull-Abwehr.
Die vollständige Registrierungs- und Probe-Referenz lebt in Firewall: MCP-Server; die End-to-End-Durchführung ist Einen MCP-Server verbinden.

3. Default-Deny, dann die geprüften Tools per Allow-List freigeben

Eine Allow-List ist der Unterschied zwischen „der Server kann sechs Dinge tun” und „der Server kann tun, was sein Betreiber morgen entscheidet”. Setzen Sie das default_verdict der Policy auf deny, fügen Sie dann eine Regel pro Tool hinzu, das Sie geprüft haben und dem Sie vertrauen. Weil das Gateway jedes Tool als <server>.<tool> namespaced, können Sie Regeln auf einen Server scopen, ohne die anderen zu berühren.
// Policy on the mcp surface: deny by default, allow only what you reviewed.
// tool_name_glob supports a full-segment wildcard: "github.*" (prefix),
// "*.exec" (suffix), or "*.shell.*" (infix). Mid-segment globs like
// "github.get_*" fall back to an exact match and won't expand.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Nun läuft github.create_issue, läuft github.get_issue, und ein frisch eingeführtes github.delete_repo wird verweigert, bis Sie es geprüft und erlaubt haben. Ein verweigerter tools/call kommt zum Modell zurück als Tool-Fehler (firewall deny: …) — der Agent passt sich an statt abzustürzen. Siehe MCP-Tools per Allow-List freigeben für das vollständige Rezept und Firewall-Regeln für das matchende DSL.

4. Das Credential verschlüsseln — niemals Auth selbst bauen

Ein Drittanbieter-Server braucht fast immer ein Credential, und ein Credential ist das, was Sie am wenigsten im Klartext sitzen oder das Modell erreichen lassen wollen. Registrieren Sie die Auth des Servers über OrcaRouter, sodass sie im Ruhezustand verschlüsselt, beim Lesen maskiert und nur zur Dispatch-Zeit injiziert wird. auth_mode ist einer von none, bearer, oauth oder basic:
# Console route, UserAuth, Developer+.
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\"}"
  }'
Das Credential wird in dem Moment verschlüsselt und maskiert, in dem es gespeichert wird — es erreicht nie das Modell oder den Client, und beim Lesen sehen Sie nur jemals die Maske. Spiegeln Sie bei einem Update die Maske zurück, um den gespeicherten Wert zu behalten; senden Sie frisches auth_json nur, wenn Sie rotieren. Siehe Authentifizieren und Credential-Rotation.

5. Egress sperren: wohin können seine Tools reichen?

Verdikte pro Aufruf entscheiden, welches Tool läuft; Egress entscheidet, wohin es reichen darf. Ein Tool, das „Daten zurückgibt”, und ein Tool, das „Ihre Secrets an den Host eines Angreifers exfiltriert”, können dasselbe Tool mit einem anderen Argument sein — die Egress-Steuerung ist das, was sie auseinanderhält. Das Gateway validiert bereits jeden Remote-Endpunkt und seine aufgelöste Dial-IP gegen eine SSRF-Policy bei jedem Hop, verweigert Intranet-Bereiche und die Cloud-Metadata-Adresse und prüft die IP neu, um DNS-Rebinding abzuwehren. Obendrauf verfassen Sie Ihre eigene Egress-deny-Regel für die Hosts und CIDRs, die dieser Server nie berühren sollte:
// An egress-stage rule scopes its verdict to the outbound destination.
// egress_json carries host/CIDR allow + deny lists.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
Es gibt kein Preset, das CIDR-Regeln für Sie liefert — Sie verfassen die Host/CIDR-deny-Liste selbst, gescopt auf das, was dieser Server legitimerweise braucht. Siehe Egress-Limits und Datenexfiltration.

6. Quarantänisieren, was der Agent selbst installiert

Der Server, den Sie registriert haben, ist ein Risiko; die Skills, BYO-MCP-Server und Plugins, die ein Agent danach selbst installiert, sind ein anderes. OrcaRouter scannt jede installierbare Fähigkeit, weist ihr ein Risiko-Band zu und leitet einen Durchsetzungsmodus ab — allow, quarantine oder block — der auf jedem Regel-Verdikt obendrauf reitet. Alles, was bei der ersten Nutzung auto-erkannt wird, ist quarantänisiert, bis ein Mensch es prüft: eine Fähigkeit, die niemand genehmigt hat, bekommt keinen Freibrief, nur weil sie harmlos gescannt hat. Eine quarantine-Fähigkeit eskaliert alles unterhalb eines deny auf pending_approval, sodass ihre Tools nur laufen, nachdem Sie hingesehen haben.
Versuchen Sie nicht, jeden Skill von Hand zu registrieren. Genehmigen Sie die vorab, denen Sie vertrauen, und lassen Sie den Rest auto-erkennen und quarantänisieren — prüfen Sie dann aus echten Daten. Der Modus rastet bei einem Re-Scan enger ein, nie lockerer. Siehe Firewall: Skills und MCP-Tool-Poisoning.

7. Erst Shadow, dann den Trail beobachten

Kippen Sie einen brandneuen Server nicht direkt auf Durchsetzung. Setzen Sie die Policy in den Shadow-Modus — durchsetzende Verdikte werden auf audit heruntergestuft und als [shadow] would … geloggt — sodass Sie sehen können, was blockiert worden wäre, bevor es tatsächlich ist. Wenn der Audit-Trail richtig aussieht, lassen Sie den Shadow-Modus fallen und setzen durch. Nachdem er live ist, beobachten die Controls weiter:
Jeder gesteuerte Aufruf zeichnet sein Verdikt, seine Oberfläche und die gematchte Regel auf. Lesen Sie sie, um zu bestätigen, dass die Allow-List und die Egress-Regeln sich wie beabsichtigt verhalten. Siehe MCP-Events auditieren.
Raten- und Kosten-Spikes gegen eine gelernte Baseline, plus Retry-Loops und neuartige Tool-Pfade, tauchen als Anomalien auf — lesbar von jedem Member.
Schalten Sie den Observe-Modus ein, um Aufrufe, die eine Policy noch nicht abdeckt, als Lücken zu loggen, sodass Sie aus dem verschärfen, was ein Agent tatsächlich tut, nicht aus Mutmaßungen.

8. Der schnelle Weg: ein Autonomie-Level wählen

Wenn Sie die Schritte 3–5 für einen Server, dem Sie nicht voll vertrauen, lieber nicht von Hand bauen wollen, wenden Sie ein Autonomie-Level an und bearbeiten Sie von dort. Die Levels schreiben echte, editierbare Policy- und Guardrail-Zeilen — sie sind ein Ausgangspunkt, keine Black Box:
LevelWas es setzt
permissiveObserve-Modus an — loggt alles, setzt nichts durch.
balancedDefault-Audit-Policy, die destruktive Shell verweigert, plus das PII-Shield-Guardrail im Flag-only-Modus.
tightDefault-Deny-Policy, die destruktive Shell und fetch-förmige Tools (http_fetch/web_search/fetch_url/request — der SSRF-Vektor) verweigert, plus die PII-Shield- und Secrets-Blocker-Guardrails durchgesetzt. Secrets in Argumenten werden vom Secrets-Blocker-Guardrail auf der Anfrage abgefangen, nicht von einer Tool-Arg-Regel.
Für einen Drittanbieter-Server, den Sie noch prüfen, starten Sie bei tight, proben, dann lockern Sie spezifische Tools in eine Allow-List. Das Ein-Klick-Undo stellt den Pre-Apply-Snapshot wieder her.
Lesevorgänge von Einstellungen, Policies, entdeckten Tools, Anomalien, registrierten MCP-Servern und Skills sind für jedes Member offen; Event-, Run- und Aggregate-Lesevorgänge erfordern Developer+, und jeder Schreibvorgang erfordert Developer+. Den Klartext-Key eines Tokens zu enthüllen ist ebenfalls Developer+.

9. Wohin als Nächstes

Einen MCP-Server verbinden

Registrieren, proben und einen Server durch das Gateway exponieren.

MCP-Tools per Allow-List freigeben

Default-Deny eines Servers und nur geprüfte Tools zulassen.

Rug-Pull-Abwehr

Einen Server oder Skill erwischen, der sich ändert, nachdem Sie ihn genehmigt haben.

MCP-Sicherheitsübersicht

Die vollständige Karte der MCP-Governance-Oberfläche.
Neu beim Modell? Lesen Sie Guardrails vs. Firewall dafür, wo MCP-Governance hineinpasst, dann Übermäßige Handlungsmacht und Gefährliche Tool-Calls für die Bedrohungen, die diese Checkliste schließt.