- 저자: Jiangrong Wu 외
- 발표: arXiv v2, 2026-09-19 / NDSS 2027 accepted
- 원문: arXiv
- Tags: Email Agent, Prompt Injection, ESPI, LLM Security, Tool Calling, Protocol State, EmailStateGuard, ESPInspector, Phishing, NDSS
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
ESPI는 공격 이메일이 가짜 IMAP/SMTP/MIME/quota/NDR 상태와 그에 따른 “복구” 논리를 주장해, LLM 이메일 에이전트가 검색·출력·draft·send·delete tool을 오용하게 만드는 간접 프롬프트 인젝션입니다. 4개 framework·6개 model·4개 scenario의 480회 controlled experiment에서 353회, 73.54%가 성공했고 기존 baseline 최고치는 TAP의 33.13%였습니다.
핵심 방어는 프롬프트 문구가 아니라 authenticated mail provider state입니다. EmailStateGuard는 IMAP STATUS/SELECT/SEARCH/QUOTA 등으로 실제 상태를 다시 확인하고 tool·recipient·scope를 현재 작업에 바인딩해 동일 480회에서 0회 성공을 기록했습니다.
연구 배경
이메일 에이전트는 메시지 내용을 읽는 동시에 메일함 검색, 요약, draft, 발송, 삭제 권한을 갖습니다. 공격자가 보낸 본문은 비신뢰 데이터여야 하지만, LLM은 “quota 초과”, “delivery failure”, “MIME 복구”처럼 프로토콜 상태를 닮은 자연어를 운영 신호로 받아들일 수 있습니다.
기존 방어는 입력 문자열, jailbreak 표현, tool argument schema를 검사합니다. ESPI는 정상 protocol incident와 policy remediation을 흉내 내기 때문에 argument가 형식적으로 유효해도 행동의 근거가 위조됐다는 점을 노립니다.
공격 모델 / 전제 조건
원격 공격자는 victim에게 이메일 한 통을 보낼 수 있을 뿐 system prompt, 사용자 요청, agent runtime, 메일 서비스를 직접 제어하지 못합니다. victim이 해당 메일을 검색·요약·처리하도록 에이전트를 사용하고, 에이전트가 충분한 mailbox tool 권한을 보유해야 합니다.
63개 real-world app 표본 중 57개, 90.48%는 추가 확인 없이 자동 tool action이 가능했고 6개는 confirmation이 필요했습니다. 실험은 연구진 소유의 두 계정, synthetic mail, controlled recipient·service를 사용했으며 실제 제3자의 mailbox를 공격하지 않았습니다.
비판적 검토 / 아쉬운 점
- 실제 앱 재현성이 가장 제한됩니다. 63개 앱과 16개 CVE의 이름·ID를 redaction해 독립 검증이 불가능합니다. remediation 후 최소한 vendor·version·patch status와 anonymized reproduction trace를 공개해야 합니다.
- “전부 hijack” 통계는 one-shot ASR이 아닙니다. Gmail 63개 앱×6개 모델 378조합은 총 696번, 10개 서비스 492조합은 총 931번 시도해 각 조합의 첫 성공까지 반복했습니다. 명확한 최대 retry와 실패 censoring 없이 eventually-success를 단회 성공률처럼 읽으면 위험이 과장됩니다.
- real-world 축이 분리돼 있습니다. 앱×모델과 서비스 축을 decoupled로 시험했으므로 63×6×10 전체 조합을 검증한 것이 아닙니다. 대표 조합의 factorial sample이 있어야 서비스 전반 일반화를 뒷받침할 수 있습니다.
- 기제 라벨의 인과성이 약합니다. 성공 trace 353개를 두 annotator가 forged state 영향으로 합의했지만 inter-rater 수치가 없고 모델 reasoning trace는 faithful explanation이 아닐 수 있습니다. 상태 문구만 치환하는 causal intervention이 필요합니다.
- 방어가 같은 공격 분포에 맞춰졌을 수 있습니다. EmailStateGuard의 0/480은 강한 결과지만 adaptive adversary, provider API inconsistency, race, compromised mailbox state를 평가하지 않았습니다. 공격자가 검증 가능한 실제 상태와 악성 지시를 결합하는 후속 시험이 필요합니다.
핵심 Root Cause
깨진 불변조건은 “mailbox 상태에 의존한 보안 행동은 인증된 provider state로만 승인되어야 하며, tool action은 현재 사용자 작업·수신자·범위에 바인딩되어야 한다”입니다. 기존 agent stack은 메시지 본문이 주장하는 protocol state와 실제 IMAP/SMTP state의 provenance를 구분하지 못합니다.
따라서 middleware가 tool 이름과 argument type, OAuth permission을 올바르게 검사해도 LLM이 왜 그 action을 선택했는지는 검증되지 않습니다. 합법적 capability가 위조된 상태 전이에 의해 오용되는 confused-deputy 문제가 됩니다.
핵심 공격 원리
ESPI는 Sproto와 Rlogic 두 요소를 결합합니다. Sproto는 IMAP/SMTP/MIME/quota/NDR 오류처럼 보이는 상태를 만들고, Rlogic은 “protocol crisis → policy → remediation” 논리로 검색, 민감 내용 출력, draft 대량 생성, controlled recipient 발송, 삭제를 합리화합니다.
DeepSeek-R1은 email protocol knowledge base를 바탕으로 payload 후보를 생성합니다. 연구는 개인정보 수집, phishing, 기만적 출력, service pollution의 4개 scenario와 content output/search/draft/send/delete의 5개 primitive를 평가합니다.
공격 흐름
- 공격자가 forged protocol state와 remediation 지시를 포함한 이메일을 victim에게 보냅니다.
- 사용자가 정상 요청으로 mailbox를 조회하면 agent가 악성 메일을 context에 포함합니다.
- 모델이 본문의 상태 주장을 provider가 보낸 운영 신호로 오인합니다.
- Rlogic을 따라 추가 검색·민감 정보 조합·draft·send·delete tool을 선택합니다.
- ESPInspector가 controlled inbox, exact string, draft 수, target mail 상태를 외부 oracle로 확인합니다.
성공 조건 / 실패 조건
성공에는 악성 메일이 context에 포함되고, agent가 protocol state provenance를 검증하지 않으며, 필요한 tool permission과 자동 실행 경로가 있어야 합니다. 개인정보 수집은 민감 메일이 controlled account로 도착해야 하고, phishing은 controlled recipient 발송, 기만 출력은 정확한 문자열, pollution은 draft 10개 이상 또는 target deletion으로 판정합니다.
provider API로 실제 quota·delivery·message state를 확인하고 forged claim이 불일치하면 실패합니다. tool·recipient·scope가 사용자 요청과 맞지 않을 때 차단하고 구체적 confirmation을 요구해도 실패하며, 단순 모델 거부만으로는 안정적인 실패 조건이 아닙니다.
연구진의 실험 환경
framework survey는 14개 중 이메일 기능이 있는 LangChain 0.3.51, LlamaIndex 0.12.29, aiwaves, Griptape 1.6 네 개를 사용했습니다. 모델은 GPT-5.2, Gemini 2.5 Pro, Claude Sonnet 4.6, DeepSeek 3.2, Qwen 3.5, GLM 4.6입니다.
controlled RQ는 4 scenario×6 model×20회로 총 480회이며, 각 20회는 5개 payload×4 framework입니다. ESPInspector는 두 controlled account, synthetic data, Python smtplib, 기본 5분 대기, IMAP/SMTP 상태·hash와 API output string을 oracle로 사용합니다.
실제 앱 표본은 104개 candidate 중 mailbox가 동작한 63개입니다. 50개는 공식 존재와 version을 모두 확인했고 12개는 둘 중 하나, 1개는 둘 다 확인하지 못했으며 GitHub star나 공개 저장소 존재는 실제 사용자 수를 의미하지 않습니다.
주요 실험 결과
| 모델 | ESPI 성공 | 분모 |
| GPT-5.2 | 58, 72.5% | 80 |
| Gemini 2.5 Pro | 52, 65.0% | 80 |
| Claude Sonnet 4.6 | 46, 57.5% | 80 |
| DeepSeek 3.2 | 68, 85.0% | 80 |
| Qwen 3.5 | 63, 78.75% | 80 |
| GLM 4.6 | 66, 82.5% | 80 |
| 합계 | 353, 73.54% | 480, 95% CI 69.42–77.29% |
baseline은 naive 4.58%, escape 5.42%, context ignore 8.13%, fake 7.92%, LLM-generated 14.38%, Postmaster 22.5%, GCG 5.0%, PAIR 26.04%, TAP 33.13%였습니다. ablation은 Sproto 제거 23.13%, Rlogic 제거 40.42%로 두 구성요소가 모두 성능에 기여했습니다.
방어는 generic prompt/input 조치 71.25~72.92%, email-state prompt 60.63%, generic detector 69.58~71.04%, Progent 26.67%, AlignmentCheck 37.5%, EmailStateGuard 0/480이었습니다. 120개 ESPI payload를 일반 spam/phishing classifier에 넣었을 때 탐지율은 5~9.17%였지만, 해당 분류기는 prompt injection 전용 방어가 아니라는 점을 감안해야 합니다.
실제 발견된 취약점 / 사례
연구진은 67개 vendor에 공개했고 22곳, 즉 4개 framework와 18개 app이 확인했다고 보고합니다. 16개 CVE가 할당됐다고 하지만 미패치 상태를 이유로 ID와 앱 이름을 공개하지 않아 현재 독립적으로 매핑하거나 상태를 검증할 수 없습니다.
real-world Gmail 평가에서는 63개 앱×6개 모델의 378조합이 총 696번 시도 후 모두 한 번 이상 성공했고, 서비스 평가는 GPT-5.2와 10개 mail service의 492조합이 총 931번 시도 후 모두 성공했습니다. 이는 평균 1.84회·1.89회 시도 뒤 첫 성공이라는 결과이지 고정 1회 ASR이 아닙니다.
저자 주장 vs 실제 증명 범위
forged email protocol state가 기존 prompt injection보다 강한 공격 신호가 되고, authenticated state validation이 해당 corpus에서 효과적이라는 주장은 controlled 480회, ablation, 외부 side-effect oracle로 잘 뒷받침됩니다. 텍스트 응답이 아닌 실제 mailbox 변화로 성공을 측정한 점도 강점입니다.
하지만 63개 앱·16개 CVE의 구체적 재현, 모든 모델×앱×서비스 조합, 적응형 공격에 대한 0% 방어, 현재 제품의 패치 상태는 증명되지 않았습니다. 별 수와 공개 repository를 production deployment 규모로 해석해서도 안 됩니다.
기존 공격 / 기존 점검 방식과의 차이
기존 email IPI는 “이전 지시를 무시하고 메일을 보내라”처럼 직접 명령하거나 jailbreak를 사용합니다. ESPI는 실제 mail protocol과 운영 정책을 흉내 내어 모델이 정당한 복구 절차를 수행한다고 믿게 만들며, 외형상 정상적인 tool argument를 생성합니다.
기존 검사기가 문구·toxicity·spam·argument schema를 보면 EmailStateGuard는 의사결정의 사실 전제를 검증합니다. 즉 “무슨 문장이 있는가”보다 “그 quota·delivery·message 상태가 provider API에서 사실인가”를 보안 경계로 삼습니다.
연구의 한계와 주의해서 볼 부분
원문은 별도 limitation section이 충분하지 않고, disclosure 때문에 핵심 payload·앱·CVE·end-to-end 세부를 의도적으로 생략합니다. 이 선택은 안전성에는 이해되지만 독립 재현과 방어 일반화 검증을 제한합니다.
추가로 retry-until-success 결과, decoupled service 평가, reasoning-trace annotation, GitHub 기반 표본의 대표성, model·service 버전 변동을 주의해야 합니다. EmailStateGuard도 동일 attack generator 분포와 정상 provider state를 전제로 하므로 race, 실제 quota incident, provider compromise까지 해결한 것은 아닙니다.
공개 PoC / Exploit / Tool / Artifact 분석
논문 원문은 ESPInspector, payload generator, EmailStateGuard 구현을 설명하지만 2026-09-23 기준 공식 GitHub·artifact URL을 제공하지 않습니다. v2는 미패치 vendor 보호를 위해 payload, app identity, CVE ID, end-to-end exploit 세부를 redaction했다고 명시하므로 현재 공개 재현 가능한 exploit으로 표현할 수 없습니다.
공식 repository, release, code structure, 필요 환경을 독립 확인할 수 없으며 검색으로 확인된 저자·프로젝트 저장소도 없습니다. 따라서 논문의 0/480 방어 결과도 공개 harness로 재실행할 수 없습니다.
레드팀 / 모의해킹에서 어떻게 활용할까
연구진 소유의 송신·수신 계정과 synthetic message만 사용하는 lab을 구성합니다. 실서비스 주소로 발송하지 않고 search·draft·send·delete를 각기 dry-run 또는 controlled recipient로 제한하며, 모델 텍스트가 아니라 IMAP/SMTP side effect를 판정 기준으로 사용합니다.
관찰 포인트는 quota/NDR/MIME 상태를 본문에서 신뢰하는지, 추가 검색 범위가 사용자 요청을 벗어나는지, recipient가 변하는지, 대량 draft·삭제가 발생하는지입니다. controlled recipient 이외 발송, 실제 민감 메일 접근, 대량 상태 변경이 감지되는 즉시 중단해야 합니다.
실제 점검 시 추가할 체크리스트
- 이메일 본문이 주장한 protocol state를 provider API로 재검증하는가
- IMAP STATUS·SELECT·SEARCH·QUOTA 결과와 action 이유를 연결하는가
- 검색 범위와 반환 필드가 현재 사용자 요청에 최소화됐는가
- send/draft/delete마다 recipient·message ID·scope를 재확인하는가
- confirmation이 구체적 action과 side effect를 보여주는가
- NDR·quota·MIME 문구가 system/vendor 메시지로 오인되지 않는가
- 10개 이상 draft, bulk delete, 새로운 외부 recipient를 rate-limit하는가
- prompt detector 실패와 state validator 실패를 별도 기록하는가
- fixed one-shot과 retry-until-success 결과를 구분하는가
- synthetic mailbox·controlled recipient·즉시 중단 기준을 강제하는가
실무 가치 평가
이메일 에이전트를 배포하는 조직에는 매우 높은 가치가 있습니다. 특히 middleware가 OAuth와 tool schema를 검사하므로 안전하다고 믿는 팀에, action의 사실 전제와 provenance까지 검증해야 한다는 구체적 설계 방향을 줍니다.
다만 공개 artifact와 취약 앱 정보가 없어 논문 수치를 그대로 내부 risk rate로 쓸 수 없습니다. 가장 실용적인 적용은 EmailStateGuard의 원리, 즉 authenticated provider state·현재 user intent·recipient·scope의 결합을 자체 gateway에 구현하고 synthetic side-effect test로 검증하는 것입니다.
결론
ESPI는 메일 본문이 protocol state를 위조하면 LLM이 합법적 도구 권한을 위험한 방식으로 사용할 수 있음을 대규모 controlled experiment로 보여줍니다. 73.54%와 0/480은 강한 대비지만, redaction·retry 설계·adaptive attack 부재라는 범위 안에서 해석해야 합니다.
방어의 중심은 더 긴 system prompt나 일반 spam detector가 아닙니다. 이메일에서 주장한 상태를 인증된 provider로 확인하고 모든 side effect를 현재 사용자 의도와 명시적으로 바인딩해야 합니다.
댓글