Zum Hauptinhalt springen
Jeder MCP-Server, den Sie registrieren, jeder Skill, den ein Agent installiert, und jeder Host, den ein Tool erreicht, ist eine Abhängigkeit, die Sie nicht geschrieben haben. Die Supply Chain eines Agenten ist dynamisch — sie wächst zur Laufzeit, oft ohne einen Menschen in der Schleife — sodass das klassische „die Lockfile zur Build-Zeit überprüfen”-Modell nicht hält. Ein Community-Skill kann gekapert werden, nachdem Sie ihm vertrauen; ein entfernter MCP-Server kann leise ein Tool hinzufügen; ein Fetch-Tool kann zu einem angreifer-kontrollierten Host gesteuert werden. OrcaRouters Antwort ist, die Supply Chain dort zu steuern, wo sie handelt — am Gateway, bei der ersten Nutzung — statt zu versuchen, jede Abhängigkeit zur Installationszeit zu prüfen. Diese Seite ist die Use-Case-Landung für ai supply chain security; die Firewall- und Skills-Referenzen tragen die vollständige Mechanik.

​
1. KI-Supply-Chain-Sicherheit für Agenten, am Gateway

Der Engpass ist der Relay-Pfad. Ob eine Fähigkeit von Hand registriert, vom Agenten auto-installiert oder aus einer Community-Registry gezogen wurde — ihr erster Tool-Call überquert api.orcarouter.ai — und dort wertet die Firewall sie aus. Vier Kontrollen komponieren zu einer einzigen Haltung:

MCP-Gateway, Pro-Aufruf-Eval

Jeder tools/call wird vor dem Dispatch gegen Ihre Policy ausgewertet — das Manifest ist nie die Quelle der Wahrheit.

Skill-Risikobänder & Quarantäne

Installierte Fähigkeiten werden gescannt, bewertet und zur Überprüfung zurückgehalten, bis ein Mensch sie genehmigt.

Verschlüsselte MCP-Anmeldedaten

Server-Auth-Secrets sind im Ruhezustand verschlüsselt und werden beim Dispatch injiziert — nie dem Modell, dem Agenten oder den Aufruf-Argumenten ausgesetzt.

Egress-Allow-Lists

Pinnen Sie, wohin Tool-Calls Daten senden dürfen, sodass eine kompromittierte Abhängigkeit nicht zu einem Host exfiltrieren kann, den Sie nie genehmigt haben.
Die Erkennung erfolgt am Gateway, bei der ersten Nutzung — nicht in Ihrem Paketmanager oder Dateisystem. Das ist beabsichtigt: Es ist der eine Pfad, der jeden Agenten und jeden Tool-Call sieht, ganz gleich, wie die Fähigkeit dorthin gelangt ist.

​
2. Die Bedrohung: eine Abhängigkeit, die wächst, nachdem Sie ihr vertrauen

VektorWas passiert
Rug-PullEin registrierter MCP-Server fügt ein Tool (shell.exec, ein neues fetch) hinzu, das Sie nie genehmigt haben.
Skill-CreepEin installierter Skill verwendet Tools oder Hosts, die sein Manifest nie deklariert hat.
Anmeldedaten-DiebstahlDie Tool-Implementierung eines kompromittierten Servers liest ihr eigenes Auth-Secret, um nach Hause zu telefonieren.
Egress-ExfiltrationEine retrieve→send-Kette verschickt Ihre Daten an einen angreifer-kontrollierten Host.
Die gemeinsame Grundursache: „Ich vertraue diesem Server” wird als permanent behandelt, und der Agent ruft weiterhin neue oder modifizierte Tools ohne weitere Überprüfung auf.

​
3. Ein konkretes Beispiel — einen MCP-Server registrieren und pinnen

Sie registrieren einen Drittanbieter-MCP-Server aus der Konsole (Settings → Firewall → MCP servers; Schreibvorgänge benötigen Developer+). Das Auth-Secret des Servers wird verschlüsselt gespeichert — Sie liefern es einmal, das Gateway injiziert es beim Dispatch, und es ist bei jedem Lesen danach maskiert. Ein MCP-Server-Datensatz trägt:
FeldWerte
auth_modenone, bearer, oauth, basic
statusok, degraded, down (durch die Health-Probe gesetzt)
credentialsim Ruhezustand verschlüsselt, nie im Klartext zurückgegeben
Nach dem Registrieren proben Sie ihn aus der Konsole, um seine aktuellen Tools aufzuzählen. Die Probe ist eine Workspace-Session-Operation (/api/workspace/firewall/*), die Developer+ benötigt, nicht einen Relay-Key — Registrieren, Proben und Regel-Verfassen geschehen alle auf der Management-Ebene: 
# Console / management plane — workspace session, Developer+.
# (The relay sk-orca-... key is for /v1/* traffic only.)
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/<id>/probe \
  -H "Authorization: Bearer <workspace-session-token>"
Die Probe persistiert die Erreichbarkeit des Servers und snapshotet einen Baseline-Hash seines beworbenen Tool-Sets (Trust-on-first-use). Dann scopen Sie eine Firewall-Regel mit tool_name_glob: <server>.* auf pending_approval, bis Sie eine saubere Aufrufhistorie gesehen haben — jeder Aufruf von diesem Server wird für einen Menschen zurückgehalten, bevor er läuft. Sobald Sie ihm vertrauen, lockern Sie die Regel auf audit oder allow. Von da an evaluiert das MCP-Gateway jeden tools/call auf der mcp-Surface vor dem Dispatch — sodass, wenn ein Rug-Pull später ein undeklariertes Tool hinzufügt, Ihre Policy, nicht das Manifest des Servers, entscheidet, ob es läuft.
Re-proben Sie nach jedem Upstream-Versions-Bump (POST /api/workspace/firewall/mcp_servers/:id/probe, Developer+). Wenn das beworbene Tool-Set von der genehmigten Baseline abweicht, kippt der schema_status des Servers auf changed und der Dispatch failt closed, bis ein Admin re-baselinet (approve_schema) oder ihn quarantäniert — der Rug-Pull kann nicht still live gehen.

​
4. Skill-Risikobänder & Quarantäne

Jede installierbare Fähigkeit — ob Sie sie registriert haben oder das Gateway sie zur Laufzeit auto-detektiert hat — wird durch den Skill-Scanner geführt. Findings rollen zu einem Risikoband und einem Enforcement-Mode auf:
low · medium · high · critical. Das Band wird aus deterministischen Scanner-Durchläufen über das Manifest und die deklarierten Scopes abgeleitet (undeklarierte Tool-Nutzung, Netzwerk-Egress außerhalb genehmigter Scopes, unsichere Dateisystem-Schreibvorgänge, injection-förmiger Manifest-Text).
allow (Ihre Policy-Regeln entscheiden), quarantine (jedes Nicht-deny-Verdikt eskaliert zu pending_approval — ein Mensch genehmigt jeden Aufruf), block (deny auf allen Tools dieses Skills erzwingen, unabhängig von Regeln). Ein high-Band-Skill quarantäniert automatisch; critical blockiert.
Eine Fähigkeit, die ein Agent selbst installiert, oder ein Tool, das ein Rug-Pull hinzufügt, wird in pending_approval zurückgehalten, unabhängig von seinem Scan-Score, bis ein Mensch es überprüft. Ein Operator kann nicht leise ein Tool hinzufügen und Ihre Agenten es nutzen lassen.
Der Enforcement-Mode rastet immer nur enger — das Genehmigen eines Skills lockert nie einen Block, den ein frischer Scan gesetzt hat.

​
5. Egress-Allow-Lists — das „nach Hause telefonieren” eindämmen

Das schädlichste Supply-Chain-Resultat ist eine kompromittierte Abhängigkeit, die exfiltriert. Die egress-Surface der Firewall wertet das ausgehende Ziel (Host / IP / CIDR) aus, das ein Tool meldet, sodass Sie pinnen können, wohin Daten gehen dürfen. Sie verfassen eine Egress-Regel selbst: eine Host/CIDR-Allow-List mit einem cidr_match-Prädikat lehnt alles ab, was nicht auf der Liste steht. Kombinieren Sie sie mit einer Sequenz-Regel, die die retrieve→egress-Kette bricht, und ein vergiftetes Tool, das versucht, ein abgerufenes Dokument an einen unbekannten Host zu verschicken, wird am Gateway abgelehnt.
Die tight-Autonomie-Stufe liefert ein SSRF-Preset, aber es lehnt fetch-förmige Tool-Namen (http_fetch, web_search, fetch_url, request) ab — es ist keine CIDR-/Cloud-Metadata-Denylist. Wenn Sie RFC-1918- / Metadata- / spezifisches-CIDR-Egress-Blocking brauchen, verfassen Sie die Egress-Host/CIDR-Deny-Regel selbst. Siehe Firewall: Regeln für den cidr_match-Operator und das Egress-Scoping.

​
6. Verschlüsselte Anmeldedaten — ein kompromittierter Server kann Ihre Keys nicht lesen

Server-Auth-Secrets sind im Ruhezustand verschlüsselt und werden vom Gateway zur Dispatch-Zeit injiziert. Sie erreichen nie das Modell, den Agenten oder die Tool-Call-Argumente — sodass ein kompromittierter oder bösartiger Server Ihre API-Keys nicht exfiltrieren kann, indem er seinen eigenen Anmeldedaten-Blob liest. Die Konsole gibt das Secret immer maskiert zurück — selbst einem Admin. Der entschlüsselte Wert wird auf genau einem Pfad ausgehändigt: einem Request, der einen firewall-gateway-scoped Token trägt (ein dedizierter Token-Typ, den ein Admin explizit für das Gateway/den Proxy prägt), sodass ein gewöhnlicher geleakter Relay-Key Ihre MCP-Anmeldedaten nicht aufzählen kann.

​
7. Für ein Audit zusammenrollen

Supply-Chain-Governance ist auch ein Audit-Artefakt. OrcaRouter mappt auf die OWASP Top 10 for LLM Applications — einschließlich der LLM05 Supply Chain-Kontrolle — als Teil der Compliance-Engine, neben Frameworks wie soc2, iso_27001, iso_42001, nist_ai_rmf und dem eu_ai_act. Das Installieren eines Compliance-Packs (POST /api/compliance/packs/:key/install, Workspace-Admin, kostenpflichtiger Plan) materialisiert die passenden Guardrails und Firewall-Policies und startet in einer Observe-first-Haltung. Compliance-Reports enthalten eine AI-supply-chain-evidence-Sektion — die Upstream-Anbieter, zu denen Ihr Workspace tatsächlich geroutet hat, plus eine Privileged-access- und Key-hygiene-Überprüfung — und sind Ed25519-signiert und öffentlich verifizierbar. Das Durchsuchen des Katalogs und der Readiness ist für jedes Member kostenlos; siehe Compliance für den vollständigen Lebenszyklus.
MCP-Governance besteht aus zwei komplementären Ebenen: Pro-Aufruf-Firewall-Auswertung auf der mcp-Surface (Durchsetzung dessen, was eine Abhängigkeit tut), plus einer Tool-Schema-Integritäts-Baseline (Trust-on-first-use-Hash des beworbenen Tool-Sets, bei jeder Probe neu geprüft — Drift kippt den schema_status des Servers auf changed und failt den Dispatch closed, bis ein Admin re-baselinet oder quarantäniert). Zusammen mit Skill-Risikobändern und Quarantäne ist das Durchsetzung sowohl dessen, was eine Abhängigkeit tut, als auch ein verifizierbarer Datensatz dessen, was sie deklariert hat.

​
8. Eine Supply-Chain-Baseline

Registrieren Sie ihn, proben Sie sein Tool-Set und scopen Sie eine <server>.*-Regel auf pending_approval oder audit. Lesen Sie die Scan-Findings — jedes undeclared-tool- oder external-egress-Finding ist ein Grund, ihn quarantäniert zu halten. Verifizieren Sie, wer die Endpunkt-URL kontrolliert.
Halten Sie eine Egress-Allow-List für jeden Agenten mit Fetch/Search/Export-Tools gepinnt. Beobachten Sie die Discovered-tools-Ansicht auf Fähigkeiten, die ohne eine Regel auftauchten, und den Anomalie-Feed auf neuartige Tool-zu-Tool-Pfade.
Deaktivieren Sie den Server (PUT .../mcp_servers, "enabled": false) — seine Anmeldedaten werden nie entschlüsselt, während er deaktiviert ist. Re-proben Sie, um neue Tools sichtbar zu machen, rescannen Sie den Skill und überprüfen Sie die pending_approval-Warteschlange, statt massen-zu-genehmigen.

​
9. Verwandte Bedrohungen & Konzepte

Firewall: MCP-Server

MCP-Server hinter dem Gateway registrieren, ihre Tools proben und ein Pro-Aufruf-Verdikt anwenden, bevor ein Aufruf den echten Server erreicht.

Firewall: Skills

Jede installierbare Fähigkeit scannen und risikobewerten. Riskante Skills quarantänieren oder blockieren, bevor ihre Tools laufen.