AI 에이전트의 '승인된 조작'이 변조·이탈되는 Authorization-Execution Gap 공격 리스크와 안전한 실행

• AI 에이전트에서의 **Authorization-Execution Gap (승인-실행 갭)**이란 무엇인가 - 승인된 조작이 실행되기 사이에 변조·이탈되는
• 4가지 공격 패턴 - 기존 보안 개념인 「TOCTOU」와의 관계와 AI 에이전트 고유의 리스크
• **Execution Integrity (실행 완전성)**를 검증하는 실천적인 설계 패턴 - PreToolUse / PostToolUse 후크를 활용한 구현 예시

AI 에이전트에게 도구(Tool) 사용을 허가한다. 데이터베이스에 대한 읽기 액세스를 승인한다. 파일 편집을 승인한다——이러한 「승인(Authorization)」은 AI 에이전트를 안전하게 운용하기 위한 기본적인 제어입니다.

하지만, 「승인한 조작」과 「실제로 실행되는 조작」이 정말로 일치하는지 당신은 검증하고 있습니까?

기존 보안에서는 권한 체크와 조작 실행 사이에 시간 차가 있을 때 발생하는 취약성을 **TOCTOU (Time-of-Check to Time-of-Use)**라고 부릅니다. AI 에이전트의 세계에서는 이 문제가 더욱 복잡한 형태로 현상화되고 있습니다. 사용자가 「이 조작을 허가합니다」라고 버튼을 누른 순간과 에이전트가 실제로 도구를 호출하는 순간 사이에는, 도구 정의의 동적 변경, 파라미터(Parameter)의 개변, 컨텍스트(Context) 오염과 같은 개입의 여지가 있습니다.

본 기사에서는 이 「승인」과 「실행」 사이에 잠재된 갭을 **Authorization-Execution Gap (승인-실행 갭)**으로 체계화하고, 실행 완전성 (Execution Integrity)을 검증하기 위한 설계 패턴을 해설합니다.

TOCTOU는 「조건을 확인한 시점」과 「그 조건에 기반하여 조작을 실행하는 시점」 사이에 타임랙(Time lag)이 있을 경우, 그 사이에 조건이 변경되어 버리는 취약성입니다.

친숙한 예로 설명하겠습니다. 영화관에서 연령 확인(Check)을 하고 티켓을 구매한 뒤, 상영 시작까지 30분의 대기 시간이 있는 경우, 그 사이에 티켓을 다른 사람에게 넘겨줄 수 있습니다. 「연령 확인 완료」라는 체크 결과와 「영화를 관람함」이라는 실행이 분리되어 있기 때문에 발생하는 문제입니다.

AI 에이전트의 대부분은 다음과 같은 승인 메커니즘을 가지고 있습니다.

승인 레벨	설명	예
도구 단위의 승인	특정 도구의 사용을 허가/거부함	「Bash 도구 실행을 허가하시겠습니까?」
...
이것들은 모두 「체크 시점」의 정보에 기반하여 판단합니다. 하지만 AI 에이전트의 실행 환경에서는 체크와 실행 사이에 많은 개입 포인트가 존재합니다.

Rug Pull은 MCP (Model Context Protocol) 환경에서 특히 심각한 공격입니다. 최초 승인 시에는 무해한 도구 정의를 제시하고, 승인 후에 정의를 동적으로 변경합니다.

이 공격은 MCP 클라이언트가 도구 정의를 캐시(Cache)하지 않고 매번 서버로부터 가져올 경우 성립합니다. 사용자는 「안전한 계산 도구」를 승인했다고 생각하지만, 실제로는 개변된 「데이터 탈취 도구」가 실행됩니다.

도구 자체는 정당하게 승인되었더라도, 호출 시의 파라미터가 승인 시의 의도와 다른 케이스입니다.

// 사용자가 승인한 의도: 프로젝트 설정 파일을 읽음
// 승인 메시지: "read_file 도구 사용을 허가하시겠습니까?"
// 사용자의 인식: "설정 파일을 읽는구나, OK"
...

여기서의 문제는 승인이 「도구 단위」로 이루어지며, 「파라미터 단위」로는 이루어지지 않는다는 점입니다. read_file 사용을 허가한 시점에서 에이전트는 어떤 파일이든 읽을 수 있게 됩니다. 이는 「자동차 운전을 허가한 것」이 「어디든 가도 좋다」를 의미하게 되는 것과 같습니다.

승인 시점에는 에이전트의 의도가 정당하더라도, 승인 후에 컨텍스트가 오염되어 실행 시의 의도가 바뀌는 패턴입니다.

이 공격의 특징은 승인 메커니즘 자체는 정상적으로 기능하고 있다는 점입니다. 사용자는 write_file을 허가하고, 에이전트는 write_file을 실행합니다. 하지만, 「무엇을」 쓰느냐가 승인 시의 의도와 다릅니다.

여러 단계에 걸친 태스크에서 각 단계는 정당해 보이지만, 전체로서 승인된 범위를 초과하는 패턴입니다.

개별 조작은 '파일 읽기(File Read)', 'HTTP 통신(HTTP Communication)', '파일 쓰기(File Write)'와 같이 각각 단독으로는 무해해 보입니다. 하지만 이 세 가지를 조합하면 데이터의 외부 유출이 성립됩니다. 각 단계를 개별적으로 승인하는 메커니즘으로는 이러한 복합적인 위협을 탐지할 수 없습니다.

Execution Integrity(실행 완전성)는 **'인가된 조작이, 인가된 대로, 인가된 범위 내에서 실행되는 것을 검증하는 설계 원칙'**입니다.

기존의 인가(Authorization) 모델이 '체크 시점'의 정적인 판단인 반면, Execution Integrity는 '체크 → 실행 → 검증'의 라이프사이클 전체를 커버합니다.

Rug Pull 공격에 대한 대책으로, 툴 정의(Tool Definition)를 승인 시점에 고정하고, 실행 시점에 변경이 없는지 검증합니다.

import hashlib
import json
class ToolDefinitionPinner:
...

툴 단위가 아니라, 파라미터(Parameter)의 허용 범위를 사전에 정의하여 실행 시점에 이탈을 탐지합니다.

from dataclasses import dataclass
@dataclass
class ParameterBoundary:
...

개별 툴 호출이 아니라, 일련의 조작을 체인(Chain)으로서 평가하여 복합적인 데이터 유출 패턴을 탐지합니다.

from collections import deque
from dataclasses import dataclass, field
@dataclass
...

Claude Code의 Hooks 시스템처럼, 툴 실행 전후에 인터셉트 포인트(Intercept Point)를 마련하여 실시간으로 검증합니다.

{
"hooks": {
"PreToolUse": [
...

PreToolUse 훅의 구현 예시입니다.

#!/bin/bash
# .claude/hooks/verify-execution-integrity.sh
# 툴 실행 전에 파라미터의 타당성을 검증한다
...

실제 프로젝트에서 Execution Integrity를 도입할 때의 체크리스트입니다.

카테カテゴリ	체크 항목	대응 패턴
툴 정의	승인 시의 툴 정의를 해시(Hash)로 기록하고 있는가	패턴 1
...	패턴 2
조작 체인	읽기 → 외부 전송의 체인을 감시하고 있는가	패턴 3
조작 체인	조작 빈도 이상(단시간 내 대량 읽기 등)을 탐지하고 있는가	패턴 3
훅 (Hook)	실행 전 검증 훅을 설정하고 있는가	패턴 4
...

"read_file 사용을 허용하시겠습니까?"라는 질문에 '허용'을 선택한 시점에서, 에이전트는 프로젝트 내의 어떤 파일이든 읽을 수 있게 됩니다. 이는 read_file이라는 툴에 대한 인가이지, '프로젝트 설정을 읽는다'라는 조작에 대한 인가가 아닙니다.

대책: 가능하다면 파라미터 제약이 포함된 승인(per-invocation approval)을 검토하십시오. Claude Code의 Hooks 중 PreToolUse 훅을 통해 파라미터를 검증하는 방법이 현실적입니다.

한 번 허용한 조작이 세션 전체에 걸쳐 유효하게 유지되는 것도 문제입니다. 세션 시작 시 허용한 툴이 몇 시간 후의 다른 컨텍스트에서도 동일한 권한으로 실행됩니다.

대책: 인가에 TTL(Time To Live, 유효 기간)을 설정하여, 일정 시간이 경과한 후에는 재승인을 요구하는 메커니즘을 구축하십시오.

실행 전 검증(PreToolUse)만으로는 불충분합니다. 실행 결과가 의도와 다르거나, 실행 자체는 정당하더라도 결과가 예상 밖인 경우가 있습니다.

대책: PostToolUse 훅을 통해 실행 결과를 감사(Audit)하고, 이상이 탐지될 경우 사용자에게 알림을 보내는 메커니즘을 마련하십시오.

Execution Integrity는 단독으로는 만능 해결책(Silver Bullet)이 될 수 없습니다. 기존의 인가 제어(최소 권한, 스코프 제한), 입력 검증(프롬프트 인젝션 방지), 출력 필터링과 결합했을 때 비로소 효과를 발휘합니다.

AI 에이전트의 '인가'는 기존의 액세스 제어(Access Control)와는 다른 구조적인 과제를 안고 있습니다.

• Authorization-Execution Gap은 인가된 조작이 실행되기 전 사이에 변조 또는 이탈되는 리스크를 의미합니다 - 이 문제는 Rug Pull (툴 정의 변경), 파라미터 변조 (Parameter Manipulation), 컨텍스트 오염 (Context Contamination), **조작 체인 악용 (Operation Chain Exploitation)**의 4가지 패턴으로 나타납니다 - 대책으로는 인가 라이프사이클에 Execution Integrity (실행 완전성) 검증을 통합해야 합니다 - 구체적으로는 툴 정의의 해시 검증, 파라미터 경계 (Parameter Boundary), 조작 체인 분석, Pre/Post 후크 (Hook)의 4가지 설계 패턴이 유효합니다

AI 에이전트가 자율성을 높일수록, "인가했으니 안전하다"라는 전제는 무너집니다. "신뢰하되, 검증하라 (Trust, but verify)" —— 이 원칙을 인가 메커니즘 자체에 내재화하는 것이 안전한 AI 에이전트 운영의 핵심입니다.