Test quy tắc firewall an toàn

Bạn đã viết một quy tắc firewall — một deny trên shell.exec, một egress allow-list, một mệnh đề argument chỉ kích hoạt trên rm -rf — và giờ bạn muốn biết nó làm đúng cái bạn nghĩ trước khi nó thay đổi một cuộc gọi tool production nào. Firewall cho bạn ba cách không-phá-hủy để test quy tắc firewall, mỗi cái trả lời một câu hỏi khác nhau:

Chạy thử một cuộc gọi

Sandbox Test đưa một cuộc gọi tool tổng hợp qua engine thật và trả về verdict — không gì dispatch, không gì ghi log. Developer+.

Replay một tư thế

Simulate replay một autonomy level trên traffic gần đây của bạn và đếm bao nhiêu cuộc gọi nó sẽ block. Member-đọc-được.

Chạy trên traffic live

Shadow mode đánh giá cả một chính sách trên các cuộc gọi thật nhưng hạ cấp mọi verdict thực thi thành audit. Bán kính tác động bằng không.

Cả ba cấu hình qua console (hoặc các route quản lý /api/workspace/firewall/*, vốn xác thực bằng session / access token của bạn — không phải một relay key sk-orca-…). Các cuộc gọi relay /v1/* của agent bạn không bao giờ thay đổi trong khi bạn test.

1. Test quy tắc firewall với sandbox Test chạy-thử

Sandbox Test là vòng lặp chặt nhất: đưa nó một cuộc gọi tool tổng hợp duy nhất và nó chạy engine đánh giá thật — phân giải chính sách đầy đủ, các quy tắc được duyệt theo thứ tự ưu tiên, first-match-wins — rồi trả về verdict, quy tắc đã tạo ra nó, và lý do có-thể-đọc-bởi-con-người. Cuộc gọi là một chạy thử: không gì được dispatch tới một tool nào, và không gì được viết vào events feed hay kho Discovered-tools. Nó trả lời một câu hỏi chính xác: với đúng tên tool này và các đối số này, chính sách của tôi quyết định gì — và quy tắc nào quyết định nó?

Sandbox Test là Developer+. Nó có thể xem trước trên một chính sách nháp chưa-lưu theo id và phản hồi làm hiện tên chính sách đã khớp và nhãn quy tắc, nên nó nằm gần một xem-trước-bề-mặt-ghi hơn một đọc thuần — khác với Simulate và các chế độ xem đọc khác, vốn mở cho mọi thành viên.

Một lần chạy thử cụ thể

Giả sử bạn đã thêm một quy tắc nên deny shell.exec chỉ khi lệnh chứa rm -rf. Bạn muốn xác nhận hai điều trong một lần ngồi: lệnh nguy hiểm bị deny, và một cái vô hại vẫn qua.

Test cuộc gọi nguy hiểm

Trong Security → Firewall, mở tab Test, chọn bề mặt response, nhập tên tool shell.exec và đối số {"command": "rm -rf /data"}, và chạy. Phản hồi nêu tên verdict và quy tắc đã khớp:

{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}

Test cuộc gọi vô hại

Chạy lại với {"command": "ls -la"}. Mệnh đề argument không còn khớp, nên quy tắc rơi xuống mặc định của chính sách — bạn nên thấy allow hoặc audit và một rule_label trống. Nếu rm -rf deny và ls -la không, thì mệnh đề argument của bạn được thu hẹp đúng.

Xem trước một bản nháp trước khi gắn nó

Truyền một policy_id để đánh giá trên một chính sách nháp cụ thể thay vì cái mà traffic của bạn hiện phân giải về — nên bạn có thể chứng minh một chính sách mới đúng trước khi bạn gắn một key vào nó hoặc thăng cấp nó làm mặc định workspace.

Đọc gap trong phản hồi. gap: true nghĩa là một chính sách đã phân giải nhưng không quy tắc nào bên trong nó khớp cuộc gọi (và workspace ở observe mode) — tool trượt qua mọi quy tắc và rơi về mặc định. Đó là một lỗ hổng độ phủ cần đóng trước khi bạn ship, không phải một verdict để tin.

Sandbox Test dùng cùng các bề mặt như đánh giá live — inbound, response, mcp, egress (mặc định inbound) — nên test mỗi quy tắc trên bề mặt nó được ghim vào. Trên inbound không có đối số tại thời điểm gọi, nên một quy tắc sanitize leo thang thành một block ở đó đúng như nó sẽ làm trong production; xem stage để biết tại sao bề mặt quan trọng.

2. Simulate một autonomy level trước khi áp dụng nó

Sandbox Test kiểm tra một cuộc gọi. Simulate trả lời câu hỏi cấp-tư-thế: nếu tôi chuyển cả workspace này sang một autonomy level chặt hơn, bao nhiêu traffic gần đây của tôi nó sẽ block? Simulate replay các quy tắc deny của một level ứng cử trên các event firewall gần đây của bạn và trả về tác động giả định — chỉ tên tool và số đếm, không bao giờ đối số. Nó chỉ-đọc và Member-đọc-được, nên bất kỳ ai trong team có thể xem trước bán kính tác động của tight trước khi một Developer cam kết với nó.

Ba level sẽ làm gì

tight — default-deny, deny shell phá hủy, deny các tool hình-dạng-fetch (vector SSRF), PII Shield + Secrets Blocker thực thi. Simulate cho thấy bao nhiêu traffic thật của bạn mà sàn này sẽ bắt.
balanced — mặc định audit, deny shell phá hủy, PII Shield ở audit-only (flag PII). Tư thế khởi đầu được khuyến nghị.
permissive — chỉ observe; không gì được thực thi.

Simulate so với apply

Simulate không thay đổi gì — nó là một what-if trên các event quá khứ. Áp dụng một autonomy level (một thao tác ghi Developer+) dựng các dòng chính sách autonomy_* và guardrail thật, có thể chỉnh sửa, với hoàn-tác một-cú-nhấp từ audit snapshot. Xem trước với Simulate, rồi áp dụng khi số đếm trông đúng.

3. Shadow mode: test trên traffic live không bán kính tác động

Sandbox Test và Simulate là các xem-trước offline. Shadow mode là cái live: một cờ theo-từng-chính-sách đánh giá chính sách trên traffic agent thật, duyệt mọi quy tắc, chọn một verdict — rồi hạ cấp mọi verdict thực thi (deny, sanitize, pending_approval) thành audit và thêm tiền tố lý do [shadow] would …. Cuộc gọi luôn đi qua; không gì bị block, che, hay giữ. Điều đó làm cho events feed đọc lên giống một lần chạy production với việc thực thi đã tắt. Lọc theo [shadow] và bạn có một danh sách đầy đủ mọi cuộc gọi mà chính sách sắp bắt đầu block — trước khi nó block một cái.

Phương pháp test	Chạy trên	Câu hỏi nó trả lời
Sandbox Test	Một cuộc gọi tổng hợp	”Đúng cuộc gọi này nhận verdict gì, và quy tắc nào quyết định?”
Simulate	Các event gần đây	”Một autonomy level chặt hơn sẽ block bao nhiêu cuộc gọi?”
Shadow mode	Traffic live	”Chính sách này sẽ block gì trên traffic production thật?”

Shadow mode là cái sâu nhất trong ba — độ phủ live đầy đủ với bán kính tác động bằng không. Nó có trang riêng: Triển khai một chính sách firewall với shadow mode đi qua toggle, các lý do [shadow] would …, và cú lật để thực thi.

4. Một thứ tự test thực tế

Ba tool kết hợp thành một đường triển-khai-an-toàn — kiểm tra rẻ nhất trước, độ phủ rộng nhất cuối:

Chạy thử các quy tắc bạn vừa viết

Dùng Test để xác nhận mỗi quy tắc mới kích hoạt trên các cuộc gọi nó nên và để qua các cuộc gọi nó không nên — kể cả các trường hợp âm tính. Nhanh, Developer+, không gì được lưu.

Đo tư thế (tùy chọn)

Nếu bạn dùng một autonomy level thay vì các quy tắc viết-tay, Simulate level và đọc số đếm sẽ-bị-block trên traffic thật trước khi áp dụng nó.

Shadow trên traffic live

Bật shadow mode và để một cửa sổ đại diện các cuộc gọi thật chảy qua. Đọc các event [shadow] would …; siết chặt bất kỳ quy tắc nào làm hiện một dương tính giả — vẫn trong shadow, bán kính tác động bằng không.

Thực thi

Khi feed kích hoạt trên đúng cái bạn mong đợi và không gì bạn không mong đợi, tắt shadow. Cuộc gọi kế tiếp thực thi thật.

Test xem trước chính sách, không phải các skill được quản trị. Một skill ở chế độ block hoặc quarantine vẫn thực thi ngay cả dưới một chính sách shadow — định đoạt xem xét của skill thắng. Đưa một chính sách vào shadow chưa bao giờ là một yêu cầu bỏ cách ly một skill.

5. Tham chiếu API

Các route quản lý này dùng session / access token của bạn và là theo phạm vi workspace:

Method & path	Vai trò	Mục đích
`POST /api/workspace/firewall/test`	Developer+	Chạy thử một cuộc gọi tool tổng hợp trên chính sách đã phân giải (hoặc một `policy_id` nháp). Trả về verdict, `policy_name`, `rule_label`, `reason`, `gap`, `shadow_mode`. Không gì dispatch hay ghi log.
`GET /api/workspace/firewall/simulate?level=`	Member	Replay một autonomy level trên các event gần đây; trả về số đếm sẽ-bị-block.
`GET /api/workspace/firewall/policies/:id`	Member	Đọc cờ `shadow_mode` hiện tại của một chính sách.
`PUT /api/workspace/firewall/policies`	Developer+	Bật/tắt `shadow_mode` trên chính sách.

Thân Test nhận surface (mặc định inbound), một tool_name bắt buộc, args_json tùy chọn, và một policy_id tùy chọn để ghi đè phân giải.

Đi đâu tiếp theo

Shadow mode

Triển khai trên traffic-live: [shadow] would …, bộ lọc events, và cú lật để thực thi.

Kiểm tra đối số

Thu hẹp một quy tắc theo đối số nào — các mệnh đề mà sandbox Test cho bạn xác minh trên rm -rf vs ls -la.

Verdict

allow / audit / deny / sanitize / pending_approval / cap_cost mỗi cái làm gì khi một test thôi là một test.

Events log

Nơi các verdict shadow đáp xuống — lọc, đào sâu vào lần chạy và quy tắc đã khớp.

Để biết ngữ pháp khớp-quy-tắc mà các test này thực thi, xem tham chiếu quy tắc firewall đầy đủ; để biết test khớp vào mô hình rộng hơn ở đâu, xem chế độ thực thi.

Chạy thử một cuộc gọi

Replay một tư thế

Chạy trên traffic live

​1. Test quy tắc firewall với sandbox Test chạy-thử

​Một lần chạy thử cụ thể

​2. Simulate một autonomy level trước khi áp dụng nó

​3. Shadow mode: test trên traffic live không bán kính tác động

​4. Một thứ tự test thực tế

​5. Tham chiếu API

​Đi đâu tiếp theo

Shadow mode

Kiểm tra đối số

Verdict

Events log

1. Test quy tắc firewall với sandbox Test chạy-thử

Một lần chạy thử cụ thể

2. Simulate một autonomy level trước khi áp dụng nó

3. Shadow mode: test trên traffic live không bán kính tác động

4. Một thứ tự test thực tế

5. Tham chiếu API

Đi đâu tiếp theo