메인 콘텐츠로 건너뛰기
천장이 없는 키는 에이전트가 루프에 빠지면 당신의 전체 워크스페이스 잔액을 소진할 수 있는 키입니다. 침해되거나 폭주하는 에이전트의 피해 반경을 제한하는 가장 효과적인 단일 방법은 그 키에 지출 상한을 주는 것입니다. 호스팅 게이트웨이에서 모든 키는 미국 달러로 측정되는 api key quota에 의해 unlimited이거나 bounded입니다 — 그리고 그 선택은 키 편집기의 한 필드입니다. 이 페이지는 두 모드, 릴레이 경로에서 상한이 강제되는 방식, 그리고 언제 어느 것을 고를지를 설명합니다. 키가 담는 제약의 전체 집합 — 모델 허용 목록, IP 허용 목록, 정책 연결 — 에 대해서는 토큰 객체를 참조하세요.

​
1. 두 모드

모든 키는 정확히 두 상태 중 하나로 해석됩니다:

Unlimited

unlimited_quota = true. 키는 키별 천장 없이 워크스페이스 잔액에서 끌어옵니다. 요청 시점에 지출 검사가 실행되지 않습니다 — 유일한 제한은 워크스페이스 자체의 잔액입니다.

Bounded

credit_limit_usd > 0. 키는 USD로 자체 평생 지출 상한을 담습니다. 누적 지출이 상한에 도달하면, 키는 작동을 멈춥니다 — 워크스페이스의 나머지는 손대지 않습니다.
콘솔 Keys 화면(/console/token)에서 이것을 설정합니다. 키를 생성하거나 편집하려면 Developer 역할 이상이 필요합니다.
credit_limit_usd = 0은 무제한을 의미합니다 — 0은 “상한 없음”의 센티넬이지 “0달러 상한”이 아닙니다. 키를 제한하려면, 그것에 양수 달러 금액을 주세요.

​
2. API 키 쿼터가 강제되는 방식

credit_limit_usd를 양수로 설정하면, 게이트웨이는 그것을 그 키에 대한 내부 remain_quota 잔액으로 변환하고 unlimited_quota를 false로 뒤집습니다. 그 이후로:
  • **remain_quota**는 키가 사용량을 청구함에 따라 차감되는 키의 남은 지출 여유입니다.
  • **used_quota**는 키가 이미 장부에 올린 누적 지출입니다.
  • 모든 릴레이 호출에서, 게이트웨이는 요청을 전달하기 전에 키를 검사합니다. remain_quota가 0에 도달한 bounded 키는 exhausted로 거부됩니다 — 호출은 모델에 결코 도달하지 않습니다.
unlimited 키(unlimited_quota = true)는 그 잔액 검사를 전적으로 건너뜁니다; 그것은 워크스페이스 잔액과 당신이 설정한 다른 키 수준 제한(모델 허용 목록, IP 허용 목록, 만료)에 의해서만 제한됩니다.
bounded 키는 평생 상한이지 롤링 월간 예산이 아닙니다 — 상한은 키의 생애에 걸친 총 지출을 셉니다. 리셋되는 예산을 원한다면, 당신만의 주기로(예: 스프린트마다 새 키) 새로운 bounded 키를 발행하고 이전 것을 폐기하세요. 키 관리를 참조하세요.

​
3. 하나의 구체적 예시

예약된 요약 에이전트를 배포하면서 그것이 모델이 무엇을 하든 결코 $25 이상 지출할 수 없음을 보장하고 싶다고 합시다. 키를 생성할 때 상한을 설정하세요: 
// POST to the console Keys screen (Developer+).
// Configure in the console — the relay key (sk-orca-…) is never used to
// administer keys; it is only presented on /v1/* inference calls.
{
  "name": "nightly-summarizer",
  "credit_limit_usd": 25,        // bounded: $25 lifetime cap
  "model_limits_enabled": true,
  "model_limits": ["openai/gpt-4o-mini"],
  "expired_time": -1             // -1 = never expires
}
게이트웨이는 이것을 bounded 키로 저장합니다: unlimited_quota = false와 25상당의‘remainquota‘.에이전트는평소처럼‘sk−orca−…‘릴레이키로모델을호출합니다.누적지출이25 상당의 `remain_quota`. 에이전트는 평소처럼 `sk-orca-…` 릴레이 키로 모델을 호출합니다. 누적 지출이 25에 닿는 순간, 키는 소진되고 이후의 모든 /v1/* 호출이 거부됩니다 — 당신이 대시보드를 지켜보지 않아도, 그리고 워크스페이스의 나머지를 건드리지 않고. 나중에 동일한 키를 unlimited로 만들려면, 그것을 편집하여 unlimited 토글을 뒤집으세요 — 콘솔이 unlimited_quota = true와 credit_limit_usd = 0을 함께 설정하고, 키는 전체 워크스페이스 잔액에서 다시 끌어올 수 있습니다.

​
4. 어느 모드를 고를까

자율 에이전트, CI 작업, 또는 서드파티 통합에 건네지는 어떤 키든 bounded여야 합니다. 지출 상한은 프롬프트 인젝션 루프나 재시도 폭풍이 무한정의 청구서를 쌓을 수 없게 하는 가장 저렴한 보장입니다 — 상한은 피해가 복리로 불어나기 전에 키를 멈춥니다. 그것을 좁은 모델 제한과 IP 허용 목록과 짝지으세요.
데모, 부하 테스트, 또는 단일 배포를 위해서만 존재하는 키에 대해서는, 작은 credit_limit_usd를 expired_time과 결합하세요. 키는 먼저 닿는 제한 중 어느 것으로든 스스로 은퇴합니다. 쿼터 상한 & 만료와 만료 키를 참조하세요.
당신이 완전히 통제하는 핵심 프로덕션 서비스가 사용하는 키, 키별 상한이 그저 가짜 장애를 일으킬 곳에서는, unlimited로 남을 수 있습니다 — 워크스페이스 잔액이 백스톱입니다. 이런 키는 적게 유지하고, 명확하게 명명하고, 그래도 모델과 IP 제한으로 범위 지정하세요.
실행 중간에 소진되는 bounded 키는 즉시 호출을 거부하기 시작합니다. 그것이 요점입니다 — 하지만 방치된 에이전트가 작업 도중에 멈출 수 있음을 의미합니다. 예상하는 작업에 맞게 상한 크기를 정하고, 콘솔의 사용량 뷰에서 지출을 지켜보아 합법적 실행을 물어뜯기 전에 상한을 올릴 수 있게 하세요.

​
5. 상한 필드들이 어떻게 관련되는가

이것을 통제하는 세 필드는 파생 잔액을 가진 단일 스위치입니다 — 당신은 달러 상한을 설정하고, 게이트웨이가 나머지를 도출합니다:
필드의미
credit_limit_usd당신의 입력. > 0 = USD bounded 상한; 0 = unlimited.
unlimited_quota키에 상한이 없을 때 true; 양수 credit_limit_usd를 주면 자동으로 false로 설정됨.
remain_quotabounded 키의 파생 지출 여유; 0에 도달하면 키가 소진됨.
당신은 편집기에서 오직 credit_limit_usd(또는 unlimited_quota)만 설정합니다. remain_quota와 used_quota는 키가 사용량을 청구함에 따라 게이트웨이가 유지합니다 — 그것들은 읽기 전용 텔레메트리이며, 콘솔의 사용량 뷰에 표시됩니다.

​
6. 이것이 제어 스택에서 차지하는 위치

지출 상한은 키가 얼마나 할 수 있는지를 제한합니다; 키 범위의 나머지는 그것이 무엇을 할 수 있는지를 제한합니다. 둘은 결합됩니다:

쿼터 상한 & 만료

달러 상한을 절대 만료와 결합하여 키가 먼저 닿는 제한 중 어느 것으로든 스스로 은퇴하게 하세요.

토큰 객체

키가 담는 모든 필드 — 모델 제한, IP 허용 목록, 정책 연결, 환경 레이블 — 을 하나의 레퍼런스로.

최소 권한 체크리스트

가능한 가장 좁은 키를 위한 전체 레시피, 한 번에 하나의 제약씩.

범위, 키 & 정책

상한이 워크스페이스 → 정책 → 키 계층에 어떻게 들어맞는지, 그리고 키를 제한하는 것이 어떻게 피해 반경을 줄이는지.
각 키의 지출 상한이 좁을수록, 어느 한 침해된 에이전트가 쌓을 수 있는 청구서가 작아지고 — 각 키가 무엇을 지출하도록 권한을 받았는지에 대한 감사 추적이 더 명확해집니다.