Chuyển đến nội dung chính
Hầu hết các team dùng bảo mật agent quá muộn và từng mặt phẳng một — một regex trên prompt ở đây, một tool deny-list ở kia. Kết quả là một tư thế có lỗ hổng: sàng lọc văn bản không bao giờ thấy một shell.exec, hoặc một firewall tool không bao giờ để ý một số thẻ tín dụng rời đi trong một prompt. Cách nhanh nhất tới một baseline bảo mật agent đầy đủ là đặt cả hai mặt phẳng cùng lúc. Kiểm soát autonomy của OrcaRouter — baseline Secure Agents — làm chính xác điều đó: một công tắc cấp-workspace duy nhất viết một chính sách firewall và một guardrail cùng nhau, trong một transaction, với hoàn tác một-cú-nhấp. Bạn không soạn một quy tắc để được bảo vệ; bạn chọn một level và tinh chỉnh sau.
Hai mặt phẳng bổ trợ, không dư thừa. Guardrails sàng lọc văn bản prompt/phản hồi (PII, secret, ý định jailbreak và injection); firewall quản trị các hành động mà một agent thực hiện (tool nào, cuộc gọi MCP, và host). Cái nào một mình cũng để lại một khoảng trống mà cái kia đóng — xem Guardrails vs. Firewall.

​
1. Tại sao một baseline thắng hai nửa-biện-pháp

Một lần chạy agent thật băng qua cả hai mặt phẳng trong một request duy nhất. Mô hình đọc một prompt (văn bản), quyết định gọi db.query (hành động), và kết quả của tool feed lại vào lượt kế tiếp (văn bản lần nữa). Bảo mật chỉ một mặt phẳng để cái kia không-được-canh:

Chỉ firewall

Bạn deny shell phá hủy, nhưng một prompt vẫn mang SSN của một khách hàng thẳng tới mô hình — và một đối số tool vẫn rò rỉ một API key.

Chỉ guardrails

Bạn mask PII trong prompt, nhưng agent vẫn gọi rm -rf, với tới một endpoint cloud-metadata, hoặc loop trên một tool chạy hoang.
Kiểm soát autonomy loại bỏ lựa chọn. Một level đặt một tư thế nhất quán trên cả hai mặt phẳng, nên không có cửa sổ nào mà một cái được cấu hình và cái kia thì không.

​
2. Baseline bảo mật agent: ba level

Mỗi level bao cùng hai mặt phẳng. Chọn một; nó là sàn của bạn, và bạn thêm độ chính xác bằng các quy tắc sau.
LevelFirewallGuardrailsObserve mode
tightDefault-deny; shell phá hủy + tool hình-dạng-fetch bị denyPII Shield + Secrets Blocker thực thiOff
balancedDefault-audit; shell phá hủy bị denyPII Shield ở audit-only (flag PII)Off
permissiveKhông chính sách thực thiKhôngOn — ghi log mọi cuộc gọi như một gap
Một vài chi tiết đáng ghim, vì chúng định hình cái mỗi level thực sự bắt:
tight đóng dấu verdict mặc định của chính sách firewall thành deny, rồi xếp các quy tắc deny cho tên tool shell/exec mang lệnh phá hủy — shell.*, bash, cmd, powershell, exec — và cho tên tool hình-dạng-fetch mang SSRF — http_fetch, web_search, fetch_url, request (và các biến thể MCP-namespace <server>.* của chúng). Nó deny các tên tool này; nó không ship một quy tắc egress CIDR hay cloud-metadata. Nếu bạn muốn deny 169.254.169.254 hoặc các dải RFC-1918 theo đích đến, soạn quy tắc egress của riêng bạn — xem Kiểm soát egress.
Cả guardrail PII Shield và Secrets Blocker đều hoạt động và thực thi. PII Shield mask PII trên request trước khi nó đến được mô hình; Secrets Blocker bắt thông tin xác thực trong request. Secret trong đối số tool được bắt bởi guardrail này trên request — firewall không bóc chúng theo mặc định.
balanced audit mọi thứ (verdict mặc định audit) nên bạn thấy hành vi thật của agent, trong khi vẫn deny lớp phá hủy nhất đơn lẻ — shell phá hủy. PII Shield chạy ở chế độ audit-only (flag PII, không block). Bạn có một dấu vết đầy đủ với gần như không rủi ro một block bất ngờ, rồi siết chặt từ khả năng nhìn thấy thay vì phỏng đoán.
permissive thực thi không gì — nó tồn tại để quan sát một agent hoàn toàn mới với không rủi ro block vô tình. Observe mode ở lại on, nên mọi cuộc gọi tool vẫn được ghi log như một khoảng trống độ phủ (hiển thị trong Discovered Tools). Dùng nó để học hình dạng của một agent, rồi chuyển sang balanced hoặc tight.

​
3. Một ví dụ cụ thể: áp dụng balanced, quan sát cả hai feed

Áp dụng một level là một hành động console duy nhất (Firewall → Posture) hoặc một cuộc gọi API. Route chạy dưới session của bạn và yêu cầu Developer+. 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
Phản hồi mang một audit_id — giữ nó; nó là cái bạn truyền để hoàn tác. Một khi áp dụng, baseline là live trên cuộc gọi tool kế tiếp. Không redeploy, không đổi code agent. Giờ bạn quan sát cả hai mặt phẳng cùng lúc:
  • Firewall → Events — mọi verdict cuộc-gọi-tool (audit, các cuộc gọi shell-phá-hủy bị deny). Xem Events log.
  • Guardrails → Matches — mọi lần trúng chính-sách-nội-dung (các flag PII Shield).
Vì balanced viết một chính sách firewall và một guardrail thật, có thể chỉnh sửa (mỗi cái đặt tên theo level), bạn có thể mở cái nào sau đó và tinh chỉnh nó — baseline là một điểm khởi đầu, không phải một preset bị khóa.
Xem trước trước khi bạn cam kết. GET /api/workspace/firewall/simulate?level=tight (Member, chỉ-đọc) cho thấy chính xác cái tight sẽ thay đổi trên trạng thái hiện tại của bạn — không gì được áp dụng. Chạy nó sau một hai ngày trên balanced để xác nhận tight sẽ không deny các cuộc gọi là một phần của traffic bình thường của bạn.

​
4. Hoàn tác là một cuộc gọi

Mỗi thay đổi autonomy có thể đảo ngược từ audit snapshot của nó, khôi phục trạng thái trước chính xác — chính sách, quy tắc, guardrail, và cài đặt — không phải một reset generic. 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Với một workspace rất lớn mà snapshot vượt giới hạn kích thước audit-log, việc áp dụng vẫn thành công nhưng hoàn tác một-cú-nhấp không khả dụng cho thay đổi đó — bạn áp dụng lại level bạn muốn thay vào. Điều này hiếm, nhưng đáng biết trước khi bạn siết chặt một workspace production bận rộn.

​
5. Đường được khuyến nghị

Bắt đầu rộng, quan sát, rồi siết chặt từ một vị thế có khả năng nhìn thấy:
1

Áp dụng balanced

Dấu vết audit đầy đủ; chỉ shell phá hủy bị deny; PII được flag. Chạy các agent của bạn bình thường trong một hai ngày.
2

Simulate tight

GET /api/workspace/firewall/simulate?level=tight và so các deny của nó với cái Events feed thực sự cho thấy. Nếu các cuộc gọi hình-dạng-fetch hoặc shell-phá-hủy là một phần của luồng bình thường của bạn, sửa agent trước.
3

Áp dụng tight

Một khi simulate không có bất ngờ nào, chuyển sang tight. Hoàn tác chỉ một cuộc gọi nếu production hỏng.
4

Tinh chỉnh với quy tắc

Baseline là sàn của bạn. Khoét các ngoại lệ hoặc thêm các kiểm soát nó không bao phủ với quy tắc firewall và guardrail có tên. Gắn một chính sách hoặc guardrail cụ thể vào một key riêng lẻ để có phạm vi mịn hơn.

​
6. Vai trò cho baseline kết hợp

Kiểm soát autonomy trải dài cả hai mặt phẳng, nhưng mọi hành động đều được giới hạn vai trò.
Hành độngVai trò tối thiểu
Simulate một level / xem Matches guardrail / xem Discovered ToolsMember
Xem Events & Runs firewallDeveloper+
Áp dụng một autonomy levelDeveloper+
Hoàn tác một thay đổi autonomyDeveloper+
Toàn bộ cấu hình chạy trong console dưới session của bạn (/api/workspace/firewall/* và /api/guardrail/*). Chỉ các cuộc gọi relay /v1/* dùng một key sk-orca-…; các route gateway-key là một phạm vi riêng. Xem Phạm vi: key, chính sách, workspace.

​
7. Sau baseline: nơi tinh chỉnh mỗi mặt phẳng

Baseline đưa bạn được bảo vệ trong 30 phút đầu. Từ đó, mỗi mặt phẳng có tham chiếu riêng cho công việc chính xác:

Tổng quan Firewall

Verdict, bề mặt, predicate argument, phê duyệt — mặt phẳng hành động.

Guardrails

Quy tắc keyword, regex, PII, llm_judge, và grounding — mặt phẳng nội dung.

Shadow mode

Triển khai một chính sách firewall đã siết chặt ở audit-only trước khi thực thi.

Baseline Secure Agents

Trang khái niệm cho kiểm soát autonomy và ngữ nghĩa hoàn tác của nó.
Baseline là sàn đóng cả hai mặt phẳng cùng lúc; quy tắc là cách bạn nâng trần. Xem Bảo mật AI agent và control stack để biết cách các lớp kết hợp, và Quyền tự quyết quá mức để biết mối đe dọa mà baseline này trả lời trực tiếp nhất.