메인 콘텐츠로 건너뛰기
너무 적극적인 guardrail은 guardrail이 없는 것보다 나쁩니다 — 당신의 팀은 Matches 피드를 무시하는 법을 배우거나, 당신이 규칙을 느슨하게 하여 실제로 원했던 포착을 잃습니다. OrcaRouter는 정밀한 중간 경로를 제공합니다: 단일 매치를 거짓 양성으로 표시하면, 엔진이 그 발견 사항을 기억하고 향후 요청에서 그것을 건너뜁니다 — 규칙을 건드리거나, 패턴을 느슨하게 하거나, SDK 변경을 출시하지 않고. 이것은 거짓 양성 워크플로에 초점을 둔 랜딩입니다. 전체 guardrail 엔진 — 모든 규칙 타입, 필드, 라우트 — 은 Guardrails 레퍼런스를 참조하세요.
여기 모든 단계는 호스팅된 게이트웨이(api.orcarouter.ai)에 대한 콘솔 액션입니다. 당신의 세션에서 매치를 분류하며; 최종 /v1/* 호출만 sk-orca-... 릴레이 키를 사용합니다. 매치를 거짓 양성으로 표시하려면 워크스페이스 Admin 역할이 필요합니다; Matches 피드와 그 결과로 생긴 억제 목록을 읽는 것은 모든 멤버에게 개방됩니다.

​
1. 규칙을 약화시키지 않고 guardrail 거짓 양성 줄이기

규칙이 과도하게 발동할 때의 본능은 그것을 느슨하게 하는 것입니다 — 정규식 제외를 넓히고, 엔티티를 떨어뜨리고, block을 flag로 전환. 그것은 하나의 거짓 양성을 정책의 구멍과 맞바꿉니다. mark-false-positive 억제는 외과적 대안입니다:

발견 사항 하나 억제

잘못 발동한 정확한 매치를 — 특정 규칙 아래 특정 부분 문자열을 — 음소거하며, 전체 규칙이 아닙니다. 다음 진정으로 민감한 히트는 여전히 발동합니다.

규칙 편집 없음, 재배포 없음

억제는 게이트웨이에 워크스페이스 메모리로 존재합니다. 규칙은 작성된 그대로 유지됩니다; 당신의 앱은 변경 없이 /v1/*를 계속 호출합니다.

워크스페이스 전체 메모리

한 Admin이 한 번 표시하면; 억제가 워크스페이스 전반에서 중복 제거되므로, 모든 멤버의 트래픽이 혜택을 받습니다 — 키별 팬아웃 없음.

되돌릴 수 있음

매치를 표시 해제하면(또는 억제를 삭제하면) 다음 요청에서 발견 사항이 다시 발동합니다. 아무것도 파괴되지 않습니다.
억제는 당신이 양성으로 판단한 발견 사항을 위한 것입니다. 전체 규칙이 잘못 보정되었다면 — 잘못된 형태, 잘못된 스테이지 — 매치를 차례로 음소거하는 대신 규칙을 고치고 평가 하니스에서 증명하세요.

​
2. 매치가 억제가 되는 방식

발동하는 모든 규칙은 워크스페이스 Matches 피드에 match를 기록합니다 — 규칙 타입, 액션, 스테이지, 그리고 상세 문자열. 그 매치 중 하나를 거짓 양성으로 표시하면, 게이트웨이는 발견 사항에 대한 안정적인 지문을 도출하고 그것을 워크스페이스의 억제 목록에 씁니다. 모든 향후 요청에서, 엔진은 각 발견 사항의 지문을 그 목록에 대해 검사하고 억제된 것을 차단, 마스킹, 또는 플래그하기 전에 건너뜁니다. 두 종류의 발견 사항이 지문을 생성합니다:
CVE / SBOM 발견 사항은 이미 안정적인 신원과 함께 제공됩니다 — 권고 또는 컴포넌트 신원이 발견 사항과 함께 이동합니다. 하나를 억제하면 그 정확한 CVE/컴포넌트를, 그리고 그것만 음소거합니다. 이것이 억제 저장소가 만들어진 네이티브 케이스입니다.
키워드, 정규식, PII, 그리고 다른 결정적 규칙 타입은 자체 신원을 운반하지 않으므로, 게이트웨이는 쓰기 측(당신의 mark-FP 클릭)과 강제 측(다음 요청)에서 동일한 데이터에서 하나를 합성합니다: guardrail, 규칙의 매칭 신원, 그리고 — 원시 캡처가 켜져 있을 때 — 매치된 부분 문자열 자체.
합성 지문의 정밀도는 Log raw content에 달려 있으며, 이는 기본적으로 꺼져 있습니다. 캡처가 켜져 있으면, 지문은 정확한 매치된 부분 문자열을 키로 삼으므로, ORD-48291507을 억제하면 그 주문 번호를 음소거하고 그 외에는 아무것도 음소거하지 않습니다. 캡처가 꺼져 있으면, 키로 삼을 부분 문자열이 없으므로, 억제는 규칙 레벨 음소거로 폴백합니다 — 워크스페이스에 대해 (그 스테이지에서) 그 하나의 규칙을 침묵시킵니다. 폴백은 그것이 온 규칙을 결코 넘어서지 않습니다. 로깅 및 프라이버시를 참조하세요.

​
3. 하나의 구체적인 예

ORD- 더하기 여덟 자리 숫자 형태의 내부 주문 번호를 마스킹하는 regex 규칙을 실행한다고 합시다. 지원 티켓이 당신이 통과시켜도 괜찮다고 결정한 방식으로 ORD-48291507을 정당하게 인용합니다. 규칙을 약화시키고 싶지 않습니다 — 단지 이 하나의 번호가 발동을 멈추기를 원합니다.
1

Matches 피드 열기

콘솔에서 Guardrails → Matches를 엽니다. guardrail과 규칙 타입별로 필터링하여 ORD-48291507 히트의 행을 찾습니다. (리터럴 부분 문자열을 보려면, 매치가 기록될 때 guardrail의 Log raw content가 켜져 있어야 합니다 — 기본적으로 꺼져 있습니다.)
2

거짓 양성으로 표시

매치 상세를 열고 Mark as false positive를 선택합니다. 워크스페이스 Admin으로서, 이것은 매치를 스탬프하고 발견 사항의 지문을 키로 삼은 워크스페이스 억제를 미러링합니다.
3

억제되었는지 확인

Suppressions 목록을 엽니다 — 새 항목이 그것이 온 guardrail과 규칙, 그리고 사유 *“Marked as false positive from Matches”*로 레이블되어 나타납니다. 워크스페이스의 모든 멤버가 이 목록을 읽을 수 있습니다.
4

동일한 요청 다시 전송

당신의 릴레이 키를 사용하여, 이전과 정확히 동일하게 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": "Status of order ORD-48291507?"}
    ]
  }'
억제된 발견 사항은 건너뛰어집니다 — ORD-48291507이 통과합니다 — 반면 다른 모든 주문 번호는 여전히 매치되어 이전과 같이 마스킹됩니다.

​
4. 억제 vs. 대안

억제는 노이즈가 많은 규칙을 조용히 만드는 네 가지 방법 중 하나입니다. 맞는 가장 좁은 것을 선택하세요:
접근무엇을 변경하는가언제 찾을지
Mark FP발견 사항 하나(또는 캡처 꺼짐 시 규칙 하나)특정 양성 히트; 규칙은 그 외에는 올바름
규칙 편집매칭 자체잘못된 형태/스테이지 — 고친 뒤 다시 평가
flag 액션관찰 전용, 차단 없음아직 신뢰하지 않는 새 규칙
평가 하니스라이브 변경 없음 — 측정출시 전에 정밀도 증명
체계적으로 잘못된 규칙을 FP를 차례로 표시하여 덮지 마세요. 동일한 형태를 반복적으로 억제하고 있다면, 규칙이 잘못 보정된 것입니다 — 정규식을 앵커하고, 키워드 목록을 좁히거나, 더 엄격한 PII 엔티티를 선택하고, 평가 실행으로 검증하세요.

​
5. 억제 되돌리기

여기 아무것도 일방통행이 아닙니다:
  • 매치 표시 해제 — 동일한 Admin 액션을 역으로 하여, 매치의 FP 스탬프를 제거하고(그것에 매핑되는 다른 FP 표시된 매치가 없을 때) 억제를 떨어뜨립니다. 발견 사항이 다음 요청에서 다시 발동합니다.
  • 억제 직접 삭제 — Suppressions 목록에서, Developer+ 액션이 항목을 제거합니다. 같은 효과: 발견 사항이 다시 라이브가 됩니다.
억제는 워크스페이스 메모리이므로, 하나를 되돌리면 모든 멤버의 트래픽에 대한 포착을 한 번에 복원합니다 — 그것을 모두에게 억제로 표시한 것과 동일하게.

​
6. API 표면

이것들은 릴레이 키가 아니라 당신의 세션으로 인증되는 콘솔 라우트입니다. 각 액션을 역할 게이트하세요: 매치를 FP로 표시하는 것은 Admin; 억제 읽기는 Member; 억제 쓰기는 **Developer+**입니다.
메서드 및 경로역할목적
GET /api/guardrail/matchMember분류할 매치 나열.
POST /api/guardrail/match/:id/mark-fpAdmin매치를 거짓 양성으로 표시(억제를 미러링).
DELETE /api/guardrail/match/:id/mark-fpAdmin표시 해제 — 발견 사항 복원.
GET /api/guardrail/suppressionsMember워크스페이스의 활성 억제 나열.
POST /api/guardrail/suppressionsDeveloper+억제 직접 추가.
DELETE /api/guardrail/suppressions/:idDeveloper+억제 제거.
mark-FP 엔드포인트는 레이트 제한이 있습니다 — 그것들은 벌크 API가 아니라 의도적인, 저볼륨 분류 액션입니다. 전체 정책을 튜닝할 때는 mark-FP 호출의 루프가 아니라 평가 하니스를 찾으세요.

​
7. 다음으로 갈 곳

Matches 피드

발동하는 모든 규칙이 안착하는 곳 — 무언가를 표시하기 전에 분류하는 곳.

테스트 및 평가

출시하기 전에 코퍼스에 대해 규칙의 정밀도를 증명하세요 — 억제가 증상을 치료할 때의 체계적 수정.

로깅 및 프라이버시

Log raw content가 억제가 정확한 부분 문자열을 키로 삼을지 규칙 레벨 음소거로 폴백할지 어떻게 제어하는지.

Guardrails 레퍼런스

완전한 엔진 — 모든 규칙 타입, 액션, 라우트.
억제는 콘텐츠 발견 사항을 관리합니다. 노이즈가 많은 agent firewall 규칙을 — 안전하다고 판단한 툴 매치를 — 조용히 만들려면, 그것은 별개의 표면입니다; Firewall과 그 이상 피드를 참조하세요. guardrails와 firewall이 어디서 나뉘는지 이해하려면 Guardrails vs Firewall을 읽으세요.