메인 콘텐츠로 건너뛰기
소스 제한이 없는 키는 순수한 베어러 자격 증명입니다: 그 문자열을 가진 누구든 어디서나 그것을 제시할 수 있습니다. allow_ips 필드는 키를 IP 허용 목록 API 키로 바꿉니다 — 그것은 당신이 나열한 소스 주소에서 제시될 때만 작동합니다. 공격자의 머신, 가정용 프록시, 또는 침해된 CI 러너에서 재생된 유출된 키는 모델에 닿기 전에 거부됩니다. 이것은 최소 권한의 소스 바인딩 절반입니다: model_limits는 키가 도달할 수 있는 어떤 모델인지를 제한하고, allow_ips는 키가 어디서 제시될 수 있는지를 제한합니다.

​
1. allow_ips가 하는 일

allow_ips는 소스 주소 또는 CIDR 범위 목록을 담습니다. 모든 요청에서 OrcaRouter는 호출자의 소스 IP를 그 목록과 비교합니다:
  • 매치 → 요청이 모델 제한, 쿼터, 정책 검사로 진행됩니다.
  • 매치 없음 → 요청이 인증 계층에서 HTTP 403(access_denied)으로 거부됩니다 — 어떤 업스트림 모델 호출보다 먼저.
  • 빈 목록 → 제한 없음; 키는 어떤 주소에서든 수락됩니다.
이 검사는 키 유효성과 함께 키가 통과하는 첫 번째 게이트입니다 — guardrails 전에, firewall 전에, 미터링 전에 실행됩니다. 나열되지 않은 소스는 당신의 정책이나 잔액에 결코 도달하지 못합니다.
빈 allow_ips는 없음이 아니라 모든 IP 허용을 의미합니다. 그것을 비워 두는 것이 제한 없는 기본값입니다 — 키를 고정해야 이 필드가 무언가를 합니다.

​
2. 허용되는 형식

각 항목은 단일 IP 또는 CIDR 범위입니다. 둘을 자유롭게 섞으세요; 한 줄에 한 항목씩 나열하세요.

단일 주소

203.0.113.7 — 정확히 하나의 호스트. 고정 IP 서버 또는 안정적인 egress 주소를 가진 NAT 게이트웨이에 가장 적합.

CIDR 범위

203.0.113.0/24 — 블록 전체. 클라우드 서브넷, VPN 풀, 또는 하나의 egress CIDR 뒤의 오토스케일링 그룹에 가장 적합.
베어 IP는 그 하나의 주소와 매치하고; CIDR은 블록 내 모든 주소와 매치합니다. IPv4와 IPv6 리터럴 모두 파싱됩니다.
모든 합법적 호출자를 여전히 커버하는 가장 좁은 범위로 고정하세요. 하나의 호스트 (/32)는 /24보다 좁습니다; /24는 “어디서나”보다 좁습니다. 드롭하는 각 비트는 유출된 키가 여전히 작동하는 장소의 집합을 넓힙니다.

​
3. 콘솔에서 설정하기

/console/token의 키 편집기에서 allow_ips를 설정하세요. 키를 생성하거나 편집하려면 Developer 역할 이상이 필요합니다.
  1. Console → API Keys를 열고 키를 생성하거나 편집합니다.
  2. 키 편집기에서, 신뢰할 수 있는 주소를 IP allow-list 필드에 입력합니다 — 한 줄에 하나의 IP 또는 CIDR.
  3. 저장합니다. 제한은 그 키가 하는 다음 요청에 적용됩니다 — 재배포도, 에이전트 코드 변경도 없습니다.
키를 잠그기 전에 게이트웨이가 보는 실제 소스 주소를 검증하세요. 당신의 에이전트가 NAT, 로드 밸런서, 또는 egress 프록시 뒤에 있으면, OrcaRouter가 관측하는 주소는 그 egress 홉이지 에이전트의 사설 IP가 아닙니다. egress 주소를 허용 목록에 넣고, 출시 전에 배포된 환경에서 테스트하세요.

​
4. 하나의 구체적 예시: 예약된 에이전트

티켓을 요약하는 예약 작업이 오직 하나의 클라우드 서브넷에서만 실행됩니다. 그 키를 그 서브넷에 고정하여 자격 증명이 다른 어디서든 무용지물이 되게 하세요.
필드값효과
allow_ips203.0.113.0/24스케줄러의 egress 블록만 이 키를 제시할 수 있음
model_limits하나의 요약 모델프런티어 모델로 격상할 수 없음
credit_limit_usd주간 상한폭주 루프가 잔액을 소진할 수 없음
릴레이 호출 자체는 변하지 않습니다 — 여전히 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": "Summarize this ticket..."}]
  }'
203.0.113.0/24 내부에서 제시되면, 호출이 진행됩니다. 정확히 동일한 요청을 다른 어떤 주소에서 재생하면 게이트웨이는 다음을 반환합니다: 
{
  "error": {
    "message": "您的 IP 不在令牌允许访问的列表中 (request id: ...)",
    "type": "orcarouter_api_error",
    "code": "access_denied"
  }
}
모델은 결코 호출되지 않고, 쿼터가 소비되지 않으며, 거부가 로깅됩니다.
allow_ips는 전적으로 콘솔 키 편집기를 통해 구성됩니다 — 당신의 워크스페이스 세션에서의 Developer 이상 작업입니다. 그것에 대한 릴레이 키 셀프 서비스는 없습니다: 키는 자체 소스 허용 목록을 넓힐 수 없습니다.

​
5. IP 허용 목록이 봉쇄하는 것과 봉쇄하지 않는 것

IP 허용 목록 API 키는 키가 어디서 작동하는지를 제한합니다 — 피해 반경의 한 조각. 그것은 다른 범위 필드들을 대체하기보다 함께 결합됩니다.
로그, git 커밋, 또는 침해된 노트북에서 유출된 자격 증명은, 공격자가 당신의 허용 목록 범위에서도 트래픽을 발원할 수 없는 한 무용지물입니다. 이것이 이 필드의 핵심 역할입니다 — 전체 사고 대응은 유출된 키를 참조하세요.
침해가 허용 목록에 있는 호스트라면 — 당신 자신의 서버에서 실행되는 오염된 의존성 — 소스 IP 검사는 통과합니다. allow_ips를 model_limits, 지출 상한, 그리고 firewall 정책과 짝지어 신뢰된 소스 침해도 여전히 제한되게 하세요.
IP 고정은 키를 단명하게 만들지 않습니다. 그것을 절대 만료와 로테이션 일정과 결합하여 키가 새 장소에서 작동을 멈추는 것 동시에 결국 작동을 멈추게 하세요.

​
6. 운영 노트

당신의 호출자가 안정적인 소스 주소를 갖지 않는다면(egress가 회전하는 서버리스, 모바일 클라이언트, 넓은 사무실 네트워크), IP 고정은 잘못된 통제입니다 — 실제 트래픽을 잠그거나 범위를 의미 없을 때까지 넓혀야 할 것입니다. 대신 model_limits, 지출 상한, 만료, 그리고 정책 연결에 의지하세요.
allow_ips 편집은 다음 요청에 적용됩니다 — 기다려야 할 전파 지연이 없습니다. 리전을 추가하거나 서브넷을 마이그레이션할 때, 키를 먼저 업데이트하고, 새 범위가 작동하는지 확인한 다음, 이전 것을 드롭하세요.
allow_ips는 개별 키에 존재하므로, 각 에이전트는 자체 소스 바인딩을 가질 수 있습니다. 스케줄러 키는 배치 서브넷에 고정하고 대화형 키는 더 넓은 사무실 범위를 허용할 수 있습니다 — 둘 다 동일한 워크스페이스에서.

​
7. 다음 단계

토큰 객체

allow_ips를 포함한 키의 모든 필드를 하나의 레퍼런스로.

모델 제한

키가 도달할 수 있는 모델을 제한 — 소스 + 범위 바인딩의 나머지 절반.

유출된 키

키가 노출되는 순간 해야 할 일.

최소 권한 체크리스트

모든 키를 동일한 강화 패스에 통과시키세요.
IP 허용 목록은 만들 수 있는 가장 저렴한 피해 반경 절감입니다: 하나의 필드, 코드 변경 없음, 그리고 유출된 키가 실행되도록 의도되지 않은 모든 곳에서 작동을 멈춥니다. 심층 방어를 위해 나머지 범위 지정 키 모델과 짝지으세요.