Skip to main content
A “rug-pull” is an MCP server that changes its tool definitions after you approved it — re-defining a trusted tool to do something new, or quietly adding one. OrcaRouter catches this at the schema layer: it baselines each server’s advertised tool set and re-checks it on every load, so drift fails closed instead of silently serving the changed tools. This page is the reference for the per-server schema status and what each state means for traffic.

​
1. The baseline fingerprint

On first contact the gateway computes a canonical hash of the server’s advertised tool set and stores it as the approved baseline:
  • The hash covers every tool’s name, description, and input JSON schema — exactly the surface a rug-pull would alter (a tool gaining an exfiltrating argument, or a description weaponized for prompt injection flips the hash).
  • It is order-independent: a server re-ordering its tool list, or re-ordering keys inside a schema, does not look like a change. Only a real definition change moves the hash.
On every later probe the gateway re-hashes the live tools and compares them to the stored baseline. This is a per-server check — it does not depend on any rule you author.

​
2. The schema status lifecycle

Each registered server carries a schema_status. The states and how they affect whether the server’s tools are served:
StatusMeaningTools served?
(unbaselined)First use — no baseline recorded yet.Discovery posture: Yes (trust-on-first-use — the current schema is captured as the baseline). Strict posture: No — see pending below.
verifiedLive schema matches the approved baseline.Yes
changedDrift detected — the live schema differs from the baseline.No — fails closed
pendingAn unbaselined server under a strict (no trust-on-first-use) posture — awaiting approval.No — fails closed
quarantinedAn admin has held the server.No — fails closed
The three closed states — changed, pending, quarantined — all stop the server’s tools from being served through the gateway. verified always serves; an unbaselined server serves only under the discovery posture (trust-on-first-use) and is held as pending under the strict posture. Drift never silently passes.

​
3. What happens on drift

When a re-check finds the live schema no longer matches the baseline:
1

Status flips to changed

The server’s schema_status becomes changed and the drift timestamp is recorded.
2

Tools stop being served

The gateway fails closed: that server’s tools are withheld from the unified MCP surface, so an agent cannot call the changed definitions.
3

The console surfaces it

The drift shows up for review so an admin can compare the new tool set against the approved one.
4

Re-baseline or quarantine

An admin approves the new schema (re-baselines — the current tool set becomes the new verified baseline) or quarantines the server. Until one of those happens, the server stays closed.

​
4. Re-approving a drifted server

Re-baselining is a single call (or the console action): 
POST /api/workspace/firewall/mcp_servers/:id/approve_schema
Requires the Developer role. It records the live tool set as the new approved baseline and returns the server to verified. (Quarantining a server is a separate action, for when you decide the change is hostile — approve_schema only re-baselines to verified.) The action is written to the audit trail.
Re-approve only after you have reviewed the diff. Approving a drifted schema without checking it defeats the control — it tells OrcaRouter the new (possibly malicious) tool definitions are trusted.

​
5. Where this fits

Schema-drift detection is the schema-layer half of rug-pull defense; the other half is per-call evaluation on the mcp surface (every tools/call is checked against your policy at dispatch). Together they cover both “the definitions changed” and “this specific call is dangerous”.

Rug-pull defense

The full rug-pull picture — schema baseline plus per-call evaluation.

MCP security overview

The MCP gateway, skills, and credentials.

MCP tool poisoning

The threat this state machine defends against.

MCP audit events

Monitoring schema changes and gateway decisions.