Chuyển đến nội dung chính
Mỗi MCP server bạn đăng ký, mỗi skill mà một agent cài đặt, và mỗi host mà một tool vươn tới đều là một dependency bạn không viết. Chuỗi cung ứng của một agent là động — nó phát triển lúc runtime, thường không có con người trong vòng lặp — nên mô hình kinh điển “xem xét lockfile lúc build time” không còn đứng vững. Một community skill có thể bị cướp quyền sau khi bạn tin tưởng nó; một MCP server từ xa có thể lặng lẽ thêm một tool; một fetch tool có thể bị lèo lái tới một host do kẻ tấn công kiểm soát. Câu trả lời của OrcaRouter là kiểm soát chuỗi cung ứng nơi nó hành động — tại gateway, ở lần dùng đầu tiên — thay vì cố thẩm định mọi dependency lúc cài đặt. Trang này là trang đích use-case cho bảo mật chuỗi cung ứng ai; các tham chiếu FirewallSkills mang theo toàn bộ cơ chế.

1. Bảo mật chuỗi cung ứng ai cho agent, tại gateway

Điểm nghẽn là đường relay. Dù một khả năng được đăng ký bằng tay, tự cài đặt bởi agent, hay kéo từ một registry cộng đồng, cuộc gọi tool đầu tiên của nó vượt qua api.orcarouter.ai — và đó là nơi Firewall đánh giá nó. Bốn kiểm soát kết hợp thành một tư thế duy nhất:

MCP gateway, đánh giá theo từng cuộc gọi

Mỗi tools/call được đánh giá đối với chính sách của bạn trước khi dispatch — manifest không bao giờ là nguồn chân lý.

Phân dải rủi ro & quarantine skill

Các khả năng được cài đặt được quét, chấm điểm, và giữ lại để xem xét cho đến khi một con người duyệt chúng.

Credential MCP được mã hóa

Các secret xác thực server được mã hóa khi nghỉ và tiêm vào lúc dispatch — không bao giờ phơi bày cho mô hình, agent, hay các argument cuộc gọi.

Allow-list egress

Ghim nơi các cuộc gọi tool có thể gửi dữ liệu, nên một dependency bị xâm phạm không thể exfiltrate tới một host bạn chưa bao giờ duyệt.
Phát hiện ở gateway, ở lần dùng đầu tiên — không phải trong package manager hay filesystem của bạn. Đó là chủ đích: đó là con đường duy nhất thấy mọi agent và mọi cuộc gọi tool bất kể khả năng đó đến đó bằng cách nào.

2. Mối đe dọa: một dependency phát triển sau khi bạn tin tưởng nó

VectorĐiều xảy ra
Rug-pullMột MCP server đã đăng ký thêm một tool (shell.exec, một fetch mới) bạn chưa bao giờ duyệt.
Skill creepMột skill được cài đặt dùng các tool hoặc host mà manifest của nó chưa bao giờ khai báo.
Trộm credentialPhần triển khai tool của một server bị xâm phạm đọc secret xác thực của chính nó để gọi về nhà.
Exfiltration egressMột chuỗi truy-xuất→gửi vận chuyển dữ liệu của bạn tới một host do kẻ tấn công kiểm soát.
Gốc rễ chung: “Tôi tin server này” bị coi như vĩnh viễn, và agent cứ tiếp tục gọi các tool mới hoặc đã sửa đổi mà không có thêm xem xét nào.

3. Một ví dụ cụ thể — đăng ký và ghim một MCP server

Bạn đăng ký một MCP server của bên thứ ba từ console (Settings → Firewall → MCP servers; ghi cần Developer+). Secret xác thực của server được lưu mã hóa — bạn cung cấp nó một lần, gateway tiêm nó lúc dispatch, và nó được mask trên mọi lần đọc sau đó. Một bản ghi MCP server mang theo:
FieldGiá trị
auth_modenone, bearer, oauth, basic
statusok, degraded, down (do health probe đặt)
credentialsmã hóa khi nghỉ, không bao giờ trả về dưới dạng plaintext
Sau khi đăng ký, probe nó từ console để liệt kê các tool hiện tại của nó. Probe là một thao tác session-workspace (/api/workspace/firewall/*) cần Developer+, không phải một key relay — đăng ký, probe, và soạn quy tắc tất cả đều diễn ra trên mặt phẳng quản lý:
# Console / management plane — workspace session, Developer+.
# (The relay sk-orca-... key is for /v1/* traffic only.)
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/<id>/probe \
  -H "Authorization: Bearer <workspace-session-token>"
Probe lưu lại tính tiếp cận được của server và chụp snapshot một baseline hash của tập tool được quảng bá của nó (trust-on-first-use). Rồi giới hạn một quy tắc Firewall với tool_name_glob: <server>.* thành pending_approval cho đến khi bạn đã thấy một lịch sử cuộc gọi sạch — mỗi cuộc gọi từ server đó được giữ lại cho một con người trước khi nó chạy. Một khi bạn tin tưởng nó, nới lỏng quy tắc thành audit hoặc allow. Từ điểm đó trở đi MCP gateway đánh giá mọi tools/call trên bề mặt mcp trước khi dispatch — nên nếu một rug-pull sau đó thêm một tool chưa khai báo, chính sách của bạn, không phải manifest của server, quyết định liệu nó có chạy hay không.
Probe lại sau bất kỳ lần nâng version thượng nguồn nào (POST /api/workspace/firewall/mcp_servers/:id/probe, Developer+). Nếu tập tool được quảng bá trôi dạt khỏi baseline đã duyệt, schema_status của server lật sang changed và dispatch fail closed cho đến khi một admin tạo baseline lại (approve_schema) hoặc quarantine nó — rug-pull không thể âm thầm lên sống.

4. Phân dải rủi ro & quarantine skill

Mỗi khả năng có thể cài đặt — dù bạn đăng ký nó hay gateway tự phát hiện nó lúc runtime — đều được chạy qua skill scanner. Các phát hiện gộp lên thành một dải rủi ro và một chế độ thực thi:
low · medium · high · critical. Dải được suy ra từ các lượt quét tất định trên manifest và các phạm vi được khai báo (dùng tool chưa khai báo, egress mạng ngoài các phạm vi đã duyệt, ghi filesystem không an toàn, văn bản manifest có hình dạng injection).
allow (các quy tắc chính sách của bạn quyết định), quarantine (bất kỳ verdict không-deny nào leo thang thành pending_approval — một con người duyệt mỗi cuộc gọi), block (buộc deny trên mọi tool của skill này bất kể quy tắc). Một skill dải high quarantine tự động; critical block.
Một khả năng mà một agent tự cài đặt, hoặc một tool mà một rug-pull thêm vào, bị giữ trong pending_approval bất kể điểm quét của nó cho đến khi một con người xem xét nó. Một operator không thể lặng lẽ thêm một tool và để các agent của bạn bắt đầu dùng nó.
Chế độ thực thi chỉ luôn siết chặt hơn — duyệt một skill không bao giờ nới lỏng một block mà một lần quét mới đã đặt.

5. Allow-list egress — kiềm chế cú “gọi về nhà”

Hậu quả chuỗi cung ứng gây hại nhất là một dependency bị xâm phạm exfiltrate. Bề mặt egress của Firewall đánh giá đích đến đi ra ngoài (host / IP / CIDR) mà một tool báo cáo, nên bạn có thể ghim nơi dữ liệu được phép đi. Bạn tự soạn một quy tắc egress: một allow-list host/CIDR với một predicate cidr_match deny mọi thứ ngoài danh sách. Kết hợp nó với một quy tắc trình tự phá vỡ chuỗi truy-xuất→egress, và một tool bị nhiễm độc cố vận chuyển một tài liệu được truy xuất tới một host không xác định sẽ bị deny tại gateway.
Cấp độ tự chủ tight ship một preset SSRF, nhưng nó deny các tên tool có hình dạng fetch (http_fetch, web_search, fetch_url, request) — nó không phải một denylist CIDR/cloud-metadata. Nếu bạn cần block egress RFC-1918 / metadata / CIDR-cụ-thể, tự soạn quy tắc deny egress host/CIDR. Xem Firewall: Quy tắc để biết toán tử cidr_match và việc giới hạn egress.

6. Credential được mã hóa — một server bị xâm phạm không thể đọc key của bạn

Các secret xác thực server được mã hóa khi nghỉ và tiêm bởi gateway lúc dispatch. Chúng không bao giờ đến mô hình, agent, hay các argument cuộc gọi tool — nên một server bị xâm phạm hoặc độc hại không thể exfiltrate các API key của bạn bằng cách đọc credential blob của chính nó. Console luôn trả về secret đã được mask — ngay cả với một Admin. Giá trị đã giải mã được trao ra trên đúng một con đường: một request mang một token có phạm vi firewall-gateway (một kiểu token chuyên dụng mà một Admin đúc tường minh cho gateway/proxy), nên một key relay bị rò rỉ thông thường không thể liệt kê các credential MCP của bạn.

7. Tổng hợp cho một cuộc audit

Kiểm soát chuỗi cung ứng cũng là một artifact audit. OrcaRouter ánh xạ tới OWASP Top 10 cho Ứng dụng LLM — bao gồm kiểm soát LLM05 Supply Chain — như một phần của engine tuân thủ, song song với các framework như soc2, iso_27001, iso_42001, nist_ai_rmf, và eu_ai_act. Cài đặt một compliance pack (POST /api/compliance/packs/:key/install, workspace Admin, gói trả phí) hiện thực hóa các guardrail và chính sách firewall khớp và bắt đầu ở một tư thế observe-first. Các báo cáo tuân thủ bao gồm một mục bằng chứng chuỗi-cung-ứng-AI — các provider thượng nguồn mà workspace của bạn thực sự định tuyến tới, cộng với một xem xét truy cập đặc quyền và vệ sinh key — và được ký Ed25519 và xác minh công khai được. Duyệt catalog và sự sẵn sàng là miễn phí cho mọi Member; xem Compliance để biết toàn bộ vòng đời.
Kiểm soát MCP là hai lớp bổ trợ: đánh giá firewall theo từng cuộc gọi trên bề mặt mcp (thực thi trên những gì một dependency làm), cộng với một baseline toàn vẹn tool-schema (hash trust-on-first-use của tập tool được quảng bá, kiểm tra lại trên mỗi probe — drift lật schema_status của server sang changed và fail dispatch closed cho đến khi một admin tạo baseline lại hoặc quarantine nó). Cùng với phân dải rủi ro skill và quarantine, đó là thực thi trên cả những gì một dependency làm và một bản ghi xác minh được về những gì nó đã khai báo.

8. Một baseline chuỗi cung ứng

Đăng ký nó, probe tập tool của nó, và giới hạn một quy tắc <server>.* thành pending_approval hoặc audit. Đọc các phát hiện quét — bất kỳ phát hiện tool-chưa-khai-báo hoặc egress-bên-ngoài nào là một lý do để giữ nó quarantine. Xác minh ai kiểm soát URL endpoint.
Giữ một allow-list egress được ghim cho bất kỳ agent nào có tool fetch/search/export. Theo dõi chế độ xem Discovered tools tìm các khả năng xuất hiện mà không có quy tắc, và feed bất thường tìm các đường tool-sang-tool mới lạ.
Vô hiệu hóa server (PUT .../mcp_servers, "enabled": false) — các credential của nó không bao giờ được giải mã khi bị vô hiệu hóa. Probe lại để lộ diện các tool mới, quét lại skill, và xem xét hàng đợi pending_approval thay vì duyệt hàng loạt.

9. Mối đe dọa & khái niệm liên quan

Firewall: MCP Server

Đăng ký các MCP server đằng sau gateway, probe các tool của chúng, và áp dụng một verdict theo từng cuộc gọi trước khi bất kỳ cuộc gọi nào đến server thật.

Firewall: Skills

Quét và chấm điểm rủi ro mọi khả năng có thể cài đặt. Quarantine hoặc block các skill rủi ro trước khi các tool của chúng chạy.