승인 프롬프트가 코딩 에이전트의 보안 경계로 작동하지 않는 이유

코딩 에이전트가 인간에게 파일 변경 승인, 데이터베이스 호출 또는 배포를 요청할 때, 해당 승인 프롬프트는 마치 보안 경계처럼 느껴집니다. 하지만 실제로는 그렇지 않습니다.

실제 환경에서 승인 프롬프트는 세 가지 이유로 권한을 유출합니다: 승인 피로(approval fatigue), 만료되지 않는 승인, 그리고 결정이 포착된 시점보다 오래 지속되는 구식 대기 승인입니다.

승인 피로 (Approval fatigue)

전체 PR 라이프사이클(PR lifecycle)을 수행하는 에이전트는 단일 세션에서 수십 개의 프롬프트를 노출할 수 있습니다. 이 중 대부분은 위험도가 낮습니다: 설정 파일 형식 지정, 로그 읽기, 테스트 재실행 등입니다. 하지만 일부는 고위험군입니다: 배포 매니페스트(deployment manifest)에 쓰기, 시크릿(secrets) 건드리기, 네트워크 규칙 변경 등이 해당합니다.

프롬프트에서 모든 것이 똑같이 보일 때, 인간은 읽기를 멈춥니다. 그들은 에이전트가 계속 움직이도록 "승인" 버튼을 누르는 법을 배우고 나중에 처리하려 합니다. 바로 그때 배포가 잘못된 환경으로 갔고 롤백(rollback)에 30분이 걸린 것입니다.

해결책은 더 많은 프롬프트가 아닙니다. 모든 프롬프트를 구별할 수 있게 만드는 것입니다.

만료되지 않는 승인 (Approvals that never expire)

대부분의 에이전트 툴킷은 "kubectl apply 승인" 또는 "/etc에 쓰기 승인"과 같은 행동 범주에 대한 부울(boolean) 결정으로 승인을 기록합니다. 여기에 시간 제한이 없습니다.

오전 9시에 부여된 승인이 사건 맥락이 바뀌고, 온콜 담당자가 인계하고, 에이전트의 임무 범위가 표류한 오후 4시에도 동일한 행동을 승인할 권한을 주어서는 안 됩니다.

만료 기한이 없으면, 그 승인은 상시 자격 증명(standing credential)이 됩니다. 인간은 특정 시점의 설명서를 검토했을 뿐인데, 자신도 모르게 영구적인 부여권을 발행해버린 것입니다.

구식 대기 승인 (Stale pending approvals)

반대의 경우입니다: 프롬프트가 사람이 통화 중이거나 잠들어 있는 동안 큐(queue)에 머무릅니다. 세 시간이 지난 후, 에이전트는 이 대기 요청을 환경의 더 새로운 스냅샷과 비교하여 재실행합니다.

인간이 승인했던 설명은 더 이상 실행될 내용과 일치하지 않습니다. 그 승인은 발급되었을 때는 타당했지만, 실제로 수행될 때는 부적절한 것입니다.

이것이 바로 '보류 승인(pending approvals)'과 '승인된 동작(authorized actions)'이 같지 않은 이유입니다. 보류 승인은 특정 시점의 특정 동작에 대한 결정을 담고 있습니다. 그 시간 창이 닫히면, 해당 결정은 철회되어야 합니다.

더 나은 형태: 정확한 동작 해시(action hash)에 바인딩되는 만료되는 HOLD 승인

상시 자격 증명(standing credentials)을 발급하지 않으면서도 인간의 개입을 유지하는 실용적인 해결책입니다:

1. 동작을 일시 중지하고, 대기열에 넣지 마십시오. 에이전트는 실행될 정확한 내용에 대한 결정론적 해시(deterministic hash)를 가진 HOLD를 방출합니다.
2. 승인을 카테고리가 아닌 해시에 바인딩하십시오. 인간의 '예'는 그 해시에 서명하는 것입니다. 입력, 대상 또는 인자 중 무엇이든 변경되면 해시가 바뀌고 승인은 적용되지 않습니다.
3. 짧고 연장할 수 없는 만료 시간을 첨부하십시오. 5분에서 15분 정도면 집중적인 검토에 충분하며, 인간이 배포 카운트다운이 0에 도달하는 동안 답변을 강요받지 않을 만큼 충분히 길게 설정합니다.
4. 만료 시 폐쇄 실패(Fail closed on expiry)를 구현하십시오. 타이머가 만료되면 HOLD는 DENY로 전환됩니다. 에이전트는 여전히 동작을 원한다면 새로운 해시와 함께 신선한 요청을 다시 방출합니다.

Cirvix AgentControl은 승인을 다음과 같이 구조화합니다:

import { createHash } from "crypto";

function actionHash(action: Record<string, unknown>): string {
...

세 가지 확인 사항—승인 상태, 해시가 정확한 동작과 일치하는지 여부, 현재 시간이 아직 만료 기간 내에 있는지 여부—은 승인을 상시 자격 증명이 아닌 단일 실행을 위한 검증 가능한 티켓으로 만듭니다.

에이전트에게 변화하는 점

• 에이전트의 루프는 단순히 보류 대기열을 재시도하는 대신, 명시적인 HOLD/DENY 전환 기능을 갖게 됩니다.
• 툴 래퍼(Tool wrappers)는 실행 전에 동작 해시를 계산하고, 해당들을 승인한 해시와 일치하지 않으면 실행을 거부합니다.
• 관측 가능성(Observability)이 단순해집니다: 모든 승인 이벤트가 해시와 만료 시간을 담고 있으므로, 거부된 실행을 무엇이 승인했는지와 비교하여 어떤 필드가 벗어났는지 정확히 확인할 수 있습니다.

변하지 않는 점

인간은 여전히 검토합니다. 차이점은 그 검토가 범위가 지정된다는 것입니다: 짧은 시간, 특정 행동, 그리고 범위가 벗어날 때 명확한 실패 모드가 존재한다는 점입니다.

프롬프트 기반의 승인은 여전히 UX(사용자 경험)로서 유용합니다. 다만 그것을 경계로 삼아서는 안 됩니다. 진정한 경계는 실행 시 강제 구현 계층(enforcement layer)이 검증하는 해시 바운드(hash-bound), 시간 제한적 결정입니다.

저는 에이전트 도구 호출에 대한 오픈 소스 기본 거부 정책 계층인 Cirvix AgentControl을 구축하고 있습니다: https://github.com/CIRVIX/agent-control (사용하려면 npx @cirvix_ai/agent-control scan을 시도해 보세요).