Bảng thuật ngữ verdict, hành động và masking

Khi bạn đọc một firewall event hoặc một guardrail match, hàng đó cho bạn biết gateway đã quyết định gì — deny, sanitize, [EMAIL]. Trang này là bảng tra cứu cho những từ đó: mỗi từ nghĩa là gì, nó làm gì với cuộc gọi, và đi đâu để biết cơ chế đầy đủ. Hãy mở nó khi bạn soạn quy tắc hoặc phân loại feed event. Hai mặt phẳng kiểm soát tạo ra hai từ vựng. Firewall quản trị các hành động tool và phát ra một verdict. Guardrails sàng lọc văn bản prompt và phản hồi và phát ra một action cộng, trên một mask, một tag masking có kiểu. Chúng không bao giờ chia sẻ một từ — một guardrail không bao giờ nói deny, một firewall không bao giờ nói mask.

Đây là một chỉ mục tham chiếu, không phải hướng dẫn cách-làm. Về use-case đằng sau mỗi kiểm soát xem Guardrails vs Firewall; về các body HTTP xem Mã lỗi bảo mật.

1. Bảng thuật ngữ verdict firewall

Một quy tắc firewall (hoặc default_verdict của chính sách) phân giải mọi cuộc gọi tool về đúng một trong sáu verdict này. Engine duyệt các quy tắc theo thứ tự ưu tiên, match đầu tiên thắng, và fallback về mặc định nếu không có gì khớp.

allow — cho cuộc gọi đi qua

Cuộc gọi tiến hành tới tool. Vẫn được ghi log như một firewall event nên nó hiện ra trong Runs và feed event. Đây là cái bạn muốn cho các tool mà một agent được tin tưởng tường minh để dùng.

audit — cho phép, nhưng ghi lại để xem xét

Traffic giống hệt allow, nhưng gắn cờ như một thứ bạn muốn theo dõi. Đây là default_verdict được khuyến nghị: quan sát mọi thứ, không chặn gì, cho tới khi các quy tắc của bạn được tinh chỉnh. Autonomy level balanced cung cấp guardrail PII Shield ở chế độ chỉ-flag (audit), nên PII được ghi lại mà không giữ cuộc gọi.

deny — chặn cuộc gọi

Cuộc gọi không bao giờ tới tool. Trên bề mặt inbound cái này trả về HTTP 400 firewall_blocked; qua MCP gateway nó quay lại dưới dạng một lỗi tool (firewall deny: <reason>) để model có thể phản ứng thay vì sập. Đánh dấu skip-retry. Tốn không model token.

sanitize — redact các argument, chuyển tiếp cuộc gọi đã làm sạch

Thay các chuỗi con đã khớp (secret, PII) trong các argument của cuộc gọi tool bằng một token [redacted:<preset>], rồi chuyển tiếp cuộc gọi với các argument đã làm sạch. Nó chỉ redact các argument — không bao giờ nội dung mà một tool trả về. Trên bề mặt inbound, nơi chưa có argument lúc gọi, sanitize leo thang thành một deny.

pending_approval — giữ chờ con người

Cuộc gọi được xếp hàng để xem xét và agent nhận được một phản hồi đã giữ mang theo một approval id (HTTP 400 firewall_approval_pending). Một người duyệt giải quyết nó trong console hoặc qua một HMAC webhook callback; agent poll id và gửi lại một lần với một header phê duyệt dùng một lần. Xem Phê duyệt của con người.

cap_cost — deny một khi lần chạy tiêu quá

Soạn dưới dạng một quy tắc với một trần (cents) theo từng quy tắc. Nó phân giải thành allow khi lần chạy agent còn dưới ngân sách và thành deny một khi mức chi tích lũy vượt cap — nên một event hiển thị allow hoặc deny, không phải từ literal cap_cost. Một circuit-breaker cho các vòng lặp mất kiểm soát.

Ở chế độ shadow, deny / sanitize / pending_approval đều bị hạ cấp thành audit và lý do được thêm tiền tố [shadow] would …. Event ghi lại verdict mà lẽ ra đã kích hoạt, nhưng traffic không đổi — đó là toàn bộ ý nghĩa của một lần triển khai an toàn.

Verdict mặc định

default_verdict chỉ chấp nhận ba verdict không-tương-tác:

Giá trị	Ý nghĩa khi không quy tắc nào khớp
`allow`	Cho phép các cuộc gọi tool không được bao phủ một cách im lặng.
`audit`	Cho phép nhưng ghi lại — mặc định.
`deny`	Chặn bất cứ thứ gì không quy tắc nào cho phép tường minh (tư thế default-deny).

Autonomy level tight đặt default_verdict: deny; balanced và mặc định được cung cấp dùng audit.

2. Các hành động guardrail

Một quy tắc guardrail kích hoạt một trong năm hành động. Chúng là tương đương ở mặt phẳng văn bản của verdict — và một quy tắc guardrail không bao giờ tạo ra một verdict firewall.

Action	Nó làm gì	Quota
`block`	Từ chối toàn bộ request với HTTP 400 `guardrail_blocked`.	Không — chặn input kích hoạt trước đo lường; chặn output hoàn lại.
`mask`	Redact mỗi match thành một tag có kiểu (xem §3) và chuyển tiếp văn bản đã làm sạch.	Bình thường — cuộc gọi tiến hành.
`flag`	Chỉ ghi log. Ghi lại một match; không thay đổi gì về traffic.	Bình thường.
`annotate`	Không chặn. Đính một ghi chú con người đọc được vào request (chèn lên upstream như một thông báo bảo mật) mà không mask hay chặn văn bản.	Bình thường.
`spotlight`	Không chặn. Bọc văn bản (không đáng tin) đã khớp trong các dấu phân cách và bảo model coi vùng được phân cách là dữ liệu, không bao giờ là hướng dẫn — phòng vệ “spotlighting” chống prompt-injection.	Bình thường.

Một request guardrail bị chặn được đánh dấu skip-retry — chạy lại cùng một prompt trên một kênh khác chỉ chặn lại.

Dùng flag để đo một quy tắc mới đối với traffic thật trước khi bạn chuyển nó sang block hoặc mask. Feed Matches hiển thị những gì lẽ ra đã bị bắt với tác động zero lên traffic — đối tác guardrail của chế độ shadow của firewall.

Một quy tắc pii đơn lẻ có thể áp dụng các hành động khác nhau cho các thực thể khác nhau với entity_actions — mask email và phone, nhưng block trên credit_card và ssn, từ một quy tắc. Các key phải là một thực thể được bật trên quy tắc; các value phải là block / mask / flag / annotate.

3. Bảng thuật ngữ tag masking

Trên một hành động mask, mọi thực thể đã khớp được thay thế ngay trong dòng bằng một tag có kiểu — [<TÊN_THỰC_THỂ_VIẾT_HOA>] — để model (giai đoạn input) hoặc bên gọi (giai đoạn output) thấy hình dạng của dữ liệu mà không thấy giá trị. Masking chạy trên cả hai giai đoạn, bao gồm phản hồi streaming: một stream scanner nhận biết token mask các match nằm vắt qua ranh giới chunk trước khi chúng tới client.

Thực thể	Tag
`email`	`[EMAIL]`
`phone`	`[PHONE]`
`credit_card`	`[CREDIT_CARD]`
`ssn`	`[SSN]`
`ip`	`[IP]`
`iban`	`[IBAN]`
`mac_address`	`[MAC_ADDRESS]`
`jwt`	`[JWT]`
`aws_access_key`	`[AWS_ACCESS_KEY]`
`api_key_openai`	`[API_KEY_OPENAI]`
`bitcoin_address`	`[BITCOIN_ADDRESS]`

Ba định danh khu vực được cung cấp thêm trên tập cơ sở:

Thực thể	Tag	Khu vực
`jp_mynumber`	`[JP_MYNUMBER]`	Nhật Bản
`kr_rrn`	`[KR_RRN]`	Hàn Quốc
`cn_resident_id`	`[CN_RESIDENT_ID]`	Trung Quốc

Thực thể tùy chỉnh theo cùng quy ước. Một thực thể tùy chỉnh tên employee_id mask thành [EMPLOYEE_ID] trừ khi bạn đặt một thay thế mask_with tường minh. Tối đa 25 thực thể tùy chỉnh mỗi quy tắc, mỗi cái là một regex RE2 với một checksum luhn tùy chọn. Xem Phát hiện PII.

4. Một ví dụ chạy thực

Một cuộc gọi tool db.query đơn lẻ, đọc từ trên xuống dưới, chạm vào cả hai từ vựng:

firewall verdict : sanitize        # secret bị tước khỏi argument SQL
guardrail action : mask            # một email trong prompt bị redact
masking tag      : [EMAIL]         # cái model thực sự nhận được

Firewall sanitize đã làm sạch các argument tool; guardrail mask đã làm sạch văn bản prompt; tag [EMAIL] là cái model thấy thay cho địa chỉ. Cùng một request, ba lớp khác nhau, ba từ từ bảng thuật ngữ này.

5. Các từ về tư thế bạn sẽ thấy bên cạnh verdict

Đây không phải verdict hay action, nhưng chúng quyết định liệu một verdict có được thực thi hay không — nên chúng hiện ra trong cùng các chế độ xem event và settings.

Từ	Mặt phẳng	Ý nghĩa
Shadow mode	Firewall	Cờ theo từng chính sách. Hạ cấp mọi verdict thực thi thành `audit`, thêm tiền tố lý do `[shadow] would …`.
Observe mode	Firewall	Settings của workspace. Khi không chính sách nào phân giải, cho phép cuộc gọi nhưng ghi log nó như một khoảng trống độ phủ (Discovered tools).
Enforce	Firewall	Shadow tắt + một chính sách đính: các verdict có hiệu lực.
Fail-open	Guardrails	Mặc định cho các quy tắc nâng cao (`llm_judge`, `grounding`, `external`) — một timeout được quan sát, request tiếp tục. Lật sang fail-closed theo từng quy tắc.
Log raw content	Guardrails	Mặc định tắt. Khi tắt, một match ghi lại rằng một quy tắc đã kích hoạt nhưng không phải chuỗi con đã khớp.

Về sự phân biệt deny-vs-audit-vs-shadow chuyên sâu, xem Chế độ thực thi.

6. Nơi mỗi từ được định nghĩa

Bề mặt	Từ vựng	Trang chủ
Chính sách firewall	`allow` `audit` `deny` `sanitize` `pending_approval` `cap_cost`	Firewall
Khớp quy tắc firewall	`tool_name_glob`, `args_match`, egress, sequence	Quy tắc firewall
Quy tắc guardrail	`block` `mask` `flag` `annotate` `spotlight`	Guardrails
Guardrail PII	tên thực thể + tag masking	Guardrails
MCP & skills	dải rủi ro skill, chế độ `quarantine` / `block`	Firewall MCP, Firewall skills
Body lỗi HTTP	`guardrail_blocked`, `firewall_blocked`, `firewall_approval_pending`	Mã lỗi

Mọi thuật ngữ ở đây cũng xuất hiện trong Bảng thuật ngữ khái niệm rộng hơn, vốn bổ sung các thuật ngữ danh tính, scope, và đe dọa. Trang này là lát cắt hẹp, tập trung vào quyết định — chỉ verdict, action, và tag masking.

7. Đọc liên quan

Tại sao bị chặn?

Truy vết một cuộc gọi bị từ chối đơn lẻ về đúng quy tắc và verdict đã chặn nó.

Chế độ thực thi

Cách audit, shadow, observe, và enforce liên hệ — và cách triển khai an toàn.

Guardrails vs Firewall

Mặt phẳng nào sở hữu quyết định nào, và vì sao một request có thể đi qua cả hai.

Cuộc gọi tool nguy hiểm

Mối đe dọa mà các verdict deny và sanitize tồn tại để chặn.

​1. Bảng thuật ngữ verdict firewall

​Verdict mặc định

​2. Các hành động guardrail

​3. Bảng thuật ngữ tag masking

​4. Một ví dụ chạy thực

​5. Các từ về tư thế bạn sẽ thấy bên cạnh verdict

​6. Nơi mỗi từ được định nghĩa

​7. Đọc liên quan

Tại sao bị chặn?

Chế độ thực thi

Guardrails vs Firewall

Cuộc gọi tool nguy hiểm

1. Bảng thuật ngữ verdict firewall

Verdict mặc định

2. Các hành động guardrail

3. Bảng thuật ngữ tag masking

4. Một ví dụ chạy thực

5. Các từ về tư thế bạn sẽ thấy bên cạnh verdict

6. Nơi mỗi từ được định nghĩa

7. Đọc liên quan