0클릭 AI 공격: 간접 프롬프트 주입이 AI 에이전트를 장악하는 방식
요약
본 글은 공격자가 AI 인터페이스에 직접 접근하지 않고도 문서, 이메일 등 간접적인 콘텐츠를 통해 에이전트를 장악하는 '0클릭 AI 공격'의 위험성을 경고합니다. 핵심 방어 전략으로 데이터 출처(provenance)와 무결성 상태를 메타데이터로 관리하고 신뢰 전파 계층을 구축해야 한다고 제안합니다.
핵심 포인트
- 신뢰는 단순한 프롬프트가 아닌, 출처 및 무결성을 가진 메타데이터여야 합니다.
- 에이전트는 자격 증명과 연결성 때문에 일반 챗봇보다 훨씬 위험하며, 공격의 표적이 됩니다.
- 방어는 모든 것을 '안전하게' 만드는 것이 아니라, 신뢰할 수 없는 콘텐츠가 무엇에 영향을 미치도록 통제하는 데 초점을 맞춰야 합니다.
description: "공격자가 AI 인터페이스에 전혀 접근하지 않고도 어떻게 AI 에이전트를 손상시킬 수 있는지—문서, 이메일, 웹페이지, RAG 콘텐츠 및 도구 응답 내부에 지침을 숨김으로써."
신뢰 전파 계층 (The Trust Propagation Layer)
0클릭 공격에서 결정적인 실패는 단순히 LLM이 '악성 프롬프트를 따른다'는 것이 아닙니다. 그것은 신뢰할 수 없는 데이터가 신뢰 경계를 넘나들고 실행 결정에 영향을 미치도록 허용된다는 것입니다.
일반적인 에이전트 파이프라인에서 흐름은 다음과 같을 수 있습니다:
external content → retrieval → model context → plan → tool call → downstream service
만약 시스템이 모든 컨텍스트 항목을 동등하게 취급한다면, 이메일, 문서, 웹페이지 또는 도구 응답에 포함된 악성 지침은 합법적인 작업 지침과 구별할 수 없게 됩니다.
따라서 더 강력한 아키텍처는 신뢰를 데이터와 함께 전파되는 메타데이터로 취급합니다. 콘텐츠는 trusted, untrusted 또는 tainted와 같은 출처(provenance) 및 무결성 상태를 가져야 하며; 기밀도 범위(confidentiality scope) 역시 그것과 함께 이동해야 합니다. 그리고 이러한 레이블은 검색 구성 요소, 모델, 에이전트 및 도구 사이에서 정보가 이동하는 동안 첨부된 채로 남아 있어야 합니다.
고위험 도구가 실행되기 전에, 시스템은 에이전트가 무엇을 하기를 원하는지뿐만 아니라, 지침이 어디서 왔는지, 신뢰할 수 없는 콘텐츠가 결정에 영향을 미쳤는지, 해당 조치가 현재 작업에 맞는지, 그리고 요청된 리소스가 호출자의 권한 범위 내에 있는지 등을 평가할 수 있습니다.
핵심 아키텍처 아이디어는 간단합니다:
모델은 행동을 제안할 수 있지만, 신뢰할 수 없는 콘텐츠가 그 행동을 승인할 권한을 절대 상속받아서는 안 됩니다.
이것은 보안을 모든 문서를 '안전하게' 만들려고 노력하는 것에서 벗어나, 신뢰할 수 없는 문서가 무엇에 영향을 미치도록 허용할지 통제하는 쪽으로 이동시키기 때문에 중요한 구분점입니다.
에이전트가 새로운 신뢰 증폭기 (The Agent Is the New Trust Amplifier)
일반적인 챗봇은 잘못된 답변을 생성할 수 있습니다.
자율 에이전트는 나쁜 결과를 초래할 수 있습니다.
그 차이는 엄청납니다.
만약 손상된 에이전트가 다음 사항에 접근할 수 있다고 가정해 봅시다:
만약 손상된 에이전트가 다음 사항에 접근할 수 있다고 가정해 봅시다:
- CRM 기록(records)
- 내부 문서(Internal documents)
- 데이터베이스(Databases)
- 클라우드 API(Cloud APIs)
- 티케팅 시스템(Ticketing systems)
- 파일 저장소(File storage)
- 외부 웹 서비스(External web services)
공격자는 각 시스템을 개별적으로 악용할 필요가 없습니다.
단지 에이전트의 의사결정 과정에 한 번만 영향을 주면 됩니다.
에이전트는 이미 자격 증명(credentials)을 가지고 있습니다.
에이전트는 이미 연결성(connectivity)을 가지고 있습니다.
에이전트는 이미 워크플로우(workflow)를 가지고 있습니다.
에이전트는 기계 속도(machine speed)로 행동을 수행할 수 있습니다.
이는 위험한 방정식을 만듭니다:
Untrusted content
+
Autonomous reasoning
...
이러한 일이 발생하기 위해 모델 자체가 '악의적'일 필요는 없습니다.
모든 구성 요소가 설계된 대로 정확하게 기능하는 동안에도 시스템은 실패할 수 있습니다.
다중 에이전트 문제(The Multi-Agent Problem)
여러 에이전트가 협력할 때 위험은 더욱 커집니다.
다음과 같이 상상해 보세요:
Orchestrator
↓
Research Agent
...
첫 번째 에이전트는 공격자가 통제하는 문서를 읽습니다.
두 번째 에이전트는 그 요약본을 받습니다.
세 번째 에이전트는 두 번째 에이전트를 신뢰하고 도구 호출(tool call)을 실행합니다.
공격자는 다운스트림 시스템 중 어느 것도 직접적으로 제어하지 않으면서 효과적으로 여러 보안 경계를 넘나들었습니다.
이는 신뢰 전파(trust propagation) 또는 **연쇄 실패(cascade failure)**의 한 형태입니다.
원래의 악성 콘텐츠는 보이는 대화에서 사라질 수 있지만, 그 영향력은 요약본, 계획, 구조화된 출력(structured outputs), 메모리, 또는 도구 매개변수(tool parameters)를 통해 살아남을 수 있습니다.
이것이 복잡한 에이전트 시스템에 단일 에이전트, 단일 턴 보안 테스트가 불충분한 이유입니다.
시스템은 진입점에서는 안전해 보이지만 여전히 여러 단계 떨어진 다운스트림에서 취약할 수 있습니다.
실제 사례: EchoLeak 유형의 공격(The EchoLeak Class of Attack)
광범위한 업계는 간접 프롬프트 주입이 심각하게 주의를 기울여야 할 이유를 이미 목격했습니다.
Microsoft가 공개한 **EchoLeak (CVE-2025-32711)**은 공격자가 통제하는 콘텐츠가 기존의 직접적인 프롬프트를 통해서가 아니라, 어시스턴트가 처리한 콘텐츠를 통해 AI 비서에 영향을 줄 수 있는 실제 유형의 공격을 입증했습니다.
중요한 교훈은 특정 개별 제품이나 CVE(Common Vulnerabilities and Exposures)보다 더 광범위합니다.
AI 비서들은 사용자들을 대신하여 점점 더 많은 작업을 수행하고 있습니다.
그것들은 읽습니다.
그것들은 검색합니다. (retrieve).
그것들은 요약합니다.
그것들은 탐색합니다. (search).
그것들은 도구를 호출합니다. (call tools).
그것들은 행동합니다. (act).
이러한 자율성이 확장됨에 따라, 보안 경계는 모델 인터페이스에서 에이전트가 소비하는 전체 정보 생태계로 바깥쪽으로 이동하고 있습니다.
기존 통제만으로는 충분하지 않은 이유
이것이 WAF(Web Application Firewall), API 게이트웨이, 엔드포인트 보안 또는 ID(Identity) 제어가 쓸모없다는 의미는 아닙니다.
그들은 여전히 필수적입니다.
문제는 그것들이 서로 다른 계층을 보호한다는 것입니다.
WAF는 다음을 볼 수 있습니다:
POST /api/agent
ID 시스템은 다음을 볼 수 있습니다:
Agent: authenticated
API 게이트웨이는 다음을 볼 수 있습니다:
Tool request: authorized
하지만 AI 보안 제어는 다른 질문에 답해야 합니다:
왜 에이전트가 그 도구 요청을 하도록 결정했는가?
그 행동은 사용자에 의해 촉발되었는가?
신뢰할 수 있는 워크플로우(workflow)에 의해?
검색된 문서에 의해?
웹 페이지에 의해?
또 다른 에이전트에 의해?
신뢰할 수 없는 도구 응답에 의해?
이러한 구별점들이 중요합니다.
제어 평면(control plane)은 누가 호출했는지(who)뿐만 아니라, 무엇이 그 호출에 영향을 미쳤는지(what influenced the call)를 이해해야 합니다.
보안 경계는 데이터의 흐름을 따라야 한다
견고한 아키텍처는 출처(provenance)를 보안 상태의 일부로 취급합니다.
여기에는 다음이 포함될 수 있습니다:
Source
↓
Trust classification
...
중요한 원칙은 모델 자체가 최종 권위자가 되어서는 안 된다는 것입니다.
모델은 추론할 수 있습니다.
모델은 요약할 수 있습니다.
모델은 제안할 수 있습니다.
하지만 정책 계층(policy layer)이 고영향성 행동(high-impact action)이 허용되는지 결정해야 합니다.
이는 다음을 포함하는 행동에 특히 중요해집니다:
- 민감한 기록 (Sensitive records)
- 자격 증명 시스템 (Credentialed systems)
- 외부 통신 (External communication)
- 금융 운영 (Financial operations)
- 파괴적인 데이터베이스 작업 (Destructive database actions)
- 크로스 테넌트 데이터 (Cross-tenant data)
- 권한 변경 (Privilege changes)
- 대량 내보내기 (Bulk exports)
행동이 더 중대한 경우, 권한 부여가 오직 자연어 문맥에서 추론되는 것은 덜 허용 가능합니다.
방어자가 테스트해야 할 것들
가장 유용한 질문은 다음과 같지 않습니다:
"내 모델이 '이전 지침을 무시하라'는 프롬프트를 저항할 수 있는가?"
이는 단 하나의 테스트일 뿐입니다.
현대적인 AI 보안 평가는 다음 질문을 던져야 합니다:
공격자가 통제하는 콘텐츠가 에이전트에 영향을 미칠 수 있는가?
테스트 문서, 이메일, 웹 페이지, RAG 청크, 도구 응답, 메모리 항목, 그리고 에이전트 간 메시지를 테스트해야 합니다.
그러한 영향력이 여러 단계를 거쳐 지속될 수 있는가?
고립된 프롬프트보다는 다중 턴(multi-turn) 및 다중 에이전트 워크플로우를 테스트해야 합니다.
결과로 도출된 계획이 실제 도구를 트리거할 수 있는가?
추론(reasoning)과 실행(execution) 사이의 경계를 테스트해야 합니다.
에이전트가 접근해서는 안 되는 데이터에 접근할 수 있는가?
신원(identity), 테넌시(tenancy), 그리고 리소스 권한 부여를 테스트해야 합니다.
신뢰할 수 없는 출처가 시스템 외부로 데이터를 유출하게 만들 수 있는가?
아웃바운드 이메일, API, 파일 전송, 웹 요청 및 기타 데이터 유출 경로(exfiltration paths)를 테스트해야 합니다.
하나의 손상된 에이전트가 다른 에이전트에 영향을 미칠 수 있는가?
에이전트 그래프 전체에 걸친 정보 흐름과 신뢰 전파(trust propagation)를 테스트해야 합니다.
그리고 마지막으로:
공격이 성공했을 때 무슨 일이 발생하는가?
포함 방지(containment) 없이 감지만 하는 것은 충분하지 않습니다.
고위험 시스템은 동작이 정의된 보안 경계를 넘어서는 경우 실행을 중단하거나 제한하는 메커니즘이 필요합니다.
AI 보안의 더 큰 변화 (The Bigger Shift in AI Security)
0클릭 AI 공격은 애플리케이션 보안의 근본적인 변화를 노출하기 때문에 중요합니다.
전통적인 보안 질문은 다음과 같습니다:
"공격자가 시스템에 침투할 수 있는가?"
자율형 AI(autonomous AI)에게는 또 다른 질문이 중요해집니다:
"공격자가 시스템이 행동하도록 충분히 오랫동안 믿게 만들 만큼 영향을 미칠 수 있는가?"
이는 매우 다른 문제입니다.
공격자는 자격 증명(credentials)을 얻지 못할 수도 있습니다.
모델에 직접 도달하지 못할 수도 있습니다.
메모리 손상 버그를 악용하지 못할 수도 있습니다.
단순히 올바른 지침을 올바른 문서에 배치하고 자율 시스템이 그것을 읽기를 기다릴 수도 있습니다.
이것이 간접 프롬프트 주입(indirect prompt injection)을 매우 위험하게 만드는 이유입니다.
공격 표면(attack surface)은 더 이상 AI 그 자체만 아닙니다.
그것은 AI가 사용하기에 충분히 신뢰하는 모든 것입니다.
최종 요약 (Final Takeaway)
0클릭 AI 공격은 직원이 무언가를 클릭하도록 설득하는 것에 의존하지 않습니다.
그것은 AI 시스템이 공격자가 통제한 콘텐츠를 실행 가능한 컨텍스트로 해석하도록 설득하는 것에 의존합니다.
AI 에이전트가 민감한 정보를 검색하거나, 도구를 호출하거나, 외부와 통신하거나, 다른 에이전트와 조정할 권한을 갖게 되면, 작은 신뢰 실패가 큰 운영 사고로 이어질 수 있습니다.
따라서 가장 강력한 방어는 단순히 더 나은 시스템 프롬프트만으로는 부족합니다.
그것은 다음을 분리하는 아키텍처입니다:
데이터와 지침(data from instructions),
지침과 권한(instructions from authority),
그리고 모델의 결정과 최종 승인(model decisions from final authorization).
목표는 AI가 아무것도 신뢰하지 않게 만드는 것이 아닙니다.
그것은 신뢰할 수 없는 콘텐츠가 결코 조용히 신뢰받는 권한이 되는 것을 막는 것입니다.
추가 자료 (Further Reading)
간접 프롬프트 주입, RAG 보안, AI 에이전트 프롬프트 주입 및 자율 워크플로우 공격에 대한 연구를 위해 HexTyx AI Security Resource Library를 참고하십시오.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기