AI 에이전트에는 하나의 커다란 확인 버튼이 아닌 계층적 승인 에스컬레이션이 필요합니다

모든 에이전트 제품은 결국 동일한 질문에 직면하게 됩니다: "누가 '예'를 클릭할 권한이 있는가?"

가장 간단한 답변은 동작당 단일 프롬프트(prompt)를 제공하는 것입니다. 사용자는 팝업을 받고, 팝업에는 "에이전트가 X를 수행하려고 합니다"라고 표시되며, 사용자가 예 또는 아니오를 클릭하면 실행이 계속됩니다. 하지만 이 모델은 실제 운영 환경에서 빠르게 무너집니다. 세 가지 이유가 반복해서 나타납니다:

1. 사용자는 모든 동작을 평가할 수 없습니다. 장시간 실행되는 연구(research) 또는 코딩(coding) 에이전트는 수백 개의 저위험 동작과 소수의 부수 효과(side effects)를 생성할 수 있습니다. 사용자가 모든 것을 일괄 승인하거나(실질적인 안전 장치가 없음), 피로감을 느껴 나머지를 기계적으로 승인(rubber-stamp)하게 됩니다.
2. 동일한 동작이라도 맥락에 따라 영향 범위(blast radius)가 다릅니다. "메시지 전송"은 샌드박스(sandbox) 내에서는 안전할 수 있지만, 실제 고객을 대상으로 할 때는 위험할 수 있습니다. 런타임(runtime)은 보통 이를 알고 있지만, 사용자는 대개 알지 못합니다.
3. 흥미로운 실패는 프롬프트 경계에서 발생하는 것이 아닙니다. 그것은 재시도(retries), 복구(recoveries), 폴백(fallbacks), 에스컬레이션(escalations)과 같은 가장자리(edges)에서 발생합니다. 단일 확인 버튼은 프롬프트와 부수 효과 사이에 발생하는 일에 대해 아무런 의견을 갖지 않습니다.

더 나은 모델은 계층적 승인 에스컬레이션(tiered approval escalation)입니다. 제안된 각 동작은 도구 호출(tool-call) 경계에서 계층(tier)으로 분류되며, 이 계층이 누구에게 얼마나 자주 요청할지를 결정합니다.

작동하는 계층적 에스컬레이션 정책은 다음과 같은 모습입니다:

• Tier 0 (읽기 전용, 범위 제한): 프롬프트가 필요 없고, 실행 로그 외에는 영수증도 남지 않습니다. 예시: 프로젝트 루트 내부 파일 읽기, 내부 인덱스에 대한 검색 질의, 샌드박스 URL 스냅샷.
• Tier 1 (되돌릴 수 있는 내부 상태 변경): 프롬프트는 필요 없지만, 영구적인 영수증과 취소 토큰이 있습니다. 예시: 로컬 브랜치 생성, 문서 초안 작성, 작업 공간 캐시 채우기.
• Tier 2 (제한된 외부 쓰기): 특정 클래스의 행동에 대해 세션당 한 번 사용자에게 프롬프트를 요청하고 명확한 범위를 설정합니다. 에이전트는 재요청 없이 해당 클래스 내에서 다섯, 오십, 혹은 오백 개의 쓰기를 수행할 수 있지만, 사용자는 어떤 클래스가 승인되었는지 알고 있습니다. 예시: PR(Pull Request) 생성, 테스트 채널에 메시지 전송, 특정 스레드에 댓글 게시.
• Tier 3 (되돌릴 수 없거나 영향 범위가 큰 작업): 매번 프롬프트를 요청하며, 해결된 대상(resolved target), 정책 결정(policy decision), 검증 아티팩트(verification artifact)를 제시하고 새로운 인간의 승인을 요구합니다. 예시: 실제 고객에게 전송, main 브랜치에 병합(merge), 레코드 삭제, 자격 증명 변경, 실제 계정으로 공개 메시지 게시.

이 중요한 변화는 분류가 프롬프트에서 발생하는 것이 아니라 런타임(runtime)에서 발생한다는 점입니다. 에이전트가 설득력 있게 Tier 3 작업을 정말로 Tier 1이라고

1. 모든 작업의 티어(tier)를 알고 있는 도구 레지스트리 (A tool registry). 에이전트가 설명하는 작업의 내용이 아니라, 게이트웨이(gateway)가 해결된 호출(resolved call)을 분류한 결과여야 합니다.
2. 세션 수준의 스코프 객체 (A session-level scope object). 사용자가 Tier 2 클래스를 한 번 승인하면, 해당 스코프(scope)가 실행(run)과 함께 이동합니다. 동일한 클래스 내의 다음 Tier 2 쓰기(write) 작업은 이 스코프를 확인하고 다시 묻지 않고 진행합니다.
3. 호출별 영수증 (A per-call receipt). 모든 티어의 모든 작업은 티어, 해결된 대상(resolved target), 정책 결정(policy decision), 승인 참조(approval reference), 검증 아티팩트(verification artifact)를 포함하는 작은 구조화된 기록을 생성합니다. Tier 0 및 Tier 1 영수증은 실행 로그(run log)에 일괄 처리(batched)되지만, Tier 2 및 Tier 3 영수증은 일급 객체(first-class)로 취급됩니다.
4. 에스컬레이션 경로 (An escalation path). 만약 Tier 1 작업이 갑자기 Tier 2가 되어야 하는 경우(예: 에이전트가 승인된 스코프 외부를 쓰려고 시도할 때), 런타임(runtime)이 일시 중지되고, 재분류한 뒤 사용자에게 요청합니다. 이때 프롬프트는 "계속하시겠습니까?"가 아니라, "이 작업의 티어가 방금 재조정되었습니다. 이유는 다음과 같습니다. 새로운 티어를 승인하거나 중단하십시오."가 되어야 합니다.

이것이 아닌 것. 계층적 에스컬레이션(Tiered escalation)은 가드(guard)의 대체재가 아닙니다. 가드는 프롬프트 인젝션(prompt injection), 자격 증명 유출(credential leaks), 데이터 유출 패턴(exfiltration patterns), 안전 우회(safety bypasses)를 탐지하기 위해 작업의 내용을 스캔합니다. 티어(tier)는 인간에게 물어볼지 여부를 결정하고, 가드(guard)는 작업의 실행 여부 자체를 결정합니다. Tier 0 읽기(read) 작업이라도 가드에 의해 차단될 수 있습니다. 가드를 통과한 Tier 3 전송(send) 작업이라도 인간의 승인을 위해 일시 중지될 수 있습니다.

프로덕션 환경에서 주의할 점. 초기 단계에서 나타나는 세 가지 실패 모드(failure modes)는 다음과 같습니다:

• 티어 인플레이션(Tier inflation). 에이전트는 Tier 1이 쉽다는 것을 학습하고 애매한 행동들을 이 경로로 우회시킵니다. 해결책은 에이전트가 아닌 런타임(runtime)이 티어를 선택하도록 요구하는 것입니다.
• 범위 표류(Scope drift). Tier 2 클래스가 세션 동안 확장되어 대부분의 쓰기 작업을 포괄하게 됩니다. 해결책은 단순히