메인 콘텐츠로 건너뛰기
하나의 API 키는 당신의 워크스페이스가 권한을 가진 모든 모델에 도달할 수 있습니다. 그것은 콘솔 세션에는 편리하고 장수하는 에이전트에는 위험합니다: 제한 없는 키를 가진 프롬프트 인젝션된 에이전트는 gpt-4o-mini에서 당신이 접근할 수 있는 가장 비싼 모델로, 또는 당신이 결코 승인하지 않은 데이터 처리 방식을 가진 모델로 조용히 전환할 수 있습니다. 해결책은 키별 모델 허용 목록입니다. 각 키는 model_limits 필드를 담습니다 (model_limits_enabled로 게이트됨). 그것이 켜져 있으면, 목록에 없는 모델에 대한 요청은 게이트웨이에서 거부됩니다 — 채널이 선택되기 전에, 그리고 무언가가 프로바이더로 떠나기 전에.
이것은 키 객체의 한 제약입니다. 그것은 키의 IP 허용 목록, 지출 상한, 만료, 그리고 연결된 guardrail / firewall 정책과 결합됩니다 — 각각이 키를 독립적으로 좁힙니다.

​
1. 왜 API 키별로 모델 접근을 제한하는가

모델 선택은 권한 레버입니다. 어떤 모델이든 호출할 수 있는 키는 다음으로 유도될 수 있습니다:
  • 비용 폭증 — 프리미엄 모델로 전환하면 토큰당 청구액이 배가됩니다.
  • 기능 확장 — 작은 모델용으로 범위 지정된 작업이 당신이 의도한 것보다 훨씬 많은 일을 할 수 있는 프런티어 모델로 라우팅됩니다.
  • 컴플라이언스 이탈 — 주어진 데이터 클래스에 대해 승인하지 않은 모델 패밀리로 트래픽을 보냅니다.
키를 에이전트가 실제로 필요로 하는 한두 개의 모델로 제한하면 이 셋을 한 번에 막습니다. 그것은 firewall이 툴을 허용 목록 설정하는 것의 모델 축 등가물입니다 — 에이전트는 당신이 명명한 것만 도달할 수 있고, 그 외에는 아무것도 도달할 수 없습니다.

​
2. 두 필드

모델 제한은 키에 한 쌍으로 존재합니다:
필드타입의미
model_limits_enabledbool마스터 스위치. false일 때, 키는 워크스페이스가 허용하는 모든 모델에 도달합니다.
model_limitslist모델 이름의 허용 목록. model_limits_enabled가 true일 때만 의미가 있습니다.
두 필드는 독립적이며, 조합이 중요합니다: model_limits_enabled = true에 비어 있는 목록은 키가 어떤 모델에도 도달할 수 없음을 의미합니다 — 모든 요청이 *“This token has no access to any models.”*로 거부됩니다. 최소 하나의 모델을 명명한 후에만 스위치를 켜세요.

​
3. 키에 설정하기

모델 제한은 콘솔 키 편집기(/console/token)에서, 키의 다른 제약을 설정하는 바로 그 곳에서 구성하세요. 키를 생성하거나 편집하려면 Developer 역할 이상이 필요합니다.
  1. 키를 엽니다(또는 Create key).
  2. Model limits를 활성화합니다.
  3. 이 키가 호출할 수 있는 모델을 고릅니다 — 입력하여 워크스페이스의 사용 가능한 모델을 필터링하세요.
  4. 저장합니다. 변경은 키의 다음 요청에 적용됩니다 — 재배포도, 키 로테이션도 없습니다.
저렴한 모델 하나만 건드려야 하는 예약된 요약기는 정확히 하나의 항목으로 된 허용 목록을 갖게 됩니다: 
model_limits_enabled: true
model_limits:         ["openai/gpt-4o-mini"]
그 시점부터 키는 gpt-4o-mini에 고정됩니다. 이 키에서의 요청에 있는 다른 어떤 모델 이름도 거부됩니다 — 기본 모델로의 폴백도 없고 조용한 다운그레이드도 없습니다.
모델 제한을 동일한 키의 credit_limit_usd 상한과 짝지으세요. 모델 목록은 폭주 루프가 어떤 모델에 도달할 수 있는지를 제한합니다; 지출 상한은 키가 작동을 멈추기 전에 얼마나 소진할 수 있는지를 제한합니다. 두 개의 독립적인 천장, 둘 다 게이트웨이에서 강제됩니다. 쿼터 상한 & 만료를 참조하세요.

​
4. 거부된 요청은 어떻게 보이는가

model_limits_enabled가 켜져 있고 요청이 목록 밖의 모델을 명명하면, 게이트웨이는 HTTP 403과 OpenAI 형태의 오류 본문으로 요청을 중단시킵니다: 
{
  "error": {
    "message": "This token has no access to model claude-opus-4-8 (request id: 2024...abc)",
    "type": "orcarouter_api_error",
    "code": ""
  }
}
거부의 핵심 속성:
이 검사는 게이트웨이가 아직 채널을 고르는 동안 실행됩니다 — 요청은 결코 업스트림 프로바이더에 도달하지 않으므로, 금지된 모델은 모델 토큰 비용이 들지 않습니다.
스위치가 켜져 있고 빈 허용 목록이면, 메시지는 *“This token has no access to any models”*이고 모든 요청이 거부됩니다. 이것이 “목록으로 제한”과 “키를 추론에서 완전히 잠금”의 차이입니다.
요청의 모델 이름은 목록이 검사되기 전에 정규화되므로, 관련 변형(예: thinking 변형)은 당신이 허용 목록에 넣은 동일한 정규 이름으로 해석됩니다. 콘솔이 보여주는 기본 모델 이름을 목록에 넣으세요.

​
5. 모델 제한 vs. 그룹 권한

키가 모델을 호출할 수 있는지를 결정하는 두 가지 서로 다른 것이 있습니다. 혼동하지 마세요:
레이어범위답하는 질문
워크스페이스 권한워크스페이스이 모델이 워크스페이스에 애초에 사용 가능한가?
model_limits단일 키사용 가능한 모델 중, 이 키는 어떤 것을 사용할 수 있는가?
model_limits는 오직 좁히기만 합니다. 키는 모델 제한을 사용해 워크스페이스 자체가 권한을 갖지 않은 모델에 도달할 수 없습니다 — 이미 허용된 것에서 더 작은 허용 목록을 깎아낼 수 있을 뿐입니다. 키에 추가로 아무것도 주지 않고 엄격히 덜 주려면, 바로 그것이 이 필드의 용도입니다.

​
6. 이것이 최소 권한 자세에 어떻게 들어맞는가

모델 제한은 에이전트별 키 레시피의 한 줄입니다. 자율 에이전트를 위한 가장 좁고 유용한 키는 모든 축을 한 번에 고정합니다: 그러한 키가 프롬프트 인젝션을 통해 침해되면, 피해 반경은 모든 축에서 제한됩니다 — 공격자가 당신의 예산을 어떤 모델에 지출할 수 있는지를 포함하여.
모델 제한은 키에 대한 신원 제약이며, 콘텐츠나 액션 정책이 아닙니다. 그것은 프롬프트를 검사하지 않고(그것은 Guardrails) 툴 호출을 검사하지 않습니다(그것은 Firewall) — 그것은 키가 애초에 어떤 모델을 다룰 수 있는지를 사전에 결정합니다.

​
7. 다음 단계

키 객체

키가 담는 모든 필드 — 모델 제한, IP 목록, 상한, 만료, 그리고 정책 연결 — 을 하나의 레퍼런스로.

최소 권한 체크리스트

전체 에이전트별 키 레시피: 모든 축을 에이전트가 필요로 하는 최소로 범위 지정하세요.

범위, 키 & 정책

키, guardrail, firewall 정책이 어떻게 하나의 에이전트 신원으로 바인딩되는지.

키에 정책 바인딩하기

guardrail과 firewall 정책을 동일한 키에 연결합니다.
API 키별로 모델 접근을 제한하는 것은 적용할 수 있는 가장 저렴한 권한 통제입니다: 어떤 침해된 에이전트도 말로 빠져나갈 수 없는, 게이트웨이에서 강제되는 하나의 허용 목록.