메인 콘텐츠로 건너뛰기
당신이 잡아야 할 것 중 일부는 리터럴 단어도 아니고 타입 지정된 PII 엔티티도 아닙니다 — 형태입니다. SKU 형식, 주문 번호 레이아웃, 내부 URL 패턴, 쿠폰 코드, 계약 참조. regex 규칙은 그 형태를 모든 호출에서 매치한 뒤, 프롬프트가 모델에 도달하기 전과 응답이 당신의 사용자에 도달하기 전에 그것을 차단, 마스킹, 또는 플래그하게 합니다. 이것은 구조화된 패턴 유스 케이스에 초점을 둔 랜딩입니다. 전체 guardrail 엔진 — 모든 규칙 타입, 필드, 라우트 — 은 Guardrails 레퍼런스를 참조하세요.
여기 모든 단계는 호스팅된 게이트웨이(api.orcarouter.ai)에 대한 콘솔 액션입니다. 당신의 세션에서 guardrail을 작성하며; 최종 /v1/* 호출만 sk-orca-... 릴레이 키를 사용합니다. guardrail을 생성하고 편집하려면 워크스페이스에서 **Developer+**가 필요합니다.

​
1. regex guardrail llm 제어가 필요할 때

regex 규칙은 잡으려는 것이 리터럴 거부 목록이 표현할 수 없는 구조를 가지지만 pii 탐지기가 이미 다루는 표준 신원이 아닐 때 올바른 도구입니다.

구조화된 코드

SKU, 쿠폰 코드, 계약 참조, 내부 티켓 ID — 고정 접두사와 숫자 또는 영숫자 런.

형식 형태 토큰

유한한 단어 목록이 아니라 형태로 매치되는 모든 것 — 주문 번호 레이아웃, 시리얼 형식, 내부 URL 패턴.

출력 유출 패턴

내부 호스트명, 파일 경로, 또는 레코드 ID 형식을 드러내서는 안 되는 응답 — 모델의 출력에서 형태를 스캔하세요.

저렴한, 결정적 검사

순수 패턴 매칭, 모델 호출 없음, 네트워크 없음 — 어느 방향으로든 모든 요청에서 실행하기에 안전.
맞는 가장 가벼운 도구를 선택하세요. 리터럴 용어의 유한한 목록 → 키워드 거부 목록. 타입 지정된 마스크 태그([EMAIL], [SSN])나 Luhn 검사를 원하는 이름이 지정된 신원 형태 → PII / 커스텀 엔티티. 엔티티별 타입 지정이 없는 구조적 패턴 → 여기서 다루는 regex 규칙.

​
2. RE2 — 선형 시간, 역참조 없음

regex 규칙의 pattern은 Go RE2 정규식입니다. RE2는 regex 규칙을 모든 요청에서 실행하기에 안전하게 만드는 엔진입니다:
RE2는 패턴과 무관하게 입력 길이에 선형인 매칭 시간을 보장합니다. 백트래킹 엔진은 적대적 입력(“ReDoS”)에서 기하급수적으로 폭발할 수 있습니다; RE2는 그럴 수 없습니다. 그것이 당신의 패턴을 모든 호출에서 핫 경로에서 평가하기에 안전한 이유입니다.
RE2는 역참조(\1), 룩어헤드, 또는 룩비하인드를 지원하지 않습니다. 그것들에 의존하는 PCRE 패턴을 포팅한다면, 그것들 없이 다시 작성하세요. 문자 클래스, 앵커, 수량자, 교대, 비캡처 그룹은 모두 예상대로 작동합니다.
별도의 “대소문자 무시” 스위치가 없습니다 — 플래그를 인라인으로 설정하세요. 대소문자를 구분하지 않으려면 (?i), 멀티라인은 (?m)을 앞에 붙이세요. 예: (?i)\bproject-orca\b.
규칙 빌더는 guardrail을 저장할 때 당신의 패턴을 컴파일합니다. 컴파일되지 않는 패턴은 오류에 규칙 인덱스와 함께 거부되므로, 나쁜 탐지기는 결코 릴레이 경로에 도달하지 않습니다.
RE2 패턴은 PCRE가 아닙니다. 가장 흔한 포팅 놀라움은 역참조나 룩어헤드입니다 — 둘 다 지원되지 않습니다. 대신 매치를 문자 클래스 / 교대 패턴으로 작성하고 키를 연결하기 전에 Test 탭에서 검증하세요.

​
3. 정규식 규칙의 해부

regex 규칙은 keyword 다음으로 엔진에서 가장 작은 규칙입니다: 패턴, 스테이지, 그리고 액션.
필드무엇을 하는가
patternGo RE2 정규식(선형 시간, 역참조 없음). 반드시 컴파일되어야 함.
stageinput(요청), output(응답), 또는 both.
actionblock, mask, 또는 flag.
mask 액션에서, 모든 매치는 제자리에서 단일 리터럴 [REDACTED] 태그로 대체됩니다 — regex 규칙은 타입 지정되지 않으므로, [EMAIL] 같은 엔티티별 태그를 렌더링하지 않습니다. 타입 지정된 태그나 커스텀 대체 토큰을 원한다면, 대신 형태를 커스텀 PII 엔티티로 모델링하세요.

​
4. 하나의 구체적인 예

당신의 내부 주문 번호가 ORD- 뒤에 여덟 자리 숫자가 오는 형태이고, 모델의 응답에서 결코 되울려지기를 원하지 않는다고 합시다. output 스테이지에 단일 regex 규칙을 추가합니다: 
{
  "type": "regex",
  "stage": "output",
  "action": "mask",
  "pattern": "ORD-\\d{8}"
}
콘솔에서 작성하세요:
1

guardrail 생성

Guardrails를 열고, New guardrail을 클릭한 뒤, 이름을 지정합니다(≤ 64자), 예: order-id-filter.
2

정규식 규칙 추가

규칙을 하나 추가합니다 — Type: Regular expression, Stage: Output, Action: Mask — 그리고 패턴 ORD-\d{8}을 붙여넣습니다. 저장합니다.
3

샌드박스에서 테스트

Test 탭을 열고, 샘플을 붙여넣고, output 스테이지를 선택한 뒤, 현재 정책을 로컬에서 실행합니다 — 업스트림 호출 없음, 쿼터 없음:
Your order ORD-48291507 has shipped.

Your order [REDACTED] has shipped.
4

키 연결

API 키를 편집하고 Guardrail 드롭다운에서 order-id-filter를 선택하거나(키에 guardrail_id 설정), guardrail을 워크스페이스 기본값으로 표시합니다. 키에 연결하기와 계정 기본값을 참조하세요.
그 다음 이전과 정확히 동일하게 OrcaRouter를 호출합니다 — 새 헤더 없음, SDK 변경 없음: 
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": "What is the status of my order?"}
    ]
  }'
주문 번호는 당신의 사용자에 도달하기 전에 응답에서 마스킹됩니다.

​
5. 스테이지와 스트리밍 커버리지

선택한 액션은 응답이 스트리밍되는지 여부와 상호 작용합니다:
액션비스트리밍스트리밍
block (출력)강제됨강제됨 — 스캐너가 스트림을 끊음
mask (출력)강제됨강제됨 — 스캐너가 버퍼를 재작성함
입력 스테이지 규칙은 업스트림 호출 전에 실행되므로, 스트리밍의 영향을 받지 않습니다 — 모델이 보기 전에 요청을 마스킹하는 것은 라이브입니다. 출력 mask와 출력 block은 둘 다 스트리밍과 비스트리밍 응답에서 강제됩니다. 스트리밍 커버리지를 참조하세요.

​
6. 액션 선택하기

regex 규칙은 규칙당 하나의 액션을 선택합니다:
어떤 매치든 요청을 HTTP 400 guardrail_blocked로 거부합니다. 차단된 요청은 쿼터를 소모하지 않으며 — 입력 스테이지 차단은 계량 전에 발동하고; 출력 스테이지 차단은 사전 소모된 쿼터를 환불합니다 — skip-retry로 표시됩니다. guardrail_blocked 오류를 참조하세요.
각 매치는 제자리에서 [REDACTED]로 대체되고 요청은 정화된 텍스트로 계속됩니다 — 업스트림 모델(입력 스테이지)이나 당신의 사용자(출력 스테이지)는 원본을 결코 보지 못합니다. 액션을 참조하세요.
매치를 기록하고 트래픽에 대해 아무것도 변경하지 않습니다. 새 패턴의 올바른 시작점: 그것을 flag로 출시하고, Matches 피드를 지켜본 뒤, 신뢰하게 되면 mask/block으로 프로모트하세요.
매치를 기록하고 트래픽을 변경하지 않고 메모(예: 분류에서 표시할 발견 사항)를 첨부합니다. 액션을 참조하세요.
입력 스테이지 방어: 각 매치는 모델에게 텍스트를 지시가 아니라 데이터로 취급하라고 알리는 구분자(예: ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧)로 감싸집니다 — 프롬프트 인젝션 완화. 액션을 참조하세요.

​
7. 무엇이 발동했는지 보기 — 그리고 정밀도 튜닝

발동하는 모든 규칙은 워크스페이스 Matches 피드에 match를 기록합니다 — 규칙 타입, 액션, 스테이지, 그리고 상세 문자열.
매치된 부분 문자열은 Log raw content가 켜져 있을 때 만 기록되며, 이는 기본적으로 꺼져 있습니다 — 프라이버시 보수적 자세. 그것이 꺼져 있어도 정규식 규칙이 발동했다는 사실과 그것이 얼마나 자주인지는 여전히 보지만, 잡은 리터럴 텍스트는 보지 못합니다. 분류를 위해 부분 문자열이 필요할 때 guardrail별로 켜세요; 이 설정은 소급되지 않습니다. Matches 피드와 로깅 및 프라이버시를 참조하세요.
너무 광범위한 패턴은 고전적인 정규식 함정입니다 — \d{8}은 당신의 주문 번호만이 아니라 모든 여덟 자리 숫자 런을 매치합니다. 그것을 앵커하고(ORD- 같은 고정 접두사, 단어 경계 \b), Matches 피드를 지켜보고, 진행하면서 거짓 양성을 표시하여 조이세요. 코퍼스에 대한 A/B 그리드는 — 패턴이 양성 트래픽을 플래그하지 않으면서 잡아야 할 것을 잡는지 증명하기 위해 — 한 탭 옆의 평가 하니스에 있습니다. 거짓 양성 튜닝을 참조하세요.

​
8. 다음으로 갈 곳

커스텀 PII 엔티티

형태가 단순한 [REDACTED]가 아니라 타입 지정된 마스크 태그나 Luhn 체크섬을 원하는 신원일 때.

민감어

리터럴 용어의 유한한 목록 — 구조가 필요 없을 때 패턴보다 간단합니다.

액션

block, mask, flag가 어떻게 다른지와 각각을 언제 사용하는지.

Guardrails 레퍼런스

완전한 엔진 — 모든 규칙 타입, 필드, 라우트.
regex 규칙은 콘텐츠를 관리합니다. 에이전트의 툴 호출을 관리하려면 — 파괴적 액션 거부, 툴 호출 인자 마스킹, 승인 요구 — Firewall과 그 규칙 매처를 사용하세요. 어떤 패턴도 표현할 수 없는 모호한 정책(독성, 주제 이탈, 인젝션 의도)에는 llm_judge 규칙이 워크스페이스 모델에 대해 의미론적 검사를 실행합니다. 정규식이 전체 설계에서 맞는 곳을 보려면 Guardrails vs Firewall을 읽으세요.