[Responsible AI (RAI)] 프롬프트 인젝션보다 중요한 ‘권한 기반 Agent Security’

지난 8월 31일 Anthropic이 꽤 섬뜩한 업데이트를 공개했다. 평가 환경의 설정 오류로 인터넷이 열렸고, Claude 모델 3개가 실제 컴퓨터 시스템에 무단 접근했다는 내용이다. 이 사건에서 더 중요한 건 “모델이 갑자기 악해졌다”가 아니다. 샌드박스 경계를 단일 설정에 의존한 순간, 모델의 추론 능력이 그대로 공격 표면이 됐다는 점이다.

오늘의 한 줄 결론
프롬프트 인젝션 방어의 KPI는 “모델이 거절했는가”가 아니라 “승인되지 않은 부수 효과(side effect)가 실제로 발생했는가”여야 한다.

이미지 출처: Google DeepMind, Securing the future of AI agents

AI Firewall만 세우면 된다는 착각

초기의 공격은 “이전 지시를 무시해” 같은 노골적인 문자열이었다. 지금은 다르다. 정상적인 이메일, 사내 문서, 검색 결과처럼 보이는 콘텐츠 안에 권한 주장과 업무 맥락을 섞는다. OpenAI도 최신 공격을 단순 문자열 해킹보다 에이전트를 상대로 한 사회공학에 가깝다고 설명한다.

그래서 입력 앞단에 분류기 하나를 두는 방식만으로는 부족하다. 거짓 승인 문구와 진짜 승인 문구를 구분하려면 문장 표면이 아니라 신원, 위임 범위, 목적, 목적지까지 알아야 하기 때문이다.

• Source: 이메일, PDF, 검색 결과, RAG 청크처럼 공격자가 오염시킬 수 있는 입력
• Sink: 고객정보 조회, 외부 전송, 계약 변경, 결제처럼 잘못 호출되면 사고가 되는 기능

핵심 통제 지점은 Source를 완벽히 정화하는 곳이 아니라, Source가 위험한 Sink에 연결되는 경계다.

의외의 구멍: 에이전트가 “한 번만 더 알려주세요”라고 할 때

2026년 ASPI 연구는 728개의 태스크-공격 시나리오와 10개 프런티어 모델을 비교했다. 에이전트가 명확한 지시를 바로 실행할 때보다, 모호함을 해소하기 위해 추가 질문을 한 뒤 실행할 때 공격 성공률이 크게 올랐다.

모델	일반 실행	추가 확인 상태
o3	1.8%	34.0%
Gemini-3-Flash	2.2%	35.7%

연구진은 이를 모델의 상태 변화와 clarification 인터페이스의 채널 효과가 함께 만든 결과로 분석한다. 실무적으로는 상담 에이전트가 “계약번호를 다시 입력해 주세요”라고 되묻는 순간도 별도 보안 상태로 테스트해야 한다는 뜻이다. 친절한 UX가 새로운 trust boundary가 될 수 있다.

모델을 더 강하게 만들면 해결될까?

도움은 된다. OpenAI의 자동 레드팀 모델 GPT-Red는 미지의 간접 프롬프트 인젝션 환경에서 사람 레드팀의 13%보다 높은 84%의 공격 성공률을 기록했다. 이 공격 데이터를 학습에 사용한 뒤 GPT-5.6은 가장 어려운 직접 인젝션 벤치마크에서 이전 프로덕션 모델보다 실패가 6배 줄었다.

하지만 이건 첫 번째 방어층이지 권한 통제를 대체하지 않는다. 아무리 교육을 잘 받은 직원도 결재 한도와 접근 권한 없이 금융 시스템에 투입하지 않는 것과 같다.

금융권 에이전트의 권장 구조

① Intent Plane
인증 세션 · 사용자 목적 · 데이터 등급

↓

② Untrusted Context Plane
RAG · 이메일 · PDF · Tool output

↓

③ LLM Planner
계획만 생성, 비밀키와 직접 네트워크 권한은 없음

↓

④ Deterministic Policy Gate
RBAC/ABAC · 파라미터 검증 · 승인 · 전송 목적지 검사

↓

Read Tools
검색 · 조회 · 요약

Action Tools
변경 · 전송 · 결제

Audit + Egress DLP + Kill Switch

포인트는 LLM이 스스로 “나는 권한이 있다”고 선언할 수 없게 만드는 것이다. 권한은 모델의 JSON이 아니라 인증된 세션과 정책 저장소에서 가져와야 한다.

from dataclasses import dataclass
from typing import Literal

@dataclass(frozen=True)
class ToolCall:
    tool: str
    action: Literal["read", "write", "send"]
    destination: str | None = None

def authorize(call: ToolCall, session) -> str:
    # allowed_tools와 confirmation_id는 LLM 출력이 아니라
    # 인증 세션/정책 저장소에서 주입한다.
    if call.tool not in session.allowed_tools:
        return "DENY_TOOL"

    if call.action != "read" and not session.confirmation_id:
        return "REQUIRE_HUMAN_APPROVAL"

    if (call.destination and
            call.destination not in session.egress_allowlist):
        return "DENY_EGRESS"

    return "ALLOW"

폐쇄망·금융권에서는 이렇게 바꾸면 된다

1. RAG 문서는 전부 untrusted data로 취급: 검색된 청크를 system instruction으로 승격하지 않고, 출처·문서등급·소유부서를 함께 전달한다.
2. 자유형 SQL과 자유형 HTTP 제거: 파라미터가 고정된 stored procedure, row-level security, 목적지 allowlist를 Tool Gateway에서 강제한다.
3. Read와 Action 권한 분리: 조회 에이전트가 계약 변경이나 외부 전송 도구까지 볼 이유는 없다. Managed Identity도 도구별·업무별로 쪼갠다.
4. 평가 지표 변경: refusal rate보다 unauthorized tool call rate, confirmation bypass rate, sensitive egress bytes를 본다.
5. 레드팀을 CI에 편입: 악성 문구를 PDF·FAQ·이메일·도구 응답에 심고, 모델이 속았는지가 아니라 정책 게이트가 실제 실행을 막았는지 검증한다.

에이전트에게 “절대 속지 마”라고만 교육하고 고객정보 조회와 계약 변경 권한을 통째로 주는 건, 신입사원에게 피싱 교육 한 번 하고 법인 인감까지 맡기는 것과 비슷하다. 모델 교육은 필요하지만, 진짜 보안은 권한·결재선·로그에서 나온다.

참고자료

• Anthropic — Improving our alignment and security efforts (2026.08.31)
• OpenAI — Designing AI agents to resist prompt injection
• OpenAI — GPT-Red: Unlocking Self-Improvement for Robustness
• ASPI — Seeking Ambiguity Clarification Amplifies Prompt Injection Vulnerability
• AI Agents May Always Fall for Prompt Injections
• Google DeepMind — Securing the future of AI agents