01 · THE QUESTION
확인 버튼 하나면 위험한 행동을 통제할 수 있을까
버튼이 보인다는 사실만으로 안전해지지는 않습니다. Agent가 이미 행동을 실행한 뒤 확인을 보여주거나, 승인 대상을 설명하지 못하거나, 새로 고침 뒤 pending 상태를 잃는다면 UI는 통제 장치가 아닙니다.
02 · STATE MACHINE
실행 요청을 지속 가능한 상태로 바꿉니다
APPROVAL STATES
proposed
→ policy_checked
→ pending_approval
├─ approved → executing → succeeded | failed
├─ revised → proposed
├─ rejected → cancelled
└─ expired → cancelled각 상태에는 actor, timestamp, action payload hash, policy version, decision reason이 필요합니다. 사용자가 자리를 비우거나 session이 재시작돼도 pending action을 복원할 수 있어야 하며, 승인된 payload와 실제 실행 payload가 달라지면 다시 승인을 받아야 합니다.
| 개념 | 답하는 질문 |
|---|---|
| Permission | 이 사용자가 원래 이 행동을 할 수 있는가? |
| Policy | 어떤 조건에서 자동 실행·승인·차단할 것인가? |
| Approval | 이 구체적인 행동을 지금 실행해도 되는가? |
| Audit | 누가 무엇을 보고 어떤 결정을 내렸는가? |
03 · PLACEMENT
실행 전, 실행 중, 실행 후 개입은 목적이 다릅니다
Before execution
송금, 삭제, 외부 전송처럼 되돌리기 어려운 행동은 실행 전에 멈춥니다. 대상, 범위, 예상 결과, 비용, 되돌릴 수 있는지를 사용자에게 보여주고 승인된 내용만 실행합니다.
During execution
긴 작업에서는 진행률과 현재 단계, 소비된 budget을 보여주고 취소할 수 있어야 합니다. Cancellation은 화면의 spinner만 멈추는 것이 아니라 server-side 작업과 하위 tool에도 전달돼야 합니다.
After execution
결과 검토, artifact diff, undo, rollback을 제공합니다. 실행 후 검토는 사전 승인 대체물이 아니라 결과의 품질과 예상치 못한 영향에 대응하는 별도 단계입니다.
04 · RISK
위험도와 되돌릴 수 있음으로 gate를 배치합니다
| 행동 | 위험·가역성 | 권장 흐름 |
|---|---|---|
| 공개 문서 읽기 | 낮음 · 상태 변화 없음 | 자동 실행 + trace |
| 초안 파일 생성 | 낮음 · 쉽게 되돌림 | 자동 실행 + diff |
| 내부 메시지 전송 | 중간 · 부분적 취소 | 미리보기 + 선택적 승인 |
| Production 설정 변경 | 높음 · 영향 큼 | 명시적 승인 + rollback plan |
| 삭제·결제·외부 공개 | 매우 높음 · 비가역적 | 강한 인증 + 이중 확인 + audit |
승인을 너무 자주 요청하면 사용자는 내용을 읽지 않고 통과시키는 approval fatigue에 빠집니다. Low-risk action은 policy로 자동화하고, 실제로 판단이 필요한 high-risk transition에 사람의 주의를 집중해야 합니다.
05 · APPROVAL UI
승인 화면이 반드시 답해야 할 질문
- 어떤 agent와 tool이 이 행동을 제안했는가?
- 무엇이 누구에게, 어느 범위까지 바뀌는가?
- 사용된 input과 근거는 무엇인가?
- 예상 비용과 소요 시간은 얼마인가?
- 거절, 수정, 취소, 되돌리기가 가능한가?
MCP처럼 server가 sampling이나 elicitation을 요청할 수 있는 구조에서는 사람의 통제가 tool 실행에만 머물지 않습니다. Model 사용, 추가 입력, filesystem roots 같은 host-side capability에도 동일한 정책과 사용자 표시가 필요합니다.