Allow-list các tool MCP theo từng chính sách

Một MCP server đã đăng ký quảng bá bất cứ tool nào nó muốn — và một agent sẽ vui vẻ gọi bất kỳ cái nào trong số đó. Tư thế an toàn là điều ngược lại: quyết định danh sách ngắn các tool bạn thực sự cần, cho phép chính xác những cái đó, và từ chối phần còn lại. Đó là một allow-list, và trên OrcaRouter bạn xây dựng nó từ các quy tắc tool_name_glob được đánh giá trên bề mặt mcp. Mọi tools/call băng qua MCP gateway được chạy qua chính sách firewall của bạn trước khi nó đến được server thật. Nên allow-list không phải là tư vấn — một cuộc gọi tới một tool bạn không cho phép không bao giờ được dispatch.

​

1. Tại sao một allow-list default-deny cho các tool mcp an toàn

Một deny-list — “block các tool nguy hiểm” — thất bại ngay khoảnh khắc một server thêm một tool mới, đổi tên một cái, hoặc bạn kết nối một server thứ hai. Tập các tool nguy hiểm là vô hạn; tập bạn định dùng thì nhỏ và đã biết. Một allow-list đảo ngược mặc định để cái chưa biết bị từ chối, không được nhận vào:

• Các tool mới bị từ chối theo mặc định. Một server mọc thêm một tool delete_repo sau khi bạn kết nối nó không thể được gọi cho đến khi bạn thêm nó vào allow-list.
• Phạm vi theo từng server. Namespace <server>.<tool> cho phép bạn cho phép github.create_issue trong khi từ chối mọi thứ khác dưới github.*.
• Một điểm nghẽn. Cùng một chính sách kiểm soát server đóng gói sẵn và mọi server BYO phía sau gateway, nên có một nơi để đọc allow-list.

​

2. Hai mảnh ghép

Một allow-list là một default_verdict cộng với một tập quy tắc có thứ tự. Glob được khớp đối với tên tool có namespace — github.create_issue, shell.exec. * khớp bất kỳ tool nào (dùng nó tiết kiệm; một quy tắc allow với * hoàn tác toàn bộ allow-list). Một <server>. đứng đầu thu hẹp glob về một server.

​

3. Một ví dụ cụ thể

Bạn đã kết nối một server github và bạn chỉ muốn các agent đọc và mở issue — không bao giờ xóa hay quản trị bất cứ thứ gì. Trong console, mở Firewall → Policies, đặt verdict mặc định của chính sách thành deny, và thêm hai quy tắc allow: Đó là toàn bộ allow-list. Với mặc định ở deny:

• github.create_issue → khớp quy tắc 1 → allow, dispatch.
• github.delete_repo → không khớp gì → deny theo mặc định.

Một cuộc gọi MCP bị từ chối quay lại mô hình như một lỗi tool (firewall deny: …) — cùng hình dạng mà bất kỳ tool đang thất bại nào trả về — để agent có thể thích nghi thay vì crash. (Trên bề mặt inbound, một deny thay vào đó là một HTTP 400 với mã lỗi firewall_blocked.)

​

4. Siết chặt với các argument

Một tên tool trên allow-list vẫn có thể được gọi với các argument xấu. Thu hẹp thêm bằng cách thêm một mệnh đề args_match (JSONPath + một toán tử như eq, contains, regex, in, hoặc cidr_match) vào quy tắc, hoặc bằng cách xếp một quy tắc deny phía trên allow cho một hình dạng argument cụ thể — ví dụ, cho phép github.create_issue nhưng deny nó khi repo đích không nằm trên một danh sách đã chấp thuận. Xem tham chiếu quy tắc firewall để biết toàn bộ tập toán tử.

​

5. Triển khai nó một cách an toàn

Lật một default-deny toàn-server trong production và bạn có nguy cơ làm hỏng một agent lặng lẽ phụ thuộc vào một tool bạn quên. Hai cài đặt làm giảm rủi ro: Một khi shadow log sạch — không một cuộc gọi hợp lệ nào lẽ ra bị từ chối — xóa shadow_mode và allow-list thực thi.

​

6. Xác minh nó hoạt động

Sau khi thực thi, xác nhận các tool bị từ chối thực sự bị khước từ:

• Dry-run một tools/call đối với chính sách (Developer+) để thấy verdict và quy tắc nào — hoặc mặc định — đã tạo ra nó, mà không gửi lưu lượng thật. Truyền một tên tool, bề mặt, và sample args; engine đánh giá chúng và trả về vết verdict mà không ghi lại một sự kiện.
• Theo dõi các sự kiện. Mỗi cuộc gọi bị block ghi lại một sự kiện firewall mà một Developer+ có thể đọc trong console; trang các sự kiện audit đề cập feed và các trường của nó.

​

Liên quan