Chuyển đến nội dung chính
Một MCP server bên thứ ba là một bó tool chưa được xem xét, một credential live, và phạm vi tiếp cận mạng mới. Khoảnh khắc một agent dial một cái trực tiếp, chẳng ai theo dõi cuộc gọi — và “server đã thay đổi các tool của nó sau khi bạn chấp thuận nó” là một cuộc tấn công thật, không phải giả định. Trước khi bạn trỏ một agent vào một server do người khác vận hành, bạn muốn một quy trình pre-flight lặp lại được. Trang này là pre-flight đó: một checklist ngắn, có thứ tự để thẩm định mcp server các kết nối trên OrcaRouter dùng các biện pháp kiểm soát đã tồn tại — đánh giá theo từng cuộc gọi, allow-listing default-deny, các giới hạn egress, các credential được mã hóa, và quarantine skill. Mỗi bước liên kết tới how-to tập trung để biết chiều sâu. Chạy nó một lần cho mỗi server mới; chạy lại các bước nhạy-trôi-dạt mỗi khi server thay đổi.
Mỗi bước cấu hình ở đây được làm từ console (hoặc REST API với session/ access token của bạn) và bị giới hạn theo vai trò. Chỉ các route gateway firewall và các cuộc gọi relay /v1/* mang một key kiểu sk-orca-....

1. Checklist để thẩm định các kết nối mcp server

Làm từ trên xuống. Ba bước đầu là bắt buộc cho bất kỳ server nào bạn không tự vận hành; phần còn lại làm cứng nó.

1. Probe trước khi bạn tin

Khám phá danh sách tool thật và khả năng tiếp cận trước khi viết một quy tắc nào.

2. Default-deny, rồi allow-list

Chỉ cho phép các tool bạn đã xem xét; mọi thứ khác bị từ chối.

3. Mã hóa credential

Lưu auth để nó được mã hóa lúc nghỉ, masked khi đọc, không bao giờ được mô hình thấy.

4. Khóa egress

Ràng buộc nơi các tool của server có thể vươn tới trên mạng.

5. Quarantine các skill tự cài đặt

Giữ bất cứ thứ gì agent tự cài đặt cho đến khi một con người xem xét nó.

6. Shadow trước, rồi theo dõi

Triển khai trong audit-only, rồi đọc các sự kiện và bất thường trước khi enforce.

2. Probe trước khi bạn tin

Bạn không thể xem xét các tool bạn chưa bao giờ thấy, và danh sách tool được quảng bá của một server là thứ có khả năng thay đổi dưới bạn nhất. Đăng ký server, rồi probe nó — gateway chạy một MCP initialize + tools/list đối với endpoint và trả về các tool thật cùng với các input schema của chúng, cộng với một status khả năng tiếp cận là ok, degraded, hoặc down.
# Console route, called with your session/access token (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Đọc mọi tên tool và những gì các argument của nó chấp nhận. Một server quảng bá một shell.exec hoặc một http_fetch mà bạn không mong đợi là một phát hiện, không phải một chi tiết — đó là toàn bộ điểm của việc probe trước.
Probe lại mỗi khi một server đổi chủ hoặc bạn nghi ngờ trôi dạt. Một tool mới xuất hiện trong danh sách — “rug pull” — đúng là cái bạn đang theo dõi. Xem Phòng vệ rug-pull.
Tham chiếu đăng ký và probe đầy đủ sống trong Firewall: các MCP server; hướng dẫn từ đầu đến cuối là Kết nối một MCP server.

3. Default-deny, rồi allow-list các tool bạn đã xem xét

Một allow-list là khác biệt giữa “server có thể làm sáu thứ” và “server có thể làm bất cứ điều gì người vận hành nó quyết định ngày mai”. Đặt default_verdict của chính sách thành deny, rồi thêm một quy tắc cho mỗi tool bạn đã xem xét và tin tưởng. Vì gateway đặt namespace cho mọi tool <server>.<tool>, bạn có thể thu hẹp các quy tắc về một server mà không chạm các server khác.
// Policy on the mcp surface: deny by default, allow only what you reviewed.
// tool_name_glob supports a full-segment wildcard: "github.*" (prefix),
// "*.exec" (suffix), or "*.shell.*" (infix). Mid-segment globs like
// "github.get_*" fall back to an exact match and won't expand.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Giờ github.create_issue chạy, github.get_issue chạy, và một github.delete_repo mới được giới thiệu bị từ chối cho đến khi bạn đã xem xét và cho phép nó. Một tools/call bị từ chối quay lại mô hình như một lỗi tool (firewall deny: …) — agent thích nghi thay vì crash. Xem Allow-list các tool MCP để biết công thức đầy đủ, và Quy tắc Firewall để biết DSL khớp.

4. Mã hóa credential — không bao giờ tự xoay xở auth

Một server bên thứ ba hầu như luôn cần một credential, và một credential là thứ bạn ít muốn nằm trong plaintext hoặc đến được mô hình nhất. Đăng ký auth của server qua OrcaRouter để nó được mã hóa lúc nghỉ, masked khi đọc, và chỉ được tiêm vào lúc dispatch. auth_mode là một trong none, bearer, oauth, hoặc basic:
# Console route, UserAuth, Developer+.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}"
  }'
Credential được mã hóa và masked ngay khoảnh khắc nó được lưu — nó không bao giờ đến được mô hình hoặc client, và khi đọc bạn chỉ từng thấy mask. Trên một update, echo mask trở lại để giữ giá trị đã lưu; gửi auth_json mới chỉ khi bạn đang xoay vòng. Xem Xác thựcXoay vòng credential.

5. Khóa egress: các tool của nó có thể vươn tới đâu?

Các verdict theo từng cuộc gọi quyết định tool nào chạy; egress quyết định nơi nó có thể vươn tới. Một tool “trả về dữ liệu” và một tool “exfiltrate các secret của bạn tới host của kẻ tấn công” có thể là cùng một tool với một argument khác — egress control là cái phân biệt chúng. Gateway đã xác thực mọi endpoint từ xa và IP dial đã phân giải của nó đối với một chính sách SSRF trên mọi hop, từ chối các dải intranet và địa chỉ cloud-metadata và kiểm tra lại IP để đánh bại DNS rebinding. Ở trên đó, soạn quy tắc egress deny của riêng bạn cho các host và CIDR mà server này không bao giờ nên chạm:
// An egress-stage rule scopes its verdict to the outbound destination.
// egress_json carries host/CIDR allow + deny lists.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
Không có preset nào ship các quy tắc CIDR cho bạn — bạn tự soạn danh sách deny host/CIDR, thu hẹp về cái mà server này hợp lệ cần. Xem Giới hạn egressExfiltration dữ liệu.

6. Quarantine cái mà agent tự cài đặt

Server bạn đã đăng ký là một rủi ro; các skill, các BYO MCP server, và các plugin mà một agent tự cài đặt sau đó là một rủi ro khác. OrcaRouter quét mọi khả năng cài-đặt-được, gán cho nó một dải rủi ro, và dẫn xuất một enforcement mode — allow, quarantine, hoặc block — cưỡi lên trên mọi verdict quy tắc. Bất cứ thứ gì tự phát hiện ở lần dùng đầu tiên bị quarantine cho đến khi một con người xem xét nó: một khả năng chẳng ai chấp thuận không có một suất miễn phí chỉ vì nó quét lành tính. Một khả năng quarantine leo thang bất cứ thứ gì ngắn hơn một deny lên pending_approval, nên các tool của nó chỉ chạy sau khi bạn đã xem.
Đừng cố đăng ký mọi skill bằng tay. Chấp thuận trước những cái bạn tin và để phần còn lại được tự phát hiện và quarantine — rồi xem xét từ dữ liệu thật. Mode siết chặt hơn khi quét lại, không bao giờ lỏng hơn. Xem Firewall: các skillĐầu độc tool MCP.

7. Shadow trước, rồi theo dõi trail

Đừng lật một server mới toanh thẳng tới enforcing. Đặt chính sách vào shadow mode — các verdict enforcing bị hạ cấp xuống audit và được ghi log là [shadow] would … — để bạn có thể thấy cái lẽ ra đã bị block trước khi nó thực sự bị. Khi audit trail trông đúng, bỏ shadow mode và enforce. Sau khi nó live, các biện pháp kiểm soát tiếp tục theo dõi:
Mỗi cuộc gọi được kiểm soát ghi lại verdict, bề mặt, và quy tắc đã khớp của nó. Đọc chúng để xác nhận allow-list và các quy tắc egress cư xử như dự định. Xem Audit các sự kiện MCP.
Các đột biến tốc độ và chi phí đối với một baseline đã học, cộng với các vòng lặp retry và các đường tool mới lạ, hiện ra như các bất thường — đọc được bởi bất kỳ Member nào.
Bật observe mode để ghi log các cuộc gọi mà một chính sách chưa bao trùm như các khoảng trống, để bạn siết từ cái mà một agent thực sự làm, không phải từ phỏng đoán.

8. Con đường nhanh: chọn một autonomy level

Nếu bạn muốn không tự xây tay các bước 3–5 cho một server bạn chưa hoàn toàn tin, áp dụng một autonomy level và chỉnh sửa từ đó. Các level viết các hàng chính sách và guardrail thật, chỉnh-sửa-được — chúng là một điểm khởi đầu, không phải một hộp đen:
LevelCái nó đặt
permissiveObserve mode bật — ghi log mọi thứ, không thực thi gì.
balancedChính sách default-audit từ chối shell phá hủy, cộng với guardrail PII Shield ở flag-only mode.
tightChính sách default-deny từ chối shell phá hủy và các tool hình dạng fetch (http_fetch/web_search/fetch_url/request — vector SSRF), cộng với các guardrail PII Shield và Secrets Blocker được thực thi. Các secret trong các argument bị bắt bởi guardrail Secrets Blocker trên request, không phải bởi một quy tắc tool-arg.
Với một server bên thứ ba bạn vẫn đang thẩm định, bắt đầu ở tight, probe, rồi nới các tool cụ thể vào một allow-list. Một-cú-nhấp undo khôi phục ảnh chụp trước-khi-áp-dụ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, các MCP server đã đăng ký, và các skill mở cho bất kỳ Member nào; các lần đọc event, run, và aggregate yêu cầu Developer+, và mọi việc ghi yêu cầu Developer+. Việc tiết lộ plaintext key của một token cũng là Developer+.

9. Đi đâu tiếp theo

Kết nối một MCP server

Đăng ký, probe, và phơi bày một server qua gateway.

Allow-list các tool MCP

Default-deny một server và chỉ cho phép các tool đã xem xét.

Phòng vệ rug-pull

Bắt một server hoặc skill thay đổi sau khi bạn chấp thuận nó.

Tổng quan bảo mật MCP

Bản đồ đầy đủ của bề mặt quản trị MCP.
Mới với mô hình? Đọc Guardrails vs. firewall để biết nơi quản trị MCP phù hợp, rồi Quyền hạn thái quáCác lời gọi tool nguy hiểm để biết các mối đe dọa mà checklist này đóng lại.