Zum Hauptinhalt springen
Ein „Rug Pull” ist ein MCP-Server, der seine Tool-Definitionen ändert, nachdem Sie ihn genehmigt haben — ein vertrauenswürdiges Tool neu definieren, damit es etwas Neues tut, oder still eines hinzufügen. OrcaRouter erwischt dies auf der Schema-Ebene: es baseliniert den beworbenen Tool-Satz jedes Servers und prüft ihn bei jedem Laden neu, sodass Drift fail-closed schließt, statt die geänderten Tools still zu bedienen. Diese Seite ist die Referenz für den Pro-Server-Schema-Status und was jeder Zustand für den Traffic bedeutet.

​
1. Der Baseline-Fingerabdruck

Beim ersten Kontakt berechnet das Gateway einen kanonischen Hash des beworbenen Tool-Satzes des Servers und speichert ihn als die genehmigte Baseline:
  • Der Hash deckt den Namen, die Beschreibung und das Input-JSON-Schema jedes Tools ab — genau die Oberfläche, die ein Rug Pull verändern würde (ein Tool, das ein exfiltrierendes Argument bekommt, oder eine für Prompt-Injection waffenfähig gemachte Beschreibung kippt den Hash).
  • Er ist reihenfolgeunabhängig: ein Server, der seine Tool-Liste neu ordnet oder Keys innerhalb eines Schemas neu ordnet, sieht nicht wie eine Änderung aus. Nur eine echte Definitionsänderung bewegt den Hash.
Bei jedem späteren Probe re-hasht das Gateway die Live-Tools und vergleicht sie mit der gespeicherten Baseline. Dies ist eine Pro-Server-Prüfung — sie hängt von keiner Regel ab, die Sie verfassen.

​
2. Der Schema-Status-Lebenszyklus

Jeder registrierte Server trägt einen schema_status. Die Zustände und wie sie beeinflussen, ob die Tools des Servers bedient werden:
StatusBedeutungTools bedient?
(unbaseliniert)Erste Nutzung — noch keine Baseline aufgezeichnet.Discovery-Haltung: Ja (Trust-on-first-use — das aktuelle Schema wird als Baseline erfasst). Strenge Haltung: Nein — siehe pending unten.
verifiedLive-Schema passt zur genehmigten Baseline.Ja
changedDrift erkannt — das Live-Schema weicht von der Baseline ab.Nein — schließt fail-closed
pendingEin unbaselinierter Server unter einer strengen Haltung (kein Trust-on-first-use) — wartet auf Genehmigung.Nein — schließt fail-closed
quarantinedEin Admin hat den Server zurückgehalten.Nein — schließt fail-closed
Die drei geschlossenen Zustände — changed, pending, quarantined — stoppen alle die Bedienung der Tools des Servers durch das Gateway. verified bedient immer; ein unbaselinierter Server bedient nur unter der Discovery-Haltung (Trust-on-first-use) und wird unter der strengen Haltung als pending zurückgehalten. Drift passiert nie still.

​
3. Was bei Drift passiert

Wenn eine Neuprüfung feststellt, dass das Live-Schema nicht mehr zur Baseline passt:
1

Status kippt zu changed

Der schema_status des Servers wird changed und der Drift-Zeitstempel wird aufgezeichnet.
2

Tools werden nicht mehr bedient

Das Gateway schließt fail-closed: die Tools dieses Servers werden von der vereinheitlichten MCP-Oberfläche zurückgehalten, sodass ein Agent die geänderten Definitionen nicht aufrufen kann.
3

Die Konsole zeigt es an

Der Drift taucht zur Prüfung auf, sodass ein Admin den neuen Tool-Satz gegen den genehmigten vergleichen kann.
4

Neu baselinieren oder quarantänisieren

Ein Admin genehmigt das neue Schema (baseliniert neu — der aktuelle Tool-Satz wird die neue verified-Baseline) oder quarantänisiert den Server. Bis eines davon passiert, bleibt der Server geschlossen.

​
4. Einen gedrifteten Server neu genehmigen

Das Neu-Baselinieren ist ein einzelner Aufruf (oder die Konsolen-Aktion): 
POST /api/workspace/firewall/mcp_servers/:id/approve_schema
Erfordert die Rolle Developer. Es zeichnet den Live-Tool-Satz als die neue genehmigte Baseline auf und setzt den Server auf verified zurück. (Einen Server zu quarantänisieren ist eine separate Aktion, für den Fall, dass Sie entscheiden, dass die Änderung feindselig ist — approve_schema baseliniert nur neu auf verified.) Die Aktion wird in den Audit-Trail geschrieben.
Genehmigen Sie erst neu, nachdem Sie das Diff geprüft haben. Ein gedriftetes Schema ohne Prüfung zu genehmigen, hebelt das Control aus — es sagt OrcaRouter, dass die neuen (möglicherweise bösartigen) Tool-Definitionen vertrauenswürdig sind.

​
5. Wo das hineinpasst

Die Schema-Drift-Erkennung ist die Schema-Ebenen-Hälfte der Rug-Pull-Abwehr; die andere Hälfte ist die Auswertung pro Aufruf auf der mcp-Oberfläche (jeder tools/call wird beim Dispatch gegen Ihre Policy geprüft). Zusammen decken sie sowohl „die Definitionen haben sich geändert” als auch „dieser spezifische Aufruf ist gefährlich” ab.

Rug-Pull-Abwehr

Das vollständige Rug-Pull-Bild — Schema-Baseline plus Auswertung pro Aufruf.

MCP-Sicherheitsübersicht

Das MCP-Gateway, Skills und Credentials.

MCP-Tool-Poisoning

Die Bedrohung, gegen die dieser Zustandsautomat verteidigt.

MCP-Audit-Events

Schema-Änderungen und Gateway-Entscheidungen überwachen.