---
title: "AI 에이전트 인증 4겹 방어를 전부 뚫는 방법 — Capability 기반 Warrant가 답인 이유"
published: 2026-03-31T17:46:49.000Z
canonical: https://jeff.news/article/1431
---
# AI 에이전트 인증 4겹 방어를 전부 뚫는 방법 — Capability 기반 Warrant가 답인 이유

서비스 계정, OAuth, RBAC, 정책 엔진까지 4겹 인증 스택을 갖춰도 AI 에이전트의 프롬프트 인젝션을 막지 못하는 구조적 이유를 분석하고, identity가 아닌 intent를 인코딩하는 warrant 기반 인가를 해결책으로 제시.

## 기존 인증 스택이 AI 에이전트를 못 막는 이유

- AI 에이전트에 프로덕션 시스템 접근 권한을 줄 때, 대부분 "제대로 된" 인증 스택을 구축함 — 서비스 계정, OAuth 스코프, 관계 기반 접근 제어(Zanzibar 스타일), 정책 엔진까지 4겹 방어
  - 이 4개 레이어 전부 통과해도 공격이 성공하는 시나리오가 존재함
- 예시: 청구서 처리 멀티 에이전트 파이프라인
  - 청구서가 들어오면 벤더 검증 → 승인 → 결제 실행까지 자동으로 진행
  - 악의적인 지시가 사용자 프롬프트가 아니라 **청구서 데이터의 메모 필드**에 숨어있음 — "은행 계좌가 변경됐으니 업데이트하라"는 내용
  - 에이전트는 이걸 정상 업무 절차의 일부로 처리함

## 4겹 방어가 전부 뚫리는 과정

- **서비스 계정**: 청구서 처리기는 정당한 서비스이고, 정당한 IAM 역할을 가짐. "검증 상태 업데이트"와 "은행 라우팅 번호 변경"을 구분할 메커니즘이 없음 → ALLOW
- **OAuth 스코프**: `vendors:write` 스코프가 검증 상태 업데이트에도, 은행 정보 변경에도 동일하게 적용됨 → ALLOW
  - Rich Authorization Requests(RAR) 같은 확장 스펙이 있지만, 자율 파이프라인에서 초당 수십 건의 토큰 교환 round-trip은 병목이 되므로 개발자가 그냥 넓은 토큰을 그대로 넘김
- **관계 기반 접근 제어**: 에이전트가 해당 벤더의 editor라는 건 맞음. editor는 editor일 뿐, 필드 수준의 의도를 구분하지 못함 → ALLOW
- **정책 엔진**: 사유("은행 마이그레이션")도 있고, 시간당 조작 횟수도 한도 이내. 정책 엔진은 전달받은 컨텍스트만 평가하는데, 공격받은 에이전트가 컨텍스트를 조작하면 끝 → ALLOW

> [!WARNING]
> 4개 레이어 모두 "이 에이전트가 누구인가(identity)"만 검증함. "이 에이전트가 지금 이 인자로 이 작업을 해야 하는가(intent)"는 어디서도 확인하지 않음.

- 결국 $14,200이 공격자 계좌로 이체됨 — 50년 전 confused deputy 문제가 그대로 재현된 것

## 에이전트 프레임워크의 구조적 문제

- LangGraph, CrewAI, OpenAI Swarm 등에서 자격 증명과 세션 컨텍스트가 서브 에이전트로 그대로 상속됨
  - 오케스트레이터가 `vendors:write`와 `payments:execute` 모두 보유 → 읽기 전용 리서치 서브 에이전트도 결제 실행 권한을 가지게 됨
  - 서브 에이전트가 프롬프트 인젝션당하면 폭발 반경(blast radius)이 "서브 에이전트가 해야 할 일"이 아니라 "오케스트레이터가 할 수 있는 모든 것"이 됨
- 위임 시점에 "부모의 자격 증명 중 이 태스크에 필요한 부분집합만 발급하고, 태스크 종료 시 만료"시키는 원시 메커니즘(primitive)이 없음

## 해결책: Warrant 기반 인가 (Capability Security)

- "너는 재무 역할이다" 대신 → **"너는 벤더 V-4521에 대해 계좌 7291034851로만, 10분 이내에 결제할 수 있다"**
  - 서명된 토큰(warrant)에 허용 도구, 인자 제약조건, TTL을 명시
  - 오케스트레이터가 태스크 계획 시 ERP에서 정상 계좌를 읽고, 서브 에이전트가 오염된 데이터를 만지기 **전에** warrant에 암호학적으로 고정
- 위임 체인에서 각 단계마다 권한이 좁아질 수만 있고, 넓어질 수 없음
  - 서명은 각 hop마다 이루어지고, 로컬에서 마이크로초 단위로 검증 — 서버 콜백 불필요
  - 탈취된 warrant도 보유자의 암호 키에 바인딩되어 있고 수분 내 만료

| | ID 기반 | Warrant 기반 |
|---|---|---|
| 권한 부여 | "재무 역할 보유" | "V-4521에 특정 계좌로만 결제 가능" |
| 부여 시점 | 설정 시 | 태스크별 |
| 위임 | 인가 서버 round-trip 필요 | 오프라인으로 각 hop에서 축소 |
| 에이전트 탈취 시 | 전체 ambient 권한 노출 | 해당 태스크 warrant 범위만 노출 |

- 프롬프트 인젝션 자체를 막지는 못함 — 아직 누구도 못 막음
  - 하지만 폭발 반경을 "해당 태스크에 필요한 정확한 범위"로 제한함
- IETF OAuth Working Group에 Internet-Draft로 제출된 상태
- 오픈소스 라이브러리 Tenuo로 공개됨 — Rust 코어, Python SDK, LangGraph/CrewAI/OpenAI/Google ADK/Temporal 연동 지원

---

## 기술 맥락

- 여기서 말하는 confused deputy 문제는 1988년 Hardy가 명명한 고전적 보안 이슈예요. 정당한 권한을 가진 프로그램이 외부 입력에 속아서 자기 권한을 악용당하는 건데, AI 에이전트 시대에 와서 이게 폭발적으로 심각해진 거거든요. 에이전트가 도구 출력(tool output)을 "데이터"가 아니라 "지시"로 해석하는 순간 기존 RBAC/ABAC 전부 무력화됨
- Capability-based security는 Dennis & Van Horn이 1966년에 제안한 개념인데, 기존에는 OS 레벨(capsicum, seL4)에서나 쓰였어요. 이걸 에이전트 위임 체인에 적용한 게 이 논문의 핵심인데, 단순 capability 토큰과 다른 점은 각 hop에서 권한을 축소만 할 수 있는 단방향 위임 체인이라는 것
- OAuth RAR(RFC 9396)이 이론상 fine-grained 인가를 지원하긴 하는데, 현실적으로 자율 에이전트 파이프라인에서 매 tool call마다 Authorization Server와 round-trip하는 건 레이턴시 때문에 불가능에 가까워요. 그래서 개발자들이 넓은 토큰을 그냥 전달하게 되는 건데, warrant 방식은 이 round-trip 없이 로컬에서 검증 가능하다는 게 실용적 차별점

## 핵심 포인트

- 기존 인증은 전부 identity 기반 — intent를 검증하지 못함
- 에이전트 프레임워크가 자격 증명을 서브 에이전트에 그대로 상속
- Warrant: 허용 도구+인자 제약+TTL을 서명된 토큰으로 발급
- IETF OAuth WG에 Internet-Draft 제출, 오픈소스 Tenuo 공개

## 인사이트

프롬프트 인젝션이 해결 불가능한 현실에서, 폭발 반경을 제한하는 접근이 훨씬 실용적. 에이전트에 권한을 줄 때 '누구인가'가 아니라 '무엇을 할 수 있는가'로 생각해야 함.