15개 모델, 8개 공격 시나리오, 거부율 100%에서 38%까지. 텍스트만 보고 툴을 호출하는 AI 에이전트 보안이 왜 구조 문제인지, 이 수치가 먼저 드러낸다. 원문 발췌에 따르면 가장 비싼 모델도 공격의 절반만 거부했고, 가격은 20배였다고 한다. 더 강한 모델을 도입하는 것만으로 권한위임 보안이 해결되지는 않는다는 뜻이다.

세 줄 요약

• 핵심 쟁점은 이것이다. 에이전트가 검증할 수 없는 텍스트 컨텍스트를 근거로 툴 호출을 결정하면, 컨텍스트 일부를 통제한 공격자가 권한이 있는 것처럼 꾸밀 수 있다.
• 이 문제가 중요한 이유는 모델 정렬과 거부 성능의 편차가 크기 때문이다. 원문 발췌 기준으로 15개 모델의 거부율 범위가 100%에서 38%까지 벌어졌고, 고비용 모델도 공격을 절반만 막았다.
• 지금 독자가 할 일은 분명하다. 툴 실행 앞단에 별도 인가 계층을 두고, 사용자·에이전트 신원과 위임 범위를 텍스트가 아니라 검증 가능한 토큰이나 정책으로 확인하라.

현황

이 글이 다루는 출발점은 arXiv에 올라온 aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents다. 제공된 발췌에 따르면 이 연구는 AI 에이전트가 “검증할 수 없는 텍스트”를 바탕으로 툴을 호출한다는 점을 문제의 중심에 둔다. 누군가가 컨텍스트 일부를 제어하면, 권한이 있는 사용자처럼 보이는 문장을 끼워 넣어 에이전트를 움직일 수 있다는 설명이다. 이는 보안 취약점이 프롬프트 인젝션의 한 갈래에 그치지 않고, 권한 판단 자체가 텍스트에 묶여 있다는 구조 문제라는 뜻이다.

숫자도 분명하다. 원문 발췌 기준으로 평가는 15개 contemporary language models와 8개 공격 시나리오로 이뤄졌고, 완전 평가된 모델들의 거부율은 100%에서 38%까지 갈렸다. 더 눈에 띄는 대목은 가격 대비 방어력이다. 가장 비싼 모델도 공격의 절반만 거부했는데 가격은 20배였다고 발췌는 적었다. “더 비싼 모델 = 더 안전한 권한위임”이라는 가정은 그대로 두기 어렵다.

이 연구가 실무와 만나는 지점은 기존 MCP·툴 사용 패턴을 버리자는 데 있지 않다. 조사 결과에 따르면 더 직접적인 결합 방식은 MCP 서버 바깥에 별도 인가 계층을 두는 것이다. 이 계층은 각 툴 호출마다 사용자 신원, 에이전트 신원, 위임 체인, 호출 맥락을 검증한다. 관련 연구는 여기에 identity, attenuated authorization, provenance binding이 함께 필요하다고 설명한다. 쉽게 말해 “누가, 누구 대신, 어디까지, 어떤 경로로” 호출했는지를 텍스트가 아니라 증빙으로 판단하자는 얘기다.

분석

이 변화가 중요한 이유는 에이전트가 이제 채팅창 밖으로 나와 캘린더를 수정하고, 파일을 읽고, 외부 시스템을 호출하기 시작했기 때문이다. 검색형 챗봇에서 잘못된 답변은 불편으로 끝날 수 있다. 반면 툴 호출 에이전트에서 잘못된 권한 판단은 실행으로 이어진다. 권한위임을 자연어에 묶어두면, 공격자는 인증 시스템을 깨는 대신 문맥을 오염시키는 쪽을 노린다. 이때 모델의 “거부할 줄 아는가”는 보조 수단일 뿐이다. 최종 통제점으로 두기에는 한계가 있다.

그래서 오프호스트 인가가 주목된다. 조사 결과에 따르면 더 강한 보장을 노리는 설계는 툴 실행 전에 모든 호출을 가로채는 권한 검증 계층을 두는 방식이다. 이 계층은 ALLOW, DENY, REQUIRE_CONFIRM 같은 결과를 내리고, 권한은 텍스트 문장이 아니라 명시적이고 감사 가능하며 철회 가능한 형태로 표현한다. 다만 반론도 있다. 이런 구조는 시스템 복잡도를 높이고, 사용자 경험을 무겁게 만들 수 있다. 위임 체인을 촘촘히 검증할수록 통합 비용도 커진다. 또 이번 조사 결과만으로 특정 단일 구현이 업계 표준으로 굳었다고 말하기는 이르다. 설계 원칙은 비교적 분명하지만, 구현 패턴은 각 스택의 제약을 크게 탄다.

실전 적용

실서비스 팀이라면 우선순서를 바꿔야 한다. “모델이 위험한 요청을 잘 거부하는가”보다 “모델이 거부하지 못했을 때도 실행을 막는가”를 먼저 물어야 한다. 조사 결과는 LLM 가드레일을 보조 계층으로 두고, 별도 Policy Decision Point가 사용자 의도와 허용된 액션의 정합성을 검사하는 쪽에 무게를 싣는다. 여기에 구조화된 로깅도 필요하다. agent action, tool invocation, context snapshot, schema version을 변조 방지 형태로 남겨야 사후 감사가 가능하다.

예를 들어 협업 도구 에이전트가 “관리자가 허용했다”는 문장을 컨텍스트에서 읽고 결제 시스템 호출을 시도한다고 하자. 이때 안전한 구조는 모델이 그 문장을 믿는지에 기대지 않는다. 툴 앞단 인가 계층이 실제 사용자 신원, 에이전트 신원, 위임 범위, 확인 단계 요구 여부를 다시 검사한다. 맞지 않으면 차단하거나 재확인을 요구한다. 텍스트는 힌트일 뿐, 권한의 근거가 아니다.

오늘 바로 할 일 체크리스트 3개:

• 모든 툴 호출 앞에 중앙 인가 게이트를 두고 결과를 ALLOW, DENY, REQUIRE_CONFIRM처럼 결정적으로 반환하게 설계하라.
• 권한을 프롬프트 문장에 넣지 말고 사용자·에이전트 신원과 위임 범위를 담은 별도 증빙이나 정책 객체로 분리하라.
• 각 호출마다 컨텍스트 스냅샷, 호출된 툴, 입력 파라미터, 결정 결과, 정책 버전을 구조화 로그로 남기고 수정·삭제 권한을 엄격히 제한하라.

FAQ

Q. 모델 성능이 더 좋아지면 이 문제는 자연스럽게 해결됩니까?
아닙니다. 제공된 발췌만 보면 모델별 거부 성능 편차가 크고, 고비용 모델도 공격을 절반만 거부했습니다. 성능 향상은 도움이 될 수 있지만, 권한 검증을 모델 판단에만 맡기면 남는 위험이 큽니다.

Q. 기존 MCP 기반 툴 시스템을 전면 교체해야 합니까?
그럴 필요는 없어 보입니다. 조사 결과 기준으로는 MCP를 대체하기보다, MCP 바깥에 별도 인가 계층을 붙여 각 툴 호출의 신원, 위임 체인, 맥락을 검증하는 방식이 더 직접적입니다.

Q. 로그는 어디까지 남겨야 합니까?
검색 결과 기준으로는 agent action, tool invocation, context snapshot, schema version 같은 실행 맥락을 구조화하고 변조 방지되게 남기는 접근이 적절합니다. 다만 어떤 프롬프트 조각까지 저장할지는 서비스의 개인정보·보안 요구에 맞춰 따로 정해야 합니다.

결론

에이전트 보안의 핵심은 “모델이 속지 않게 만들기”가 아니라 “속아도 실행되지 않게 만들기”다. 텍스트 컨텍스트 기반 권한 판단에서 벗어나, 신원 결합형 인가와 독립된 정책 집행 계층을 어디까지 현실적인 비용으로 붙일 수 있는지가 다음 경쟁 포인트다.

다음으로 읽기

• AI 대화와 게임의 경계
• AI 자료 모음 (24h) - 2026-07-08
• DiLoCo 집계, 평균이 최선일까
• 에이전트가 빠를수록 배움은 줄까
• AI 데이터 경로별 통제

참고 자료

• A practical guide to building agents | OpenAI - openai.com
• Running Codex safely at OpenAI | OpenAI - openai.com
• NIST SP 800-171 Rev. 3 - nvlpubs.nist.gov
• AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A - arxiv.org
• AgentBound: Verifiable Behavioral Governance for Autonomous AI Agents - arxiv.org
• Digital Identity for Agentic Systems: Toward a Portable Authorization Standard for Autonomous Agents - arxiv.org
• arxiv.org - arxiv.org