메인 콘텐츠로 건너뛰기
저장된 guardrail이 있고 전체 워크스페이스가 아니라 특정 API 키만 그것으로 검사되기를 원합니다. 그것이 API 키별 guardrail 바인딩의 목적입니다: 키에 guardrail_id를 설정하면 그 키로 하는 모든 /v1/* 호출이 다음 요청에서 검사됩니다 — 재배포 없이, SDK 변경 없이. 이 페이지는 바인딩만 다룹니다 — 연결하는 방법, 해석이 유효 정책을 선택하는 방법, 그리고 오프 스위치가 하는 일. 규칙 타입, 액션, 스테이지는 Guardrails 레퍼런스를 참조하세요.

​
1. guardrail_id로 API 키별 guardrail 바인딩하기

guardrail은 워크스페이스 범위이지만, 강제는 키별로 결정됩니다. 각 API 키는 guardrail_id 필드를 운반합니다. 그것을 guardrail로 가리키면 그 키 — 그리고 오직 그 키만 — 가 그 정책으로 검사됩니다. 이는 한 워크스페이스가 서로 다른 키에서 서로 다른 정책을 실행하게 합니다:
  • 엄격한 pii-blocker에 바인딩된 프로덕션 키,
  • 더 가벼운 flag-only 정책에 바인딩된 스테이징 키,
  • 아무것도 연결되지 않은 내부 키.
바인딩은 게이트웨이의 키에 존재하므로, guardrail을 편집하면 바인딩된 키가 다음 요청에서 이동합니다. 당신의 애플리케이션은 이전과 정확히 동일하게 https://api.orcarouter.ai/v1/chat/completions를 계속 호출합니다.
릴레이 키(sk-orca-…)는 당신의 앱이 보내는 것입니다. 거기에 guardrail을 연결하는 것은 당신의 세션으로 인증되는 콘솔 / 토큰 API 액션입니다 — 릴레이 키 자체로 guardrail을 구성하는 일은 결코 없습니다.

​
2. 콘솔에서 연결하기

콘솔에서 바인딩을 구성합니다(역할 게이팅: 키와 guardrail 편집에는 **Developer+**가 필요합니다).
1

키 열기

/console/token으로 이동하여 검사하려는 API 키를 생성하거나 편집합니다.
2

guardrail 선택

키 에디터에서 Guardrail 드롭다운으로 guardrail을 선택합니다. 이는 키에 guardrail_id를 설정합니다.
3

저장

바인딩은 그 키의 다음 요청에서 적용됩니다. 재배포 없음.
그 후, 바인딩된 키로 하는 정상 릴레이 호출은 자동으로 검사됩니다: 
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 please"}
    ]
  }'
바인딩된 guardrail이 입력 스테이지에서 이메일을 마스킹하면, 업스트림 모델은 [EMAIL]을 보고 주소는 결코 보지 못합니다 — 동일한 호출, 클라이언트 변경 없음.
하나가 아니라 워크스페이스의 모든 키를 검사하려면, 각 키를 바인딩하기 보다 guardrail을 워크스페이스 기본값으로 설정하세요. 계정 기본 guardrail을 참조하세요.

​
3. 해석이 유효 guardrail을 선택하는 방식

모든 요청에서 게이트웨이는 정확히 하나의 유효 guardrail(또는 없음)을 다음 순서로 해석합니다:
키의 guardrail_id가 guardrail을 가리키고 그리고 그 guardrail이 존재하며 그리고 활성화되어 있으면, 그것이 적용됩니다. 명시적 연결은 권위적입니다 — 워크스페이스 기본값으로 조용히 폴백하지 않습니다.
키에 연결이 없으면(guardrail_id가 0/설정 안 됨), 워크스페이스의 활성화된 기본 guardrail이(설정되어 있다면) 적용됩니다.
강제 없음. 요청은 기능을 한 번도 활성화하지 않은 워크스페이스와 바이트 단위로 동일합니다 — 아무것도 차단, 마스킹, 또는 로깅되지 않습니다.
결정은 핫 경로에서의 인덱싱된 룩업 하나이며 페일 오픈입니다: 해석이 일시적 오류에 부딪히면, 게이트웨이는 요청을 실패시키기보다 강제 없음으로 저하됩니다. 안전성은 저하되지만 가용성은 보존됩니다.

​
4. 오프 스위치: 연결 비활성화, 폴백 없음

이것이 사람들이 놓치는 부분입니다. 명시적 키 연결은 그 자체로 권위입니다 — 따라서 연결된 guardrail을 비활성화하면 그 키에 대한 강제가 OFF가 되고, 워크스페이스 기본값으로 폴백하지 않습니다.
키 상태무엇이 요청을 검사하는가
guardrail_id → 활성화된 guardrail그 guardrail
guardrail_id → 비활성화된 guardrail없음(폴백 없음)
guardrail_id → 삭제됨 / 누락됨없음(폴백 없음)
guardrail_id = 0 / 설정 안 됨워크스페이스 기본값(있다면)
연결된 guardrail을 비활성화하는 것은 그 키에 대한 오프 스위치이지, 기본값으로의 강등이 아닙니다. 키가 워크스페이스 기본값으로 폴백하기를 원한다면, 그 연결을 지우세요(guardrail_id를 0으로 설정) — 그것이 가리키는 guardrail을 그냥 비활성화하지 마세요.
이는 firewall과의 의도적인 차이입니다: 비활성화된 연결 firewall 정책을 가진 키는 워크스페이스 기본 firewall 정책으로 폴백합니다. 반면 비활성화된 연결 guardrail은 없음으로 해석됩니다. 같은 발상, 반대 폴백 — Guardrails vs. firewall을 참조하세요.

​
5. 바인딩 분리 또는 지우기

특정 guardrail로 키 검사를 중단하려면, 결과가 다른 두 가지 별개의 동작이 있습니다:
  • 연결 지우기 — 키의 guardrail_id를 0으로 설정합니다. 이제 키는 워크스페이스 기본값(있다면)으로, 또는 없음으로 해석됩니다.
  • guardrail 비활성화 — guardrail의 enabled를 끕니다. 명시적으로 거기에 연결된 모든 키는 이제 없음으로 해석되고(§4에 따라), 그것을 워크스페이스 기본값으로 의존하던 키는 강제 없음으로 떨어집니다.
키를 워크스페이스 기준선에 두고 싶을 때는 지우기를; 그 정책을 이름이 지정된 연결인 모든 곳에서 일시 중지하고 싶을 때는 비활성화를 선택하세요.

​
6. 검사된 요청이 비용을 얼마나 발생시키는가(그리고 아닌가)

guardrail이 해석되면, 그 규칙이 요청을 결정합니다. 바인딩된 키에 대해 알아둘 가치가 있는 두 가지 결과:
  • block은 오류 코드 guardrail_blocked와 함께 HTTP 400을 반환하며, 발동한 guardrail과 규칙을 명시합니다. 쿼터를 소모하지 않습니다 — 입력 스테이지 차단은 계량 전에 발동하고, 출력 스테이지 차단은 사전 소모된 쿼터를 환불합니다 — 그리고 skip-retry로 표시됩니다.
  • mask는 매치를 타입 지정된 태그(예: [EMAIL])로 재작성하고 정화된 요청을 통과시킵니다; 업스트림 모델은 원본을 결코 보지 못합니다.
정확한 응답 형태는 guardrail_blocked 오류 페이지를, 출력 규칙이 스트리밍 응답에서 어떻게 동작하는지는 스트리밍 커버리지를 참조하세요.

​
7. 다음으로 갈 곳

첫 guardrail 생성하기

키에 바인딩할 정책을 만듭니다.

계정 기본 guardrail

워크스페이스의 모든 키를 한 번에 검사합니다.

Guardrails 레퍼런스

규칙 타입, 액션, 스테이지, PII, judge, grounding.

키, 정책 및 워크스페이스

바인딩이 게이트웨이 전반에서 어떻게 범위 지정되는지.