도메인 위장 프롬프트 공격, 에이전트 방어의 맹점을 찌르다

arXiv에 올라온 Blind Spots in the Guard: How Domain-Camouflaged Injection Attacks Evade Detection in Multi-Agent LLM Systems는 LLM 에이전트 보안의 불편한 약점을 지적한다. 초록에 따르면 기존 injection detector는 “ignore previous instructions”처럼 스스로를 드러내는 정적 템플릿에 맞춰진 경우가 많다. 논문은 공격 payload가 대상 문서의 도메인 어휘와 권위 구조를 흉내 내면 탐지율이 Llama 3.1 8B에서 93.8%에서 9.7%로, Gemini 2.0 Flash에서 100%에서 55.6%로 떨어졌다고 보고한다. 참고할 만한 배경 자료로는 OWASP Top 10 for LLM Applications, NIST AI Risk Management Framework, Meta Llama, Google Gemini API 문서가 있다.

이 결과가 중요한 이유는 에이전트가 문서를 읽고 행동하기 때문이다. 단순 챗봇은 잘못 답하면 수정할 수 있지만, 메일 에이전트·코딩 에이전트·CRM 에이전트는 도구를 호출하고 파일을 바꾸고 외부 시스템에 쓰기를 수행한다. Google AI 검색 조작, SEO가 보안 문제가 됐다가 검색 결과의 오염을 다뤘다면, 이번 논문은 내부 업무 문서처럼 그럴듯한 텍스트가 방어망을 통과하는 문제를 보여준다.

“악성 문장”이 아니라 “그럴듯한 업무 지시”가 문제다

프롬프트 인젝션 방어는 흔히 금칙어와 패턴을 찾는다. 그러나 실제 공격자는 “이전 지시를 무시하라”라고 쓰지 않아도 된다. 금융 문서라면 감사·승인·정산 어휘를, 의료 문서라면 처방·보험·임상 기록 형식을, 개발 문서라면 릴리스·핫픽스·보안 패치 어휘를 쓴다. 에이전트가 그 도메인의 권위 구조를 신뢰하도록 설계됐다면, 공격은 더 자연스럽게 보인다.

멀티 에이전트 시스템에서 더 위험하다

멀티 에이전트 구조에서는 한 에이전트가 읽은 문서가 다른 에이전트의 입력이 된다. 분석 에이전트가 오염된 내용을 요약하고, 실행 에이전트가 그 요약을 근거로 도구를 호출할 수 있다. 그래서 AI 에이전트 테스트, 분산시스템의 주장부터 검증한다에서 말한 분산 시스템 관점이 중요하다. 프롬프트 인젝션은 단일 입력 검사가 아니라 데이터 흐름 전체의 무결성 문제다.

한국 기업의 보안 기준

국내 금융, 커머스, 제조 기업이 에이전트를 도입할 때 “사내 문서니까 안전하다”는 가정은 위험하다. 협력사 문서, 고객 이메일, 티켓, 웹 검색 결과는 모두 외부 입력이다. 방어는 최소권한, 출처 태깅, 도구 호출 전 정책 검증, 사람이 승인해야 하는 고위험 행동 분리, 로그의 재현 가능성으로 구성해야 한다. Statewright, 에이전트 신뢰성을 상태기계로 묶다와 AI 워터마크 제거 도구가 던진 provenance 경고가 강조한 출처와 상태 관리가 보안 요구사항이 된다.

결론

도메인 위장 인젝션은 프롬프트 보안을 “나쁜 문장 찾기”에서 “행동 권한 검증”으로 끌어올린다. 에이전트가 실제 시스템을 만질수록 탐지율 하나보다 안전한 실행 경계가 더 중요해진다.

FAQ

도메인 위장 인젝션이란 무엇인가?

공격 문장이 대상 업무 문서의 어휘, 형식, 권위 구조를 흉내 내 탐지기를 속이는 방식이다.

논문이 보고한 핵심 수치는 무엇인가?

초록 기준 Llama 3.1 8B의 탐지율은 93.8%에서 9.7%로, Gemini 2.0 Flash는 100%에서 55.6%로 떨어졌다.

왜 멀티 에이전트에서 더 위험한가?

한 에이전트의 오염된 출력이 다른 에이전트의 입력과 도구 호출 근거가 되며 피해가 전파될 수 있기 때문이다.

키워드 필터로 막을 수 없나?

일부는 막지만, 도메인 말투를 흉내 낸 payload에는 취약하다. 출처, 권한, 행동 정책을 함께 봐야 한다.

기업의 첫 대응은 무엇이어야 하나?

외부 입력 태깅, 최소권한, 고위험 도구 호출 승인, 재현 가능한 로그, 정기적인 adversarial test를 마련하는 것이다.