메인 콘텐츠로 건너뛰기
firewall 규칙을 작성했습니다 — shell.exec에 대한 deny, egress 허용 목록, rm -rf에만 발동하는 인자 절 — 이제 그것이 단일 프로덕션 툴 호출을 변경하기 전에 정확히 생각한 대로 작동하는지 알고 싶습니다. firewall은 firewall 규칙을 테스트하는 세 가지 비파괴적 방법을 제공하며, 각각은 다른 질문에 답합니다:

한 호출 dry-run

Test 샌드박스는 하나의 합성 툴 호출을 실제 엔진에 먹이고 판정을 반환합니다 — 아무것도 디스패치 안 함, 아무것도 로깅 안 함. Developer+.

자세 재생

Simulate는 최근 트래픽에 대해 자율성 수준을 재생하고 그것이 얼마나 많은 호출을 차단할지 셉니다. Member 판독 가능.

라이브 트래픽에 대해 실행

Shadow mode는 실제 호출에 대해 전체 정책을 평가하되 모든 강제 판정을 audit로 강등합니다. 폭발 반경 제로.
세 가지 모두 콘솔(또는 세션 / 액세스 토큰으로 인증하는 /api/workspace/firewall/* 관리 라우트 — 릴레이 sk-orca-… 키가 아님)을 통해 구성됩니다. 테스트하는 동안 에이전트의 /v1/* 릴레이 호출은 결코 변하지 않습니다.

​
1. dry-run Test 샌드박스로 firewall 규칙 테스트하기

Test 샌드박스는 가장 빡빡한 루프입니다: 하나의 합성 툴 호출을 주면 그것이 실제 평가 엔진을 실행하고 — 전체 정책 해석, 우선순위 순으로 순회되는 규칙, 첫 매치 승리 — 판정, 그것을 생성한 규칙, 그리고 사람이 읽을 수 있는 이유를 반환합니다. 호출은 dry run입니다: 어떤 툴에도 아무것도 디스패치되지 않고, 이벤트 피드나 Discovered-tools 인벤토리에 아무것도 쓰이지 않습니다. 그것은 한 질문에 정확히 답합니다: 이 정확한 툴 이름과 이 인자가 주어졌을 때, 내 정책은 무엇을 결정하는가 — 그리고 어떤 규칙이 그것을 결정하는가?
Test 샌드박스는 **Developer+**입니다. 저장되지 않은 초안 정책에 대해 id로 미리 보기할 수 있고 응답이 매치된 정책 이름과 규칙 레이블을 표출하므로, 평범한 읽기보다 쓰기 표면 미리 보기에 가깝게 위치합니다 — 모든 멤버에게 개방되는 Simulate 및 다른 읽기 뷰와 달리.

​
하나의 구체적인 dry run

shell.exec을 명령이 rm -rf를 포함할 때만 거부해야 하는 규칙을 추가했다고 합시다. 한 자리에서 두 가지를 확인하고 싶습니다: 위험한 명령은 거부되고, 무해한 것은 여전히 통과.
1

위험한 호출 테스트

Security → Firewall에서, Test 탭을 열고, response 표면을 고르고, 툴 이름 shell.exec과 인자 {"command": "rm -rf /data"}를 입력하고, 실행합니다. 응답이 판정과 매치된 규칙을 명명합니다:
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

무해한 호출 테스트

{"command": "ls -la"}로 다시 실행합니다. 인자 절이 더 이상 매치하지 않으므로, 규칙은 정책 기본값으로 떨어집니다 — allow이나 audit과 빈 rule_label을 봐야 합니다. rm -rf가 거부되고 ls -la가 그렇지 않으면, 인자 절이 올바르게 범위 지정된 것입니다.
3

연결하기 전에 초안 미리 보기

트래픽이 현재 해석하는 것 대신 특정 초안 정책에 대해 평가하려면 policy_id를 전달하세요 — 그래서 키를 연결하거나 워크스페이스 기본값으로 프로모트하기 전에 새 정책이 옳음을 증명할 수 있습니다.
응답에서 gap을 읽으세요. gap: true는 정책이 해석되었지만 그 안의 어떤 규칙도 호출에 매치하지 않았음(그리고 워크스페이스가 observe 모드)을 의미합니다 — 툴이 모든 규칙을 빠져나가 기본값으로 떨어졌습니다. 그것은 신뢰할 판정이 아니라 출시 전에 메울 커버리지 구멍입니다.
Test 샌드박스는 라이브 평가와 같은 표면을 사용합니다 — inbound, response, mcp, egress(기본값 inbound) — 그래서 각 규칙을 그것이 고정된 표면에서 테스트하세요. inbound에는 호출 시점 인자가 없으므로, sanitize 규칙은 거기서 프로덕션에서와 정확히 같이 block으로 격상됩니다; 표면이 왜 중요한지는 stages를 참조하세요.

​
2. 적용하기 전에 자율성 수준 Simulate

Test 샌드박스는 한 호출을 검사합니다. Simulate는 자세 수준 질문에 답합니다: 이 전체 워크스페이스를 더 엄격한 자율성 수준으로 전환하면, 최근 트래픽의 얼마나 많은 부분을 차단할까? Simulate는 후보 수준의 deny 규칙을 후행 firewall 이벤트에 대해 재생하고 차단되었을 영향을 반환합니다 — 툴 이름과 카운트만, 결코 인자는 아님. 그것은 읽기 전용이고 Member 판독 가능이므로, Developer가 그것을 약속하기 전에 팀의 누구나 tight의 폭발 반경을 미리 볼 수 있습니다.
  • tight — 기본 거부, 파괴적 셸 거부, fetch 형태 툴(SSRF 벡터) 거부, PII Shield + Secrets Blocker 강제. Simulate는 이 바닥이 실제 트래픽의 얼마나 많은 부분을 잡을지 보여줍니다.
  • balanced — 기본 audit, 파괴적 셸 거부, 감사 전용의 PII Shield(PII 플래그). 권장 시작 자세.
  • permissive — observe 전용; 아무것도 강제 안 함.
Simulate는 아무것도 변경하지 않습니다 — 과거 이벤트에 대한 if 가정입니다. 자율성 수준 적용(Developer+ 쓰기)은 감사 스냅샷에서 원클릭 실행 취소와 함께, 실제의, 편집 가능한 autonomy_* 정책 및 guardrail 행을 구체화합니다. Simulate로 미리 본 다음, 카운트가 맞아 보이면 적용하세요.

​
3. Shadow mode: 폭발 반경 없이 라이브 트래픽에 대해 테스트

Test 샌드박스와 Simulate는 오프라인 미리 보기입니다. Shadow mode는 라이브 것입니다: 실제 에이전트 트래픽에 대해 정책을 평가하고, 모든 규칙을 순회하고, 판정을 고르는 — 그런 다음 모든 강제 판정(deny, sanitize, pending_approval)을 audit로 강등하고 이유에 [shadow] would …를 접두하는 — 정책별 플래그. 호출은 항상 통과합니다; 아무것도 차단되거나, 가려지거나, 보류되지 않습니다. 그것은 이벤트 피드를 강제가 꺼진 프로덕션 실행처럼 읽히게 만듭니다. [shadow]로 필터링하면, 정책이 차단하기 시작하려는 모든 호출의 완전한 목록을 — 그것이 하나를 차단하기 전에 — 갖게 됩니다.
테스트 방법무엇에 대해 실행답하는 질문
Test 샌드박스하나의 합성 호출”이 정확한 호출은 어떤 판정을 받고, 어떤 규칙이 결정하는가?”
Simulate최근 이벤트”더 엄격한 자율성 수준이 얼마나 많은 호출을 차단할까?”
Shadow mode라이브 트래픽”이 정책이 실제 프로덕션 트래픽 전반에서 무엇을 차단할까?”
Shadow mode는 셋 중 더 깊은 것입니다 — 폭발 반경 제로의 전체 라이브 커버리지. 자체 페이지를 가집니다: shadow mode로 firewall 정책 롤아웃하기는 토글, [shadow] would … 이유, 그리고 강제로의 전환을 안내합니다.

​
4. 실용적인 테스트 순서

세 도구는 하나의 안전 롤아웃 경로로 조합됩니다 — 가장 저렴한 점검 먼저, 가장 넓은 커버리지 마지막:
1

방금 작성한 규칙 dry-run

Test를 사용해 각 새 규칙이 발동해야 할 호출에 발동하고 그렇지 않아야 할 것은 통과시키는지 — 부정적 경우 포함 — 확인하세요. 빠르고, Developer+, 아무것도 영속화 안 됨.
2

자세 가늠(선택)

직접 작성한 규칙이 아니라 자율성 수준을 사용하는 경우, 수준을 Simulate하고 적용하기 전에 실제 트래픽에 대해 차단되었을 카운트를 읽으세요.
3

라이브 트래픽에 대해 shadow

shadow mode를 켜고 대표적인 윈도우의 실제 호출이 흐르게 하세요. [shadow] would … 이벤트를 읽고; 거짓 양성을 표출하는 규칙을 조이세요 — 여전히 shadow 상태, 폭발 반경 제로.
4

강제

피드가 예상한 것에 발동하고 예상치 않은 것에는 발동하지 않으면, shadow를 끄세요. 다음 호출이 실제로 강제합니다.
테스트는 통제되는 skill이 아니라 정책을 미리 봅니다. block이나 quarantine 모드의 skill은 shadow 정책 하에서도 여전히 강제합니다 — skill의 검토 처분이 이깁니다. 정책을 shadow 하는 것은 skill을 격리 해제하라는 요청이 결코 아니었습니다.

​
5. API 레퍼런스

이 관리 라우트는 세션 / 액세스 토큰을 사용하며 워크스페이스 범위입니다:
메서드 및 경로역할목적
POST /api/workspace/firewall/testDeveloper+해석된(또는 초안 policy_id) 정책에 대해 하나의 합성 툴 호출 dry-run. 판정, policy_name, rule_label, reason, gap, shadow_mode 반환. 아무것도 디스패치되거나 로깅 안 됨.
GET /api/workspace/firewall/simulate?level=Member최근 이벤트에 대해 자율성 수준 재생; 차단되었을 카운트 반환.
GET /api/workspace/firewall/policies/:idMember정책의 현재 shadow_mode 플래그 읽기.
PUT /api/workspace/firewall/policiesDeveloper+정책에서 shadow_mode 토글.
Test 본문은 surface(기본값 inbound), 필수 tool_name, 선택적 args_json, 그리고 해석을 재정의하는 선택적 policy_id를 받습니다.

​
다음으로 갈 곳

Shadow mode

라이브 트래픽 롤아웃: [shadow] would …, 이벤트 필터, 그리고 강제로의 전환.

인자 검증

규칙을 어떤 인자로 범위 지정 — Test 샌드박스가 rm -rf 대 ls -la에 대해 검증하게 하는 절.

Verdicts

테스트가 테스트이기를 멈출 때 allow / audit / deny / sanitize / pending_approval / cap_cost가 각각 하는 일.

이벤트 로그

shadow된 판정이 떨어지는 곳 — 필터링, 실행과 매치된 규칙으로 파고들기.
이 테스트가 행사하는 규칙 매칭 문법은 전체 firewall rules 레퍼런스를 참조하세요; 테스트가 더 넓은 모델에 어떻게 들어맞는지는 강제 모드를 참조하세요.