메인 콘텐츠로 건너뛰기
api.orcarouter.ai에서 에이전트가 사용하는 키가 있고, 그 키가 만드는 모든 툴 호출이 — 차단, 감사, 정화, 또는 승인 대기 처리되어 — 에이전트 코드를 건드리지 않고 통제되기를 원합니다. 그것이 두 단계의 에이전트 firewall 설정입니다: firewall 정책을 한 번 생성한 다음, 키를 그것에 가리킵니다. 다음 호출부터 키가 발행하는 모든 툴이 게이트웨이에서 정책에 대해 검사됩니다. 이 페이지는 생성-및-연결 경로입니다. 전체 정책 모델(표면, 판정, 해석)은 Firewall 개요를 참조하고; 규칙 문법은 Firewall Rules를 참조하세요.
모든 정책 및 키 구성은 콘솔에서(또는 세션 / 액세스 토큰을 사용하는 /api/workspace/firewall/* 관리 라우트에서 — 릴레이 sk-orca-… 키가 아님) 일어납니다. 에이전트의 /v1/* 호출만 릴레이 키를 사용합니다. 정책을 생성하고 연결하는 것은 Developer+ 액션입니다.

​
1. 에이전트 firewall 설정 한눈에 보기

firewall 정책은 이름이 지정된, 워크스페이스 범위 객체입니다: 순서가 있는 규칙 목록과 어떤 규칙도 매치하지 않는 모든 것에 대한 기본 판정. 키는 자신의 firewall_policy_id 필드를 통해 정책에 옵트인합니다. 스택의 다른 어떤 것도 변하지 않습니다.

정책 생성

이름을 짓고, 기본 판정을 고르고, 규칙을 추가합니다 — 또는 자율성 수준 / 프리셋에서 시드하고 편집합니다.

키 연결

키의 firewall_policy_id를 정책으로 설정하거나, 정책을 워크스페이스 기본값으로 표시하여 연결되지 않은 모든 키가 그것을 상속하게 합니다.

​
2. 콘솔에서 정책 생성

  1. Security → Firewall → Policies를 열고 New policy를 선택합니다.
  2. 이름을 짓고(워크스페이스 고유) Enabled를 켠 채로 둡니다.
  3. 기본 판정을 고릅니다 — §3 참조.
  4. 규칙 편집기에서 규칙을 추가하거나, 비어 있는 채로 시작하고 Discovered tools가 나중에 실제 트래픽으로부터 작성을 구동하게 합니다.
  5. 저장합니다. 정책은 존재하지만 키가 그것을 가리키거나 워크스페이스 기본값으로 만들기 전까지는 아무것도 통제하지 않습니다.
규칙을 먼저 직접 작성하고 싶지 않나요? 자율성 수준을 적용하세요(balanced이 권장 시작점) — 그러면 그 후 튜닝할 수 있는 실제의, 편집 가능한 정책 및 guardrail 행이 구체화됩니다. 또는 내장 프리셋에서 규칙을 시작하고 편집하세요. 어느 쪽이든 같은 곳에 도달합니다: 키에 연결하는 이름이 지정된 정책.

​
3. 기본 판정 고르기

기본 판정은 정책이 툴 호출에 어떤 규칙도 매치하지 않을 때 하는 일입니다. 그것은 자세의 바닥입니다. 정확히 세 값을 받습니다:
default_verdict어떤 규칙도 매치하지 않을 때…
audit (기본값)호출을 허용하되 기록합니다. 모든 것을 관찰하고 아무것도 차단하지 않음 — 시작하기에 안전한 곳.
allow허용하고 로깅, 검토 레코드 없음.
deny규칙이 명시적으로 허용하지 않는 모든 것을 차단 — allow 규칙과 짝지어 사용하는 기본 거부 자세.
deny는 기본 거부입니다: 규칙이 명시적으로 허용하지 않는 모든 툴 호출은 차단됩니다. 강력하지만, 허용 목록에 넣는 것을 잊은 호출을 멈추게 됩니다. 기본 거부 정책은 먼저 shadow mode하에서 롤아웃하고 강제하기 전에 이벤트 피드를 보세요.
규칙이 생성할 수 있는 판정(allow, audit, deny, sanitize, pending_approval, cap_cost)은 Verdicts에서 다룹니다 — 기본 판정은 위의 세 가지로 제한됩니다.

​
4. 정책을 키에 연결

키는 자신의 **firewall_policy_id**를 통해 정책에 옵트인합니다. 콘솔에서:
  1. Keys를 열고, 에이전트가 사용하는 키를 편집합니다.
  2. Firewall policy를 생성한 정책으로 설정합니다(이는 firewall_policy_id를 씁니다).
  3. 저장합니다. 그 키가 만드는 다음 호출이 통제됩니다.
바인딩은 게이트웨이의 키에 존재합니다 — 에이전트는 동일한 Authorization: Bearer sk-orca-…와 동일한 요청 본문을 계속 보냅니다. 에이전트의 툴 호출 코드에는 변경이 없습니다. 
# Your agent's relay call is unchanged. The attached policy is enforced
# at the gateway before any tool call in the response is dispatched.
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "delete the staging table"}],
    "tools": [{"type": "function", "function": {"name": "db.query"}}]
  }'
규칙이 inbound 표면에서 툴 호출을 거부하면, 그 호출은 코드 firewall_blocked와 함께 HTTP 400으로 돌아오며, 툴과 이유를 명시합니다 — block은 어떻게 보이는가 참조.

​
5. 해석: 연결됨 → 워크스페이스 기본값

임의의 툴 호출에 대해, 게이트웨이는 어떤 정책이 적용되는지를 다음 순서로 해석합니다:
호출하는 키의 firewall_policy_id가 존재하고 활성화된 정책을 가리키면, 그 정책이 적용됩니다.
그렇지 않으면 워크스페이스의 활성화된 is_default 정책이 적용됩니다(설정된 경우). 워크스페이스당 최대 하나의 정책만 기본값이 될 수 있습니다; 새 기본값을 프로모트하면 동일한 트랜잭션에서 이전 것이 강등됩니다.
연결도 없고 기본값도 없으면 정책이 없습니다. observe mode가 켜져 있으면 호출이 허용되고 커버리지 갭으로 로깅됩니다; 꺼져 있으면 호출이 조용히 허용됩니다.
비활성화된 연결 정책은 워크스페이스 기본값으로 폴백합니다 — 강제를 끄지 않습니다. (이는 guardrails와 다릅니다. guardrails에서는 비활성화된 연결이 없음으로 해석됩니다.) 키를 firewall 범위 밖으로 빼내려면, 그것을 떼어내세요(firewall_policy_id를 0으로 설정), 그냥 정책을 비활성화하지 마세요.
연결되지 않은 모든 키에 대해 정책을 기본값으로 만들려면, 키를 하나씩 연결하기보다 그것을 편집하여 워크스페이스 기본값으로 설정하세요 — 정책 관리 참조.

​
6. 적용되었는지 확인

그것에 의존하기 전에, 정책이 예상한 대로 발동하는지 확인하세요:
  • 테스트하기 — 샌드박스 Test 탭은 샘플 툴 호출에 대해 정책을 dry-run하고 판정, 매치된 규칙, 이유를 반환합니다. 아무것도 디스패치되거나 영속화되지 않습니다. 규칙 테스트 참조.
  • 이벤트 피드 보기 — 키가 라이브 트래픽을 받으면, Events가 각 평가를 보여주며, 판정, 표면, 툴, 실행으로 필터링 가능합니다.
모든 강제 정책은 먼저 shadow mode 뒤에서 롤아웃하세요: 프로덕션에서와 정확히 동일하게 평가하고 로깅하지만, 모든 강제 판정을 audit로 강등하고 이유에 [shadow] would …를 접두합니다. 이벤트 피드가 예상한 것에 발동하고 예상치 않은 것에 발동하지 않음을 보이면 shadow를 끄세요.

​
다음으로 갈 곳

규칙 작성

전체 매칭 언어 — 툴 glob, 인자 절, egress 목록, 새니타이저.

툴 허용 목록

deny 기본 판정을 명시적 allow 규칙과 짝지으세요.

정책 관리

기본값, 활성화/비활성화, 버전 관리, 그리고 되돌리기.

제로 트러스트가 필요한 이유

텍스트뿐 아니라 액션을 통제하는 것이 에이전트에게 왜 중요한가.
정책이 멈추기 위한 위협은 위험한 툴 호출과 과도한 자율성을 참조하세요.