메인 콘텐츠로 건너뛰기
에이전트가 탈취되면 — 프롬프트 인젝션, 오염된 툴 결과, 폭주 루프 — 그것이 실제로 할 수 있는 것은 정확히 한 가지에 의해 제한됩니다: 그 API 키가 무엇을 하도록 허용되었는가. 제한도 정책도 없는 키는 침해된 하나의 에이전트를 워크스페이스 전체의 사고로 바꿉니다. 이 페이지는 모든 키를 출시 전에, 그리고 그 후 주기적으로 다시 실행하는 강화 패스입니다. 그것은 의도적으로 짧습니다: 하나의 체크리스트, 하나의 작동 예시, 그다음 각 필드의 깊이로 가는 링크들. 그 뒤의 멘탈 모델은 범위 & 키에서 시작하세요; 필드별 레퍼런스는 키 개요를 참조하세요.

​
1. 최소 권한 체크리스트

모든 키 — 새것이든 기존이든 — 를 키 편집기(/console/token)에서 이 여섯 게이트에 통과시키세요. 그중 어느 것이든 설정하려면 Developer 역할 이상이 필요합니다; 두 정책 평면(§5–6)은 별도로 작성되어 여기서 바인딩됩니다.
model_limits를 이 에이전트가 필요로 하는 정확한 목록으로 설정하세요(그리고 model_limits_enabled를 활성화하세요). 목록 밖의 어떤 모델에 대한 호출도 게이트웨이를 떠나기 전에 거부되므로, 탈취된 에이전트는 더 비싸거나 더 강력한 모델로 격상할 수 없습니다. 확인: 목록이 작업이 허용하는 만큼 짧은가 — 이상적으로 하나의 모델? 깊이: 모델 제한.
allow_ips를 에이전트가 실제로 호출하는 소스 주소 또는 CIDR로 설정하세요. 다른 어디서든 제시된 유출된 키는 인증 계층에서 거부됩니다. 비어 있으면 모든 IP가 허용됩니다. 확인: 고정 호스트 또는 예약된 에이전트의 경우, 목록이 비어 있지 않고 그 egress로 범위 지정되어 있는가? 깊이: IP 허용 목록.
credit_limit_usd를 에이전트가 그 생애에 결코 넘어서는 안 되는 천장으로 설정하세요. 게이트웨이가 그것을 키의 지출에 대해 강제합니다. 0은 무제한을 의미합니다 — 폭주 루프가 당신의 전체 잔액을 소진할 수 있습니다. 확인: 상한이 0이 아니라 실제 예산인가? 깊이: 쿼터, 상한 & 만료.
expired_time을 절대 만료 — 스프린트, 배포, 또는 CI 실행의 종료 — 로 설정하세요. -1은 절대 만료되지 않음을 의미합니다. 단명 키는 잊혀진 공격 표면으로 남아 있을 수 없습니다. 확인: 임시 또는 계약자 키가 -1이 아니라 실제 만료를 갖는가? 깊이: 만료 키.
guardrail_id를 통해 guardrail을 연결하여 요청(그리고 지원되는 경우 응답) 텍스트가 모델에 도달하기 전에 PII, 시크릿, 인젝션 의도에 대해 검사되게 하세요. 확인: 민감한 프롬프트를 다루는 키가 바인딩된 guardrail을 갖거나 워크스페이스 기본값을 상속받는가? §5 참조.
firewall_policy_id를 통해 firewall 정책을 연결하여 이 키가 발행하는 모든 툴 호출, MCP 디스패치, egress가 에이전트가 합법적으로 필요로 하는 것의 허용 목록에 대해 평가되게 하세요. 확인: 툴을 호출하는 에이전트가 바인딩된 firewall 정책을 갖거나 워크스페이스 기본값을 상속받는가? §6 참조.
위의 필드들은 키에서 유일한 고객 구성 가능 레버입니다 — 콘솔에서 모두 설정하세요; 여기 어떤 것도 에이전트 코드 변경이 필요하지 않습니다. 키를 다시 읽으면 그것이 마스킹되어 보입니다; 평문은 생성 시 한 번 표시됩니다. 키 마스킹을 참조하세요.

​
2. 무엇을 / 얼마나 자주 / 어디서

세 질문이 체크리스트를 일회성 잡일에서 자세로 바꿉니다.

무엇을

위의 여섯 게이트, 순서대로: model_limits → allow_ips → credit_limit_usd → expired_time → guardrail_id → firewall_policy_id.

얼마나 자주

모든 키에서 생성 시, 그리고 반복 검토 시 — 에이전트의 범위가 바뀔 때, 키를 로테이션할 때, 그리고 장수하는 키에 대해 고정된 주기로.

어디서

콘솔 키 편집기(/console/token)에서, **Developer+**로. 두 정책은 자체 콘솔에서 작성된 다음, 키에서 바인딩됩니다.

​
3. 하나의 구체적인 최소 권한 키

저렴한 모델 하나로, 하나의 호스트에서 지원 티켓을 요약하는 예약된 에이전트는 거의 권한이 필요 없습니다. 완전히 강화된 키:
필드값이유
model_limits하나의 요약 모델프런티어 모델로 격상할 수 없음
allow_ips스케줄러의 egress CIDR유출된 키가 다른 곳에서 무용지물
credit_limit_usd주간 상한폭주 루프가 잔액을 소진할 수 없음
expired_time배포 종료 시점자동 만료, 남아 있을 수 없음
guardrail_idPII 마스킹 guardrail요청 텍스트가 검사됨
firewall_policy_id자신의 툴만 허용 목록 설정예상치 못한 툴 호출 없음
이 에이전트가 탈취되더라도, 여전히 하나의 모델만, 하나의 IP 범위에서만, 상한까지만, 그리고 자신의 firewall 정책이 허용하는 툴만 호출할 수 있습니다. 워크스페이스의 나머지는 손대지 않으며 — firewall 감사 추적이 그것이 무엇을 하도록 권한을 받았는지 정확히 보여줍니다.
model_limits도, allow_ips도 없고, credit_limit_usd: 0, expired_time: -1, 그리고 정책 연결도 없는 키는 최대 권한을 가집니다. 유출되면, 그것을 가진 자가 당신의 전체 워크스페이스를 얻습니다. 그 조합을 기본값이 아니라 발견으로 취급하세요 — unlimited vs bounded를 참조하세요.

​
4. /v1 릴레이 호출 vs 콘솔

체크리스트는 당신의 세션(Developer+ 사용자)으로 콘솔에서 구성됩니다. 당신의 에이전트는 그 구성 라우트를 결코 건드리지 않습니다 — 그것은 /v1/* 추론 호출에서 자체 범위 지정 릴레이 키(sk-orca-…)를 제시하고, 위의 제한과 바인딩된 정책이 각 호출에서 강제됩니다. 
# The agent's runtime call — the relay key, scoped by the checklist above.
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..."}]
  }'
키의 model_limits가 openai/gpt-4o-mini를 포함하지 않으면, 이 호출은 게이트웨이를 떠나기 전에 거부됩니다. 호출자의 IP가 allow_ips에 없으면, 인증 계층에서 거부됩니다. 에이전트 코드는 동일하게 유지됩니다; 키가 피해 반경을 결정합니다.

​
5. 게이트 5 — 바인딩된 guardrail

guardrail_id는 워크스페이스 범위의, 순서가 있는 콘텐츠 정책을 키에 바인딩합니다. 해석은 키의 명시적 guardrail(존재하고 활성화된 경우), 그렇지 않으면 워크스페이스 기본값, 그렇지 않으면 없음입니다.
Guardrails는 비활성화될 때 엄격한 끔 스위치입니다: 비활성화되거나 삭제된 guardrail_id는 키가 어떤 guardrail도 받지 않음을 의미합니다 — 워크스페이스 기본값으로 폴백하지 않습니다. 이는 firewall 평면(§6)의 반대이므로, 바인딩된 guardrail이 단지 연결된 것이 아니라 활성화되어 있는지 검증하세요.
guardrail의 규칙은 모델 전에(입력 단계) 그리고 지원되는 경우 응답에(출력 단계) block, mask, 또는 flag 액션으로 실행됩니다. 예를 들어 PII Shield 프리셋은 요청이 모델에 도달하기 전에 그 안의 PII를 마스킹합니다. guardrail을 **Developer+**로 작성하고 연결하세요 — Guardrails와 정책 바인딩을 참조하세요.

​
6. 게이트 6 — 바인딩된 firewall 정책 + 게이트웨이 범위

firewall_policy_id는 워크스페이스 범위의 툴 호출 정책을 바인딩합니다. 그것은 에이전트가 취하는 액션 — 광고된 툴, 모델이 발행한 tool_calls, MCP 디스패치, 그리고 아웃바운드 egress — 을 판정이 allow, audit, deny, sanitize, pending_approval, 또는 cap_cost인 순서가 있는 규칙 목록에 대해 통제합니다.
firewall 평면은 guardrails와 다르게 해석됩니다: 연결된 firewall 정책이 비활성화되면 워크스페이스 기본값으로 폴백하며, 강제를 끄지 않습니다. 그래서 정책을 바인딩하고 비활성화하면 키가 워크스페이스 기본값으로 되돌아갑니다 — 결코 조용히 보호되지 않은 채로 가지 않습니다.
두 평면을 한 번에 설정하는 가장 빠른 방법은 자율성 수준입니다 — 워크스페이스의 firewall 및 guardrail 자세(tight / balanced / permissive)를 원자적으로 구성하는 단일 스위치이며, 원클릭 실행 취소를 제공합니다. Firewall §8을 참조하세요.
is_firewall_gateway는 별도 종류의 키입니다 — Firewall MCP 및 evaluate-hook 라우트(/api/v1/firewall/*)를 위해서만 발행되며, 추론을 위해서는 결코 발행되지 않습니다. 일반 키는 그 라우트에서 403을 받고, 추론 경로의 게이트웨이 키는 과도하게 범위 지정된 것입니다. 그 플래그를 활성화하고 게이트웨이 키의 평문을 읽으려면 **Admin+**가 필요합니다. 하나의 키, 하나의 목적.

​
7. 체크리스트 이후

Secure-agents 기준선

권장 시작 자세 — 하나의 자율성 스위치, 그다음 실제 트래픽으로부터 튜닝.

정책 바인딩

guardrail_id와 firewall_policy_id가 어떻게 연결되고 해석되는지.

과도한 권한

이 체크리스트가 봉쇄하도록 만들어진 위협.

유출된 키

범위 지정 키가 노출되는 순간 해야 할 일.
각 키가 좁을수록, 어느 한 에이전트가 침해되었을 때의 피해 반경이 작아지고 — 각 에이전트가 무엇을 하도록 권한을 받았는지에 대한 기록이 더 명확해집니다. 모든 키에서 최소 권한 체크리스트를 실행하고, 계속 실행하세요.