메인 콘텐츠로 건너뛰기
llm 프롬프트가 운반하는 민감한 데이터를 마스킹해야 할 때 — 이메일, 카드 번호, 국가 ID, 시크릿 — 게이트웨이는 모델이 보기 전에 각 매치를 제자리에서 재작성합니다. 마스킹된 값은 타입 지정된 태그(jane@acme.com → [EMAIL])가 되므로, 원시 값이 당신의 워크스페이스를 결코 떠나지 않으면서도 모델은 여전히 일관된 프롬프트를 읽습니다. 이 페이지는 마스킹이 무엇을 렌더링하는지, 태그를 어떻게 바꾸는지, 그리고 단일 규칙에서 일부 엔티티는 마스킹하면서 다른 엔티티는 차단하는 방법에 초점을 둔 정리입니다. 전체 엔진 — 모든 규칙 타입, 스테이지, 라우트 — 은 Guardrails 레퍼런스를, 요청에서의 마스킹은 구체적으로 입력 스테이지 규칙을 참조하세요.

​
1. llm 프롬프트가 운반하는 민감한 데이터를 타입 지정된 태그로 마스킹

mask 액션이 있는 pii 규칙은 엔티티를 탐지하고 각 매치를 타입 지정된 마스킹 태그로 대체합니다 — 값을 드러내지 않고 무엇이 제거되었는지를 명시하는 대괄호 안의 대문자 레이블:
엔티티렌더링된 태그
email[EMAIL]
credit_card[CREDIT_CARD]
ssn[SSN]
전체 내장 탐지기 세트 — email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, 그리고 지역별 jp_mynumber, kr_rrn, cn_resident_id — 는 각각 자체 대괄호 태그를 렌더링합니다([PHONE], [IBAN], [JP_MYNUMBER] 등). 태그는 결정적입니다: 동일한 엔티티는 항상 동일한 레이블을 렌더링하므로, 다운스트림 프롬프트가 안정적으로 유지되고 당신의 로그가 깔끔하게 읽힙니다.
타입 지정된 태그는 모델 품질 면에서 무차별적 [REDACTED]를 이깁니다. 모델은 여전히 이메일 vs. 계정 번호 vs. 전화번호를 보고 있음을 알므로, 데이터의 형태에 대해 계속 추론할 수 있습니다 — “reply to [EMAIL]”는 실제 값을 결코 쥐지 않고도 실행 가능한 지시로 유지됩니다.
입력 마스킹은 완전히 라이브입니다 — 게이트웨이는 스트리밍이든 아니든 프롬프트가 모델에 도달하기 전에 그것을 재작성합니다. 출력 마스킹도 비스트리밍 응답에서 라이브입니다: 출력 스테이지의 mask 규칙은 완성이 반환되기 전에 그것을 재작성합니다. 스트리밍 출력 마스킹만 로드맵에 있습니다; 스트리밍 응답에서는 출력 스테이지에서 block을 선호하세요. 정확한 스테이지/스트림 매트릭스는 스트리밍 커버리지를 참조하세요.

​
2. 하나의 구체적인 예

규칙을 당신의 세션에서 콘솔에서 작성하세요 — guardrail 구성에는 릴레이 키가 아니라 **Developer+**가 필요합니다. pii-shield라는 이름의 guardrail에 단일 pii 규칙을 추가합니다: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn"]
}
키에 연결하고(​guardrail_id를 설정하거나, 워크스페이스 기본값으로 표시 — 키에 연결하기 참조), 그 sk-orca-... 릴레이 키로 게이트웨이를 호출합니다: 
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 about her SSN 123-45-6789"}
    ]
  }'
게이트웨이는 전달하기 전에 프롬프트를 *“Reply to [EMAIL] about her SSN [SSN]”*로 재작성합니다. 업스트림 모델은 주소나 번호를 결코 보지 못합니다. 먼저 에디터의 Test 탭에서 정확한 렌더링을 증명하세요 (업스트림 호출 없음, 쿼터 없음) — 테스트 및 평가를 참조하세요.

​
3. mask_with로 태그 오버라이드하기

내장 엔티티는 고정된 태그를 렌더링합니다. 커스텀 엔티티 — 내장 세트 위에 얹은 자신의 정규식 탐지기 — 는 mask_with로 대체 텍스트를 직접 설정하게 합니다: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP-[0-9]{6}",
      "mask_with": "[STAFF_ID]"
    }
  ]
}
mask_with는 그 엔티티의 매치에 대한 그대로의 대체 문자열입니다. EMP-004217은 [STAFF_ID]가 됩니다. 비워두면 매치는 기본 태그 [<UPPERCASE_NAME>] — 여기서는 [EMPLOYEE_ID] — 를 렌더링하므로, 커스텀 탐지기는 오버라이드 없이도 항상 읽기 쉬운 타입 지정된 마스킹을 생성합니다.
name(소문자 ASCII / 숫자 / 밑줄, 반드시 문자로 시작), pattern(Go RE2 정규식 — 선형 시간, 역참조 없음), 선택적 checksum(luhn은 카드 형태 번호를 검증), 그리고 선택적 mask_with. 규칙당 최대 25개의 커스텀 엔티티 — 각각이 전체 텍스트에 대한 스캔이므로, 상한이 핫 경로를 선형으로 유지합니다. 커스텀 PII 엔티티를 참조하세요.
name은 감사 로그와 Matches 피드로 따옴표 없이 흐르므로, 문자로 시작하는 소문자 ASCII 문자, 숫자, 밑줄로 유지하세요(예: employee_id, internal_ticket). 검증기는 그 외 모든 것을 거부합니다.

​
4. 일부 엔티티는 마스킹, 다른 엔티티는 차단 — entity_actions

단일 pii 규칙은 세 개의 겹치는 규칙을 쌓는 대신 entity_actions를 통해 서로 다른 엔티티에 서로 다른 액션을 적용할 수 있습니다. 전형적인 형태: 저민감도 연락처 데이터는 마스킹하되, 고민감도 필드는 곧바로 차단. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
여기서 email, phone, ip는 규칙의 최상위 mask를 따라 [EMAIL] / [PHONE] / [IP]를 렌더링하고; credit_card나 ssn 매치는 대신 전체 요청을 HTTP 400 guardrail_blocked로 차단합니다.
필드규칙
키규칙에서 선언된 엔티티여야 함(내장 또는 커스텀).
값block, mask, flag, 또는 annotate.
차단된 요청은 쿼터를 소모하지 않습니다 — 입력 스테이지 차단은 계량 전에 발동합니다. 마스킹된 요청은 정화된 텍스트로 통과합니다. 따라서 하나의 규칙이 단일 연결과 애플리케이션 변경 없이 일상적 필드를 조용히 마스킹하고 규제된 필드를 하드 스톱할 수 있습니다.

​
5. Mask vs. block vs. flag

마스킹은 규칙(또는 엔티티별 오버라이드)이 취할 수 있는 액션 중 하나입니다. 트래픽을 얼마나 방해하고 싶은지로 선택하세요:

mask

매치를 타입 지정된 태그로 마스킹하고 정화된 텍스트로 요청을 통과시킵니다. 모델은 원시 값을 결코 보지 못합니다.

block

전체 요청을 HTTP 400 guardrail_blocked로 거부합니다. 아무것도 모델에 도달하지 않습니다. 결코 전송되어서는 안 되는 데이터에 사용하세요.

flag

트래픽에 대해 아무것도 변경하지 않습니다 — 매치만 기록합니다. 강제하기 전에 규칙이 얼마나 자주 발동할지 측정합니다.
좋은 롤아웃은 flag → mask → block입니다: 영향을 가늠하려면 flag, 탐지기를 신뢰하게 되면 mask, 그리고 전혀 통과시킬 수 없는 필드에는 block을 예약하세요. 액션과 거짓 양성 튜닝을 참조하세요.

​
6. 무엇이 마스킹되었는지 확인하기

발동하는 모든 규칙은 워크스페이스 Matches 피드에 match를 기록합니다 — 규칙 타입, 액션, 스테이지, 그리고 상세 문자열. 매치된 부분 문자열 자체(원시 이메일, 실제 카드 번호)는 Log raw content가 켜져 있을 때 만 기록되며, 이는 기본적으로 꺼져 있습니다 — 핵심 전체가 원시 값을 당신의 로그에서 차단하는 것이므로, 프라이버시 보수적 자세입니다.
Log raw content는 분류를 위해 부분 문자열이 진정으로 필요할 때만, 그리고 guardrail별로만 켜세요. 그것이 꺼져 있으면, 피드는 번호를 결코 저장하지 않고 [CREDIT_CARD]가 마스킹되었음을 증명합니다. 토글은 소급되지 않습니다. 로깅 및 프라이버시를 참조하세요.

​
7. 다음으로 갈 곳

  • PII Shield 프리셋 — 클릭 한 번으로 적용할 수 있는, 단일 규칙의 모든 것 마스킹 시작점.
  • 커스텀 PII 엔티티 — mask_with와 선택적 luhn으로 자신의 정규식 탐지기를 작성합니다.
  • 입력 스테이지 규칙 — 마스킹이 오늘날 라이브로, 모델 앞에서 그리고 계량 앞에서 실행되는 곳.
  • 시크릿 차단 — 자격 증명의 경우, (마스킹이 아니라) 차단이 올바른 선택입니다.
  • 스트리밍 커버리지 — 오늘날 어떤 스테이지/스트림 조합이 마스킹 vs. 차단하는지.
완전한 엔진은 Guardrails 레퍼런스를 읽거나, 마스킹이 억제하도록 만들어진 위협은 PII 노출과 시크릿 유출을 읽으세요.