MCP-Tool-Poisoning & Rug-Pulls

Ein Drittanbieter-MCP-Server oder ein installierter Skill ist eine Supply-Chain-Abhängigkeit. Zwei Fehlermodi stechen hervor:

• Poisoning — der Server war von Anfang an bösartig. Sein Manifest sah harmlos aus; das gefährliche Verhalten steckte in der Tool-Implementierung, nicht in den deklarierten Scopes.
• Rug-Pull — Sie haben ihm vertraut, dann änderte er sich. Ein neues Tool erschien, das der Betreiber des Servers still hinzugefügt hatte, oder ein Community-Registry-Eintrag wurde gekapert und so aktualisiert, dass er nach Hause telefonierten.

Beide Bedrohungen haben eine gemeinsame Ursache: Nachdem Sie „Ich vertraue diesem Server” gesagt haben, rufen Ihre Agenten weiterhin seine Tools auf — sogar neue oder geänderte — ohne weitere Überprüfung.

​

1. Wie MCP-Tool-Poisoning Ihre Agenten erreicht

Jeder tools/call, den Ihr Agent ausgibt, läuft durch den deklarierten Tool-Satz des MCP-Servers. Ein vergifteter oder rug-gepullter Server nutzt dieses Vertrauen auf einige Weisen aus:

​

2. OrcaRouters Verteidigungen

​

2.1 Jeder tools/call wird vor dem Ausführen firewall-ausgewertet

MCP-Server verbinden sich über das Firewall-MCP-Gateway unter /api/v1/firewall/mcp mit Ihren Agenten. Das Gateway leitet einen Tool-Call erst weiter, wenn die Firewall-Engine ihn gegen Ihre Policy ausgewertet hat. Das bedeutet, Ihre Allowlist ist die Quelle der Wahrheit — nicht das Tool- Manifest des Servers. Wenn ein Rug-Pull shell.exec hinzufügt und Ihre Policy keine Regel hat, die es erlaubt, ist das Verdikt deny und der Aufruf verlässt das Gateway nie. Das Modell empfängt einen Tool-Fehler (firewall deny: …) und kann reagieren; das vom Angreifer hinzugefügte Tool ist bei Ankunft tot. Verdikte, die die Engine zurückgeben kann:

​

2.2 Automatisch erkannte Fähigkeiten werden bis zur Überprüfung quarantäniert

Wenn ein Agent selbst eine Fähigkeit installiert — oder ein Rug-Pull neue Tools hinzufügt, die beim Registrieren des Servers nicht vorhanden waren — erkennt die Firewall die neue Fähigkeit automatisch außerhalb des Hot-Paths, synthetisiert ein Manifest, scannt es und weist ein Risikoband und einen Enforcement-Mode zu. Entscheidend: automatisch erkannte Fähigkeiten werden immer quarantäniert, unabhängig vom Scan-Ergebnis: Sie werden in pending_approval gehalten, bis ein Mensch sie überprüft. So werden Rug-Pulls eingedämmt. Ein Betreiber kann kein neues Tool still hinzufügen und Ihre Agenten es einfach verwenden lassen — diese Aufrufe werden zurückgehalten, bis Sie die neue Fähigkeit inspizieren und genehmigen.

​

2.3 Skill-Scanning weist ein Risikoband und einen Enforcement-Mode zu

Jede installierbare Fähigkeit — ob Sie sie registriert haben oder die Firewall sie automatisch erkannt hat — wird durch den Skill-Scanner geleitet. Der Scanner führt deterministische Durchläufe über das Manifest und deklarierte Scopes durch:

• prompt_injection — Manifest-Text, der versucht, Anweisungen zu kapern.
• tool_creep — Tools, die das Manifest verwendet, aber nie deklariert.
• network_egress — HTTP(S)-Hosts außerhalb der genehmigten Netzwerk-Scopes.
• fs_write_unsafe — Schreib-Modus-Dateisystemzugriff außerhalb /tmp.

Befunde werden zu einem Risikoband zusammengefasst (low / medium / high / critical) und einem Enforcement-Mode: Ein high-Band-Skill wird automatisch quarantäniert; critical wird blockiert. Ein einzelner error-Befund (z. B. tool_creep für ein nicht deklariertes shell.exec) reicht aus, um einen Skill zu blockieren, selbst wenn sein numerischer Score niedrig aussieht. Der Mode verschärft sich nur — einen Skill zu genehmigen entspannt nie einen durch einen frischen Scan gesetzten Block.

​

2.4 Credentials werden verschlüsselt gespeichert

Server-Auth-Secrets werden im Ruhezustand mit einem Workspace-Secrets-Schlüssel verschlüsselt und vom Gateway zur Dispatch-Zeit injiziert. Sie erreichen nie das Modell, den Agenten oder die Aufruf-Argumente. Ein kompromittierter Server kann Ihre API-Keys nicht exfiltrieren, indem er sein eigenes auth_json liest.

​

3. Was nach einem vermuteten Rug-Pull zu tun ist

1. Den Server sofort deaktivieren — ein deaktivierter Server wird aus der Laufzeit-Registry entfernt und seine Credentials werden nie entschlüsselt. Verwenden Sie PUT /api/workspace/firewall/mcp_servers mit "enabled": false.
2. Erneut sondieren, um Änderungen zu entdecken — POST /api/workspace/firewall/mcp_servers/:id/probe führt tools/list aus und gibt alle neuen Tools zurück, die seit Ihrer letzten Sondierung erschienen sind.
3. Den Skill-Datensatz erneut scannen — POST /api/workspace/firewall/skills/:id/rescan führt den Scanner erneut gegen das aktualisierte Manifest aus. Wenn das Verdikt zu flagged oder blocked degradiert, sendet die Firewall ein Event in Ihren Feed.
4. pending_approval-Warteschlange überprüfen — alle Aufrufe, die seit dem Rug-Pull zurückgehalten wurden, sind in der Warteschlange. Inspizieren und verweigern Sie sie, anstatt sie bulk-zuzugenehmigen.
5. Call-Log auditieren — prüfen Sie den Firewall-Event-Trail auf Aufrufe, die durchgegangen sind, bevor Sie die Änderung erkannt haben.

​

4. Skill-Scanning mit Firewall-Regeln kombinieren

Skill-Scanning und Firewall-Regeln sind komplementär und komponieren:

• Eine Regel mit tool_name_glob: community.* auf pending_approval stellt sicher, dass Sie jeden Aufruf von einem community-sourced Server überprüfen, unabhängig vom Risikoband.
• Ein quarantänierter Skill überschreibt eine allow-Regel — selbst wenn Ihre Policy http.fetch breit erlaubt, hält ein quarantänierter Skill, der es besitzt, den Aufruf trotzdem zurück.
• Verwenden Sie skill_name_glob in einer Regel, um engere Policies auf nicht vertrauenswürdige Server zu begrenzen, ohne Ihre Erstanbieter-Integrationen zu beeinträchtigen.

Siehe Firewall: MCP-Server für das vollständige Gateway-Modell und Firewall: Skills für den Scanner und die Enforcement-Mode-Referenz.

​

5. Verwandte Bedrohungen

• Gefährliche Tool-Calls — Regeln zum Blockieren destruktiver oder irreversibler Tool-Aktionen unabhängig von der Quelle.
• Datenexfiltration — Egress-Regeln, die einschränken, wohin Tool-Calls Daten senden dürfen.
• Bedrohungsmodell — die vollständige Angriffsfläche, die OrcaRouter verteidigt.