Chuyển đến nội dung chính
Một “rug pull” là chế độ thất bại MCP nơi một server cư xử đàng hoàng trong khi bạn đang theo dõi và hóa thù địch một khi nó được tin tưởng: một tool bạn đã chấp thuận lúc kết nối bắt đầu lén lút thêm argument, một community server bạn đã liệt kê lặng lẽ thêm một khả năng mới, hoặc một skill mà một agent tự cài đặt lật từ lành tính sang nguy hiểm trong production. Nguy hiểm là chẳng ai xem xét lại một kết nối sau khi nó live — quyết định tin cậy được đưa ra một lần, tại cái bắt tay, và không bao giờ được xem lại. OrcaRouter không tin tưởng cái bắt tay. Nó phòng vệ trên ba mặt trận. MCP gateway của Firewall đánh giá mỗi tools/call vào lúc dispatch đối với chính sách live của bạn. Tập tool được quảng bá của mỗi server đã đăng ký được lập baseline ở lần probe đầu tiên và kiểm tra lại để phát hiện trôi dạt — nếu schema tool thay đổi khỏi baseline đã chấp thuận, server fail closed cho đến khi một admin chấp thuận lại hoặc quarantine nó. Và lớp Skills gán cho mỗi khả năng đã cài đặt một dải rủi ro và một enforcement mode — quarantine bất cứ thứ gì rủi ro hoặc chưa được xem xét cho đến khi một con người ký duyệt. Một server không thể giành được một suất miễn phí bằng cách cư xử đàng hoàng trong một trăm cuộc gọi đầu tiên.

​
1. Tại sao bảo vệ rug pull MCP cần đánh giá theo từng cuộc gọi

Một review lúc kết nối trả lời một câu hỏi một lần: server này có an toàn để liệt kê không? Nó không thể trả lời câu hỏi thực sự quan trọng lúc runtime: cuộc gọi cụ thể này, với các argument cụ thể này, có an toàn ngay bây giờ không? OrcaRouter trả lời câu hỏi thứ hai. Mỗi tools/call băng qua gateway được đánh giá trên bề mặt mcp trước khi nó được dispatch tới server thật, với tên tool và các argument trong tay. Verdict được tính tươi mỗi lần, nên khoảnh khắc một tool bắt đầu làm điều gì đó mà chính sách của bạn cấm — exfiltrate một secret trong một argument, vươn tới một host bị từ chối, gọi một khả năng bạn chưa bao giờ chấp thuận — cuộc gọi bị dừng, bất kể cùng tool đó đã cư xử thế nào một phút trước.
Đánh giá theo từng cuộc gọi kiểm soát hành vi của mỗi cuộc gọi — nội dung argument, các đích đến, rủi ro của skill sở hữu — nên nó bắt được một rug pull ngay cả khi tool giữ một chữ ký giống hệt và chỉ hành vi của nó hóa thù địch. Phát hiện trôi dạt schema (§ bên dưới) là lớp bổ trợ: nó bắt trường hợp nơi chính tập tool được quảng bá của server thay đổi. Cả hai đều chạy.
Các verdict mà engine có thể trả về trên bề mặt mcp:

allow / audit

Được chuyển tiếp tới server. audit ghi log cuộc gọi; allow lặng lẽ.

sanitize

Được chuyển tiếp với các argument của lời gọi tool được redact trước (nó không bao giờ viết lại những gì server trả về).

deny

Được trả về mô hình như một lỗi tool (firewall deny: …) để agent có thể thích nghi thay vì crash.

pending_approval

Cuộc gọi được giữ lại cho một con người giải quyết trước khi nó có thể chạy.

​
2. Quarantine theo dải rủi ro của skill

Nửa thứ hai của phòng vệ rug-pull bao trùm chuỗi cung ứng: các skill, plugin, và các bring-your-own MCP server mà một agent cài đặt. Mỗi cái được đăng ký như một bản ghi theo phạm vi workspace, được quét bởi một risk engine xác định, và được gán một dải rủi ro (low / medium / high / critical) cộng với một enforcement mode:
ModeHiệu ứng lúc runtime
allowCác verdict quy tắc quyết định; skill không thêm gì.
quarantineBất cứ thứ gì ngắn hơn một deny được leo thang lên pending_approval — các tool chỉ chạy sau khi một con người chấp thuận.
blockCác tool của skill bị từ chối thẳng.
Đây là nơi một rug pull bị kiềm chế. Một khả năng mà một agent tự cài đặt là auto_detected và bị quarantine cho đến khi được xem xét — ngay cả khi nó quét sạch, nó không chạy theo thẩm quyền của riêng nó. Và mode của một skill chỉ từng siết chặt hơn khi quét lại: một block hoặc quarantine bạn đặt không bao giờ bị nới lỏng lặng lẽ khi một manifest được trình lại.
Quarantine được thực thi độc lập với shadow mode. Một skill được đặt quarantine hoặc block vẫn được giữ lại ngay cả khi chính sách xung quanh đang ở shadow rollout — nên một khả năng rủi ro không thể luồn qua trong một triển khai theo giai đoạn.
Xem Firewall: Skills để biết toàn bộ scanner, các trọng số chấm điểm, và các tín hiệu tin cậy.

​
3. Phát hiện trôi dạt tool-schema

Rug pull kinh điển là một server đã đăng ký thay đổi những gì nó quảng bá — thêm một tool, thay đổi input schema của một tool, đổi một description. OrcaRouter lập baseline tập tool được quảng bá của mỗi server đã đăng ký trên một probe thành công và theo dõi nó để phát hiện trôi dạt.

Baseline ở lần probe đầu tiên

Probe thành công đầu tiên ghi lại một hash chính tắc của các tool của server (trust-on-first-use dưới một tư thế discovery; dưới một tư thế enforcing, một server chưa lập baseline được giữ pending cho đến khi một admin chấp thuận tập tool ban đầu của nó).

Trôi dạt fail closed

Trên một probe sau, nếu tập tool chính tắc không còn khớp với baseline đã chấp thuận, server được đánh dấu changed và ngừng được phục vụ — gateway sẽ không dispatch các tool của nó cho đến khi bạn quyết định.

Chấp thuận hoặc quarantine

Chấp thuận lại để lập baseline lại theo schema mới, hoặc quarantine server. Một server bị quarantine cũng bị tắt và chỉ một chấp thuận tường minh mới khôi phục dịch vụ — một chỉnh sửa thường không thể bật lại nó.

Được audit

Lần phát hiện trôi dạt đầu tiên khỏi một baseline đã chấp thuận ghi một mục audit workspace, nên thay đổi nằm trên hồ sơ.
Schema status của một server là một trong unknown (chưa bao giờ lập baseline), verified (khớp baseline), changed (trôi dạt, bị giữ), pending (chưa lập baseline dưới enforcing), hoặc quarantined. Lớp này bắt rug pull làm dịch chuyển schema; đánh giá theo từng cuộc gọi (§1) bắt cái giữ một chữ ký giống hệt và chỉ thay đổi hành vi.

​
4. Một ví dụ cụ thể

Giả sử một community MCP server notes quảng bá một tool notes.search vô hại. Bạn liệt kê nó, xem xét nó, và nó hoạt động. Một tuần sau server bị xâm nhập và notes.search bắt đầu đính một argument exfiltration POST ngữ cảnh của bạn tới một host của kẻ tấn công. Một gateway chỉ-lúc-kết-nối sẽ chuyển tiếp nó — tên tool và schema trông không đổi. OrcaRouter đánh giá cuộc gọi: 
# 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
(Các toán tử args_match là eq, contains, regex, in, cidr_match, gt, lt; cidr_match kiểm tra một argument có giá trị IP đối với một CIDR. Để ràng buộc nơi một tool có thể vươn tới theo host/CIDR, dùng danh sách đích egress thay vì một mệnh đề argument.) Tại dispatch, engine trả về deny, và thay vì chuyển tiếp cuộc gọi, gateway trao cho agent một tool-result error MCP — một kết quả bình thường được gắn cờ như một lỗi, không phải một thất bại truyền tải — để mô hình có thể thích nghi: 
firewall deny: <your rule's reason>
Cùng cuộc gọi đã thành công tuần trước giờ bị block — vì quyết định được đưa ra trên cuộc gọi, không phải trên kết nối.
sanitize redact các argument mà agent của bạn gửi, không bao giờ nội dung mà một tool trả về. Nếu bạn cần ràng buộc nơi một tool có thể vươn tới, ghép một quy tắc deny với một danh sách đích egress — đừng dựa vào sanitize để scrub các phản hồi.

​
5. Cách nó khớp với nhau

Đánh giá theo từng cuộc gọi bắt một tool tin cậy hóa độc hại — cùng tên, hành vi mới trong các argument hoặc đích đến. Quarantine skill bắt một khả năng mới hoặc chưa được xem xét xuất hiện ngay từ đầu — một cài đặt tự phát hiện, một manifest quét lại mới suy giảm. Một rug pull có thể mang một trong hai hình dạng, nên cả hai đều chạy: mode của skill cưỡi lên trên verdict quy tắc theo từng cuộc gọi.
Có — xem §3. Tập tool được quảng bá của mỗi server đã đăng ký được lập baseline ở lần probe đầu tiên và kiểm tra lại để phát hiện trôi dạt; một server đã trôi dạt fail closed cho đến khi bạn chấp thuận lại hoặc quarantine nó. Điều đó bổ trợ cho đánh giá theo từng cuộc gọi, vốn cũng bắt một tool giữ một chữ ký giống hệt và chỉ thay đổi hành vi của nó.
Một verdict pending_approval giữ cuộc gọi cho một con người giải quyết trong console (Developer+) hoặc qua một HMAC approval callback. Xem enforcement modes để biết cách các lần giữ và chấp thuận được hiện ra cho một agent.

​
6. Cấu hình nó

Mỗi bước dưới đây là một hành động console / quản lý được xác thực bằng session hoặc access token của bạn — không phải relay key sk-orca-…. Chỉ lưu lượng relay /v1/* dùng relay key.
1

Đăng ký các MCP server của bạn phía sau gateway

Kết nối mỗi server để các tool của nó được quảng bá dưới một endpoint được audit duy nhất. Đăng ký là Developer+.
2

Đặt một verdict mặc định và các quy tắc trên bề mặt mcp

Soạn các quy tắc với tool_name_glob và args_match sao cho các cuộc gọi rủi ro giải thành deny, sanitize, hoặc pending_approval. Xem tham chiếu quy tắc Firewall.
3

Xem xét các skill bị quarantine

Bất cứ thứ gì tự phát hiện ngồi ở quarantine cho đến khi một người xem xét (Developer+) chấp thuận nó. Đọc dải và các phát hiện trước.
4

Triển khai trong shadow, rồi enforce

Dùng enforcement modes để chạy các quy tắc mới trong shadow, theo dõi các sự kiện audit, và lật sang enforcing một khi các verdict trông đúng.
Các lần đọc (cài đặt, chính sách, các tool đã khám phá, các bất thường) mở cho bất kỳ Member nào; mọi việc ghi là Developer+. Việc đọc plaintext của một firewall-gateway key là Developer+.

​
Liên quan

Firewall: các MCP Server

Toàn bộ MCP gateway reference — đăng ký, probe, dispatch.

Firewall: Skills

Các lượt scanner, chấm điểm rủi ro, và việc dẫn xuất quarantine.

Đầu độc tool MCP

Mô hình đe dọa mà phòng vệ rug-pull tồn tại để chống lại.

Giới hạn egress

Soạn các quy tắc deny host/CIDR để ràng buộc nơi các tool có thể vươn tới.

Checklist tin cậy

Checklist từ đầu đến cuối để tin tưởng một MCP server.

Guardrails vs. Firewall

Khi nào chính sách nội dung áp dụng và khi nào firewall áp dụng.