Chuyển đến nội dung chính
Một agent có thể kết nối mạng có thể bị biến thành ống dẫn dữ liệu. Kẻ tấn công đặt hướng dẫn trong tài liệu mà agent đọc — trang web, chunk được truy xuất, kết quả tool — và những hướng dẫn đó hướng agent POST dữ liệu nhạy cảm đến host do kẻ tấn công kiểm soát, hoặc thăm dò dịch vụ nội bộ (SSRF). Agent không bao giờ “quyết định” exfiltrate; nó thực thi những gì trông, với nó, như hướng dẫn hợp lệ. Trang này đề cập cách Agent Firewall và Guardrails stack trong OrcaRouter cho phép bạn phòng thủ chống AI data exfiltration — mà không thay đổi code agent.
Firewall thấy egress chỉ cho các đích đến được định tuyến qua gateway qua đường MCP dispatch hoặc evaluate hook. Một tool mà agent của bạn thực thi hoàn toàn bên trong tiến trình của chính nó nằm ngoài tầm nhìn của nó. Định tuyến các lời gọi tool network-bound của agent qua gateway và chúng được quản lý.

​
1. Cách cuộc tấn công hoạt động

Con đường chuẩn qua agent chạy trong ba bước:
  1. Injection — agent đọc nội dung không đáng tin mang hướng dẫn nhúng (trang web, tài liệu được fetch, ghi chú CRM).
  2. Thu thập — hướng dẫn bị tiêm nhiễm nói agent thu thập tài liệu nhạy cảm — API key, dòng database, user PII — dùng các tool nó đã có.
  3. Exfiltration — agent được nói gửi tài liệu đó ra ngoài qua tool có hình dạng fetch: http_fetch, web_search, fetch_url, hoặc request. Đích đến do kẻ tấn công kiểm soát.
SSRF có cùng hình dạng được hướng vào trong: thay vì host bên ngoài, agent được hướng đến 169.254.169.254 (cloud metadata), Redis port nội bộ, hoặc dịch vụ private khác. Xem Prompt injection để biết bước injection; trang này tập trung vào bước mạng.

​
2. Egress allow-list — khóa đích đến đi ra ngoài

Phòng thủ bền vững nhất là egress allow-list: liệt kê các host mà agent hợp pháp được phép kết nối và từ chối mọi thứ khác. Một quy tắc egress dùng stage: egress và trường egress. Verdict kiểm soát cực tính — allow pass các đích đến đã liệt kê; một catch-all deny priority thấp hơn block phần còn lại: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": [
        "api.openai.com",
        "api.anthropic.com",
        "api.orcarouter.ai"
      ]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Các mục khớp như CIDR, IP literal, hoặc hostname không phân biệt hoa thường. Hostname được phân giải best-effort và kiểm tra lại đối với các mục IP/CIDR, nên đích đến như 169.254.169.254 được trả về bởi DNS vẫn bị bắt bởi mục deny CIDR 10.0.0.0/8. Một cuộc gọi bị block trả về HTTP 400 với mã lỗi firewall_blocked. Để từ chối dải đã biết xấu mà không có allow list tường minh, viết quy tắc deny egress nhắm vào cloud metadata endpoint (169.254.169.254) và dải private RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Xếp chồng allow-list của bạn lên trên ở số priority thấp hơn để quy tắc deny được đánh giá trước.

​
3. Block các tool có hình dạng fetch tại tầng tên

Trước khi một đích đến egress được đánh giá, bạn có thể loại bỏ hoàn toàn khả năng. Autonomy level tight từ chối http_fetch, web_search, fetch_url, và request theo tool-name glob như backstop SSRF và exfiltration. Nếu agent của bạn không cần bất kỳ tool nào trong số đó, tight loại bỏ bề mặt tấn công trong một bước: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Để từ chối fetch tool mà không áp dụng toàn bộ tư thế tight, viết quy tắc deny bề mặt inbound. inbound block tool trước khi mô hình có thể chọn nó — agent không bao giờ nhận được khả năng trong danh sách tool của nó: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Lặp lại cho mỗi tên tool có hình dạng fetch mà agent stack của bạn dùng.

​
4. Guardrail Secrets Blocker — ngăn credential tại prompt

Guardrail Secrets Blocker chạy ở giai đoạn input, quét prompt để tìm AWS-style access key, OpenAI key, Anthropic key, GitHub token, và các pattern credential tương tự trước khi request rời gateway. Nếu một secret được phát hiện, request bị block — credential không bao giờ đến mô hình và không bao giờ xuất hiện trong lời gọi tool. Bật nó từ panel Guardrails, hoặc như một phần của autonomy level tight. Nó độc lập với quy tắc egress firewall.
Mối đe dọaLớp ngăn chặn nó
Prompt mang API keySecrets Blocker (input guardrail)
Agent gọi fetch tool đến host kẻ tấn côngQuy tắc egress allow/deny
Tool có hình dạng fetch được quảng bá cho mô hìnhQuy tắc inbound deny hoặc autonomy tight
Agent kết nối cloud metadata hoặc RFC-1918Quy tắc egress deny liệt kê các CIDR đó

​
5. Triển khai với shadow mode

Nếu bạn không chắc host nào mà agent của bạn hợp pháp kết nối ngày nay, bắt đầu ở shadow mode trước khi thực thi:
  1. Tạo quy tắc egress với allow list dự định của bạn và đặt shadow_mode: true trên chính sách.
  2. Xem feed Events — các cuộc gọi sẽ bị block xuất hiện là [shadow] would deny với đích đến.
  3. Điều chỉnh danh sách allow cho đến khi chỉ các đích đến có thể tiếp cận bởi kẻ tấn công sẽ bị từ chối, rồi tắt shadow mode để bắt đầu thực thi.
Không có traffic nào bị block khi shadow mode bật.

​
6. Tiếp theo

Tham chiếu Firewall rules

Ngôn ngữ so khớp hoàn chỉnh — danh sách egress, CIDR, argument clause, và tất cả verdict.

Tổng quan Agent Firewall

Chính sách, bề mặt, autonomy level, và khả năng quan sát.

Prompt injection

Bước injection hướng agent đến exfiltration.

MCP tool poisoning

Các tool MCP độc hại đăng ký khả năng có hình dạng fetch.