메인 콘텐츠로 건너뛰기
여러분은 프로덕션 앞에 두고 싶은 정책이 있습니다. 두려움은 정책이 아닙니다 — 그것을 켰을 때 여러분의 에이전트가 실제로 필요로 하는 툴을 차단하거나, 여러분의 앱이 의존하는 필드를 마스킹한다는 것을 발견하는 것입니다. 해결책은 샌드박스에서 더 많이 테스트하는 것이 아닙니다; 아무것도 망가뜨릴 수 없는 자세로 실제 트래픽에 대해 롤아웃한 다음, 무엇이 발동하는지 본 후에만 강화하는 것입니다. 이 레시피가 그 롤아웃입니다: observe → shadow → enforce, 자율성 balanced 다음 tight. 여러분은 내내 콘솔(또는 REST API)에 머무릅니다; 에이전트는 https://api.orcarouter.ai/v1/...을 이전과 정확히 동일하게 계속 호출합니다.
모델이 처음이신가요? 각 자세가 기계적으로 무엇을 하는지는 강제 모드를, 각 자율성 수준이 무엇을 설정하는지는 Secure Agents 기준선을 읽으세요. 이 페이지는 시퀀스입니다 — 스위치를 뒤집는 순서.

​
1. 세 가지 움직임의 AI 보안 롤아웃

전체 롤아웃은 세 단계에서 자율성을 안전성과 교환하며, 각각은 다음 단계 전에 라이브 트래픽에 대해 검증됩니다:

Observe

모든 것을 허용, 모든 것을 로깅. 커버되지 않은 툴 호출은 Discovered Tools에 도착합니다; guardrail flag 규칙은 트래픽을 변경하지 않고 매치를 기록합니다. 여러분은 에이전트의 실제 형태를 학습합니다.

Shadow

실제 정책이 모든 호출을 평가하되, 모든 강제 판정이 audit로 강등되고 [shadow] would …로 로깅됩니다. 무엇이 차단될지 정확히 봅니다 — 실제로 아무것도 차단되지 않고.

Enforce

Shadow off. deny는 차단하고, mask는 가리고, pending_approval은 보류합니다. 자율성은 넓은 데서(balanced) 단단한 데로(tight) 가고, 여러분의 에이전트는 통제됩니다.
규율이 핵심입니다: 여러분 자신의 트래픽에 대해 shadow에서 발동하는 것을 먼저 지켜보지 않은 규칙을 결코 강제하지 마세요.

​
2. 움직임 하나 — observe (autonomy = permissive)

가능한 한 넓게 시작하세요. Firewall → Posture에서 permissive 자율성 수준을 적용하거나(Developer+) — POST /api/workspace/firewall/autonomy. 그것은 워크스페이스 observe mode를 활성화하고 강제 정책을 남기지 않으므로, 모든 호출이 허용되고 커버되지 않은 모든 호출이 커버리지 갭으로 로깅됩니다. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
/api/workspace/firewall/* 라우트는 릴레이 sk-orca-... 키가 아니라 여러분의 콘솔 세션 / 액세스 토큰에서 실행됩니다. 자율성 수준 적용은 워크스페이스 쓰기입니다 — Developer+. /v1/* 모델 호출만 릴레이 키를 사용합니다.
이제 실제 트래픽을 그것에 가리키고 실행하게 두세요. 두 피드를 지켜보세요:
  • Firewall → Discovered Tools(Member) — 여러분의 에이전트가 호출하는 모든 툴이, covered 또는 gap으로 플래그됨. 이것이 여러분 규칙의 입력입니다: 여러분은 가설이 아니라 실제로 일어나는 트래픽을 위한 정책을 작성하려는 참입니다.
  • Guardrails → Matches(Member) — 어떤 flag 액션 규칙이라도 추가했다면, 요청을 건드리지 않고 그것들이 기록하는 모든 매치.
Discovered Tools가 새 툴을 표면화하기를 멈출 때까지 실행하게 두세요. 그 안정된 목록이 여러분의 규칙 작성 사양입니다.

​
3. 움직임 둘 — shadow (실제 정책, 차단 0)

이제 여러분이 실제로 원하는 정책을 작성하고 — 툴 glob, 인자 절, egress 목록, cap_cost 상한 — 연결하기 전에 **shadow_mode**를 켜세요. (규칙은 firewall 규칙에서 구축하세요; 전체 정책 모델은 Firewall 레퍼런스에 있습니다.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
shadow_mode: true로, 그 deny와 그 cap_cost는 둘 다 평가 시점에 audit로 강등됩니다 — 엔진은 실제 판정을 계산하고, [shadow] would …로 접두하여 로깅하고, 호출을 통과시킵니다. 정책을 롤아웃하는 키에 연결하거나(키에 firewall_policy_id 설정) 워크스페이스 기본값으로 만드세요. 그런 다음 [shadow] 접두로 필터링된 Firewall → Events / Runs(Developer+)를 읽고 양쪽을 확인하세요:
모든 shell.exec 호출이 [shadow] would deny를 보여줍니다. 여러분의 상한을 넘는 모든 run이 [shadow] would cap_cost를 보여줍니다. 정책은 여러분이 그것을 위해 구축한 트래픽을 봅니다.
어떤 정당한 툴도 차단했을 판정으로 나타나지 않습니다. 이것이 거짓 양성 검사입니다 — shadow가 존재하는 이유. 필요한 툴이 플래그되면, 강제하기 전에 규칙을 고치고 다시 지켜보세요.
Guardrail에는 정책 수준 shadow가 없습니다. 동등물은 규칙별 flag 액션입니다: 그것은 Matches 피드에 매치를 기록하고 아무것도 변경하지 않으므로, 콘텐츠 규칙을 block이나 mask로 전환하기 전에 측정할 수 있습니다. 이 같은 움직임을 통해 여러분의 guardrail 규칙을 flag로 실행하세요.

​
4. 움직임 셋 — enforce (자율성 balanced, 다음 tight)

shadow 로그가 적절해 보이면, 하나가 아니라 두 단계로 강제하세요. 기본 거부로 곧장 점프하지 마세요. 먼저, balanced. 이것이 권장 첫 강제 자세입니다: firewall 기본 판정은 audit지만, 가장 파괴적인 액션(파괴적 셸 같은)은 거부되고, PII Shield guardrail은 audit 전용으로 실행됩니다 — 아직 마스킹하지 않고 PII를 플래그합니다. 여러분은 이제 나머지를 여전히 관찰하면서 최악의 것을 차단하고 있습니다. 같은 움직임에서 여러분 자신의 정책에 shadow_mode를 끄세요 — 그래서 그것의 deny / cap_cost 판정이 기준선과 함께 라이브가 됩니다. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
한 시간 동안 Events를 지켜보세요. 실제 차단이 이제 [shadow] 접두 없이 나타납니다. 거부된 툴 호출은 HTTP 400 firewall_blocked를 반환합니다; 그것은 skip-retry이고 모델 토큰을 소모하지 않습니다. 그런 다음, tight. balanced가 조용해지면, 기본 거부로 가세요. tight 수준은 기본 거부하고, 파괴적 셸 및 SSRF egress를 거부하고, PII Shield + Secrets Blocker를 강제합니다 — PII는 모델이 보기 전에 요청에서 마스킹되고, 여러분의 요청 내 시크릿은 차단됩니다. 차단된 프롬프트는 HTTP 400 guardrail_blocked를 반환하고, 쿼터를 소모하지 않으며, skip-retry입니다.
StageFirewall (액션)Guardrails (텍스트)무엇을 증명하는가
permissiveObserve; 아무것도 차단 안 됨flag만실제 트래픽 형태
balanced기본 audit; 파괴적 셸 거부됨PII 플래그됨최악의 경우가 멈춤
tight기본 거부; 셸 + fetch 형태 툴(SSRF) 거부됨PII 마스킹됨, 시크릿 차단됨완전 제로 트러스트
PII를 위한 스트리밍 주의사항. tight 아래에서, PII Shield는 모델이 보기 전에 요청의 PII를 마스킹합니다 — 그것은 라이브입니다. 스트리밍 응답의 출력 측 마스킹은 아직 라이브가 아닙니다; 출력 block은 스트리밍에서 강제됩니다(스캐너가 스트림을 끊음). 모델 출력을 가리는 데 의존한다면, 먼저 guardrail Test 탭에서 여러분의 stage/stream 조합을 확인하세요. Guardrails를 참조하세요.

​
5. 비상 탈출구 — 원클릭 실행 취소

모든 자율성 변경은 여러분의 이전 자세를 스냅샷하는 단일 트랜잭션이므로, Firewall → Posture에서(또는 POST /api/workspace/firewall/autonomy/undo/:audit_id) 곧바로 되돌릴 수 있습니다. 더 부드러운 수준을 그냥 다시 적용할 수도 있습니다 — tight을 다시 balanced로, 또는 balanced를 다시 permissive로 — 언제든지.
Undo는 가장 최근 적용의 감사 스냅샷에서 복원합니다. 여러분이 되돌리려는 적용 이후로 수동 정책 편집을 했다면, 그 스냅샷은 더 이상 가장 최근의 미사용 것이 아니고 undo는 조용히 그 편집을 굴려 없애기보다 거절합니다. 그런 일이 일어나면, 대신 더 부드러운 수준을 다시 적용하세요 — 그것은 항상 사용 가능합니다.

​
6. 각 움직임의 판정이 어디서 오는가

롤아웃은 여러분이 요청하지 않은 것을 결코 차단하지 않습니다, 각 자세가 명시적이고 관찰 가능한 메커니즘에 매핑되기 때문입니다:
PostureMechanismOutcome
Observe워크스페이스 firewall_observe_mode on + guardrail flag허용 + 갭 / 매치 로깅
Shadow정책별 shadow_mode실제 판정 계산, audit로 강등, [shadow] would …로 로깅
Enforceshadow_mode off + tight/balanced 자율성deny / mask / cap_cost 라이브 됨
네 용어 — observe mode, audit 판정, flag 액션, 그리고 shadow_mode — 는 별개의 스위치이며, 강제 모드에 나란히 문서화되어 있습니다.

​
7. 다음 단계

강제 모드

observe, shadow, enforce 뒤의 메커니즘 맵.

Secure Agents 기준선

각 자율성 수준이 설정하는 것, 그리고 먼저 그것을 시뮬레이션하는 법.

자율 에이전트 길들이기

강제한 후의 다음 단계: 비용 상한, 이상 탐지, 그리고 승인.

Agent Firewall

정책, 규칙, 판정, shadow mode, 그리고 MCP 게이트웨이를 전부.
신뢰할 수 있는 go-live는 스위치가 아니라 롤아웃입니다. 여러분의 에이전트가 무엇을 하는지 관찰하고, 정책을 그것의 실제 트래픽에 대해 shadow 처리한 다음, 강제하세요 — tight 전에 balanced — 그러면 모든 규칙은 그것이 차단하기 전에 프로덕션에서 검증됩니다.