Guardrails

워크스페이스와 API 키를 갖추었다면(소개 참조), guardrails는 모든 모델 앞에 콘텐츠 정책을 두는 방법입니다. 이 페이지는 OrcaRouter guardrail 엔진의 정식 레퍼런스입니다 — 무엇인지, 어떻게 사용하는지, 그리고 게이트웨이의 나머지 부분과 어떻게 결합하는지.

1. guardrail 엔진이란

guardrail은 워크스페이스 범위의, 이름이 지정된 콘텐츠 정책으로, 게이트웨이가 요청 입력과 모델 출력에 대해 실행하는 순서가 있는 규칙 목록입니다. guardrail을 한 번 저장하고, 임의의 API 키를 그것에 연결하거나(또는 하나를 워크스페이스 기본값으로 설정), 게이트웨이는 업스트림 모델의 전후로 모든 호출을 검사합니다. 각 규칙은 한 가지를 결정합니다 — 무엇을 찾을지(규칙 타입), 어디서 찾을지(스테이지: 요청 입력 또는 모델 출력), 그리고 그것에 대해 무엇을 할지(액션: block, mask, 또는 flag). 엔진은 적용 가능한 모든 규칙을 실행하고 그 결과를 단일 결정으로 접습니다. guardrail을 편집하면 그것에 연결된 모든 키에서 바로 다음 호출에 반영됩니다. 재배포 없음. 코드 변경 없음. SDK 업그레이드 없음. 정책은 애플리케이션이 아니라 게이트웨이에 존재합니다 — 앱은 이전과 정확히 동일하게 /v1/chat/completions를 계속 호출합니다. 엔진은 내장 규칙 타입에 대해 결정적이고 의존성이 없습니다: 네트워크 호출이 없는 순수 문자열 및 정규식 매칭으로, 핫 릴레이 경로에서 안전하게 실행됩니다. 고급 규칙(외부 벤더, LLM 심판, 컨텍스트 그라운딩)은 외부로 호출하며 동시에 디스패치되므로 느린 검사가 다른 검사 뒤에서 직렬화되는 일이 없습니다. guardrails는 워크스페이스 범위입니다 — 모든 멤버가 워크스페이스의 guardrails를 보며 테넌트 경계를 넘지 않습니다.

2. 빠른 시작 — 5단계로 첫 요청 검사하기

guardrail 생성

콘솔에서 /console/guardrails로 이동하여 New guardrail을 클릭합니다. 이름을 pii-shield로 지정합니다. 규칙을 하나 추가합니다:

Type: PII detection
Stage: Input (request)
Action: Mask — 매치 마스킹
Entities: email, phone, ssn

저장합니다.

샌드박스에서 테스트

에디터 내부의 Test 탭을 열고, *“email me at jane@acme.com”*을 붙여넣고, input 스테이지를 선택한 뒤 실행합니다. 샌드박스는 업스트림으로 아무것도 보내지 않고 판정과 렌더링된 텍스트 — email me at [EMAIL] — 를 표시합니다.

키 연결

/console/token으로 이동하여 API 키를 생성 또는 편집하고, Guardrail 드롭다운에서 pii-shield를 선택합니다. 바인딩은 게이트웨이의 키에 존재합니다.

요청 전송

그 키를 사용하여 이전과 정확히 동일하게 OrcaRouter를 호출합니다:

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"}
    ]
  }'

게이트웨이는 전달하기 전에 이메일을 [EMAIL]로 마스킹합니다. 업스트림 모델은 그 주소를 결코 보지 못합니다.

정책 강화

/console/guardrails로 돌아가 pii-shield를 편집합니다 — 엔티티별 오버라이드를 통해 ssn의 액션을 Block으로 변경합니다. 저장합니다. SSN을 포함하는 바로 다음 요청은 HTTP 400 guardrail_blocked로 거부됩니다. 애플리케이션 변경 없음.

이것이 핵심 가치입니다.

3. 개념: guardrails, 규칙, 스테이지, 액션

개념	정의
Guardrail	이름이 지정된, 워크스페이스 범위 정책. 식별자: `name`(≤ 64자). `enabled`, `is_default`, 그리고 `rules` JSON blob을 가집니다.
Rule	정책 내부의 한 검사: `type`, `stage`, `action`, 그리고 타입별 필드. 규칙은 순서대로 실행됩니다.
Stage	`input`(요청), `output`(모델의 응답), 또는 `both`.
Action	`block`(호출 거부), `mask`(매치 마스킹), 또는 `flag`(로그만 — 트래픽을 변경하지 않고 관찰).

범위 지정과 워크스페이스 기본값

guardrails는 API 키와 정확히 동일하게 범위가 지정됩니다: 활성 워크스페이스가 있으면 워크스페이스 공유, 그렇지 않으면 사용자별. 임의의 요청에 대한 해석:

키 연결 — 키에 명시적 guardrail_id가 있으면 그 guardrail이 적용됩니다(존재하고 활성화된 경우). 명시적 연결은 결코 조용히 폴백하지 않습니다; 그것을 비활성화하는 것이 오프 스위치입니다.
워크스페이스 기본값 — 키에 연결이 없으면 워크스페이스의 활성화된 is_default guardrail이 적용됩니다.
둘 다 아님 — 강제 없음. 요청은 기능을 한 번도 활성화하지 않은 워크스페이스와 바이트 단위로 동일합니다.

워크스페이스당 최대 하나의 guardrail만 기본값이 될 수 있습니다. 새 기본값을 프로모트하면 동일한 트랜잭션에서 이전 것이 강등됩니다.

설계상 페일 오픈. guardrail 해석이 일시적 오류(예: DB 끊김)에 부딪히면, 게이트웨이는 트래픽을 중단시키기보다 강제 없음으로 저하됩니다. 안전성은 저하되지만 가용성은 보존됩니다.

block은 어떻게 보이는가

차단된 요청은 오류 코드 guardrail_blocked와 함께 HTTP 400을 반환하며, 발동한 guardrail과 규칙을 명시하는 메시지를 담습니다. 차단된 요청은 쿼터를 소모하지 않습니다 — input 스테이지 차단은 계량 전에 발동하고, output 스테이지 차단은 사전 소모된 쿼터를 환불합니다 — 그리고 skip-retry로 표시됩니다(동일한 프롬프트를 다시 실행해도 그저 다시 차단될 뿐입니다).

4. 규칙 타입

규칙은 두 그룹으로 나뉩니다: 내장(결정적, 네트워크 없음)과 고급(모델 또는 벤더로 외부 호출).

타입	그룹	무엇을 하는가
Keyword denylist (`keyword`)	내장	리터럴 용어 목록 중 하나라도 매치합니다 — 대소문자를 구분하지 않으며, 부분 문자열 매치입니다(따라서 `class`는 `classic`도 매치합니다).
Regular expression (`regex`)	내장	RE2 패턴을 매치합니다(선형 시간, 역참조 없음).
PII detection (`pii`)	내장	내장 엔티티 타입(과 사용자 정의 타입)을 탐지합니다. §5 참조.
Maximum length (`max_chars`)	내장	한 스테이지에서 텍스트의 문자 수를 상한 처리합니다.
External vendor (`external`)	고급	검사를 연결된 벤더(Aporia, Averta, BYO-webhook 등)에 위임합니다. §9 참조.
LLM judge (`llm_judge`)	고급	워크스페이스의 모델에 대해 의미론적 검사를 실행합니다. §6 참조.
Contextual grounding (`grounding`)	고급	요청에서 검색된 소스(RAG)에 대해 답변의 충실도를 채점합니다. §7 참조.

guardrail은 임의 개수의 임의 타입 규칙을 혼합합니다. 고급 규칙 (external, llm_judge, grounding)은 동시에 디스패치되므로 느린 검사 하나가 다른 검사 뒤에서 직렬화되지 않습니다.

5. PII detection 심층

pii 규칙은 민감한 엔티티를 탐지하고 각 매치에 규칙의 액션을 적용합니다. 내장 탐지기 세트는 닫혀 있으며 엔진, 검증기, 규칙 빌더가 공유합니다: email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt, bitcoin_address. mask 액션에서 각 매치는 타입 지정된 태그로 대체됩니다 — 이메일은 [EMAIL]이, SSN은 [SSN]이 되는 식입니다.

커스텀 엔티티

내장 세트 위에 자신의 탐지기를 얹습니다. 커스텀 엔티티는 다음과 같습니다:

name — 소문자 ASCII / 숫자 / 밑줄, 반드시 문자로 시작해야 함 (예: employee_id). 감사 로그와 텔레메트리에 따옴표 없이 흐릅니다.
pattern — Go RE2 정규식(선형 시간, 역참조 없음).
checksum — 선택; luhn은 Luhn 알고리즘으로 매치를 검증합니다 (예: 카드 유사 번호용).
mask_with — 선택적인 그대로의 대체 문자열; 기본값은 [<UPPERCASE_NAME>].

규칙당 최대 25개의 커스텀 엔티티(각각이 전체 텍스트에 대한 정규식 스캔이므로, 상한이 핫 경로를 선형으로 유지합니다). 컴파일된 패턴은 요청 전반에서 캐시됩니다.

엔티티별 액션 오버라이드

단일 PII 규칙은 entity_actions를 통해 서로 다른 엔티티에 서로 다른 액션을 적용할 수 있습니다. 기본적으로 이메일 / 전화 / IP를 마스킹하되 credit_card나 ssn에서는 차단하는 하나의 규칙 — 세 개의 겹치는 규칙 대신:

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

키는 규칙에서 활성화된 엔티티여야 하며, 값은 block / mask / flag 중 하나여야 합니다. 검증기는 그 외 모든 것을 거부합니다.

6. LLM judge

llm_judge 규칙은 워크스페이스가 이미 호출할 수 있는 모델에 대해 의미론적 검사를 실행합니다. 어떤 정규식으로도 포착되지 않는 모호한 정책에 사용하세요 — 독성, 괴롭힘, 주제 이탈, 프롬프트 인젝션 의도.

필드	의미
`judge_model`	평가에 사용할 모델 또는 라우터 별칭(예: `gpt-4o-mini`, `orcarouter/cheap`). 워크스페이스의 채널에 대해 해석됩니다.
`judge_rubric`	무엇을 플래그할지 기술하는 시스템 프롬프트.
`judge_format`	`yes_no`, `score`, `category` 중 하나(필수; 콘솔에서는 `yes_no`가 미리 선택됩니다).
`judge_threshold`	`score`의 경우: 점수가 이 값 이상일 때 차단/플래그.
`judge_categories`	`category`의 경우: 거부 목록.
`judge_timeout_ms`	심판 호출을 제한합니다. `0` → 엔진 기본값.
`judge_fail_open`	`true`(기본값) → 심판 오류는 관찰되지만 요청은 계속됩니다; `false` → 오류/타임아웃을 차단으로 취급합니다.

심판 호출은 워크스페이스의 채널을 통해 라우팅되므로, 그 토큰은 다른 호출과 마찬가지로 청구되고 귀속됩니다(심판 서브 라인으로). 엔진은 모델이 파싱 가능한 출력을 반환하도록 루브릭에 JSON 스키마 부록을 덧붙입니다.

7. Contextual grounding

grounding 규칙은 어시스턴트의 답변을 요청에서 검색된 소스(당신의 RAG 컨텍스트)에 대해 측정하고, 그것에 충실하지 않은 답변을 플래그하거나 차단합니다. 심판 시임을 재사용합니다 — 동일한 워크스페이스 채널, 동일한 비용 귀속.

필드	기본값	의미
`grounding_model`	워크스페이스 선택	러너가 충실도 검사를 해석하는 모델.
`grounding_rubric`	내장	기본 충실도 루브릭을 오버라이드합니다.
`grounding_threshold`	`0.7`	충실도 하한, `0.0`–`1.0`. 그 아래에서 액션이 발동합니다.
`grounding_strict`	`false`	`true`일 때 “제공된 소스 없음”이 차단으로 취급됩니다(기본 허용 대비).
`grounding_max_bytes`	`100000`	심판에게 전달되는 연결된 소스 컨텍스트를 상한 처리합니다.
`grounding_timeout_ms`	`3000`	심판 호출을 제한합니다.

8. 템플릿, 샌드박스, 평가 하니스

템플릿 라이브러리

New guardrail 분할 버튼은 곧바로 템플릿으로 열리며, 전체 라이브러리는 클릭 한 번 거리에 있습니다. 프리셋은 서버 측에서 작성되므로 콘솔, 샌드박스, 그리고 이 문서가 정확히 동일한 동작을 기술합니다. 카테고리에는 다음이 포함됩니다:

PII (pii) — PII Shield, PII Blocker(엄격), Contact-Info Redactor, 응답 PII redactor.
Secrets (secrets) — AWS / OpenAI / GitHub 자격 증명 차단기, 개인 키 및 클라우드 토큰, 암호화폐 지갑, 출력 내 시크릿.
Compliance (compliance) — GDPR(EU PII), PCI(전체 카드 차단), HIPAA(PHI), 금융 데이터, 컴플라이언스 로거, 법적 고지 강제.
Brand (brand) — 욕설(차단 / 마스킹 / 다국어), 경쟁사 언급, 아동 안전 키워드.
Safety (safety) — 프롬프트 인젝션, 탈옥, 시스템 프롬프트 유출, 자해.
Cost (cost) — 프롬프트 / 응답 크기 상한 및 토큰 상한.
Agent (agent) — URL 필터, 마크다운 이미지, 셸 툴 호출, 출력 내 SQL 인젝션 필터.

프리셋을 시작점으로 적용한 뒤 자유롭게 편집하세요 — 프리셋은 씨앗이지 잠금이 아닙니다.

테스트 샌드박스

모든 에디터에는 Test 탭이 있습니다. 샘플을 붙여넣고, 스테이지를 선택한 뒤, 현재 정책을 로컬에서 실행합니다 — 업스트림 호출 없음, 쿼터 없음. 샌드박스는 판정과(mask 규칙의 경우) 렌더링된 텍스트를 반환하므로, 키를 연결하기 전에 규칙이 예상대로 동작함을 증명할 수 있습니다.

평가 / 레드팀 하니스

Eval 탭은 입력 코퍼스에 대해 guardrail을 실행하고 어떻게 채점했는지 보고합니다 — 심판 루브릭을 튜닝하거나 출시 전에 정책이 알려진 공격을 잡아내는지 증명하는 데 유용합니다.

번들 코퍼스는 게이트웨이와 함께 제공됩니다 — 적대적 및 레드팀 세트(유해 행동 프롬프트, 툴 인젝션, 다국어 레드팀) 및 거짓 양성을 측정하기 위한 양성(benign) 세트.
커스텀 코퍼스 — 실제 트래픽 형태에 대해 테스트하도록 자신의 JSONL을 업로드합니다.
**실행(Runs)**은 점수와 함께 나열됩니다; 실행을 열어 실패를 샘플별로 검사합니다.

9. External vendors

external 규칙은 검사를 연결된 벤더에 위임합니다. Integrations(Guardrails 페이지의 헤더 CTA) 아래에서 벤더를 한 번 연결한 뒤, 규칙에서 그 연결을 참조합니다.

지원되는 벤더

벤더	무엇인지
Aporia Guardrails (`aporia`)	프롬프트와 응답을 위한 SLM 앙상블 정책 엔진.
Averta (`averta`)	범용 SLM 분류기 엔드포인트(POST text → safe / unsafe + 선택적 재작성).
BYO Webhook (`webhook`)	자신의 URL — 프롬프트를 받아 allow / block / mask / flag 판정을 반환.

Aporia와 Averta는 base URL + API 키를 받고, webhook은 URL + 인증 헤더 + HMAC 시크릿을 받습니다.

규칙 필드

필드	의미
`connection_id`	사용할 연결된 통합(권장 경로 — 벤더 + 시크릿이 런타임에 워크스페이스의 통합에서 해석됨).
`timeout_ms`	단일 벤더 호출을 제한합니다. `0` → 기본값.
`fail_open`	`true`(기본값) → 벤더 오류는 관찰되지만 요청은 계속됩니다; `false` → 전송 오류 / 타임아웃 / 알 수 없는 프로바이더를 차단으로 취급합니다.

시크릿은 암호화 저장되며 읽기 시 마스킹됩니다. 검사 호출은 릴레이 요청의 취소를 운반하므로, 취소된 요청이 벤더 호출을 매달려 있게 남기지 않습니다.

10. 관측성

guardrails는 당신이 활용할 수 있는 빵 부스러기를 남깁니다.

Matches 피드

발동하는 모든 규칙은 match를 기록합니다 — 규칙 타입, 액션, 상세 문자열, 스테이지, 그리고(활성화된 경우) 매치된 부분 문자열. Guardrails 페이지의 Matches 탭은 워크스페이스 전반 피드입니다: 나열, 그룹화, 필터, 단일 매치로 드릴인, CSV 내보내기, 거짓 양성 표시.

원시 콘텐츠 캡처는 옵트인입니다. guardrail의 Log raw content 토글은 기본적으로 꺼져 있습니다 — 프라이버시 보수적 자세. 꺼져 있으면 Matches 피드는 규칙이 발동했다는 사실과 그 상세 메타 문자열을 기록하지만 실제 매치된 부분 문자열(예: 이메일 주소 자체)은 기록하지 않습니다. 분류를 위해 부분 문자열이 필요할 때 guardrail별로 켜세요; 이 설정은 소급되지 않습니다.

Stats

Matches 피드는 guardrail별 통계를 구동합니다 — 각 guardrail 카드는 7일 매치 스파크라인과 카운트를 표시하고, Matches 탭은 워크스페이스 합계를 운반합니다. 활동을 정책별로 슬라이스하려면 Matches 피드의 그룹화된 뷰와 필터(guardrail별, 규칙 타입별, 액션별)를 사용하세요 — 그곳에 guardrail별 사용량, 액션 혼합, 거짓 양성률이 있습니다.

버전 기록과 감사

모든 생성, 업데이트, 삭제는 변경과 동일한 트랜잭션에서 버전 관리된 기록 행을 씁니다. guardrail 행에서 History를 열어 다음을 수행할 수 있습니다:

누가 언제 변경했는지와 함께 모든 버전을 봅니다.
임의의 두 버전을 Diff합니다.
더 오래된 버전으로 Revert합니다(새 버전으로 기록됨 — 히스토리는 절대 변경되지 않음).

11. 게이트웨이 나머지 부분과의 관계

표면	guardrails와 어떻게 결합되는가?
Models	guardrails는 모델 비종속적입니다. 동일한 정책이 GPT-5, Claude, Gemini 위에서 동작합니다 — 모델 선택이 아니라 텍스트를 검사합니다.
Routing	독립적. 라우팅은 어떤 모델/채널이 요청을 처리할지 결정하고; guardrails는 모델 선택과 무관하게 동일한 요청/응답 텍스트를 검사하며 모델 선택을 절대 재정의하지 않습니다. 입력 검사는 업스트림 호출 전에 실행되고, 출력 검사는 모델이 응답한 후에 실행됩니다. Judge 및 grounding 규칙은 요청의 라우팅과는 별개로, 워크스페이스 채널을 통해 자체 모델을 해석합니다.
Prompts	독립적이며 상호 보완적. Prompts는 시스템 메시지를 주입합니다; guardrails는 콘텐츠를 검사하고 게이트합니다. 둘 다 하나의 요청에 적용될 수 있으며 guardrails는 항상 실행됩니다. 순서가 중요합니다: 입력 규칙은 레지스트리 프롬프트가 주입되기 전에 호출자의 요청을 검사하므로(주입은 나중에 라우팅 단계에서 발생함), 입력 규칙은 주입된 시스템 프롬프트가 아니라 호출자의 메시지를 봅니다; 출력 규칙은 어느 쪽이든 모델의 응답을 검사합니다.
API Keys	키는 `guardrail_id`를 통해 guardrail에 연결됩니다. 바인딩은 게이트웨이의 키에 존재하므로, guardrail을 편집하면 연결된 모든 키가 한 번에 이동합니다; 연결이 없으면 워크스페이스 기본값으로 폴백합니다.
Matches 피드	발동하는 모든 규칙은 워크스페이스의 Matches 피드에 도달합니다(요청 로그와 분리된 자체 저장소). guardrail별, 규칙 타입별, 액션별로 그룹화하고 필터링하여 guardrail별 사용량, 액션 혼합, 거짓 양성률을 확인하세요.

12. API 레퍼런스

모든 라우트는 X-Workspace-Id 헤더를 통해 워크스페이스 범위입니다. RBAC는 일관되게 강제됩니다: 읽기와 테스트 샌드박스는 모든 멤버에게 개방; 쓰기는 Developer+(및 guardrails:write 권한)를 요구; 프로덕션 트래픽 변경(삭제, 되돌리기, 벤더 구성)은 그에 맞게 게이팅됩니다.

메서드 및 경로	역할	목적
`GET /api/guardrail/`	Member	guardrail 목록(연결된 키 카운트 포함).
`GET /api/guardrail/meta`	Member	엔진 어휘 — 규칙 타입, 스테이지, 액션, PII 엔티티, 프리셋, 프리셋 카테고리.
`GET /api/guardrail/my-permissions`	Member	호출자의 guardrail 권한(UI 게이팅용).
`GET /api/guardrail/:id`	Member	단일 guardrail 상세.
`GET /api/guardrail/:id/tokens`	Member	이 guardrail에 연결된 API 키(상한 적용, 실제 총계 포함).
`POST /api/guardrail/test`	Member	샌드박스 — 한 스테이지에서 샘플 텍스트에 대해 정책을 평가합니다. 아무것도 영속화되지 않습니다.
`POST /api/guardrail/`	Developer+	guardrail 생성.
`PUT /api/guardrail/`	Developer+	guardrail 업데이트(새 기록 버전 작성).
`DELETE /api/guardrail/:id`	Developer+	guardrail 삭제.

History

메서드 및 경로	역할	목적
`GET /api/guardrail/:id/history`	Member	버전 기록(최신순).
`GET /api/guardrail/:id/history/diff`	Member	두 버전 Diff.
`GET /api/guardrail/:id/history/:version`	Member	단일 과거 버전.
`POST /api/guardrail/:id/revert`	Developer+	더 오래된 버전을 새 버전으로 복원.

평가 및 코퍼스

메서드 및 경로	역할	목적
`POST /api/guardrail/:id/eval`	Member	코퍼스(번들 이름 또는 업로드된 JSONL)에 대해 평가 실행.
`GET /api/guardrail/:id/eval/runs`	Member	guardrail의 평가 실행 목록(페이지네이션).
`GET /api/guardrail/eval/runs/:run_id`	Member	단일 평가 실행 상세.
`GET /api/guardrail/eval/corpora`	Member	워크스페이스 코퍼스 + 번들 코퍼스 목록.
`POST /api/guardrail/eval/corpora`	Developer+	JSONL 코퍼스 업로드.
`GET /api/guardrail/eval/corpora/:id`	Member	코퍼스 상세.
`DELETE /api/guardrail/eval/corpora/:id`	Developer+	코퍼스 삭제.

Matches

메서드 및 경로	역할	목적
`GET /api/guardrail/match`	Member	매치 목록(워크스페이스 범위).
`GET /api/guardrail/match/grouped`	Member	그룹화된 매치(예: 규칙 또는 guardrail별).
`GET /api/guardrail/match/stats`	Member	매치 통계(`?days=` 및 `?group_by=` 지원).
`GET /api/guardrail/match/export`	Member	매치를 CSV로 내보내기.
`GET /api/guardrail/match/:id`	Member	단일 매치 상세.
`POST /api/guardrail/match/:id/mark-fp`	Admin	매치를 거짓 양성으로 표시(레이트 제한 있음).
`DELETE /api/guardrail/match/:id/mark-fp`	Admin	거짓 양성 표시 해제(레이트 제한 있음).

키 연결하기

API 키에 guardrail_id를 설정합니다(키 에디터 또는 토큰 API를 통해). 0/null은 명시적 연결 없음을 의미합니다 — 설정되어 있다면 키는 워크스페이스 기본 guardrail로 폴백합니다.

13. FAQ

요청에서 guardrail이 해석되지 않으면 어떻게 되나요?

동작은 기능을 한 번도 활성화하지 않은 워크스페이스와 바이트 단위로 동일합니다. 키가 연결되지 않았고 워크스페이스 기본값도 설정되지 않았다면, 게이트웨이는 어떤 수정도 하지 않습니다. 아무것도 차단, 마스킹되거나 Matches 피드에 로깅되지 않습니다.

차단된 요청은 쿼터를 소모하나요?

아니요. input 스테이지 차단은 사용량이 계량되기 전에 발동하고, output 스테이지 차단은 응답이 거부된 후 사전 소모된 쿼터를 환불합니다. 어느 쪽이든 호출자는 쿼터를 지불하지 않고 HTTP 400 guardrail_blocked를 받으며 요청은 skip-retry로 표시됩니다(동일한 프롬프트를 다른 채널에 대해 다시 실행해도 그저 다시 차단될 뿐입니다).

출력(응답) 규칙은 스트리밍에서 강제되나요?

동작에 따라 다릅니다. block은 양쪽 모두에서 강제됩니다: 비스트리밍 응답에서는 답변이 반환되기 전에 검사되고, 스트리밍 응답에서는 스캐너가 스트림을 도중에 끊고 차단된 콘텐츠가 클라이언트에 도달하기 전에 대체 메시지를 내보냅니다. 출력에 대한 mask는 현재 비스트리밍 응답에만 적용됩니다 — 스트리밍 응답에서는 원본 청크가 마스킹되지 않은 채로 통과합니다(스트림 내 인밴드 재작성은 계획된 개선 사항입니다). 오늘날 출력 마스킹을 위해서는 비스트리밍 요청을 사용하거나 input 스테이지 마스킹에 의존하세요. 그것에 의존하기 전에 샌드박스와 평가 실행으로 당신의 특정 스테이지/스트림 조합을 증명하세요.

mask와 block의 차이는 무엇인가요?

Mask는 매치를 마스킹하고(예: jane@acme.com → [EMAIL]) 정화된 텍스트로 요청을 통과시킵니다 — 업스트림 모델은 원본을 결코 보지 못합니다. Block은 전체 요청을 HTTP 400으로 거부합니다. Flag는 트래픽에 대해 아무것도 변경하지 않고 매치만 기록합니다 — 강제하기 전에 규칙을 측정하는 데 사용하세요.

주입된 프롬프트 토큰과 심판 토큰은 청구되나요?

내장 규칙(keyword / regex / PII / max_chars)은 모델 호출을 하지 않으며 아무것도 청구하지 않습니다. llm_judge 또는 grounding 규칙은 워크스페이스의 채널을 통해 모델을 호출하므로, 그 토큰은 심판 서브 라인으로 청구되고 귀속됩니다.

규칙이 실제로 무엇에 매치했는지 어떻게 보나요?

guardrail에 대해 Log raw content를 켜세요. 꺼져 있으면(기본값), Matches 피드는 규칙이 발동했다는 사실과 그 상세 메타 문자열을 기록하지만 매치된 부분 문자열은 기록하지 않습니다 — 프라이버시 보수적 자세. 이 토글은 소급되지 않습니다: 활성화한 이후에 기록된 매치에만 영향을 줍니다.

guardrail 변경을 롤백할 수 있나요?

예. guardrail에서 History를 열고, 버전을 diff한 뒤, 원하는 버전으로 Revert합니다. Revert는 그 버전의 내용을 새 버전으로 전진 복사하며(히스토리는 절대 변경되지 않음) 변경은 다음 요청에서 반영됩니다.

외부 벤더나 심판이 타임아웃되면 어떻게 되나요?

기본적으로 고급 규칙은 페일 오픈합니다: 타임아웃이나 전송 오류는 텔레메트리로 기록되고 요청은 계속됩니다. 놓친 검사가 용납될 수 없는 정책의 경우 fail_open(external) 또는 judge_fail_open(judge)을 false로 설정하여 페일 클로즈하세요 — 오류를 차단으로 취급합니다.

​1. guardrail 엔진이란

​2. 빠른 시작 — 5단계로 첫 요청 검사하기

​3. 개념: guardrails, 규칙, 스테이지, 액션

​범위 지정과 워크스페이스 기본값

​block은 어떻게 보이는가

​4. 규칙 타입

​5. PII detection 심층

​커스텀 엔티티

​엔티티별 액션 오버라이드

​6. LLM judge

​7. Contextual grounding

​8. 템플릿, 샌드박스, 평가 하니스

​템플릿 라이브러리

​테스트 샌드박스

​평가 / 레드팀 하니스

​9. External vendors

​지원되는 벤더

​규칙 필드

​10. 관측성

​Matches 피드

​Stats

​버전 기록과 감사

​11. 게이트웨이 나머지 부분과의 관계

​12. API 레퍼런스

​Guardrails

​History

​평가 및 코퍼스

​Matches

​키 연결하기

​13. FAQ

1. guardrail 엔진이란

2. 빠른 시작 — 5단계로 첫 요청 검사하기

3. 개념: guardrails, 규칙, 스테이지, 액션

범위 지정과 워크스페이스 기본값

block은 어떻게 보이는가

4. 규칙 타입

5. PII detection 심층

커스텀 엔티티

엔티티별 액션 오버라이드

6. LLM judge

7. Contextual grounding

8. 템플릿, 샌드박스, 평가 하니스

템플릿 라이브러리

테스트 샌드박스

평가 / 레드팀 하니스

9. External vendors

지원되는 벤더

규칙 필드

10. 관측성

Matches 피드

Stats

버전 기록과 감사

11. 게이트웨이 나머지 부분과의 관계

12. API 레퍼런스

Guardrails

History

평가 및 코퍼스

Matches

키 연결하기

13. FAQ