메인 콘텐츠로 건너뛰기
여러분의 앱이 모델로 보내는 모든 프롬프트는 담겨서는 안 될 개인 데이터를 실어 나를 수 있습니다 — 지원 티켓에 붙여넣은 이메일, CRM 노트의 주민번호, 사용자가 채팅창에 입력한 카드번호. 그 텍스트가 일단 업스트림 프로바이더에 도달하면 여러분의 통제를 벗어납니다: 로깅되고, 캐싱되고, 어쩌면 학습에 사용됩니다. 모델의 응답도 PII를 되돌려 유출할 수 있습니다 — 세부 정보를 그대로 반복하거나 추론하여 여러분의 애플리케이션 로그에 떨어뜨립니다. 이 페이지는 게이트웨이에서 PII guardrail로 llm pii 유출을 막는 방법을 보여줍니다 — 모델이 보기 전에 요청에서 민감 엔티티를 마스킹하거나 차단하는 워크스페이스 범위 규칙입니다. 이는 Agent Firewall의 콘텐츠 계층 동료이며, 여러분의 애플리케이션 코드 변경을 요구하지 않습니다.
PII guardrail은 프롬프트와 응답의 텍스트를 검사합니다. 에이전트가 데이터로 취하는 액션을 통제하려면 — fetch 툴, egress 호스트 — 데이터 유출을 참조하세요. 두 평면은 조합되며, 대부분의 팀은 둘 다 실행합니다.

​
1. 노출은 어떻게 일어나는가

PII는 평범하고 선의로 가득한 트래픽을 통해 업스트림 프로바이더에 도달합니다:
  • 사용자가 자기 연락처 정보를 채팅에 붙여넣고 여러분의 앱이 전체 메시지를 그대로 전달합니다.
  • RAG 파이프라인이 고객 레코드를 담은 문서를 검색해 컨텍스트로 프롬프트에 채워 넣습니다.
  • 에이전트가 데이터베이스 행을 읽고 원시 필드를 툴 인자나 후속 프롬프트에 포함합니다.
  • 모델의 응답이 PII를 다시 진술하거나 추론하고, 여러분의 앱이 그것을 자체 로그에 기록합니다.
이 중 어느 것도 공격이 아닙니다 — 이들은 LLM 앱의 정상적인 형태입니다. 해법은 코드의 모든 호출 지점을 감사하는 대신, 단일 초크 포인트에서 모든 요청과 응답을 검사하는 정책입니다.

​
2. PII guardrail로 llm pii 유출을 방어하기

guardrail은 워크스페이스 범위의, 이름이 지정된 콘텐츠 정책입니다. 그 안의 pii 규칙은 민감 엔티티를 탐지하고 각 매치에 하나의 액션을 적용합니다:
액션효과
mask각 매치를 타입이 지정된 태그로 대체합니다 — jane@acme.com → [EMAIL] — 그리고 정리된 텍스트를 전달합니다. 모델은 원본을 결코 보지 못합니다.
block전체 요청을 HTTP 400 guardrail_blocked으로 거부합니다. PII가 프로바이더에 결코 도달해서는 안 될 때 사용합니다.
flag트래픽에 대해 아무것도 바꾸지 않습니다; 매치를 기록합니다. 강제하기 전에 노출을 측정하세요.
탐지기 세트는 내장되어 있고 결정론적입니다 — 순수한 패턴 매칭이며, 네트워크 호출이 없어 핫 패스에서 안전합니다. 내장 엔티티: 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. mask 액션에서는 각 매치가 타입이 지정된 태그로 렌더링됩니다 — [EMAIL], [SSN], [CREDIT_CARD] 등 — 따라서 값은 사라지면서도 프롬프트의 구조는 유지됩니다.
내장되지 않은 탐지기가 필요한가요(내부 직원 ID, 계좌 번호)? 커스텀 엔티티를 추가하세요 — 선택적 Luhn 체크섬이 있는 regex로, 규칙당 최대 25개까지 — 내장 항목 바로 옆에. Guardrails 레퍼런스를 참조하세요.

​
3. 구체적 예시 — 요청에서 PII 마스킹

가장 빠른 시작은 PII Shield 프리셋입니다: email, phone, ssn, credit_card, ip를 마스킹하는 단일 pii 규칙. 콘솔에서 구성하세요 — 코드 변경 없음, 이 단계에서는 키 없음.
1

guardrail 생성

콘솔에서 Guardrails를 열고 New guardrail을 클릭합니다. pii 카테고리에서 PII Shield 프리셋을 고르거나, 위 엔티티에 대해 액션 mask로 하나의 pii 규칙을 직접 작성하세요. 저장합니다. (쓰기는 Developer 역할 이상을 요구합니다.)
2

샌드박스에서 증명

Test 탭을 열고 *“reply to jane@acme.com”*을 붙여넣고, input 스테이지를 고르고, 실행합니다. 샌드박스는 reply to [EMAIL]을 반환합니다 — 로컬에서, 업스트림 호출 없이, 쿼터 소모 없이.
3

키에 연결

API Keys에서 키를 편집하고 Guardrail 드롭다운에서 guardrail을 선택하거나, guardrail을 워크스페이스 기본값으로 설정해 연결되지 않은 모든 키가 그것을 상속하게 하세요. 바인딩은 게이트웨이의 키에 존재합니다.
4

평소처럼 게이트웨이 호출

그 키를 사용하면, 릴레이 호출은 변경되지 않습니다:
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": "Draft a reply to jane@acme.com"}
    ]
  }'
게이트웨이는 전달하기 전에 이메일을 [EMAIL]로 다시 씁니다. 업스트림 모델은 그 주소를 결코 받지 않습니다.
PII Shield는 both 스테이지 규칙이지만, 현재 출시된 것은 라이브 요청 스테이지 마스킹입니다 — 게이트웨이는 프롬프트가 모델로 떠나기 전에 마스킹합니다. 라이브 릴레이에서의 출력 스테이지(응답) 마스킹은 로드맵에 있습니다. 응답 스테이지 규칙이 어떻게 동작하는지 검증하려면 Test 탭에서 평가하세요. 스트리밍은 §5를 참조하세요.

​
4. 대부분은 마스킹, 최악은 차단 — 엔티티별 오버라이드

단일 규칙이 entity_actions를 통해 서로 다른 엔티티에 서로 다른 액션을 적용할 수 있습니다. 저위험 식별자는 마스킹하되 결코 전달하고 싶지 않은 엔티티는 하드 차단하세요 — 겹치는 세 규칙 대신 하나로: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
여기서 이메일, 전화번호, IP는 마스킹되어 통과합니다; 카드번호나 주민번호를 실은 프롬프트는 대신 HTTP 400 guardrail_blocked으로 거부됩니다. 차단된 요청은 쿼터를 소모하지 않으며 — 입력 스테이지 차단은 미터링 전에 발동합니다 — skip-retry로 표시됩니다. 각 entity_actions 키는 규칙에 선언된 엔티티여야 하며(내장 또는 커스텀); 그 액션은 규칙의 액션 세트에 대해 검증됩니다.

​
5. 오늘 스트리밍에서 동작하는 것

액션과 스테이지는 스트리밍과 서로 다르게 상호작용합니다 — 의존하기 전에 매트릭스를 알아두세요:
완전히 라이브. 프롬프트는 업스트림 호출 전에 검사되므로, 응답이 스트리밍되든 아니든 마스킹과 차단이 동일하게 동작합니다. 이것이 오늘 PII Shield가 강제하는 표면입니다.
스트리밍 및 비스트리밍 응답 모두에서 강제됩니다. 스트림에서는 스캐너가 차단된 콘텐츠가 클라이언트에 도달하기 전에 스트림을 비행 중에 끊고 대체 메시지를 내보냅니다; 출력 차단은 사전 소모된 쿼터를 환불합니다.
현재 비스트리밍 전용. 스트리밍 응답에서는 원본 청크가 마스킹되지 않은 채 통과합니다 — 인밴드 스트림 재작성은 계획된 개선 사항입니다. 오늘 응답 마스킹을 위해서는 비스트리밍 요청을 사용하거나, 입력 스테이지 마스킹에 의존하세요. 여러분의 정확한 스테이지/스트림 조합을 먼저 Test 탭에서 증명하세요.

​
6. 무엇이 포착되었는지 보기

발동하는 모든 규칙은 매치를 기록합니다 — 그 타입, 액션, 스테이지, 그리고 detail 문자열 — 워크스페이스 Matches 피드(GET /api/guardrail/match, 모든 멤버에게 개방)에서 볼 수 있습니다. 거기서 그룹화, 필터, CSV 내보내기, 그리고 오탐 표시를 할 수 있습니다.
원시 값은 기본적으로 로깅되지 않습니다. guardrail의 Log raw content 토글은 꺼져 있습니다 — 프라이버시 보수적 자세 — 따라서 Matches 피드는 PII 규칙이 발동했다는 것과 어떤 엔티티인지를 기록하지만, 매치된 부분 문자열(이메일 주소 자체)은 기록하지 않습니다. 분류를 위해 값이 필요할 때만 guardrail별로 켜세요; 이 설정은 비소급적입니다. PII 유출을 디버깅하기 위해 자체 감사 추적에 PII를 캡처하는 것은 자기모순입니다.

​
7. 더 나아가기

전체 거주지, 보존, 삭제권 통제 — GDPR, HIPAA, 또는 PCI DSS를 위해 이 guardrail들을 구체화하는 컴플라이언스 팩 설치 포함 — 를 위해서는 아래 레퍼런스 페이지에서 시작하세요.

Guardrails 레퍼런스

모든 규칙 타입, 스테이지, 액션, 커스텀 엔티티, 버저닝, 그리고 eval 하네스 — 이 페이지 뒤의 심층 레퍼런스.

시크릿 유출

자격 증명 형태의 동기 — AWS, OpenAI, GitHub 토큰 — Secrets Blocker guardrail이 포착합니다.

안전하지 않은 출력

모델이 받는 것뿐만 아니라 되돌려 보내는 것을 검사합니다.

Guardrails vs Firewall

언제 텍스트를 검사하고 언제 액션을 통제할지 — 그리고 왜 대개 둘 다 원하는지.