메인 콘텐츠로 건너뛰기
당신의 앱이 스트리밍한다면, 콘텐츠 정책을 신뢰하기 전에 하나의 명확한 답이 필요합니다: SSE 응답에서 실제로 무엇이 강제되는가. 전체 응답을 검사하는 guardrail은 추론하기 쉽습니다; 델타가 브라우저로 플러시되는 대로 그것에 작용해야 하는 guardrail은 아닙니다. 이 페이지는 스트리밍 guardrail 커버리지 매트릭스입니다 — 입력 및 출력 스테이지 전반의 모든 액션, 스트리밍 및 비스트리밍 트래픽에서 — 각 셀이 라이브 스트림에서 어떻게 동작하는지에 대해 정밀하게 작성되었습니다. 전체 엔진 — 모든 규칙 타입, 필드, 라우트 — 은 Guardrails를 참조하세요. 스트림이 어떻게 끊기는지의 메커니즘은 스트림 안전 규칙을 참조하세요.

​
1. 스트리밍 guardrail 커버리지 질문

guardrail 규칙은 스테이지(input, output, 또는 both)와 액션 — 다섯 중 하나: block, mask, flag, annotate, 또는 spotlight — 을 운반합니다. 스테이지는 게이트웨이가 그것을 언제 실행할지 결정하고; 액션은 무엇을 하는지 결정합니다. 스트리밍이 답의 형태를 바꾸는 유일한 곳은 output 스테이지입니다 — 그것이 게이트웨이가 바이트를 먼저 전체 페이로드를 쥘 기회 없이 도착하는 대로 클라이언트로 전달하는 유일한 스테이지이기 때문입니다. 따라서 매트릭스에는 스트리밍이 중요한 두 셀이 있고, 그것들은 다르게 동작합니다: 출력 block은 스트림에서 완전히 강제되고(스캐너가 끊음), 출력 mask는 비스트리밍 응답에서만 강제됩니다. 스트리밍 응답에서 스캐너는 여전히 매치를 탐지하고 block 결정에 작용할 수 있지만, 오늘날 마스킹된 텍스트를 스트림에 재작성하지 않습니다 — 인밴드 스트리밍 출력 마스킹은 로드맵에 있습니다.
입력은 결코 문제가 아닙니다. 입력 스테이지 규칙은 모델 전에 실행됩니다 — 게이트웨이는 당신의 요청을 검사하고(​mask의 경우, 재작성하고), 그 다음 정화된 버전을 업스트림으로 전달합니다. 응답이 스트리밍될지는 무관합니다; 요청은 게이트웨이가 전부 쥐는 완전한 페이로드입니다. 입력 스캐닝은 모든 요청에서 완전히 라이브이며, 마스킹 포함입니다.

​
2. 커버리지 매트릭스

이것을 위에서 아래로 읽으세요. 모든 block 셀은 스트리밍을 포함하여 라이브입니다 — 하지만 output + mask + 스트리밍은 스트림에서 아직 강제되지 않는 하나의 셀입니다: mask 규칙은 비스트리밍 응답을 마스킹하고, 스트리밍 응답에서는 델타를 재작성하지 않고 매치를 탐지합니다(스트림 내 출력 마스킹은 로드맵에 있습니다).
스테이지 · 액션비스트리밍스트리밍
input · block요청을 거부요청을 거부
input · mask요청을 재작성요청을 재작성
output · block응답을 거부스트림을 끊음
output · mask응답을 마스킹매치를 탐지; 스트림 내에서 마스킹 안 함(로드맵)
any · flag기록만기록만
annotate와 spotlight는 트래픽을 거부하지 않고 메모를 첨부(또는 매치된 텍스트를 감싸기)하며 실제로는 입력 스테이지 액션이므로, 위의 출력/스트리밍 셀을 변경하지 않습니다; 다른 규칙처럼 매치를 기록합니다.
입력 스테이지 규칙은 업스트림 모델이 실행되기 전에 요청을 검사합니다. block은 호출을 단락시킵니다(HTTP 400 guardrail_blocked, 계량 전이므로 쿼터를 소모하지 않음). mask는 프롬프트의 매치된 필드를 제자리에서 재작성합니다 — 정화된 텍스트가 업스트림으로 가는 것이고, 모델은 원본을 결코 보지 못합니다. 이 중 어느 것도 응답이 스트리밍되는지에 달려 있지 않습니다.
비스트리밍 응답에서 완성은 반환되기 전에 전부 검사됩니다 — 차단은 **HTTP 400 guardrail_blocked**로 표시됩니다. 스트리밍 응답에서 스트림 스캐너가 델타가 흐르는 대로 그것을 지켜봅니다; block 규칙이 발동하면 스트림을 끊습니다 — 스캐너를 봉인하고, 나머지 대신 짧은 대체 알림을 내보내고, 추가 차단된 콘텐츠가 클라이언트에 도달하기 전에 SSE 채널을 닫습니다. 그때쯤이면 200 SSE 헤더가 이미 나갔으므로, 스트리밍 차단은 400을 반환할 수 없습니다: HTTP 오류가 아니라 최종 인밴드 델타로 차단을 전달합니다.
비스트리밍 응답에서 mask 규칙은 완성을 재작성합니다 — 예: 이메일이 [EMAIL]이 됩니다 — 그리고 정화된 텍스트가 클라이언트가 받는 것입니다. 스트리밍 응답에서 스트림 스캐너는 여전히 매치를 탐지하고 마스크를 계산하지만, 마스킹된 텍스트를 델타에 전달하지 않습니다 — 마스킹된 출력은 폐기되고 block 결정에만 작용됩니다. 따라서 mask 규칙은 오늘날 스트리밍 응답을 마스킹하지 않습니다; 인밴드 스트리밍 출력 마스킹은 로드맵에 있습니다. 지금 당장 스트리밍 응답에서 PII를 차단해야 한다면, 규칙을 block으로 작성하거나(스캐너가 매치 시 스트림을 끊음) 비스트리밍으로 검사하세요.
flag 규칙은 결코 트래픽을 변경하지 않습니다 — 매치를 기록하고 바이트를 통과시킵니다. 스테이지와 스트림은 그 동작을 변경하지 않습니다. 규칙을 block으로 프로모트하기 전에 그 히트율을 측정하는 데 사용하세요.
기억해야 할 한 줄: 출력 block은 두 전송 모두에서 라이브로 강제됩니다 — 스트리밍 포함 — 그리고 입력 마스킹은 항상 라이브입니다. 출력 mask는 비스트리밍 응답만 마스킹합니다; 스트림에서는 매치를 탐지하지만 아직 델타를 재작성하지 않습니다(스트림 내 출력 마스킹은 로드맵에 있습니다). 오늘날 스트리밍 응답에서 PII를 차단하려면, 규칙을 block으로 작성하거나 비스트리밍으로 검사하세요.

​
3. 하나의 구체적인 예 — 스트리밍 응답에서 PII 차단

모델이 RAG 컨텍스트에서 고객 이메일을 드러낼 수 있고, 당신의 앱이 스트리밍한다고 합시다. 출력 mask는 오늘날 스트림에서 마스킹하지 않습니다(스트림 내 출력 마스킹은 로드맵에 있습니다) — 따라서 스트리밍 응답에서 PII를 차단하려면, 출력 규칙을 block으로 작성하세요: 스캐너가 매치가 나타나는 순간 스트림을 죽입니다. (출력 mask는 비스트리밍 응답에서 마스킹합니다.) 정책 편집은 당신의 콘솔 세션에 대한 관리 액션입니다(​**Developer+**로 게이팅); sk-orca-... 릴레이 키는 /v1/* 트래픽만 보내고 정책을 결코 편집하지 않습니다.
  • /console/guardrails를 열고, New guardrail, stream-pii-out으로 이름을 지정합니다.
  • 규칙을 하나 추가합니다:
    • Type: PII detection
    • Stage: output
    • Action: block ← 매치 시 스트림을 끊음; 스트림에서 mask는 탐지만 함(비스트리밍 응답을 마스킹함)
  • 저장한 뒤, /console/token에서 키의 Guardrail 드롭다운을 통해 연결합니다.
이제 이전과 정확히 동일하게 stream: true로 게이트웨이를 호출합니다: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "stream": true,
    "messages": [
      {"role": "user", "content": "Email the customer from the record above"}
    ]
  }'
델타가 매치되면, 스캐너는 스트림을 끊고, 대체 알림을 내보내고, 채널을 닫습니다 — 클라이언트는 나머지를 결코 받지 못합니다. 응답이 깨끗하면, 모든 델타가 변경 없이 스트리밍됩니다.
스트리밍 차단은 매치 이후의 모든 것을 멈추지만, 매치가 안착하기 전에 이미 플러시된 바이트를 되돌릴 수는 없습니다. 당신의 정책이 단 하나의 위반 바이트도 결코 클라이언트에 도달해서는 안 된다고 요구한다면, 정책이 그것을 통과시킬 때까지 전체 완성이 쥐어지는 비스트리밍으로 요청을 검사하세요.

​
4. 매트릭스 전반의 PII Shield

PII Shield 프리셋은 단일 pii 규칙, 액션 mask, 스테이지 both 입니다. 그것을 매트릭스에 매핑하면 커버리지는 §2에서 예상하는 것과 정확히 같습니다:
  • 입력 스테이지 — 완전히 라이브, 스트리밍이든 아니든. 요청은 모델이 보기 전에 마스킹됩니다(입력 마스킹의 핵심 가치).
  • 출력 스테이지, 비스트리밍 — 완성은 반환되기 전에 마스킹됩니다.
  • 출력 스테이지, 스트리밍 — 스트림 스캐너는 매치를 탐지하지만 오늘날 델타를 재작성하지 않으므로, 마스킹된 형태가 스트리밍 클라이언트에 도달하지 않습니다(스트림 내 출력 마스킹은 로드맵에 있습니다).
따라서 mask 프리셋은 그 자체로 스트리밍 응답에서 PII를 다루지 않습니다. 스트리밍 응답에서 PII를 차단하려면, 그 규칙을 block으로 작성하여(또는 비스트리밍으로 호출하여) 매치 시 스트림이 끊기게 하세요. PII Shield와 마스킹 형식을 참조하세요.

​
5. 스트리밍 차단이 소모하는 것

스트리밍 차단은 다른 출력 차단과 동일한 회계를 운반합니다 — 모델이 이미 실행되었으므로, 게이트웨이가 환불을 대신 처리합니다:
  • 비스트리밍 응답에서 호출은 발동한 guardrail과 규칙을 명시하는 **HTTP 400 guardrail_blocked**를 반환합니다. 스트리밍 응답에서 200 SSE 헤더가 이미 전송 중이므로, 차단은 400 대신 최종 인밴드 대체 델타와 깔끔한 채널 닫힘으로 도착합니다.
  • 쿼터가 청구되지 않습니다. 입력 차단은 계량 전에 발동하고; 출력 차단(스트리밍이든 아니든)은 응답이 거부되면 사전 소모된 쿼터를 환불합니다. 어느 쪽이든 호출자는 아무것도 지불하지 않습니다.
  • 요청은 skip-retry로 표시됩니다 — 동일한 프롬프트를 다시 실행해도 그저 다시 차단될 뿐이므로, 게이트웨이는 다른 채널에서 재시도를 태우지 않습니다.
발동하는 모든 출력 규칙은 워크스페이스 Matches 피드에도 match를 기록합니다(GET /api/guardrail/match, 모든 Member에게 개방); 매치된 부분 문자열은 guardrail의 Log raw content 토글이 켜져 있을 때만 캡처됩니다(기본적으로 꺼짐). 전체 상세는 guardrail_blocked 오류와 matches 피드에 있습니다.

​
6. 출시 전에 당신의 스테이지/액션 조합 증명하기

매트릭스의 어느 셀이 당신의 정책에 적용되는지 추측하지 마세요 — 검증하세요. 두 도구 모두 관리 API를 통해 당신의 콘솔 세션에서 실행됩니다:

Test 탭

각 guardrail 에디터에는 Test 탭이 있습니다: 샘플을 붙여넣고, 스테이지를 선택한 뒤, 업스트림 호출 없이, 쿼터 없이 현재 정책을 실행합니다. 판정과(mask 규칙의 경우) 렌더링된 텍스트를 보세요. Test 샌드박스는 **Developer+**로 게이팅됩니다(유료 judge/grounding 호출과 아웃바운드 통합 요청을 발동할 수 있음).

Eval 탭

Eval 탭은 번들 또는 커스텀 JSONL 코퍼스에 대해 guardrail을 채점합니다 — 키를 연결하기 전에 block 규칙이 알려진 유출을 잡는지 확인하는 데 유용합니다. 평가 실행은 읽기 액세스(viewer+)만 필요합니다.
심층은 테스트 및 평가와 거짓 양성 튜닝을 참조하세요.

​
7. 다음으로 갈 곳

스트림 안전 규칙

스캐너가 SSE 스트림을 도중에 어떻게 끊는지, 그리고 스트리밍 트래픽에서 유지되는 정책을 작성하는 방법.

출력 스테이지

모델의 응답 검사 — block vs. mask, 쿼터 환불, 그리고 grounding.

입력 스테이지

모델 앞에서 요청 검사 — 마스킹 포함, 스트리밍이든 아니든.

액션

block, mask, flag, annotate, spotlight를 심층적으로 — 각각이 올바른 선택일 때.
Guardrails — grounding과 LLM judge를 포함한 모든 규칙 타입, 필드, 라우트.