Chuyển đến nội dung chính
Một agent có thể vươn tới mạng có thể bị biến thành một ống dẫn dữ liệu. Các hướng dẫn được tiêm bảo nó thu thập secret, hàng, hoặc PII với các tool nó đã nắm giữ và POST chúng tới một host của kẻ tấn công — hoặc dò các dịch vụ nội bộ (SSRF). Agent không bao giờ “quyết định” exfiltrate; nó thực thi cái mà, đối với nó, trông như một hướng dẫn hợp lệ. Công thức này kết nối ba kiểm soát đóng vòng từ đầu đến cuối — một allow-list egress khóa nơi các cuộc gọi đi ra ngoài có thể đi, guardrail Secrets Blocker dừng thông tin xác thực trước khi chúng đến được một mô hình, và một bộ sanitize argument loại bỏ secret khỏi các cuộc gọi tool mà một mô hình có phát ra. Tất cả nằm trong gateway, nên bạn cấu hình nó một lần trong console với zero thay đổi code agent của bạn. Cho giải phẫu tấn công đầy đủ, đọc Exfiltration dữ liệu qua mạng; trang này là các bước dựng.
Mọi thứ ở đây liên kết với workspace của bạn và được cấu hình từ console. Agent của bạn vẫn gọi https://api.orcarouter.ai/v1/... với cùng key sk-orca-... — chỉ có chính sách trong gateway thay đổi. Các hành động cấu hình cần các vai trò được nêu theo từng bước; các cuộc gọi relay dùng key có phạm vi giới hạn. Firewall chỉ thấy egress cho các đích đến được định tuyến qua gateway (đường dispatch MCP hoặc evaluate hook) — định tuyến các cuộc gọi tool gắn-với-mạng của bạn qua nó và chúng được quản lý.

​
1. Ba lớp ngăn ai data exfiltration

Mỗi lớp bắt cuộc tấn công ở một điểm khác trong vòng đời request. Xếp chồng cả ba — chúng độc lập và bổ trợ.

Thông tin xác thực trong prompt

Một secret được dán vào (hoặc kéo vào) request được bắt ở stage input bởi guardrail Secrets Blocker — trước khi bất kỳ mô hình nào thấy.

Secret trong tool args

Một mô hình phát ra một cuộc gọi tool mang một thông tin xác thực được làm sạch bởi một quy tắc firewall sanitize, redact argument đã khớp.

Đích đến đi ra ngoài

Bước mạng thực tế bị giới hạn bởi một allow-list egress — chỉ các host được liệt kê đi qua; mọi thứ khác bị deny.
Công thức này dùng cả hai mặt phẳng: Guardrails cho văn bản trong request, Firewall cho các hành động và mạng. Xem guardrails vs firewall để biết ranh giới nằm ở đâu.

​
2. Dừng thông tin xác thực tại prompt — guardrail Secrets Blocker

Điều đầu tiên cần khóa là chính thông tin xác thực. Guardrail Secrets & API-Key Blocker chạy ở stage input và quét request tìm các pattern thông tin xác thực — access key kiểu AWS, key OpenAI, JWT, và các token tương tự — trước khi request rời gateway. Khi khớp, request bị block: thông tin xác thực không bao giờ đến được một mô hình và không bao giờ rơi vào một cuộc gọi tool. Trong console, mở Guardrails → New guardrail (vai trò Developer; đọc và sandbox Test mở cho mọi thành viên), đặt tên nó là exfil-shield, và áp dụng preset Secrets & API-Key Blocker từ thư viện template (danh mục secrets). Preset gieo ba quy tắc block regex stage input, mỗi cái cho một hình dạng thông tin xác thực — AWS access key, key kiểu OpenAI, và GitHub token: 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
Để mở rộng độ phủ, thêm một quy tắc pii trên các thực thể built-in — tập detector bao phủ email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt, và bitcoin_address. Chọn mask (redact thành một tag có kiểu như [EMAIL]) hoặc block theo từng thực thể qua entity_actions. Masking stage input đã hoạt động; nó viết lại request trước khi mô hình thấy.
Một request bị block trả về HTTP 400 guardrail_blocked, tốn no quota (một block stage input kích hoạt trước khi đo lường), và được đánh dấu skip-retry. Chứng minh nó trong tab Test — dán một AWS key mẫu, chọn stage input, và xác nhận verdict — trước khi bạn gắn một key.

​
3. Sanitize secret khỏi argument cuộc gọi tool

Một guardrail sàng lọc prompt; nó không thấy các cuộc gọi tool mà một mô hình phát ra. Khi mô hình tạo ra một tool_call mà argument của nó mang một thông tin xác thực, một quy tắc firewall sanitize bắt nó. Sanitize redact các chuỗi con đã khớp khỏi argument của cuộc gọi tool và chuyển tiếp cuộc gọi đã làm sạch — tool chạy, nhưng với secret bị loại bỏ. Trong Firewall → Policies → New policy (vai trò Developer), đặt tên nó là exfil-firewall và thêm một quy tắc sanitize trên bề mặt response — các tool_calls mà mô hình phát ra trong câu trả lời của nó: 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize redact argument cuộc gọi tool mà thôi — không bao giờ là nội dung mà một tool trả về. Đó là một phòng thủ trên hình dạng cuộc gọi đi ra ngoài, không phải trên kết quả tool đi vào. Trên bề mặt inbound (chưa có argument tại thời điểm gọi) một verdict sanitize leo thang thành một deny. Xem ngôn ngữ so khớp đầy đủ trong Firewall rules.

​
4. Khóa các đích đến đi ra ngoài — allow-list egress

Phòng thủ bền vững nhất là chính ranh giới mạng: liệt kê các host mà agent của bạn được phép vươn tới một cách hợp lệ và deny mọi thứ khác. Một quy tắc egress dùng stage: egress và trường egress; verdict đặt cực tính — allow cho các đích đến được liệt kê đi qua và một catch-all deny ưu tiên thấp hơn block phần còn lại. Thêm các quy tắc này vào cùng chính sách exfil-firewall: 
[
  {
    "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ư một CIDR, một IP literal, hoặc một hostname không phân biệt hoa-thường. Để dừng SSRF hướng tới các dịch vụ nội bộ mà không có allow-list tường minh, tự soạn một quy tắc deny egress liệt kê endpoint cloud metadata (169.254.169.254) và các dải riêng tư RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Một cuộc gọi bị từ chối trả về HTTP 400 firewall_blocked.
Không preset nào cung cấp các quy tắc egress CIDR — bạn tự soạn các mục allow và deny host/CIDR. Cấp độ tự chủ tight autonomy level là con đường nhanh kề bên: nó deny các tên tool dạng fetch (http_fetch, web_search, fetch_url, request) thẳng thừng, loại bỏ khả năng mạng trước khi một đích đến từng được đánh giá. Dùng nó khi agent của bạn hoàn toàn không cần các tool đó.

​
5. Gắn một key có phạm vi giới hạn

Một chính sách chỉ thực thi trên các key phân giải về nó. Cho agent key riêng của nó, có phạm vi tối thiểu cần thiết — không bao giờ là key toàn tài khoản của bạn. Trong API Keys → New key (vai trò Developer):
Chọn exfil-shield từ dropdown Guardrail (đặt guardrail_id) và exfil-firewall từ dropdown Firewall policy (đặt firewall_policy_id). Cả hai liên kết nằm trên key trong gateway. Một liên kết guardrail tường minh không bao giờ âm thầm fallback — vô hiệu hóa nó là công tắc tắt. Một chính sách firewall bị vô hiệu hóa, ngược lại, fallback về chính sách mặc định của workspace.
Đặt credit_limit_usd thành một mức trần hợp lý (0 = không giới hạn) để một key bị xâm phạm không thể rút cạn quota, và allow_ips thành các IP egress của backend bạn nếu agent gọi từ một server cố định. Đặt một expired_time cho các key tạm thời (-1 = không bao giờ hết hạn).
Key bị che sau khi tạo — sao chép nó một lần. Agent của bạn giờ chạy mọi request qua exfil-shield và mọi cuộc gọi tool qua exfil-firewall mà không có code nào nhận thức rằng việc thực thi đang diễn ra.

​
6. Triển khai với shadow mode, rồi theo dõi

Nếu bạn chưa biết mọi host mà agent của bạn vươn tới một cách hợp lệ, đừng thực thi mù — quan sát trước. Xem chế độ thực thi cho con đường observe → shadow → enforce đầy đủ.
1

Shadow các quy tắc egress

Đặt shadow_mode: true trên exfil-firewall. Mọi verdict thực thi bị hạ cấp thành audit và ghi log như [shadow] would deny với đích đến. Không traffic nào bị block trong khi shadow mode đang bật.
2

Theo dõi các feed

Firewall → Events / Runs (Developer+) hiển thị mọi cuộc gọi tool và đích đến egress mà agent của bạn chạm tới và những gì sẽ bị deny. Guardrails → Matches (mọi Member) hiển thị mọi secret mà input guardrail bắt được. Tinh chỉnh danh sách allow egress cho đến khi chỉ các host kẻ-tấn-công-có-thể-tiếp-cận sẽ bị deny.
3

Thực thi

Tắt shadow_mode. Ngay request kế tiếp được quản lý — thông tin xác thực bị block tại prompt, secret bị loại bỏ khỏi tool args, các cuộc gọi đi ra ngoài giới hạn trong allow-list của bạn. Không thay đổi ứng dụng.
Feed Matches ghi lại chuỗi con đã khớp chỉ khi Log raw content được bật cho guardrail (tắt theo mặc định — tư thế bảo thủ về quyền riêng tư). Đánh dấu một false positive (Admin) để tinh chỉnh chính sách. Mọi thay đổi guardrail ghi một hàng version-history mà bạn có thể diff và revert; các thay đổi chính sách firewall được ghi lại trong audit trail.

​
7. Độ phủ tổng quan

Bước exfiltrationLớp dừng nó
Thông tin xác thực đi vào requestGuardrail Secrets Blocker (input)
Mô hình phát ra một cuộc gọi tool mang một secretQuy tắc firewall sanitize (bề mặt response)
Tool quay số tới một host của kẻ tấn côngQuy tắc egress allow / deny
Agent vươn tới cloud metadata hoặc RFC-1918Quy tắc egress deny liệt kê các CIDR đó
Tool dạng fetch được cung cấp cho mô hìnhCấp độ tự chủ tight (deny tên tool)

​
8. Đi tiếp ở đâu

Tham chiếu firewall rules

Ngôn ngữ so khớp đầy đủ — danh sách egress, CIDR, bộ sanitize, và mọi verdict.

Mối đe dọa exfiltration dữ liệu

Giải phẫu tấn công mà công thức này phòng thủ chống lại, từ đầu đến cuối.

Gia cố một MCP agent

Quản lý mọi tools/call mà một agent dispatch qua một MCP server.

Ghi log an toàn PII

Giữ dữ liệu nhạy cảm khỏi request log và feed Matches của bạn.