Zum Hauptinhalt springen
Ein „Rug Pull” ist der MCP-Fehlermodus, bei dem sich ein Server brav verhält, während Sie zusehen, und feindselig wird, sobald ihm vertraut wird: ein Tool, das Sie zur Verbindungszeit genehmigt haben, beginnt, zusätzliche Argumente einzuschmuggeln, ein von Ihnen gelisteter Community-Server fügt still eine neue Fähigkeit hinzu, oder ein vom Agenten selbst installierter Skill kippt in der Produktion von harmlos zu gefährlich. Die Gefahr ist, dass niemand eine Verbindung neu prüft, nachdem sie live ist — die Vertrauensentscheidung wurde einmal getroffen, beim Handshake, und nie überdacht. OrcaRouter vertraut dem Handshake nicht. Es verteidigt an drei Fronten. Das MCP-Gateway der Firewall wertet jeden tools/call zur Dispatch-Zeit gegen Ihre Live-Policy aus. Der beworbene Tool-Satz jedes registrierten Servers wird beim ersten Probe baseliniert und auf Drift neu geprüft — wenn sich das Tool-Schema von der genehmigten Baseline ändert, schließt der Server fail-closed, bis ein Admin neu genehmigt oder quarantänisiert. Und die Skills-Ebene weist jeder installierten Fähigkeit ein Risiko-Band und einen Durchsetzungsmodus zu — sie quarantänisiert alles Riskante oder Ungeprüfte, bis ein Mensch abzeichnet. Ein Server kann sich keinen Freibrief verdienen, indem er sich für die ersten hundert Aufrufe brav verhält.

​
1. Warum MCP-Rug-Pull-Schutz Auswertung pro Aufruf braucht

Eine Prüfung zur Verbindungszeit beantwortet eine Frage einmal: Ist dieser Server sicher zu listen? Sie kann die Frage nicht beantworten, die zur Laufzeit tatsächlich zählt: Ist dieser spezifische Aufruf, mit diesen spezifischen Argumenten, gerade jetzt sicher? OrcaRouter beantwortet die zweite Frage. Jeder tools/call, der das Gateway quert, wird auf der mcp-Oberfläche ausgewertet, bevor er an den echten Server dispatcht wird, mit Tool-Namen und Argumenten zur Hand. Das Verdikt wird jedes Mal frisch berechnet, sodass in dem Moment, in dem ein Tool anfängt, etwas zu tun, das Ihre Policy verbietet — ein Secret in einem Argument exfiltrieren, einen Host erreichen, der verweigert ist, eine nie genehmigte Fähigkeit aufrufen — der Aufruf gestoppt wird, unabhängig davon, wie sich dasselbe Tool vor einer Minute verhalten hat.
Auswertung pro Aufruf steuert das Verhalten jedes Aufrufs — Argument-Inhalte, Ziele, das Risiko des besitzenden Skills — sodass sie einen Rug Pull selbst dann erwischt, wenn das Tool eine identische Signatur behält und nur sein Verhalten feindselig wird. Die Schema-Drift-Erkennung (§ unten) ist die ergänzende Ebene: sie erwischt den Fall, in dem sich der beworbene Tool-Satz des Servers selbst ändert. Beide laufen.
Die Verdikte, die die Engine auf der mcp-Oberfläche zurückgeben kann:

allow / audit

An den Server weitergeleitet. audit loggt den Aufruf; allow bleibt still.

sanitize

Weitergeleitet mit zuvor redigierten Tool-Call-Argumenten (es schreibt nie um, was der Server zurückgibt).

deny

Zum Modell zurückgegeben als Tool-Fehler (firewall deny: …), sodass der Agent sich anpassen kann, statt abzustürzen.

pending_approval

Der Aufruf wird zurückgehalten, damit ein Mensch ihn auflöst, bevor er laufen kann.

​
2. Skill-Risiko-Band-Quarantäne

Die zweite Hälfte der Rug-Pull-Abwehr deckt die Lieferkette ab: die Skills, Plugins und Bring-your-own-MCP-Server, die ein Agent installiert. Jeder wird als workspace-bezogener Datensatz registriert, von einer deterministischen Risiko-Engine gescannt und mit einem Risiko-Band (low / medium / high / critical) sowie einem Durchsetzungsmodus versehen:
ModusEffekt zur Laufzeit
allowRegel-Verdikte entscheiden; der Skill fügt nichts hinzu.
quarantineAlles unterhalb eines deny wird auf pending_approval eskaliert — Tools laufen nur, nachdem ein Mensch genehmigt.
blockDie Tools des Skills werden rundheraus verweigert.
Hier wird ein Rug Pull eingedämmt. Eine Fähigkeit, die ein Agent selbst installiert, ist auto_detected und bis zur Prüfung quarantänisiert — selbst wenn sie sauber gescannt hat, läuft sie nicht aus eigener Autorität. Und der Modus eines Skills rastet bei einem Re-Scan nur jemals enger ein: ein block oder quarantine, das Sie gesetzt haben, wird nie still gelockert, wenn ein Manifest erneut präsentiert wird.
Quarantäne wird unabhängig vom Shadow-Modus durchgesetzt. Ein auf quarantine oder block gesetzter Skill wird weiterhin zurückgehalten, auch während die umgebende Policy im Shadow-Rollout ist — sodass eine riskante Fähigkeit während eines gestaffelten Deployments nicht durchschlüpfen kann.
Siehe Firewall: Skills für den vollständigen Scanner, die Scoring-Gewichte und die Trust-Signale.

​
3. Tool-Schema-Drift-Erkennung

Der klassische Rug Pull ist ein registrierter Server, der ändert, was er bewirbt — ein Tool hinzufügt, das Input-Schema eines Tools verändert, eine Beschreibung austauscht. OrcaRouter baseliniert den beworbenen Tool-Satz jedes registrierten Servers bei einem erfolgreichen Probe und beobachtet ihn auf Drift.

Baseline beim ersten Probe

Das erste erfolgreiche Probe zeichnet einen kanonischen Hash der Tools des Servers auf (Trust-on-first-use unter einer Discovery-Haltung; unter einer durchsetzenden Haltung wird ein unbaselinierter Server als pending zurückgehalten, bis ein Admin seinen initialen Tool-Satz genehmigt).

Drift schließt fail-closed

Bei einem späteren Probe, wenn der kanonische Tool-Satz nicht mehr zur genehmigten Baseline passt, wird der Server als changed markiert und hört auf, bedient zu werden — das Gateway dispatcht seine Tools nicht, bis Sie entscheiden.

Genehmigen oder quarantänisieren

Genehmigen Sie erneut, um auf das neue Schema neu zu baselinieren, oder quarantänisieren Sie den Server. Ein quarantänisierter Server ist auch deaktiviert, und nur eine explizite Genehmigung stellt den Dienst wieder her — ein einfaches Bearbeiten kann ihn nicht reaktivieren.

Auditiert

Die erste Erkennung von Drift von einer genehmigten Baseline schreibt einen Workspace-Audit-Eintrag, sodass die Änderung aktenkundig ist.
Der Schema-Status eines Servers ist einer von unknown (nie baseliniert), verified (passt zur Baseline), changed (gedriftet, zurückgehalten), pending (unbaseliniert unter Durchsetzung) oder quarantined. Diese Ebene erwischt den Rug Pull, der das Schema bewegt; die Auswertung pro Aufruf (§1) erwischt den, der eine identische Signatur behält und nur das Verhalten ändert.

​
4. Ein konkretes Beispiel

Angenommen, ein Community-MCP-Server notes bewirbt ein harmloses notes.search-Tool. Sie listen es, prüfen es, und es funktioniert. Eine Woche später ist der Server kompromittiert und notes.search beginnt, ein Exfiltrations-Argument anzuhängen, das Ihren Kontext per POST an einen Angreifer-Host sendet. Ein nur-zur-Verbindungszeit-Gateway würde es weiterleiten — Tool-Name und Schema sehen unverändert aus. OrcaRouter wertet den Aufruf aus: 
# Configure the deny rule in the console (Developer+), not via the relay key.
# Rule: on the mcp surface, deny notes.search whenever it carries an
#       exfiltration-shaped argument.
#   tool_name_glob: notes.search
#   args_match:     { "path": "$.callback_url", "op": "regex",
#                     "value": "^https?://(?!notes\\.example/)" }  → deny
(args_match-Operatoren sind eq, contains, regex, in, cidr_match, gt, lt; cidr_match testet ein IP-wertiges Argument gegen einen CIDR. Um zu begrenzen, wohin ein Tool nach Host/CIDR reichen darf, verwenden Sie die Egress-Zielliste statt einer Argument-Klausel.) Beim Dispatch gibt die Engine deny zurück, und statt den Aufruf weiterzuleiten, übergibt das Gateway dem Agenten einen MCP-Tool-Result-Fehler — ein normales Ergebnis, das als Fehler markiert ist, kein Transportfehler — sodass das Modell sich anpassen kann: 
firewall deny: <your rule's reason>
Derselbe Aufruf, der letzte Woche erfolgreich war, ist jetzt blockiert — weil die Entscheidung über den Aufruf getroffen wird, nicht über die Verbindung.
sanitize redigiert die Argumente, die Ihr Agent sendet, nie den Inhalt, den ein Tool zurückgibt. Wenn Sie einschränken müssen, wohin ein Tool reichen darf, paaren Sie eine deny-Regel mit einer Egress-Zielliste — verlassen Sie sich nicht auf sanitize, um Antworten zu säubern.

​
5. Wie es zusammenpasst

Die Auswertung pro Aufruf erwischt ein vertrauenswürdiges Tool, das bösartig wird — gleicher Name, neues Verhalten in den Argumenten oder im Ziel. Die Skill-Quarantäne erwischt eine neue oder ungeprüfte Fähigkeit, die überhaupt erscheint — ein auto-erkannter Install, ein neu gescanntes Manifest, das neu degradiert. Ein Rug Pull kann beide Formen annehmen, also laufen beide: der Modus des Skills reitet auf dem Regel-Verdikt pro Aufruf obendrauf.
Ja — siehe §3. Der beworbene Tool-Satz jedes registrierten Servers wird beim ersten Probe baseliniert und auf Drift neu geprüft; ein gedrifteter Server schließt fail-closed, bis Sie neu genehmigen oder quarantänisieren. Das ist ergänzend zur Auswertung pro Aufruf, die auch ein Tool erwischt, das eine identische Signatur behält und nur sein Verhalten ändert.
Ein pending_approval-Verdikt hält den Aufruf zurück, damit ein Mensch ihn in der Konsole (Developer+) oder über einen HMAC-Approval-Callback auflöst. Siehe Durchsetzungsmodi dafür, wie Zurückhaltungen und Genehmigungen einem Agenten präsentiert werden.

​
6. Konfiguration

Jeder Schritt unten ist eine Konsolen- / Management-Aktion, die mit Ihrer Session oder Ihrem Access-Token authentifiziert ist — nicht dem sk-orca-…-Relay-Key. Nur /v1/*-Relay-Traffic verwendet den Relay-Key.
1

Registrieren Sie Ihre MCP-Server hinter dem Gateway

Verbinden Sie jeden Server, sodass seine Tools unter einem auditierten Endpunkt beworben werden. Die Registrierung ist Developer+.
2

Setzen Sie ein Default-Verdikt und Regeln auf der mcp-Oberfläche

Verfassen Sie Regeln mit tool_name_glob und args_match, sodass riskante Aufrufe zu deny, sanitize oder pending_approval auflösen. Siehe die Firewall-Regel-Referenz.
3

Prüfen Sie quarantänisierte Skills

Alles Auto-Erkannte sitzt in quarantine, bis ein Prüfer (Developer+) es genehmigt. Lesen Sie zuerst das Band und die Befunde.
4

Im Shadow ausrollen, dann durchsetzen

Verwenden Sie Durchsetzungsmodi, um neue Regeln im Shadow laufen zu lassen, beobachten Sie die Audit-Events und schalten Sie auf Durchsetzung, sobald die Verdikte richtig aussehen.
Lesevorgänge (Einstellungen, Policies, entdeckte Tools, Anomalien) sind für jedes Member offen; jeder Schreibvorgang ist Developer+. Das Lesen des Klartexts eines Firewall-Gateway-Keys ist Developer+.

​
Verwandt

Firewall: MCP-Server

Die vollständige MCP-Gateway-Referenz — Registrierung, Proben, Dispatch.

Firewall: Skills

Scanner-Durchläufe, Risiko-Scoring und die Quarantäne-Ableitung.

MCP-Tool-Poisoning

Das Bedrohungsmodell, dem die Rug-Pull-Abwehr begegnet.

Egress-Limits

Verfassen Sie Host/CIDR-deny-Regeln, um zu begrenzen, wohin Tools reichen dürfen.

Trust-Checkliste

Die End-to-End-Checkliste, um einem MCP-Server zu vertrauen.

Guardrails vs. Firewall

Wann Content-Policy gilt und wann die Firewall.