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.
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.
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 dasdefault_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.
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:
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: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.
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:
Firewall-Events
Firewall-Events
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.
Anomalie-Feed
Anomalie-Feed
Raten- und Kosten-Spikes gegen eine gelernte Baseline, plus Retry-Loops und
neuartige Tool-Pfade, tauchen als Anomalien auf — lesbar von jedem
Member.
Entdeckte Tools
Entdeckte Tools
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:| Level | Was es setzt |
|---|---|
permissive | Observe-Modus an — loggt alles, setzt nichts durch. |
balanced | Default-Audit-Policy, die destruktive Shell verweigert, plus das PII-Shield-Guardrail im Flag-only-Modus. |
tight | Default-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. |
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.
