메인 콘텐츠로 건너뛰기
당신은 워크스페이스를 위한 guardrail과 firewall 정책을 작성했습니다. 이제 바로 이 키 — 당신의 finance 에이전트가 사용하는 키 — 가 워크스페이스의 나머지보다 더 엄격한 콘텐츠 정책과 더 좁은 툴 허용 목록을 실행하기를 원합니다. 그것이 키의 두 연결 필드가 하는 일입니다: guardrail과 firewall 정책을 단일 키에 바인딩하면, 그 키가 하는 모든 요청이 정확히 그 정책들에 의해 검사되고 강제됩니다 — 에이전트 코드 변경도, 재배포도 없이. 이 페이지는 두 필드, 요청 시점에 그것들이 어떻게 해석되는지, 그리고 사람들을 혼란스럽게 하는 한 가지 해석 규칙을 다룹니다: 비활성화된 firewall 연결은 비활성화된 guardrail 연결과 다르게 동작합니다.

​
1. 키별 보안 정책: 키의 두 필드

guardrail은 모델을 통과하는 텍스트(PII, 시크릿, 탈옥)를 검사합니다. firewall 정책은 에이전트가 발행하는 툴 호출(어떤 툴, 어떤 MCP 서버, 어떤 호스트)을 통제합니다. 둘 다 워크스페이스 범위의, 이름이 지정된 정책이며 — 한 번 작성되어 워크스페이스 전체에 공유됩니다 — 키는 두 필드를 통해 특정한 하나를 선택합니다:
필드바인딩 대상콘솔에서 설정
guardrail_id이 키의 프롬프트와 응답을 검사하는 guardrail.Developer+
firewall_policy_id이 키의 툴 호출을 평가하는 firewall 정책.Developer+
둘 다 /console/token의 키 편집기에서 설정됩니다. 어느 쪽이든 설정하는 것은 Developer+ 작업입니다 — 정책 자체도 Developer+로 작성됩니다 (see 범위 & 키).
이 두 필드는 독립적입니다. 키는 guardrail을 연결하고 firewall 정책은 연결하지 않을 수 있으며, 그 반대도, 둘 다도, 둘 다 아님도 가능합니다 — 각 평면이 독자적으로 해석됩니다. 필드를 미설정(0)으로 두는 것은 강제를 끄는 것과 같지 않습니다; §3을 참조하세요.

​
2. 하나의 구체적 예시

당신의 워크스페이스 기본 guardrail이 PII를 플래그하지만 통과시키고, 기본 firewall 정책이 모든 툴 호출을 감사한다고 합시다. 그것은 대부분의 에이전트에 적합합니다 — 하지만 당신의 finance 에이전트는 고객 SSN을 다루며 결코 셸 툴을 호출해서는 안 됩니다. 더 엄격한 finance-guardrail(PII를 즉시 차단)과 finance-firewall(필요한 세 개의 툴만 허용 목록 설정)을 작성한 다음, 둘 다 그 에이전트의 키에 바인딩하세요: 
# Configure via the CONSOLE (UserAuth — your session), not a relay key.
# This is the key-update call the editor at /console/token makes.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (3-tool allow-list)
}
다음 요청부터, 그 키의 트래픽은 guardrail 12에 의해 검사되고 그 툴 호출은 정책 8에 의해 평가됩니다 — 그동안 워크스페이스의 다른 모든 키는 워크스페이스 기본값을 계속 실행합니다. 에이전트 자체 코드는 결코 바뀌지 않습니다; 그것은 이전과 정확히 동일하게 sk-orca-… 키로 https://api.orcarouter.ai/v1/...을 계속 호출합니다.
이것이 최소 권한 패턴입니다: 에이전트당 하나의 좁게 범위 지정된 키, 각각 그 일이 실제로 필요로 하는 정책에 바인딩됨. 그 에이전트가 침해되면, 피해 반경은 그 키가 권한을 받은 것 그 이상도 이하도 아닙니다. 최소 권한 체크리스트를 참조하세요.

​
3. 해석: 사람들을 혼란스럽게 하는 규칙

모든 요청에 대해, 게이트웨이는 활성 guardrail과 활성 firewall 정책을 독립적으로 해석합니다. 순서는 둘 다 동일해 보입니다 — 연결 먼저, 워크스페이스 기본값 다음 — 하지만 한 가지 경우에서 갈라집니다.

​
Guardrail 해석

키의 guardrail_id가 존재하고 활성화된 guardrail을 가리킵니다. 그 guardrail이 요청을 검사합니다.
연결된 guardrail을 비활성화하는 것은 끔 스위치입니다. 키는 콘텐츠 검사를 전혀 받지 않습니다 — 워크스페이스 기본값으로 폴백하지 않습니다. 이는 의도적입니다: guardrail을 연결하고 비활성화하는 것이 그 키에 대해 검사를 끄는 방법입니다.
키에 guardrail_id가 없음. 워크스페이스의 활성화된 기본 guardrail이 설정되어 있으면 적용됩니다.
연결도 없고 워크스페이스 기본값도 없음 → 요청은 콘텐츠 검사 없이 통과합니다.

​
Firewall 해석

키의 firewall_policy_id가 존재하고 활성화된 정책을 가리킵니다. 그 정책이 키의 툴 호출을 평가합니다.
여기에 차이가 있습니다. 비활성화된 firewall 연결은 워크스페이스 기본 firewall 정책으로 폴백합니다 — 강제를 끄지 않습니다. firewall 연결을 비활성화하면 키가 워크스페이스 기본값으로 되돌아갑니다; 키를 보호되지 않은 채로 두지 않습니다.
키에 firewall_policy_id가 없음 → 워크스페이스의 활성화된 기본 firewall 정책이 적용됩니다.
연결된 정책을 비활성화하는 것은 대칭적이지 않습니다. 비활성화된 guardrail 연결은 그 키에 guardrail 없음을 의미합니다. 비활성화된 firewall 연결은 워크스페이스 기본값으로 폴백을 의미합니다. 키가 진짜로 firewall 강제를 실행하지 않게 하려면, 그 연결을 비활성화하는 것으로는 도달할 수 없습니다 — 워크스페이스 기본 firewall 정책이 설정되어 있지 않은지 확인하세요(또는 키가 통제되는 툴 호출을 발행하지 않도록 범위를 지정하세요).
워크스페이스당 최대 하나의 guardrail과 하나의 firewall 정책만 언제든 기본값이 될 수 있습니다; 새 기본값을 프로모트하면 동일한 트랜잭션에서 이전 것이 강등되므로, 두 개를 실수로 가질 수 없습니다.

​
4. block은 어떻게 보이는가

바인딩된 정책이 요청을 거부하면, 호출자는 구조화된 오류를 봅니다 — 에이전트는 크래시하는 대신 반응할 수 있습니다:
평면오류 코드HTTP비용
Guardrailguardrail_blocked400없음 — 입력 block은 미터링 전에 발동하고; 출력 block은 환불됩니다. skip-retry로 표시.
Firewall (inbound)firewall_blocked400inbound block은 모델 호출 전에 발동하므로 모델 토큰이 없습니다. skip-retry.
Firewall (held)firewall_approval_pending400사람 승인을 위해 보류됨; 에이전트가 폴링하고 승인되면 재제출합니다.
두 오류 본문 모두 OpenAI 형태이며 정책과 이유를 명시하므로, 당신의 에이전트는 코드에 따라 분기할 수 있습니다. 전체 이벤트 레코드와 매치가 로깅되는 방식에 대해서는 심층 레퍼런스를 참조하세요.

​
5. 다음으로 갈 곳

범위 & 키

전체 3단계 모델 — 워크스페이스, 정책, 키 — 과 키가 담는 모든 필드.

토큰 객체

키의 모든 필드: model_limits, allow_ips, credit_limit_usd, expired_time, 그리고 두 정책 연결.

Guardrails

guardrail_id를 통해 바인딩하는 콘텐츠 정책을 작성하세요 — 규칙, PII 엔티티, 액션, 그리고 프리셋.

Firewall

firewall_policy_id를 통해 바인딩하는 툴 호출 정책을 작성하세요 — 판정, 표면, 그리고 자율성 수준.
키를 하나씩 바인딩하는 대신 워크스페이스 전체 자세를 한 번에 설정하고 싶나요? 자율성 수준이 두 평면 — guardrails와 firewall — 을 한 번에 씁니다. 그런 다음 워크스페이스 기본값보다 더 나아가야 하는 소수의 키에만 더 엄격한 정책을 연결하세요. Guardrails vs Firewall를 참조하세요.