Chuyển đến nội dung chính
Bạn có một chính sách bạn muốn đặt trước production. Nỗi sợ không phải là chính sách — mà là việc bật nó lên và phát hiện ra nó block một tool mà agent của bạn thực sự cần, hoặc mask một trường mà ứng dụng của bạn phụ thuộc vào. Cách sửa không phải là test thêm trong sandbox; mà là triển khai đối với traffic thực trong một tư thế không thể làm hỏng gì, rồi siết chỉ khi bạn đã thấy cái gì kích hoạt. Công thức này là việc triển khai đó: observe → shadow → enforce, với tự chủ balanced trước tight. Bạn ở lại trong console (hoặc REST API) suốt chặng đường; agent vẫn gọi https://api.orcarouter.ai/v1/... y như trước.
Mới với mô hình này? Đọc Chế độ thực thi để biết mỗi tư thế làm gì về mặt cơ học, và baseline Secure Agents để biết mỗi cấp độ tự chủ đặt gì. Trang này là trình tự — thứ tự bạn lật các công tắc.

​
1. Ai security rollout trong ba động tác

Cả việc triển khai đánh đổi tự chủ lấy an toàn trong ba bước, mỗi bước được kiểm chứng đối với traffic trực tiếp trước bước kế tiếp:

Observe

Cho phép mọi thứ, ghi log mọi thứ. Các cuộc gọi tool không được bao phủ rơi vào Discovered Tools; các quy tắc guardrail flag ghi lại các match mà không thay đổi traffic. Bạn học hình dạng thực của agent của bạn.

Shadow

Một chính sách thực đánh giá mọi cuộc gọi, nhưng mọi verdict thực thi bị hạ cấp thành audit và ghi log [shadow] would …. Bạn thấy chính xác cái gì sẽ block — mà không có gì thực sự bị block.

Enforce

Tắt shadow. deny block, mask redact, pending_approval giữ lại. Tự chủ đi từ rộng (balanced) sang chặt (tight), và agent của bạn được quản lý.
Kỷ luật là điểm cốt lõi: bạn không bao giờ thực thi một quy tắc mà bạn chưa từng theo dõi kích hoạt trong shadow đối với traffic của riêng bạn.

​
2. Động tác một — observe (tự chủ = permissive)

Bắt đầu rộng nhất có thể. Áp dụng cấp độ tự chủ permissive từ Firewall → Posture (Developer+) — hoặc POST /api/workspace/firewall/autonomy. Nó bật observe mode workspace và không để lại chính sách thực thi nào, nên mọi cuộc gọi được cho phép và mọi cuộc gọi không được bao phủ được ghi log như một khoảng trống độ phủ. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
Các route /api/workspace/firewall/* chạy trên session console / access token của bạn, không phải trên một relay key sk-orca-.... Áp dụng một cấp độ tự chủ là một thao tác ghi workspace — Developer+. Chỉ các cuộc gọi mô hình /v1/* dùng relay key.
Giờ trỏ traffic thực vào nó và để nó chạy. Theo dõi hai feed:
  • Firewall → Discovered Tools (Member) — mọi tool mà agent của bạn gọi, gắn cờ covered hoặc gap. Đây là input cho các quy tắc của bạn: bạn sắp viết chính sách cho traffic thực sự xảy ra, không phải các giả định.
  • Guardrails → Matches (Member) — nếu bạn đã thêm bất kỳ quy tắc hành động flag nào, mọi match chúng ghi lại, mà không chạm tới request.
Để nó chạy cho đến khi Discovered Tools ngừng làm nổi các tool mới. Danh sách ổn định đó là đặc tả soạn-quy-tắc của bạn.

​
3. Động tác hai — shadow (một chính sách thực, zero block)

Giờ soạn chính sách bạn thực sự muốn — tool glob, mệnh đề argument, danh sách egress, một mức trần cap_cost — và bật shadow_mode trước khi bạn gắn nó. (Xây dựng quy tắc từ firewall rules; mô hình chính sách đầy đủ nằm trong tham chiếu Firewall.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
Với shadow_mode: true, deny đó và cap_cost đó đều bị hạ cấp thành audit tại thời điểm đánh giá — engine tính verdict thực, ghi log nó với tiền tố [shadow] would …, và cho cuộc gọi đi qua. Gắn chính sách vào các key bạn đang triển khai (đặt firewall_policy_id trên key) hoặc đặt nó làm mặc định workspace. Rồi đọc Firewall → Events / Runs (Developer+) lọc theo tiền tố [shadow] và xác nhận cả hai phía:
Mọi cuộc gọi shell.exec hiển thị [shadow] would deny. Mọi lần chạy vượt mức trần của bạn hiển thị [shadow] would cap_cost. Chính sách thấy traffic mà bạn xây dựng nó cho.
Không tool hợp lệ nào hiện ra với một verdict would-block. Đây là kiểm tra false-positive — lý do shadow tồn tại. Nếu một tool bạn cần bị gắn cờ, sửa quy tắc và theo dõi lại trước khi bạn từng thực thi.
Guardrail không có shadow ở cấp chính sách. Tương đương là hành động flag theo từng quy tắc: nó ghi lại một match trong feed Matches và không thay đổi gì, nên bạn có thể đo một quy tắc nội dung trước khi chuyển nó sang block hoặc mask. Chạy các quy tắc guardrail của bạn như flag qua cùng động tác này.

​
4. Động tác ba — enforce (tự chủ balanced, rồi tight)

Khi shadow log trông đúng, thực thi trong hai giai đoạn, không phải một. Đừng nhảy thẳng sang default-deny. Đầu tiên, balanced. Đây là tư thế thực thi đầu tiên được khuyến nghị: verdict mặc định firewall là audit, nhưng các hành động phá hủy nhất (như shell phá hủy) bị deny, và guardrail PII Shield chạy chỉ-audit — nó flag PII mà chưa mask nó. Giờ bạn đang block điều tệ nhất trong khi vẫn quan sát phần còn lại. Tắt shadow_mode trên chính sách của riêng bạn trong cùng động tác để các verdict deny / cap_cost của nó go live cùng với baseline. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
Theo dõi Events trong một giờ. Các block thực giờ xuất hiện không có tiền tố [shadow]. Một cuộc gọi tool bị deny trả về HTTP 400 firewall_blocked; nó là skip-retry và tốn no token mô hình. Rồi, tight. Một khi balanced yên tĩnh, chuyển sang default-deny. Cấp độ tight deny theo mặc định, deny shell phá hủy và egress SSRF, và thực thi PII Shield + Secrets Blocker — PII bị mask trên request trước khi mô hình thấy, và secret trong các request của bạn bị block. Một prompt bị block trả về HTTP 400 guardrail_blocked, tốn no quota, và là skip-retry.
Giai đoạnFirewall (hành động)Guardrails (văn bản)Bạn đang chứng minh cái gì
permissiveObserve; không block gìChỉ flagHình dạng traffic thực
balancedAudit mặc định; shell phá hủy bị denyPII được flagTrường hợp tệ nhất bị dừng
tightDefault-deny; shell + tool dạng fetch (SSRF) bị denyPII được mask, secret bị blockZero-trust đầy đủ
Cảnh báo streaming cho PII. Dưới tight, PII Shield mask PII trên request trước khi mô hình thấy — đó là live. Masking phía output của một response streaming chưa live; một block output được thực thi trên streaming (bộ quét cắt stream). Nếu bạn phụ thuộc vào việc redact output mô hình, kiểm chứng tổ hợp stage/stream của bạn trong tab Test guardrail trước. Xem Guardrails.

​
5. Cửa thoát hiểm — hoàn tác một cú nhấp

Mọi thay đổi tự chủ là một transaction duy nhất chụp snapshot tư thế trước đó của bạn, nên bạn có thể roll thẳng lại từ Firewall → Posture (hoặc POST /api/workspace/firewall/autonomy/undo/:audit_id). Bạn cũng có thể chỉ re-apply một cấp độ mềm hơn — hạ tight về balanced, hoặc balanced về permissive — bất cứ lúc nào.
Undo khôi phục từ snapshot audit của lần apply gần đây nhất. Nếu bạn đã thực hiện các chỉnh sửa chính sách thủ công kể từ lần apply bạn đang undo, snapshot đó không còn là cái mới nhất chưa dùng và undo từ chối thay vì âm thầm roll các chỉnh sửa đó đi. Khi điều đó xảy ra, re-apply một cấp độ mềm hơn thay vào đó — nó luôn sẵn có.

​
6. Verdict của mỗi động tác đến từ đâu

Việc triển khai không bao giờ block thứ gì bạn không yêu cầu, vì mỗi tư thế ánh xạ tới một cơ chế tường minh, có thể quan sát:
Tư thếCơ chếKết quả
ObserveWorkspace firewall_observe_mode bật + guardrail flagAllow + ghi log khoảng trống / match
Shadowshadow_mode theo từng chính sáchVerdict thực được tính, hạ cấp thành audit, ghi log [shadow] would …
Enforceshadow_mode tắt + tự chủ tight/balanceddeny / mask / cap_cost go live
Bốn thuật ngữ — observe mode, verdict audit, hành động flag, và shadow_mode — là các công tắc riêng biệt, được tài liệu hóa cạnh nhau trong Chế độ thực thi.

​
7. Bước tiếp theo

Chế độ thực thi

Bản đồ cơ chế đằng sau observe, shadow, và enforce.

Baseline Secure Agents

Mỗi cấp độ tự chủ đặt cái gì, và cách mô phỏng nó trước.

Thuần hóa một agent tự chủ

Bước kế tiếp một khi bạn đã thực thi: cost cap, phát hiện bất thường, và phê duyệt.

Agent Firewall

Chính sách, quy tắc, verdict, shadow mode, và MCP gateway đầy đủ.
Một go-live bạn có thể tin tưởng là một việc triển khai, không phải một công tắc. Observe những gì agent của bạn làm, shadow chính sách đối với traffic thực của nó, rồi enforce — balanced trước tight — và mọi quy tắc được kiểm chứng trên production trước khi nó từng block production.