메인 콘텐츠로 건너뛰기
firewall 규칙이 pending_approval 판정을 반환하면, 에이전트의 툴 호출은 디스패치되는 대신 보류됩니다 — 이제 사람을 기다리고 있습니다. 이 페이지는 검토자를 위한 것입니다: 콘솔에서 에이전트 툴 호출 보류를 어떻게 승인(또는 거부)하는지, 큐가 무엇을 보여주는지, 그리고 OrcaRouter가 두 검토자가 같은 결정에서 충돌하는 것을 어떻게 막는지. 그것은 human-in-the-loop의 해결 절반입니다. 호출이 왜 보류되고 보류된 에이전트가 그 후 어떻게 재제출하는지는 verdicts와 더 깊은 승인 레퍼런스를 참조하세요. 콘솔 대신 자체 시스템에서 해결하려면, 승인 웹훅을 참조하세요.

​
1. 검토자 자리에서 본 보류 호출 수명 주기

보류된 호출은 짧은 대역 외 루프입니다. 당신의 일은 중간 단계입니다:
1

호출이 보류됨

규칙이 pending_approval로 해석됩니다. 릴레이는 코드 firewall_approval_pending과 승인 id와 함께 HTTP 400을 반환합니다; 호출은 툴에 도달하지 않습니다. 에이전트가 그 id에서 폴링을 시작합니다.
2

당신이 그것을 해결

Approvals 큐를 열고, 호출이 왜 보류되었는지 읽고, 승인 또는 거부합니다 — 이 페이지의 초점.
3

에이전트가 진행(또는 중단)

승인 시, 에이전트는 일회용 X-OrcaRouter-Firewall-Approval 헤더와 함께 원래 호출을 재제출하고 게이트웨이가 그 한 번 통과시킵니다. 거부 시, 호출은 차단된 채로 있습니다.
보류를 해결하는 것은 **Developer+**로 게이트됩니다 — firewall Events 피드와 같은 게이트. 더 낮은 역할은 firewall 정책, 설정, discovered tools를 읽을 수 있지만, Developer 이상 역할만 승인 큐를 나열하거나 보류된 툴 호출을 승인/거부할 수 있습니다. 역할과 범위 참조.

​
2. pending 큐 나열

Approvals 탭은 GET /api/workspace/firewall/approvals를 읽습니다. 필터 없이 pending 큐를, 오래된 것 먼저 반환합니다 — 그래서 가장 오래 기다린 호출이 맨 위에 있고 백로그를 순서대로 처리합니다. 
GET /api/workspace/firewall/approvals?state=pending
state는 중요한 하나의 필터입니다. 값은 승인의 수명 주기에 매핑됩니다:
state반환되는 승인
pending (기본값)보류됨, 결정 대기 — 작업 큐.
approved이미 통과됨.
rejected이미 차단됨.
이것은 세션의 콘솔 라우트입니다 — sk-orca-… 릴레이 키가 아니라 대시보드에서 구성하고 검토하세요. 릴레이 키는 /v1/* 모델 호출용입니다; firewall 관리는 콘솔 로그인하에 실행됩니다.

​
3. 호출이 왜 보류되었는지 읽기

각 행은 검토자가 필요로 하는 결정 입력을 담습니다 — 툴 이름 (tool_name), 인자 지문(args_hash, 정전화된(canonicalized) 호출 인자의 SHA-256 — 원시 인자 값은 승인에 저장되지 않음), 요청 id, 그리고 정책, 규칙, 그리고 발동한 절을 명명하는 평이한 영어 출처 라인:
매치된 규칙이 속한 명명된 정책으로, 워크스페이스 범위로 해석되므로 오래된 id가 결코 다른 테넌트의 정책 이름을 표출할 수 없습니다.
규칙의 레이블과 한 줄 “왜” 설명자 — 예: command contains rm -rf, 또는 glob 전용 규칙의 경우 tool matches "http_fetch". 이것이 큐에 “Held because…” 라인을 렌더링합니다.
이 승인이 생성된 시점 또는 이후에 매치된 규칙이 편집되었으면 true. 그러면 라이브 레이블과 절이 억제되고(그것들이 더 이상 실제로 호출을 보류한 것을 반영하지 않을 수 있음), 큐는 오래된 출처 대신 “rule since changed” 노트를 보여줍니다. 툴 이름과 인자 — 진짜 결정 입력 — 은 항상 표시됩니다.
rule_changed는 오류가 아니라 의도적인 정직 신호입니다. 호출이 큐에 앉아 있는 동안 누군가 firewall 규칙을 편집하면, OrcaRouter는 더 이상 매치하지 않는 출처를 보여주기보다 가능하게-틀린 이유를 숨기는 쪽을 택합니다. 그 경우 (여전히 표시되는) 툴 이름과 정책 이름으로 결정하세요.

​
4. 승인 또는 거부

해결은 approved 또는 rejected의 decision과 선택적 reason과 함께 PATCH /api/workspace/firewall/approvals/:id를 보냅니다. 버튼을 클릭하면 콘솔이 대신 이것을 합니다; 형태는: 
PATCH /api/workspace/firewall/approvals/507f1f77bcf86cd799439011
Content-Type: application/json

{ "decision": "approved", "reason": "verified target host with the on-call" }
  • approved → 보류된 호출이 진행될 수 있습니다. 에이전트의 다음 재제출이, 일회용 승인 헤더를 담아, 한 번 통과됩니다.
  • rejected → 호출이 차단된 채로 있습니다. 에이전트는 거부를 보고 다른 경로를 고르거나, 사용자에게 묻거나, 중단할 수 있습니다.
decision은 닫힌 {approved, rejected} 집합에 대해 검증됩니다 — 그 외 어떤 것도 거부됩니다. reason은 결정과 함께 기록되고 행위자, 툴 이름, 그리고 요청 id와 함께 firewall 감사 로그에 쓰입니다.
모든 해결은 누가 결정했는지, 결정, 그리고 이유를 명명하는 워크스페이스 감사 행을 씁니다. 콘솔 해결은 사람 행위자를 기록합니다; 웹훅 해결은 시스템 행위자를 기록합니다. 해결 출처는 결코 조용히 드롭되지 않습니다.

​
5. First-writer-wins: 이중 해결 없음

pending 승인은 경합될 수 있습니다 — 콘솔의 두 검토자, 또는 콘솔 클릭과 웹훅 콜백이 함께 도착. OrcaRouter는 이것을 단일 first-writer-wins 규칙으로 해결합니다:
  • 결정은 승인이 여전히 pending인 동안에만 발동하는 원자적 조건부 업데이트입니다. 첫 작성자가 이기고 결정을 적용합니다.
  • 이후의 모든 작성자는 “이미 해결됨”을 관찰하고 멱등적 no-op으로 취급됩니다 — 오류가 아니라 이미 해결된 문서와 함께 HTTP 200을 받습니다.
응답은 당신이 어느 쪽에 있었는지 알려줍니다: 
{
  "resolved": false,
  "already_resolved": true,
  "approval": { "state": "approved", "decision": "approved", "...": "..." }
}
resolved: true는 당신의 호출이 결정을 적용했음을 의미합니다; already_resolved: true는 누군가(또는 어떤 웹훅)가 먼저 도달했고 당신이 그들의 결과를 보고 있음을 의미합니다. 어느 쪽이든 큐는 하나의 일관된 상태로 조정됩니다.
해결이 멱등적이므로, 불안정한 네트워크나 더블 클릭이 보류를 손상시키거나 결정을 뒤집을 수 없습니다. 첫 승인/거부가 유일하게 카운트되는 것입니다; 그 후의 모든 것은 그저 결과를 다시 읽습니다.

​
6. 큐를 통과하는 구체적인 흐름

balanced 자율성 워크스페이스가 규칙이 command contains rm -rf에 매치했기 때문에 에이전트의 shell.exec 호출을 보류합니다. 검토자로서 당신은:
  1. Approvals를 엽니다 — 보류된 shell.exec이 오래된 것 먼저 pending 목록의 맨 위에 있습니다.
  2. 행을 읽습니다: 툴 shell.exec, args_hash 지문, 요청 id, 그리고 “Held because… command contains rm -rf” 라인(매치된 규칙의 절에서 렌더링됨). rule_changed 플래그 없음, 그래서 출처는 최신입니다.
  3. 대상이 스크래치 디렉터리이므로, 이유와 함께 승인합니다.
  4. 당신의 PATCH가 resolved: true를 반환합니다; 에이전트의 다음 폴이 approved를 보고, 일회용 헤더와 함께 재제출하고, 명령이 정확히 한 번 실행됩니다.
팀원이 1초 일찍 그것을 승인했다면, 당신의 클릭은 그들의 결정과 함께 already_resolved: true를 반환했을 것입니다 — 해 없음, 이중 실행 없음.

​
다음으로 갈 곳

승인 레퍼런스

전체 HITL 루프: 보류, 폴, 재제출, 그리고 일회용 헤더.

승인 웹훅

HMAC 서명 콜백으로 자체 시스템에서 보류를 해결합니다.

Verdicts

pending_approval이 여섯 firewall 판정 사이에 어디에 위치하는가.

이벤트 로그

피드에서 해결된 호출의 다운스트림 결과를 확인합니다.
이 보류가 잡으려는 위험은 위험한 툴 호출과 과도한 자율성을 참조하세요.