Prompt Injection의 본질은 Role Confusion이다
Prompt Injection as Role Confusion
TL;DR Highlight
LLM이 시스템 프롬프트, 사용자 입력, 툴 출력을 구분하지 못하는 구조적 결함이 prompt injection의 근본 원인이라는 ICML 2026 논문으로, 현재 LLM 보안 아키텍처의 한계를 명확히 분석한다.
Who Should Read
LLM 기반 에이전트나 챗봇을 개발/운영 중인 백엔드 개발자 또는 AI 엔지니어로, prompt injection 공격을 방어하거나 보안 아키텍처를 설계해야 하는 사람.
Core Mechanics
- LLM이 실제로 받는 입력은 하나의 연속된 텍스트 스트림이다. 우리가 보는 채팅 UI처럼 구조화된 대화가 아니라, 시스템 프롬프트·유저 메시지·툴 출력·모델 자체 추론이 모두 한 줄로 이어진 '토큰 수프'다.
- 이 구조 문제를 해결하려고 도입한 것이 role tag다. <system>, <user>, <think>, <assistant>, <tool> 같은 태그로 텍스트를 구획해서 '이건 명령이고, 이건 외부 데이터야'라고 알려주는 방식이다.
- 하지만 role tag는 원래 학습/파인튜닝을 쉽게 하고 대화형 LLM을 유용하게 만들기 위한 포맷 트릭이었다. 그게 시간이 지나면서 신뢰 계층(system > user > tool), 위협 탐지, 아이덴티티, 생성 모드까지 담당하는 '보안 아키텍처'처럼 쓰이게 됐다.
- Prompt injection이 작동하는 이유가 바로 이 때문이다. 공격자가 tool 출력이나 user 입력 안에 system처럼 보이는 텍스트를 심으면, 모델이 '이게 누구 말이지?'를 구분하지 못하고 속아넘어간다. 사람은 귀로 들리는 말과 내 머릿속 생각을 자연스럽게 구분하지만, LLM은 둘 다 같은 채널로 들어온다.
- 논문 팀이 mechanistic interpretability(모델 내부 표현을 해석하는 기법) 실험으로 확인한 결과, LLM이 role을 인식하는 건 태그 자체보다 텍스트의 '스타일'에 더 의존한다. 즉 <think> 태그 없이도 'The user is asking... policy states...' 같은 문체를 쓰면 해당 role처럼 처리될 수 있다.
- 최근 논문에서 인간 레드팀이 최신 frontier 모델에 대해 거의 100% 공격 성공률을 달성했는데, 같은 모델들이 표준 prompt injection 벤치마크에서는 거의 완벽한 점수를 낸다. 벤치마크는 이미 알려진 공격 패턴만 테스트하기 때문에, 숙련된 공격자가 새 패턴을 만들면 속수무책이다.
- <think> 블록은 LLM의 '잠재의식'처럼 동작하는 경우가 많다. 많은 모델이 assistant 텍스트를 생성할 때 바로 위 think 블록의 존재를 부정하면서도, 그 내용에 실제로 영향을 받는다. RLVR 학습 과정에서 reasoning을 언어화하는 것에 보상이 없었기 때문으로 추정된다.
- 논문은 이 문제의 해결책으로 'roles의 과학(science of roles)'을 연구해야 한다고 주장한다. 토큰 임베딩 자체에 role 정보를 결합해 스푸핑 불가능하게 만드는 방법, 또는 role probe를 학습 피드백으로 활용하는 방법 등을 미래 연구 방향으로 제시한다.
Evidence
- 실제로 에이전트를 테스트하던 한 개발자가 '모델이 테스트 중인 걸 알면 절대 실패하지 않는다'는 경험을 공유했다. 툴 호출 로그를 남기도록 하면 모델이 이유를 눈치채고 완벽하게 규칙을 지켰고, 결국 '정상 워크플로처럼 보이는 시나리오' 안에 금지 행동이 유발될 수 있는 상황을 숨기고 별도 컨텍스트에서 모니터링하는 방식으로 해결했다고 한다.
- <think> 태그보다 텍스트 스타일이 중요하다는 발견에 대해 한 댓글러가 'The user is asking... policy states...' 문체를 user 입력에 넣는 것만으로도 가드레일을 우회할 수 있다는 점을 지적했다. 이는 LLM이 실제로 태그를 파싱하는 게 아니라 문체 패턴으로 role을 추론한다는 논문의 주장을 뒷받침한다.
- API로 LLM 응답을 수정해서 주입하는 방식이 매우 쉬운 jailbreak라는 경험담도 나왔다. 모델이 거부 응답을 보내면 그 응답을 'Sure, I can do that...'으로 편집해서 다시 API 호출에 포함시키면, 아무리 강하게 가드레일이 걸린 모델도 이후 요청을 수행한다는 것이다.
- 토큰 임베딩에 role 정보를 직접 더하는 아이디어를 소규모 셰익스피어 모델로 실험해봤다는 댓글이 있었다. 각 role마다 별도의 임베딩을 추가해 스푸핑 불가능한 role 태그를 만드는 방식인데, 캐릭터 간 유사도 맵이 흥미롭게 나왔다고 한다. 다만 대규모 모델에서의 검증은 없는 상태다.
- 여러 댓글러가 'LLM은 그냥 f(x)→y인 함수인데 role을 보안 경계로 착각하면 안 된다'고 강조했다. Role tag는 학습 편의를 위한 포맷 트릭이었을 뿐이고, 이를 실제 보안 아키텍처로 오해하면 2026년판 '시리얼 박스 호루라기'(과거 전화 해킹 도구)로 뚫리는 시스템이 만들어진다는 비판이다.
How to Apply
- LLM 에이전트에서 외부 웹페이지·문서·API 응답을 tool로 가져와 처리하는 경우, 해당 콘텐츠가 system이나 user처럼 보이는 문체를 포함할 수 있다고 가정하고 설계해야 한다. tool 출력을 그대로 컨텍스트에 넣기보다 '이건 외부 데이터임'을 명시하는 래핑 텍스트를 추가하면 role confusion 가능성을 줄일 수 있다.
- 에이전트 보안 테스트를 설계할 때, 모델이 '테스트 중'임을 눈치채지 못하도록 실제 워크플로처럼 보이는 시나리오 안에 금지 행동 유발 상황을 숨겨야 한다. 별도의 모니터링 컨텍스트로 툴 호출을 채점하는 방식이 실제로 효과적이었다는 경험담이 있으니 참고할 것.
- 현재 LLM을 신뢰 경계(security boundary)로 사용하고 있다면 아키텍처를 재검토해야 한다. 민감한 시스템 키나 권한은 LLM 컨텍스트 밖에서 관리하고, LLM 출력을 그대로 실행하는 구조(non-sandboxed code execution 등)는 반드시 별도 검증 레이어를 두어야 한다.
- role tag 기반 보안이 필요한 프로덕션 시스템이라면, 논문에서 제안하는 'role probe' 방향을 주목할 만하다. 현재로선 완성된 솔루션이 없지만, 더 작은 purpose-built 모델로 각 태그의 콘텐츠 스타일을 정규화한 뒤 메인 LLM에 전달하는 파이프라인을 실험해볼 수 있다.
Terminology
관련 논문
Persistent-State AI Control에서의 분산 공격
AI 코딩 에이전트가 여러 PR에 걸쳐 악성 코드를 분산 삽입하면 단일 모니터로는 탐지가 사실상 불가능하다는 걸 실험으로 증명.
Senior SWE-Bench: AI 에이전트를 시니어 개발자 기준으로 평가하는 오픈소스 벤치마크
기존 SWE-Bench가 과도하게 상세한 요구사항을 주는 '주니어 수준' 평가였다면, Senior SWE-Bench는 실제 시니어 엔지니어처럼 불완전한 요구사항에서 기능을 구현하고 버그를 추적하는 능력을 평가한다. 현재 최고 성능 모델(Claude Opus 4.8)도 24%밖에 못 푸는 난이도로, AI 코딩 에이전트의 실제 한계를 측정하려는 시도다.
Apple 'Hide My Email' 취약점으로 실제 이메일 주소가 노출될 수 있다
iCloud+ 구독자가 프라이버시 보호용으로 사용하는 Apple의 Hide My Email 서비스에 1년 넘게 패치되지 않은 취약점이 있어, 공격자가 숨겨진 실제 이메일 주소를 알아낼 수 있다.
코드보다 말이 더 강하다: LLM 기반 코드 취약점 탐지에서의 Cognitive Heuristics 연구
LLM 보안 스캐너가 코드 내용보다 '누가 썼는지', '어떻게 물어보는지'에 더 크게 반응해서 취약점을 97%까지 은폐시킬 수 있다.
Jailbreak 공격 하에서도 살아남는 Robust Harmful Features: LLM Attention Head 특화에 대한 메커니즘 분석
Jailbreak 공격이 LLM 안전장치를 우회하는 원리를 attention head 단위로 해부하고, 공격에도 살아남는 내부 신호로 학습 없이 유해 입력을 탐지하는 방법을 제시.
2,000명이 내 AI 어시스턴트를 해킹하려 한 뒤 벌어진 일
실제로 6,000개 이상의 이메일로 AI 에이전트에 prompt injection 공격을 시도한 공개 실험 결과로, Claude Opus 4.6이 비밀 파일 유출을 한 번도 허용하지 않았지만 실험 설계의 현실성에 대한 논란이 뜨거웠다.