Guardrails

Khi bạn đã có workspace và API key (xem Giới thiệu), guardrails là cách bạn đặt một chính sách nội dung trước mọi mô hình. Trang này là tài liệu tham khảo chính thức cho engine guardrail của OrcaRouter — nó là gì, cách dùng, và cách phối hợp với phần còn lại của gateway.

1. Engine guardrail là gì

Một guardrail là một chính sách nội dung có tên, theo phạm vi workspace — một danh sách quy tắc có thứ tự mà gateway chạy đối với input của request và output của mô hình. Bạn lưu một guardrail một lần, liên kết bất kỳ API key nào với nó (hoặc đặt một guardrail làm mặc định của workspace), và gateway sẽ sàng lọc mọi cuộc gọi trước và sau mô hình thượng nguồn. Mỗi quy tắc quyết định một điều — tìm cái gì (một loại quy tắc), tìm ở đâu (một giai đoạn: input của request hoặc output của mô hình), và làm gì với nó (một hành động: block, mask, hoặc flag). Engine chạy mọi quy tắc áp dụng được và gộp các kết quả thành một quyết định duy nhất. Chỉnh sửa một guardrail có hiệu lực trên mọi key liên kết với nó ở lần gọi kế tiếp. Không triển khai lại. Không đổi code. Không nâng cấp SDK. Chính sách nằm ở gateway, không phải trong ứng dụng của bạn — ứng dụng vẫn gọi /v1/chat/completions y như trước. Engine có tính tất định và không phụ thuộc đối với các loại quy tắc built-in: chỉ là so khớp chuỗi và regex thuần túy không có cuộc gọi mạng, an toàn để chạy trên đường relay nóng. Các quy tắc nâng cao (vendor bên ngoài, LLM judge, contextual grounding) gọi ra ngoài và được điều phối đồng thời, nên một kiểm tra chậm không bao giờ phải xếp hàng nối tiếp sau một kiểm tra khác. Guardrails thuộc phạm vi workspace — mọi thành viên thấy guardrails của workspace; không có gì vượt biên tenant.

2. Bắt đầu nhanh — sàng lọc request đầu tiên trong 5 bước

Tạo một guardrail

Trong console, vào /console/guardrails và nhấn New guardrail. Đặt tên là pii-shield. Thêm một quy tắc:

Type: PII detection
Stage: Input (request)
Action: Mask — redact match
Entities: email, phone, ssn

Lưu.

Test trong sandbox

Mở tab Test bên trong editor, dán “email me at jane@acme.com”, chọn giai đoạn input, và chạy. Sandbox hiển thị verdict và văn bản đã render — email me at [EMAIL] — mà không gửi gì lên thượng nguồn.

Liên kết một key

Vào /console/token, tạo hoặc sửa một API key, và chọn pii-shield từ dropdown Guardrail. Liên kết nằm trên key trong gateway.

Gửi một request

Dùng key đó, gọi OrcaRouter chính xác như trước:

curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com please"}
    ]
  }'

Gateway che email thành [EMAIL] trước khi chuyển tiếp. Mô hình thượng nguồn không bao giờ thấy địa chỉ.

Siết chặt chính sách

Quay lại /console/guardrails, chỉnh pii-shield — đổi hành động trên ssn thành Block qua ghi đè theo từng entity. Lưu. Request kế tiếp chứa một SSN sẽ bị từ chối với HTTP 400 guardrail_blocked. Không thay đổi ứng dụng.

Đó là giá trị cốt lõi.

3. Khái niệm: guardrail, quy tắc, giai đoạn, hành động

Khái niệm	Định nghĩa
Guardrail	Một chính sách có tên, theo phạm vi workspace. Định danh: `name` (≤ 64 ký tự). Có `enabled`, `is_default`, và một blob JSON `rules`.
Quy tắc	Một kiểm tra bên trong một chính sách: một `type`, một `stage`, một `action`, cộng các trường đặc thù theo loại. Các quy tắc chạy theo thứ tự.
Giai đoạn	`input` (request), `output` (phản hồi của mô hình), hoặc `both`.
Hành động	`block` (từ chối cuộc gọi), `mask` (redact match), hoặc `flag` (chỉ ghi log — quan sát mà không thay đổi traffic).

Phạm vi và mặc định của workspace

Guardrails có phạm vi giống hệt API key: chia sẻ theo workspace khi bạn có một workspace đang hoạt động, theo từng người dùng nếu không. Phân giải cho bất kỳ request nào:

Liên kết key — nếu key có một guardrail_id tường minh, guardrail đó áp dụng (khi nó tồn tại và được bật). Một liên kết tường minh không bao giờ âm thầm fallback; tắt nó là công tắc off.
Mặc định workspace — nếu key không có liên kết, guardrail is_default đã bật của workspace sẽ áp dụng.
Cả hai đều không — không thực thi. Request giống hệt từng byte với một workspace chưa bao giờ bật tính năng này.

Mỗi workspace có nhiều nhất một guardrail làm mặc định. Thăng cấp một mặc định mới sẽ hạ cấp cái cũ trong cùng một transaction.

Fail-open theo thiết kế. Nếu việc phân giải guardrail gặp một lỗi thoáng qua (vd: DB trục trặc), gateway suy giảm về không thực thi thay vì làm gián đoạn traffic. An toàn suy giảm; tính sẵn sàng được bảo toàn.

Một block trông như thế nào

Một request bị block trả về HTTP 400 với mã lỗi guardrail_blocked và một thông báo nêu tên guardrail và quy tắc đã kích hoạt. Một request bị block không tốn quota của bạn — một block ở giai đoạn input kích hoạt trước khi đo lường, còn một block ở giai đoạn output hoàn trả lại quota đã tiêu trước — và nó được đánh dấu skip-retry (chạy lại cùng một prompt sẽ chỉ bị block lại).

4. Các loại quy tắc

Các quy tắc chia thành hai nhóm: built-in (tất định, không có mạng) và nâng cao (gọi ra một mô hình hoặc vendor).

Type	Nhóm	Chức năng
Keyword denylist (`keyword`)	Built-in	So khớp bất kỳ thuật ngữ literal nào trong một danh sách — không phân biệt hoa thường, so khớp chuỗi con (nên `class` cũng khớp `classic`).
Regular expression (`regex`)	Built-in	So khớp một pattern RE2 (thời gian tuyến tính, không có backreference).
PII detection (`pii`)	Built-in	Phát hiện các loại entity built-in (và các entity tùy chỉnh của bạn). Xem §5.
Maximum length (`max_chars`)	Built-in	Giới hạn số ký tự của văn bản tại một giai đoạn.
External vendor (`external`)	Nâng cao	Ủy thác kiểm tra cho một vendor đã kết nối (Aporia, Averta, BYO-webhook, …). Xem §9.
LLM judge (`llm_judge`)	Nâng cao	Chạy một kiểm tra ngữ nghĩa đối với một mô hình trong workspace của bạn. Xem §6.
Contextual grounding (`grounding`)	Nâng cao	Chấm điểm độ trung thực của câu trả lời so với các nguồn được truy xuất trên request (RAG). Xem §7.

Một guardrail trộn bất kỳ số lượng quy tắc nào thuộc bất kỳ loại nào. Các quy tắc nâng cao (external, llm_judge, grounding) được điều phối đồng thời nên một kiểm tra chậm không phải xếp hàng nối tiếp sau một kiểm tra khác.

5. PII detection chuyên sâu

Một quy tắc pii phát hiện các entity nhạy cảm và áp dụng hành động của quy tắc cho mỗi match. Tập detector built-in là đóng và được chia sẻ bởi engine, validator, và rule builder: email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt, bitcoin_address. Với hành động mask, mỗi match được thay bằng một tag có kiểu — một email trở thành [EMAIL], một SSN trở thành [SSN], v.v.

Entity tùy chỉnh

Xếp chồng các detector của riêng bạn lên trên tập built-in. Một entity tùy chỉnh là:

name — ASCII chữ thường / chữ số / gạch dưới, phải bắt đầu bằng một chữ cái (vd: employee_id). Đi vào audit log và telemetry không được trích dẫn.
pattern — một regex Go RE2 (thời gian tuyến tính, không có backreference).
checksum — tùy chọn; luhn xác thực match bằng thuật toán Luhn (vd: cho các số kiểu thẻ).
mask_with — chuỗi thay thế nguyên văn tùy chọn; mặc định là [<UPPERCASE_NAME>].

Tối đa 25 entity tùy chỉnh mỗi quy tắc (mỗi cái là một lần quét regex trên toàn bộ văn bản, nên giới hạn này giữ đường nóng tuyến tính). Các pattern đã biên dịch được cache qua các request.

Ghi đè hành động theo từng entity

Một quy tắc PII đơn lẻ có thể áp dụng các hành động khác nhau cho các entity khác nhau qua entity_actions. Một quy tắc che email / phone / IP theo mặc định nhưng block trên credit_card hoặc ssn — thay vì ba quy tắc chồng chéo:

{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}

Các key phải là một entity được bật trên quy tắc; các giá trị phải là block / mask / flag. Validator từ chối mọi thứ khác.

6. LLM judge

Một quy tắc llm_judge chạy một kiểm tra ngữ nghĩa đối với một mô hình mà workspace của bạn đã có thể gọi. Dùng nó cho các chính sách mờ mà không regex nào nắm bắt được — độc hại, quấy rối, lạc đề, ý đồ prompt injection.

Trường	Ý nghĩa
`judge_model`	Mô hình hoặc bí danh router để đánh giá (vd: `gpt-4o-mini`, `orcarouter/cheap`). Phân giải đối với các kênh của workspace bạn.
`judge_rubric`	System prompt mô tả cái cần gắn cờ.
`judge_format`	Một trong các giá trị `yes_no`, `score`, hoặc `category` (bắt buộc; console tự động chọn sẵn `yes_no`).
`judge_threshold`	Cho `score`: block/flag khi điểm bằng hoặc trên giá trị này.
`judge_categories`	Cho `category`: danh sách bị từ chối.
`judge_timeout_ms`	Giới hạn cuộc gọi judge. `0` → mặc định của engine.
`judge_fail_open`	`true` (mặc định) → lỗi judge được quan sát nhưng request vẫn tiếp tục; `false` → coi lỗi/timeout là một block.

Cuộc gọi judge định tuyến qua các kênh của workspace bạn, nên token của nó được tính phí và quy gán như bất kỳ cuộc gọi nào khác (như một sub-line judge). Engine bổ sung một phụ lục JSON-schema vào rubric của bạn để mô hình trả về output có thể parse được.

7. Contextual grounding

Một quy tắc grounding đo lường câu trả lời của assistant so với các nguồn được truy xuất trên request (ngữ cảnh RAG của bạn) và gắn cờ hoặc block các câu trả lời không trung thực với chúng. Nó tái sử dụng seam judge — cùng các kênh workspace, cùng quy gán chi phí.

Trường	Mặc định	Ý nghĩa
`grounding_model`	lựa chọn workspace	Mô hình mà runner phân giải kiểm tra độ trung thực tới.
`grounding_rubric`	built-in	Ghi đè rubric độ trung thực mặc định.
`grounding_threshold`	`0.7`	Sàn độ trung thực, `0.0`–`1.0`. Dưới ngưỡng này, hành động kích hoạt.
`grounding_strict`	`false`	Khi `true`, “không có nguồn được cung cấp” được coi là một block (so với mặc định cho phép).
`grounding_max_bytes`	`100000`	Giới hạn ngữ cảnh nguồn được nối lại và đưa cho judge.
`grounding_timeout_ms`	`3000`	Giới hạn cuộc gọi judge.

8. Templates, sandbox, và bộ harness eval

Thư viện template

Nút split New guardrail mở thẳng vào một template, và toàn bộ thư viện chỉ cách một cú nhấp. Các preset được tạo ở phía server nên console, sandbox, và tài liệu này mô tả chính xác cùng một hành vi. Các danh mục bao gồm:

PII (pii) — PII Shield, PII Blocker (strict), Contact-Info Redactor, response PII redactor.
Secrets (secrets) — bộ chặn credential AWS / OpenAI / GitHub, private key & cloud token, ví crypto, secrets trong output.
Compliance (compliance) — GDPR (EU PII), PCI (chặn thẻ đầy đủ), HIPAA (PHI), dữ liệu tài chính, compliance logger, thực thi tuyên bố miễn trừ pháp lý.
Brand (brand) — tục tĩu (block / mask / đa ngôn ngữ), nhắc đến đối thủ, từ khóa an toàn trẻ em.
Safety (safety) — prompt-injection, jailbreak, system-prompt-leak, tự gây hại.
Cost (cost) — giới hạn kích thước prompt / phản hồi và giới hạn token.
Agent (agent) — bộ lọc URL, markdown-image, shell-tool-call, và SQL-injection-in-output.

Áp dụng một preset làm điểm khởi đầu, rồi chỉnh sửa tự do — một preset là hạt giống, không phải khóa.

Sandbox test

Mỗi editor có một tab Test. Dán một mẫu, chọn một giai đoạn, và chạy chính sách hiện tại cục bộ — không có cuộc gọi thượng nguồn, không tốn quota. Sandbox trả về verdict và (với các quy tắc mask) văn bản đã render, nên bạn có thể chứng minh một quy tắc làm đúng kỳ vọng trước khi liên kết một key.

Bộ harness eval / red-team

Tab Eval chạy một guardrail đối với một corpus các input và báo cáo nó chấm điểm thế nào — hữu ích để tinh chỉnh một rubric judge hoặc chứng minh một chính sách bắt được các cuộc tấn công đã biết trước khi bạn ship nó.

Corpora đóng gói sẵn đi kèm với gateway — các tập đối kháng và red-team (prompt hành vi gây hại, tool-injection, red-teaming đa ngôn ngữ) cộng với các tập lành tính để đo lường false positive.
Corpora tùy chỉnh — tải lên JSONL của riêng bạn để test đối với các dạng traffic thực tế.
Các lần chạy được liệt kê với điểm số; mở một lần chạy để kiểm tra các thất bại theo từng mẫu.

9. Vendor bên ngoài

Một quy tắc external ủy thác kiểm tra cho một vendor đã kết nối. Kết nối một vendor một lần dưới Integrations (CTA ở header trên trang Guardrails), sau đó tham chiếu kết nối đó từ một quy tắc.

Các vendor được hỗ trợ

Vendor	Nó là gì
Aporia Guardrails (`aporia`)	Bộ máy chính sách dựa trên tổ hợp SLM cho prompt và phản hồi.
Averta (`averta`)	Endpoint phân loại SLM tổng quát (POST văn bản → an toàn / không an toàn + viết lại tùy chọn).
BYO Webhook (`webhook`)	URL của riêng bạn — nhận prompt và trả về phán quyết allow / block / mask / flag.

Aporia và Averta nhận một URL gốc + API key; webhook nhận một URL + header xác thực + secret HMAC.

Các trường của quy tắc

Trường	Ý nghĩa
`connection_id`	Tích hợp đã kết nối để dùng (đường khuyến nghị — vendor + secrets phân giải từ tích hợp của workspace tại runtime).
`timeout_ms`	Giới hạn một cuộc gọi vendor đơn lẻ. `0` → mặc định.
`fail_open`	`true` (mặc định) → lỗi vendor được quan sát nhưng request vẫn tiếp tục; `false` → coi lỗi truyền / timeout / provider không xác định là một block.

Secrets được lưu mã hóa và masked khi đọc. Cuộc gọi kiểm tra mang theo sự hủy bỏ của request relay, nên một request bị hủy không để lại một cuộc gọi vendor treo lơ lửng.

10. Khả năng quan sát

Guardrails để lại các dấu vết bạn có thể hành động dựa vào.

Feed các match

Mỗi quy tắc kích hoạt ghi lại một match — loại quy tắc, hành động, một chuỗi chi tiết, giai đoạn, và (khi được bật) chuỗi con đã khớp. Tab Matches trên trang Guardrails là feed toàn workspace: liệt kê, nhóm, lọc, đào sâu vào một match đơn lẻ, xuất CSV, và đánh dấu false positive.

Thu thập nội dung thô là opt-in. Toggle Log raw content của một guardrail tắt theo mặc định — tư thế bảo thủ về quyền riêng tư. Khi tắt, feed Matches ghi lại rằng một quy tắc đã kích hoạt và chuỗi meta chi tiết của nó, nhưng không phải chuỗi con thực sự đã khớp (vd: chính địa chỉ email). Bật nó theo từng guardrail khi bạn cần chuỗi con để phân loại; thiết lập này không hồi tố.

Stats

Feed Matches cấp năng lượng cho stats theo từng guardrail — mỗi card guardrail hiển thị một sparkline và đếm match 7 ngày, và tab Matches mang tổng của workspace. Để chia hoạt động theo chính sách, hãy dùng chế độ xem nhóm và các bộ lọc của feed Matches (theo guardrail, loại quy tắc, hành động) — đó là nơi usage theo từng guardrail, hỗn hợp hành động, và tỷ lệ false-positive được lưu.

Lịch sử phiên bản và audit

Mỗi lần tạo, cập nhật, và xóa ghi một hàng lịch sử có phiên bản trong cùng transaction với thay đổi. Mở History trên một hàng guardrail để:

Xem mọi phiên bản với ai đã thay đổi nó và khi nào.
Diff bất kỳ hai phiên bản nào.
Revert về một phiên bản cũ hơn (được ghi lại như một phiên bản mới — lịch sử không bao giờ bị mutate).

11. Quan hệ với phần còn lại của gateway

Bề mặt	Phối hợp với Guardrails thế nào?
Models	Guardrails là model-agnostic. Cùng một chính sách chạy trên GPT-5, Claude, Gemini — nó sàng lọc văn bản, không phải lựa chọn mô hình.
Routing	Độc lập. Routing quyết định mô hình/kênh nào phục vụ request; guardrails sàng lọc cùng văn bản request/phản hồi đó bất kể thế nào và không bao giờ ghi đè lựa chọn mô hình. Sàng lọc input chạy trước lệnh gọi thượng nguồn, sàng lọc output chạy sau khi mô hình phản hồi. Các quy tắc judge và grounding tự phân giải mô hình của riêng chúng qua các kênh của workspace, tách biệt với routing của request.
Prompts	Độc lập và bổ trợ. Prompts chèn một system message; guardrails kiểm tra và kiểm soát nội dung. Cả hai có thể áp dụng cho một request và guardrails luôn chạy. Thứ tự quan trọng: các quy tắc input sàng lọc request của caller trước khi một registry prompt được chèn vào (việc chèn diễn ra muộn hơn, ở giai đoạn routing), nên các quy tắc input thấy các message của caller, không phải system prompt được chèn vào; các quy tắc output sàng lọc phản hồi của mô hình theo cả hai cách.
API Keys	Một key liên kết với một guardrail qua `guardrail_id`. Liên kết nằm trên key trong gateway, nên chỉnh sửa guardrail dịch chuyển mọi key liên kết cùng lúc; không có liên kết thì fallback về mặc định của workspace.
Feed Matches	Mỗi quy tắc kích hoạt đáp xuống feed Matches của workspace (kho lưu trữ riêng của nó, tách biệt với request log). Nhóm và lọc nó theo guardrail, loại quy tắc, và hành động để thấy usage, hỗn hợp hành động, và tỷ lệ false-positive theo từng guardrail.

12. Tham chiếu API

Mọi route đều theo phạm vi workspace qua header X-Workspace-Id. RBAC được thực thi nhất quán: đọc và sandbox test mở cho mọi thành viên; ghi yêu cầu Developer+ (và quyền guardrails:write); các thay đổi production-traffic (xóa, revert, cấu hình vendor) bị kiểm soát tương ứng.

Method & path	Vai trò	Mục đích
`GET /api/guardrail/`	Member	Liệt kê guardrails (với số lượng key liên kết).
`GET /api/guardrail/meta`	Member	Từ vựng của engine — loại quy tắc, giai đoạn, hành động, entity PII, preset, danh mục preset.
`GET /api/guardrail/my-permissions`	Member	Quyền guardrail của người gọi (để kiểm soát UI).
`GET /api/guardrail/:id`	Member	Chi tiết một guardrail đơn lẻ.
`GET /api/guardrail/:id/tokens`	Member	Các API key liên kết với guardrail này (giới hạn, kèm tổng thực).
`POST /api/guardrail/test`	Member	Sandbox — đánh giá một chính sách trên văn bản mẫu tại một giai đoạn. Không có gì được persist.
`POST /api/guardrail/`	Developer+	Tạo một guardrail.
`PUT /api/guardrail/`	Developer+	Cập nhật một guardrail (ghi một phiên bản lịch sử mới).
`DELETE /api/guardrail/:id`	Developer+	Xóa một guardrail.

History

Method & path	Vai trò	Mục đích
`GET /api/guardrail/:id/history`	Member	Lịch sử phiên bản (mới nhất trước).
`GET /api/guardrail/:id/history/diff`	Member	Diff hai phiên bản.
`GET /api/guardrail/:id/history/:version`	Member	Một phiên bản lịch sử đơn lẻ.
`POST /api/guardrail/:id/revert`	Developer+	Khôi phục một phiên bản cũ hơn thành một phiên bản mới.

Eval và corpora

Method & path	Vai trò	Mục đích
`POST /api/guardrail/:id/eval`	Member	Chạy một eval trên một corpus (tên đóng gói sẵn hoặc JSONL đã tải lên).
`GET /api/guardrail/:id/eval/runs`	Member	Liệt kê các lần chạy eval cho một guardrail (phân trang).
`GET /api/guardrail/eval/runs/:run_id`	Member	Chi tiết một lần chạy eval đơn lẻ.
`GET /api/guardrail/eval/corpora`	Member	Liệt kê corpora của workspace + corpora đóng gói sẵn.
`POST /api/guardrail/eval/corpora`	Developer+	Tải lên một corpus JSONL.
`GET /api/guardrail/eval/corpora/:id`	Member	Chi tiết corpus.
`DELETE /api/guardrail/eval/corpora/:id`	Developer+	Xóa một corpus.

Matches

Method & path	Vai trò	Mục đích
`GET /api/guardrail/match`	Member	Liệt kê các match (theo phạm vi workspace).
`GET /api/guardrail/match/grouped`	Member	Các match được nhóm (vd: theo quy tắc hoặc guardrail).
`GET /api/guardrail/match/stats`	Member	Stats match (hỗ trợ `?days=` và `?group_by=`).
`GET /api/guardrail/match/export`	Member	Xuất các match dưới dạng CSV.
`GET /api/guardrail/match/:id`	Member	Chi tiết một match đơn lẻ.
`POST /api/guardrail/match/:id/mark-fp`	Admin	Đánh dấu một match là false positive (rate-limited).
`DELETE /api/guardrail/match/:id/mark-fp`	Admin	Bỏ đánh dấu một false positive (rate-limited).

Liên kết một key

Đặt guardrail_id trên API key (qua editor key hoặc token API). 0/null nghĩa là không có liên kết tường minh — key fallback về guardrail mặc định của workspace, nếu có một cái được đặt.

13. FAQ

Sẽ ra sao nếu không có guardrail nào phân giải trên một request?

Hành vi giống hệt từng byte với một workspace chưa bao giờ bật tính năng này. Nếu key không được liên kết và không có mặc định workspace được đặt, gateway không thực hiện sửa đổi nào. Không có gì bị block, masked, hoặc ghi log vào feed Matches.

Một request bị block có tốn quota không?

Không. Một block ở giai đoạn input kích hoạt trước khi usage được đo lường; một block ở giai đoạn output hoàn trả lại quota đã tiêu trước sau khi phản hồi bị từ chối. Dù theo cách nào, người gọi không tốn quota, nhận HTTP 400 guardrail_blocked, và request được đánh dấu skip-retry (chạy lại cùng một prompt đối với một kênh khác sẽ chỉ bị block lại).

Các quy tắc output (phản hồi) có được thực thi trên streaming không?

Điều này tùy thuộc vào action. Block được thực thi theo cả hai cách: trên một phản hồi không streaming, câu trả lời được sàng lọc trước khi trả về, còn trên một phản hồi streaming, một scanner cắt stream giữa chừng và phát ra một thông điệp thay thế trước khi bất kỳ nội dung bị block nào đến được client. Mask trên output hiện chỉ áp dụng cho các phản hồi không streaming — trên một phản hồi streaming, chunk gốc đi qua mà không được mask (việc viết lại stream in-band là một cải tiến đã được lên kế hoạch). Để mask output ở thời điểm hiện tại, hãy dùng các request không streaming hoặc dựa vào masking ở stage input. Hãy chứng minh tổ hợp stage/stream cụ thể của bạn trong sandbox và bằng một lần chạy eval trước khi dựa vào nó.

Khác biệt giữa mask và block là gì?

Mask redact match (vd: jane@acme.com → [EMAIL]) và cho request đi qua với văn bản đã làm sạch — mô hình thượng nguồn không bao giờ thấy bản gốc. Block từ chối toàn bộ request với HTTP 400. Flag không thay đổi gì về traffic và chỉ ghi lại một match — dùng nó để đo lường một quy tắc trước khi thực thi nó.

Token prompt được chèn và token judge có bị tính phí không?

Một quy tắc built-in (keyword / regex / PII / max_chars) không thực hiện cuộc gọi mô hình và không tính phí gì. Một quy tắc llm_judge hoặc grounding gọi một mô hình qua các kênh của workspace bạn, nên các token đó được tính phí và quy gán như một sub-line judge.

Làm sao để tôi thấy một quy tắc thực sự đã khớp cái gì?

Bật Log raw content cho guardrail. Khi tắt (mặc định), feed Matches ghi lại rằng một quy tắc đã kích hoạt và chuỗi meta chi tiết của nó nhưng không phải chuỗi con đã khớp — tư thế bảo thủ về quyền riêng tư. Toggle không hồi tố: nó chỉ ảnh hưởng các match được ghi sau khi bạn bật nó.

Tôi có thể rollback một thay đổi guardrail không?

Có. Mở History trên guardrail, diff các phiên bản, và Revert về cái bạn muốn. Revert sao chép nội dung của phiên bản đó tiến lên thành một phiên bản mới — lịch sử không bao giờ bị mutate — và thay đổi có hiệu lực ở request kế tiếp.

Điều gì xảy ra nếu một vendor bên ngoài hoặc judge time out?

Theo mặc định, các quy tắc nâng cao fail open: một timeout hoặc lỗi truyền được ghi lại dưới dạng telemetry và request vẫn tiếp tục. Đặt fail_open (external) hoặc judge_fail_open (judge) thành false để fail closed — coi lỗi là một block — cho các chính sách mà một kiểm tra bị bỏ lỡ là không chấp nhận được.

​1. Engine guardrail là gì

​2. Bắt đầu nhanh — sàng lọc request đầu tiên trong 5 bước

​3. Khái niệm: guardrail, quy tắc, giai đoạn, hành động

​Phạm vi và mặc định của workspace

​Một block trông như thế nào

​4. Các loại quy tắc

​5. PII detection chuyên sâu

​Entity tùy chỉnh

​Ghi đè hành động theo từng entity

​6. LLM judge

​7. Contextual grounding

​8. Templates, sandbox, và bộ harness eval

​Thư viện template

​Sandbox test

​Bộ harness eval / red-team

​9. Vendor bên ngoài

​Các vendor được hỗ trợ

​Các trường của quy tắc

​10. Khả năng quan sát

​Feed các match

​Stats

​Lịch sử phiên bản và audit

​11. Quan hệ với phần còn lại của gateway

​12. Tham chiếu API

​Guardrails

​History

​Eval và corpora

​Matches

​Liên kết một key

​13. FAQ

1. Engine guardrail là gì

2. Bắt đầu nhanh — sàng lọc request đầu tiên trong 5 bước

3. Khái niệm: guardrail, quy tắc, giai đoạn, hành động

Phạm vi và mặc định của workspace

Một block trông như thế nào

4. Các loại quy tắc

5. PII detection chuyên sâu

Entity tùy chỉnh

Ghi đè hành động theo từng entity

6. LLM judge

7. Contextual grounding

8. Templates, sandbox, và bộ harness eval

Thư viện template

Sandbox test

Bộ harness eval / red-team

9. Vendor bên ngoài

Các vendor được hỗ trợ

Các trường của quy tắc

10. Khả năng quan sát

Feed các match

Stats

Lịch sử phiên bản và audit

11. Quan hệ với phần còn lại của gateway

12. Tham chiếu API

Guardrails

History

Eval và corpora

Matches

Liên kết một key

13. FAQ