메인 콘텐츠로 건너뛰기
모든 guardrail 규칙은 세 가지 질문에 답합니다 — 무엇을 찾을지(타입), 어디서 찾을지(스테이지), 그리고 그것에 대해 무엇을 할지(액션). 이 페이지는 그 세 번째 선택에 관한 것입니다. 규칙의 액션은 그것에서 가장 중대한 단일 필드입니다: 매치가 요청을 멈출지, 조용히 재작성할지, 아니면 그저 빵 부스러기를 남길지를 결정합니다. 규칙 빌더는 총 다섯 가지 액션을 노출합니다 — block, mask, flag, annotate, spotlight. 이 페이지는 처음에 찾게 되는 세 가지 강제 선택을 다룹니다: block, mask, flag. 규칙당 하나를 선택하세요(또는, PII 규칙의 경우 서로 다른 엔티티를 서로 다른 액션으로 라우팅; §5 참조). 나머지 둘은 비차단의 프롬프트 형성 액션입니다: annotate는 업스트림에 보안 메모를 주입하고 (코드 보안 참조), spotlight는 매치된 신뢰할 수 없는 입력을 구분자로 감싸 모델이 그것을 지시가 아니라 데이터로 취급하게 합니다. 전체 명단은 Guardrails 개요에 있습니다. 더 넓은 엔진 — 규칙 타입, 스테이지, 정책을 키에 연결하기 — 은 Guardrails 개요나 전체 Guardrails 레퍼런스에서 시작하세요.

​
1. guardrail block mask flag 결정을 한 줄로

block

HTTP 400 guardrail_blocked로 호출을 거부합니다. 모델이 결코 실행되지 않거나(입력 스테이지) 그 답변이 결코 반환되지 않습니다(출력 스테이지).

mask

각 매치를 마스킹하고 — 예: jane@acme.com → [EMAIL] — 정화된 텍스트를 통과시킵니다. 요청은 계속됩니다.

flag

트래픽에 대해 아무것도 변경하지 않습니다. 피드에 매치를 기록하고 계속 진행합니다. 관찰 전용.
이것이 세 가지 강제 액션입니다. 설정한 것은 규칙이 실행되는 모든 곳에서 존중됩니다 — 콘솔 규칙 빌더, Test 샌드박스, 그리고 라이브 /v1/* 릴레이 경로가 모두 동일한 block / mask / flag 값을 읽습니다.

​
2. 하나의 구체적인 예 — 세 규칙, 세 액션

세 규칙이 각각 다른 액션을 선택하는 단일 guardrail입니다. 이것을 당신의 세션에서 콘솔(/console/guardrails)에서 작성합니다 — sk-orca-... 릴레이 키는 /v1/* 호출 전용이며, 정책 편집에는 결코 쓰이지 않습니다. guardrail을 생성하거나 편집하려면 Developer+ 역할이 필요합니다. 
{
  "rules": [
    { "type": "keyword", "stage": "input",  "action": "block",
      "keywords": ["internal-only", "do-not-share"] },
    { "type": "pii",     "stage": "input",  "action": "mask",
      "entities": ["email", "phone"] },
    { "type": "regex",   "stage": "output", "action": "flag",
      "pattern": "(?i)acme\\s+confidential" }
  ]
}
각 규칙이 요청에 대해 하는 일:
  • block 규칙은 그 리터럴 용어 중 하나를 담은 모든 프롬프트를 거부합니다 — HTTP 400, 모델이 결코 실행되지 않습니다.
  • mask 규칙은 모델이 보기 전에 프롬프트에서 이메일과 전화번호를 [EMAIL] / [PHONE]로 재작성합니다.
  • flag 규칙은 기밀 마커에 대해 모델의 출력을 지켜보고 응답을 변경하지 않은 채 매치를 기록합니다 — 따라서 강제를 결정하기 전에 그것이 얼마나 자주 나타나는지 측정할 수 있습니다.
엔진은 적용 가능한 모든 규칙을 실행하고 그 결과를 하나의 판정으로 접습니다. 어느 규칙이든 차단하면, 요청은 차단됩니다.

​
3. block — HTTP 400으로 거부

block 액션은 전체 호출을 거부합니다. 호출자는 오류 코드 guardrail_blocked와 함께 HTTP 400을 받으며, 발동한 guardrail과 규칙을 명시하는 메시지를 받습니다.
입력 스테이지 차단은 계량 전에 발동하므로 아무것도 소모되지 않습니다. 출력 스테이지 차단은 답변을 거부한 후 사전 소모된 쿼터를 환불합니다. 어느 쪽이든 호출자는 차단된 호출에 대해 아무것도 지불하지 않습니다.
guardrail_blocked 결과는 skip-retry입니다 — 동일한 프롬프트를 다른 채널에 대해 다시 실행해도 그저 다시 차단될 뿐이므로, 게이트웨이는 재시도를 낭비하지 않습니다. guardrail_blocked 오류를 참조하세요.
비스트리밍 응답에서 답변은 반환되기 전에 검사됩니다. 스트리밍 응답에서 스캐너가 스트림을 도중에 끊고 차단된 콘텐츠가 클라이언트에 도달하기 전에 대체 메시지를 내보냅니다. 스트리밍 커버리지를 참조하세요.
매치가 요청이 진행되어서는 안 됨을 의미할 때 block을 찾으세요 — 프롬프트의 시크릿, 탈옥 시도, 하드 컴플라이언스 라인.

​
4. mask — 마스킹하고 계속

mask 액션은 각 매치를 마스킹하고 정화된 텍스트로 요청을 통과시킵니다. 업스트림 모델은 원본을 결코 보지 못합니다. PII 규칙에서, 각 매치는 엔티티에서 파생된 타입 지정된 태그로 대체됩니다 — 이메일은 [EMAIL], SSN은 [SSN], 신용카드는 [CREDIT_CARD]가 되는 식입니다. (커스텀 엔티티별로 대체 문자열을 오버라이드할 수 있습니다; 마스킹 형식 참조.)
입력 스테이지 마스킹은 모든 스트림에서 라이브입니다. 스트리밍이든 아니든 모델이 실행되기 전에 요청을 재작성합니다. 출력 스테이지 마스킹은 비스트리밍 응답에만 적용됩니다 — 마스킹된 텍스트는 전체 답변이 검사된 후 전달됩니다. 스트리밍 응답에서 게이트웨이는 마스크를 계산하지만 마스킹된 텍스트를 아직 전달하지 않으므로, mask 규칙은 오늘날 스트리밍 응답을 마스킹하지 않습니다; 스트림 내 출력 마스킹은 로드맵에 있습니다. (출력 block은 여전히 스트림을 도중에 끊습니다 — §3 참조.) 당신의 정확한 스테이지/스트림 조합을 먼저 샌드박스에서 증명하세요. 스트리밍 커버리지를 참조하세요.
콘텐츠는 괜찮지만 부분 문자열이 모델에 도달해서는 안 될 때 mask를 찾으세요 — PII 마스킹이 정식 사례입니다. 턴키 시작점은 PII Shield 프리셋입니다; PII Shield를 참조하세요.

​
5. flag — 로깅만, 아무것도 변경 안 함

flag 액션은 관찰 전용입니다: 요청은 규칙이 전혀 없는 것과 바이트 단위로 동일하며, 단지 매치가 Matches 피드에 기록됩니다. 아무것도 차단되지 않고, 아무것도 마스킹되지 않습니다.
flag는 강제하기 전에 규칙을 측정하는 방법입니다. 새 키워드나 정규식을 flag로 출시하고, 며칠 동안 Matches 피드를 지켜보며 실제 트래픽에서 그것의 진양성 대 거짓 양성 비율을 확인한 뒤, 신뢰하게 되면 mask나 block으로 프로모트하세요. flag를 켠 채로 노이즈가 많은 패턴을 튜닝하는 것이 block을 켠 채로 프로덕션에서 거짓 양성을 발견하는 것보다 낫습니다. 거짓 양성 튜닝을 참조하세요.
플래그된 매치는 규칙 타입, 액션, 스테이지, 그리고 상세 문자열을 기록하며 — 그리고 매치된 부분 문자열은 그 guardrail에 대해 Log raw content가 켜져 있을 때 만 기록됩니다(기본적으로 꺼짐, 프라이버시 보수적 자세). 로깅 및 프라이버시를 참조하세요.

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

단일 PII 규칙은 겹치는 규칙을 쌓는 대신 entity_actions를 통해 서로 다른 엔티티를 서로 다른 액션으로 라우팅할 수 있습니다. 각 오버라이드 값은 block / mask / flag / annotate 중 하나여야 하며, 규칙이 이미 선언한 엔티티를 참조해야 합니다 — 검증기는 그 외 모든 것을 거부합니다. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
이 한 규칙은 이메일, 전화, IP를 마스킹하되 카드 번호나 SSN에서는 요청을 곧바로 차단합니다. 동일한 오버라이드 모델 아래에서 자신의 탐지기를 얹는 것은 커스텀 PII 엔티티를 참조하세요.

​
7. 올바른 액션 선택하기

…하고 싶다면사용효과
요청을 완전히 멈춤blockHTTP 400, 쿼터 없음, skip-retry
부분 문자열을 제거하고 호출 유지mask마스킹된 텍스트 전달
트래픽을 건드리지 않고 지켜봄flag매치만 기록
액션은 스테이지와 결합됩니다. 동일한 액션이 입력 vs 출력에서 약간 다르게 동작합니다 — 입력 차단은 사전에 쿼터를 절약하고; 출력 차단은 그것을 환불하고; 출력 마스킹은 비스트리밍 응답에만 적용되는 반면, 출력 차단은 스트리밍과 비스트리밍 응답을 모두 끊습니다. 이 페이지와 함께 입력 스테이지와 출력 스테이지를 읽으세요.

​
8. 다음으로 갈 곳

guardrail_blocked 오류

400이 어떻게 보이는지, 왜 쿼터를 소모하지 않는지, 그리고 skip-retry가 어떻게 작동하는지.

마스킹 형식

타입 지정된 태그, 커스텀 대체 문자열, 그리고 마스킹된 프롬프트가 모델에게 어떻게 읽히는지.

스트리밍 커버리지

오늘날 정확히 어떤 액션 × 스테이지 × 스트림 조합이 강제되는지.

강제 모드

block / mask / flag가 firewall의 audit 판정을 포함한 게이트웨이의 더 넓은 강제 모델에 어떻게 매핑되는지.
firewall은 툴 정책을 위한 자체 판정 어휘(allow, audit, deny, sanitize 등)를 가집니다 — 이 콘텐츠 액션과는 구별됩니다. guardrails vs. firewall을 참조하세요.