Chuyển đến nội dung chính
Gateway nằm giữa agent của bạn và mọi mô hình mà nó gọi. Điều đó làm cho nó trở thành điểm duy nhất thấy mọi cuộc gọi bất kể provider — mọi prompt, mọi phản hồi, mọi lời gọi tool, và mọi request đi ra ngoài mà agent của bạn định tuyến qua nó — bất kể SDK nào phát ra cuộc gọi. Điểm nghẽn đó là nơi kiểm tra và thực thi thuộc về. (Những gì nó không thể thấy — một tool chạy hoàn toàn bên trong tiến trình của bạn và không bao giờ vượt qua gateway — được đề cập trong §4.) Trang này giải thích chính xác những gì gateway có thể và không thể thấy, cách phát hiện hoạt động, và cách đóng các khoảng trống.

​
1. Tại sao gateway là điểm kiểm tra đúng

Hầu hết các kiểm soát bảo mật nằm trong ứng dụng: library wrapper, agent framework hook, per-provider SDK. Các kiểm soát đó có một lỗ hổng cấu trúc nghiêm trọng — chúng phá vỡ ngay khi bạn thêm provider thứ hai, đổi framework, hoặc để agent tự cài đặt một skill mới. Gateway không có những đường nối đó. Mọi cuộc gọi mà agent của bạn phát ra, bất kể mô hình, provider, hoặc khả năng tool đến như thế nào, đều transit qua một điểm duy nhất trước khi bất kỳ thứ gì đến được thượng nguồn. Đó là lớp duy nhất nơi bạn có thể đưa ra đảm bảo: nếu nó xảy ra, gateway đã thấy nó. OrcaRouter sử dụng vị trí đó cho hai lượt thực thi riêng biệt:
  • Guardrails sàng lọc văn bản — prompt mà agent của bạn gửi và phản hồi mà mô hình trả về. Một guardrail block trả về HTTP 400 guardrail_blocked và không tốn quota.
  • Firewall phán xét hành động — các tool mà agent gọi, các MCP server nó kết nối, và các đích đến mạng nó báo cáo. Một firewall deny trả về HTTP 400 firewall_blocked trên bề mặt inbound, hoặc lỗi tool trên bề mặt MCP, để mô hình thấy sự từ chối và có thể lý luận về nó.
Cả hai lớp đều được cấu hình một lần trong workspace của bạn và gắn vào một API key. Không triển khai lại. Không đổi SDK. Agent của bạn vẫn gọi https://api.orcarouter.ai/v1 như trước.

​
2. Bốn bề mặt thực thi

Firewall đánh giá mọi lời gọi tool đối với đúng một bề mặt — điểm trong vòng đời cuộc gọi nơi gateway thấy nó.
Bề mặtNhững gì gateway thấy
inboundCác tool mà agent của bạn quảng bá cho mô hình trên request — định nghĩa tool. Chặn ở đây ngăn mô hình không bao giờ chọn một tool nguy hiểm.
responseCác tool_calls mà mô hình phát ra trong phản hồi của nó — các hành động đã chọn của mô hình trước khi chúng được dispatch.
mcpMột tools/call được dispatch qua Firewall MCP gateway hoặc được đánh giá qua SDK hook — cuộc gọi tại thời điểm dispatch.
egressMột đích đến mạng đi ra ngoài (host / IP / CIDR) mà một tool báo cáo — bề mặt SSRF và data-exfiltration.
Guardrails thêm hai giai đoạn văn bản nữa nằm chồng lên trên các bề mặt ở trên: input (prompt và message request) và output (văn bản phản hồi của mô hình). Một request có thể đi qua tất cả chúng.

​
3. Phát hiện lần dùng đầu tiên

Phát hiện xảy ra tại gateway, lần dùng đầu tiên — không phải lúc cài đặt. Một tool, MCP server, hoặc skill mà agent tự cài đặt được bắt lần đầu tiên cuộc gọi của nó vượt qua gateway. Đây là chủ đích: gateway là điểm nghẽn duy nhất thấy mọi provider, mọi agent, và mọi cuộc gọi bất kể khả năng đến từ đâu. Chờ phát hiện lúc cài đặt sẽ bỏ lỡ các khả năng được nạp lúc runtime.
Điều này có nghĩa là một tool mới xuất hiện trong chế độ xem Discovered tools ngay khi nó xuất hiện trên một request, ngay cả khi không có quy tắc nào đặt tên nó. Bật observe mode để ghi lại mọi lời gọi tool không có quy tắc khớp như là khoảng trống độ phủ — chế độ xem đó thúc đẩy việc soạn chính sách từ traffic thực tế.

​
4. Những gì gateway không thể thấy

Đảm bảo kiểm tra bao gồm các cuộc gọi vượt qua gateway. Nó không mở rộng đến một tool mà agent của bạn chạy hoàn toàn bên trong tiến trình của chính nó — một cái đọc file local, gọi library function, hoặc thực thi subprocess mà không bao giờ gửi message đến gateway. Đó là một ranh giới trung thực, không phải lỗi thiết kế. Mục tiêu thiết kế là làm cho gateway trở thành con đường được audit cho các cuộc gọi quan trọng — những cuộc gọi có hậu quả ngoài đời thực:
Nơi nó chạyGateway thấy nó không?Cách đóng khoảng trống
Lời gọi tool qua trung gian mô hình (mô hình phát ra tool_calls)Có — bề mặt responseKhông cần hành động; đã được quản lý.
MCP dispatch qua Firewall MCP gatewayCó — bề mặt mcpKhông cần hành động; đã được quản lý.
Agent của bạn gọi POST /api/v1/firewall/evaluate trước khi dispatchCó — được đánh giá inlineĐã được quản lý qua evaluate hook.
Tool chạy in-process, không tiếp xúc gatewayKhôngĐịnh tuyến MCP dispatch và các tool gọi mạng qua gateway thay vì gọi chúng trực tiếp từ tiến trình agent.
Nếu bạn có tool chạy in-process ngày nay và có hậu quả ngoài đời thực, con đường đến độ phủ là đăng ký chúng như các MCP server đằng sau Firewall MCP gateway hoặc gọi evaluate hook từ vòng lặp agent của bạn trước khi dispatch.

​
5. Kiểm soát vai trò trên dữ liệu kiểm tra

Quyền truy cập vào các bề mặt kiểm tra được giới hạn theo vai trò trong workspace của bạn:
Khả năngVai trò tối thiểu
Đọc guardrail match, chính sách firewall & discovered toolMember
Đọc feed Events & Runs của firewallDeveloper
Tạo hoặc thay đổi guardrails, chính sách firewall, quy tắcDeveloper
Xuất compliance, plaintext firewall-gateway-scoped key, flag is_firewall_gatewayAdmin
Một token có phạm vi firewall-gateway (key dùng để gọi /api/v1/firewall/evaluate và MCP gateway) yêu cầu vai trò Admin để tạo. Một API key thông thường nhận 403 trên các route đó.

​
6. Tiếp theo

Control stack

Đường đi request đầy đủ — key, guardrail, mô hình, firewall, audit — trong một sơ đồ.

Trách nhiệm chung

Những gì gateway bảo mật và những gì nằm trong ứng dụng của bạn.

Agent Firewall

Soạn chính sách, cấu hình bề mặt, và quản lý lời gọi tool chuyên sâu.
Gateway là điểm kiểm tra duy nhất cho mọi cuộc gọi vượt qua nó — cấu hình chính sách của bạn một lần và mọi provider, mọi agent, và mọi lời gọi tool đều được bao phủ.