Chuyển đến nội dung chính
Một coding agent là thứ có đòn bẩy cao nhất trong workspace của bạn và nguy hiểm nhất. Nó chạy shell.exec, chỉnh sửa file, fetch URL, và nạp các community skill — bất kỳ cái nào trong số đó cũng có thể rm -rf một volume, đọc một .env, hoặc exfiltrate tới một host của kẻ tấn công. Công thức này khóa chặt bề mặt đó với Firewall: deny shell phá hủy, kiểm chứng argument của các cuộc gọi bạn có cho phép, rào egress, và giữ các thao tác thực sự rủi ro lại cho một con người. Không cái nào chạm vào code của agent — chính sách nằm trong gateway và được thực thi ở lần gọi kế tiếp.
Mọi thứ bên dưới được cấu hình trong console (Firewall → Posture / Policies). Các route quản lý đó dùng session console của bạn, không phải một relay key. Chỉ các cuộc gọi /v1/* mà agent của bạn thực hiện mới mang một key sk-orca-…. Việc chỉnh chính sách yêu cầu vai trò Developer.

​
1. Bắt đầu bằng cách quan sát, không phải block — baseline coding agent an toàn

Đừng soạn quy tắc mù. Cho agent key sk-orca-… của nó, rồi mở Firewall → Posture và áp dụng cấp độ tự chủ balanced autonomy level. Trong một transaction điều này audit mọi cuộc gọi tool, gắn cờ PII, và deny shell phá hủy — nên hành động tệ nhất đã được rào trong khi bạn học phần còn lại về hành vi của agent từ traffic thực. Để nó chạy, rồi đọc Firewall → Discovered tools: mọi tool mà workspace đã thấy, gắn cờ covered (một quy tắc áp dụng) hoặc gap (không có gì áp dụng). Danh sách đó là bản nháp allow-list của bạn. Khi feed trông đúng, chuyển sang tight (default-deny) hoặc soạn chính sách nhắm đích bên dưới.
balanced là tư thế khởi đầu được khuyến nghị; permissive không block gì nhưng vẫn ghi log mọi thứ; tight là default-deny cộng với các preset secrets và SSRF. Xem baseline để biết chính xác mỗi cái cụ thể hóa thành gì.

​
2. Deny shell phá hủy — tầng sàn không thể thương lượng

Quy tắc quan trọng duy nhất nhất cho một coding agent là không có shell phá hủy. Các cấp độ tự chủ balanced và tight đã cung cấp cái này dưới dạng preset Block destructive shell, nó cụ thể hóa các quy tắc deny thực, có thể chỉnh sửa, bao phủ cả các tên tool trực tiếp của workspace (shell.*, bash, cmd.*, powershell.*, exec.*) và các dạng được đặt namespace MCP mà một server đã đăng ký phơi bày (*.shell.*, *.cmd.*, …). Nếu bạn muốn thu hẹp phạm vi hơn “deny tất cả shell”, soạn một quy tắc chỉ deny các lệnh phá hủy và audit phần còn lại. Một quy tắc khớp trên một glob tên tool cộng với một predicate argument tùy chọn (JSONPath đối với argument của cuộc gọi):
Trong Firewall → Policies, thêm một quy tắc bên trên mặc định của bạn:
  • Tool glob: shell.exec
  • Args match (mệnh đề JSONPath):
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Verdict: deny
Các toán tử argument là một tập đóng — eq, contains, regex, in, cidr_match, gt, lt. Một cuộc gọi mà $.command của nó khớp regex sẽ bị block; mọi thứ khác rơi xuống quy tắc kế tiếp.
Một cuộc gọi bị từ chối trên bề mặt inbound trả về HTTP 400 với mã lỗi firewall_blocked và một thông báo nêu tên tool và lý do. Một cuộc gọi được dispatch qua MCP gateway quay lại như một lỗi tool (firewall deny: …) để mô hình có thể phản ứng thay vì crash. Các block inbound kích hoạt trước cuộc gọi mô hình thượng nguồn, nên chúng không tốn token mô hình.
Xem Firewall rules cho ngôn ngữ so khớp đầy đủ (tool glob, mệnh đề argument, chuỗi, cost cap).

​
3. Kiểm chứng argument trên các tool bạn giữ lại

Cho phép một tool không giống với cho phép mọi argument của nó. Cùng predicate JSONPath thu hẹp phạm vi một deny cũng cho bạn ràng buộc hình dạng của một cuộc gọi được cho phép — nên db.query không thể mang một DROP, và file.write không thể thoát khỏi một thư mục.

Block một SQL DROP

Glob db.query, mệnh đề {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}, verdict deny.

Redact một secret trong args

Verdict sanitize redact các chuỗi con đã khớp khỏi argument của cuộc gọi tool trước khi cuộc gọi được chuyển tiếp. Nó không bao giờ chạm tới những gì một tool trả về; trên bề mặt inbound (chưa có argument tại thời điểm gọi) nó leo thang thành một block.
Firewall sanitize argument của cuộc gọi tool, không phải kết quả tool. Để chặn một secret khỏi việc đi vào một request ngay từ đầu, gắn guardrail Secrets Blocker vào key — cái đó sàng lọc bản thân văn bản prompt trước khi mô hình thấy. Hai mặt phẳng phối hợp: guardrail sàng lọc văn bản, Firewall quản lý hành động.

​
4. Kiểm soát egress — rào nơi agent có thể vươn tới

Một coding agent có thể fetch URL có thể bị lái vào SSRF (chạm tới cloud-metadata hoặc một host nội bộ 10.x) hoặc bị dùng để exfiltrate. Cấp độ tự chủ tight cung cấp một preset SSRF deny các tên tool dạng fetch (http_fetch, web_search, fetch_url, request, và các dạng <server>.* của chúng) thẳng thừng. Để kiểm soát ở cấp đích đến, soạn một quy tắc egress. Quy tắc egress thu hẹp phạm vi theo host hoặc CIDR với các mục allow / deny, được đánh giá trên bề mặt egress: 
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
Cái đó kích hoạt trên bất kỳ đích đến đi ra ngoài nào được một tool báo cáo mà rơi vào một dải riêng tư, IP cloud-metadata, hoặc một hostname nội bộ — cho các đích đến công khai đi qua trong khi rào các cái nguy hiểm.
Không preset nào cung cấp các quy tắc egress dựa trên CIDR — preset SSRF khớp các tên tool dạng fetch. Denylist host/CIDR ở trên là cái bạn tự soạn. Xem Dừng exfiltration cho pattern đầy đủ.

​
5. Giữ các thao tác rủi ro lại cho một con người (HITL)

Một số thao tác không nên được tự-động-cho-phép hay tự-động-deny — một deploy, một git push, một migration phá hủy. Cho những cái đó, dùng verdict pending_approval. Cuộc gọi bị giữ lại, agent nhận một phản hồi “held” với một approval id, và một reviewer giải quyết nó ngoài luồng:
  1. Soạn một quy tắc (vd: glob deploy.*, verdict pending_approval).
  2. Cuộc gọi bị giữ trả về HTTP 400 firewall_approval_pending với một approval id.
  3. Một reviewer phê duyệt nó từ console (Developer+) hoặc qua một webhook callback ký HMAC.
  4. Agent poll approval, rồi gửi lại cuộc gọi gốc với một header dùng một lần X-OrcaRouter-Firewall-Approval — và gateway cho nó đi qua đúng lần đó.
Triển khai mọi chính sách mới trong shadow mode trước. Chính sách đánh giá và ghi log chính xác như nó sẽ làm trong production, nhưng mọi verdict thực thi bị hạ cấp thành audit với lý do [shadow] would … — nên bạn có thể chứng minh nó kích hoạt trên những gì bạn mong đợi trước khi nó có thể làm hỏng một build.

​
6. Quản lý các skill và MCP server nó nạp

Coding agent kéo vào các khả năng lúc runtime — community skill, MCP server BYO. Firewall quản lý cả hai ở gateway:
  • Skills được quét vào một dải rủi ro với một chế độ thực thi (allow / quarantine / block). Một skill được tự động phát hiện bị quarantine — giữ lại chờ phê duyệt — cho đến khi một reviewer thông qua nó. Xem Skills.
  • MCP server bạn đăng ký dispatch mọi tools/call qua gateway, nó đánh giá mỗi cái trên bề mặt mcp trước khi dispatch. Thông tin xác thực được lưu mã hóa; một probe sức khỏe báo cáo ok / degraded / down. Xem MCP servers và Gia cố một MCP agent.

​
7. Kiểm chứng và quan sát

Trước khi bạn phụ thuộc vào một chính sách, dry-run nó. Tab Test đánh giá một cuộc gọi tool mẫu đối với chính sách hiện tại và hiển thị verdict, quy tắc đã khớp, và lý do — không có gì được dispatch, không có gì được persist. Một khi live, Firewall → Events / Runs là bản ghi của mọi lần đánh giá, có thể lọc theo verdict, surface, tool, và run, và feed bất thường gắn cờ các spike tốc độ/chi phí đối với baseline đã học của workspace, retry_loop, và các đường tool chưa từng thấy.

​
Tóm lại

Tham chiếu Firewall

Mặt phẳng chính sách đầy đủ — bề mặt, verdict, phân giải, tự chủ.

Firewall rules

Ngôn ngữ so khớp: glob, mệnh đề argument, egress, chuỗi.

Cuộc gọi tool nguy hiểm

Mối đe dọa mà công thức này phòng thủ chống lại.

Excessive agency

Tại sao agent quá nhiều quyền là rủi ro agent cốt lõi.

Công thức autonomous agent

Khóa chặt một vòng lặp agent hoàn toàn tự chủ từ đầu đến cuối.

Dừng exfiltration

Các pattern egress và lethal-trifecta chuyên sâu.