사내 문서를 읽고 메일을 요약하고 일정을 정리하는 AI 에이전트를 붙이는 조직이 늘었다. 그런데 에이전트에게 권한을 주는 순간 지금까지 없던 공격 경로가 하나 열린다. 모델이 읽게 될 자료 안에 “앞의 지시는 무시하고 이렇게 하라”는 문장을 미리 심어 두는 공격, 프롬프트 인젝션이다. 공격자는 서버를 뚫을 필요도 계정을 탈취할 필요도 없다. 에이전트가 어차피 읽게 될 문서 한 장이면 된다.
지시와 데이터가 한 통에 섞인다
언어 모델에는 명령을 받는 통로와 데이터를 받는 통로가 따로 없다. 개발자가 심어 둔 시스템 프롬프트, 사용자가 입력한 질문, 모델이 참조하려고 끌어온 웹페이지와 사내 문서가 전부 하나의 토큰 열로 합쳐져 들어간다. 모델이 보기에 “너는 고객 상담원이다”와 “앞의 지시는 무시하라”는 형식상 구분되지 않는다. SQL 인젝션이 데이터를 쿼리문으로 읽히게 만든 문제였다면, 프롬프트 인젝션은 데이터를 지시로 읽히게 만드는 문제다.
공격은 크게 둘로 나뉜다. 사용자가 입력창에 직접 공격 문장을 넣는 직접 인젝션, 그리고 모델이 나중에 가져올 외부 자료 안에 미리 심어 두는 간접 인젝션이다. 실무에서 위험한 쪽은 간접이다. 심는 사람과 피해를 보는 사람이 다르고, 피해자는 자기가 무엇을 열었는지조차 모르는 채로 당하기 때문이다. 숨길 자리도 많다. 웹페이지의 흰 글씨, 문서 메타데이터, 이슈 트래커 댓글, 이미지 안의 글자까지 모델이 읽을 수 있는 모든 곳이 후보다.
에이전트가 되면서 피해의 종류가 달라졌다
챗봇 시절의 프롬프트 인젝션은 대체로 모델이 하지 말아야 할 말을 하게 만드는 선에서 끝났다. 에이전트는 다르다. 메일을 보내고 파일을 열고 결제를 승인하고 코드를 실행할 권한을 이미 갖고 있다. 탈취당한 지시는 문장이 아니라 행동으로 바뀐다.
2025년 6월 공개된 EchoLeak가 그 선을 넘은 사례로 자주 인용된다. Aim Security 연구팀이 찾아낸 이 취약점은 공격 메일 한 통이 사서함에 들어와 있기만 하면, 이후 사용자가 Copilot에게 평범한 질문을 던지는 순간 메일 안에 숨어 있던 지시가 작동해 대화 맥락에 올라온 사내 정보를 외부로 내보내는 구조였다. SecurityWeek의 정리에 따르면 사용자가 그 메일을 열거나 링크를 누를 필요조차 없었다. 마이크로소프트는 CVE-2025-32711로 등록해 심각도 9.3을 매긴 뒤 서버 쪽에서 수정했고, 실제 악용 정황은 확인되지 않았다고 밝혔다.
OWASP는 이 문제를 어디에 놓았나
OWASP의 생성형 AI 보안 프로젝트가 내는 두 목록 모두 이 문제를 1위에 두고 있다.
| 목록 | 1위 항목 | 무엇을 가리키나 |
|---|---|---|
| Top 10 for LLM Applications (2025) | LLM01 프롬프트 인젝션 | 입력이 모델의 의도된 지시를 덮어쓰거나 우회하는 문제 |
| Top 10 for Agentic Applications (2026) | ASI01 에이전트 목표 탈취 | 외부 문서나 데이터를 통해 에이전트의 목표 자체를 바꾸는 문제 |
2025년 12월에 나온 에이전트 애플리케이션용 목록은 이름부터 바뀌었다는 점이 눈에 띈다. 더 이상 “모델이 이상한 말을 한다”가 아니라 “에이전트가 다른 목표를 갖게 된다”로 문제를 정의한다. 같은 목록의 나머지 항목도 도구 오남용, 권한 남용, 메모리 오염, 에이전트 간 통신처럼 모델 바깥의 설계를 겨냥하고 있다.
한 겹으로 막히지 않는 이유
- 구분할 자리가 없다. 지시와 데이터를 나누는 문법이 모델 입력에 존재하지 않는다. 구분자나 태그로 감싸는 방식은 공격자가 같은 구분자를 흉내 내면 무너진다.
- 필터는 우회를 전제해야 한다. 금지어 목록은 번역, 인코딩, 띄어쓰기 변형, 이미지 삽입 같은 변주에 약하다. EchoLeak도 여러 겹의 필터를 지나갔다.
- 정상 동작과 경계가 흐리다. “요약해서 담당자에게 보내라”는 지시는 문서에 적혀 있어도 업무상 타당해 보인다. 무엇이 공격인지는 문장만 봐서는 판정하기 어렵다.
OWASP도 프롬프트 인젝션에 확실한 예방책이 있는지는 분명하지 않다고 적고 있다. 완전 차단이 아니라 피해 범위를 줄이는 쪽으로 목표를 바꾸는 편이 현실적이다.
프롬프트 인젝션은 패치로 닫히는 버그라기보다 지금 모델 구조가 안고 있는 성질에 가깝다. 모델이 완벽히 걸러 주기를 기다리는 대신, 에이전트가 틀린 지시를 따랐을 때 어디까지 벌어질 수 있는지를 먼저 좁혀 두는 것이 실무의 출발점이다.
지금 할 수 있는 것
- 에이전트 계정에 사람과 같은 권한을 주지 않는다. 읽기 전용으로 시작해 필요한 범위만 열고, 외부로 나가는 동작은 별도 자격 증명으로 분리한다.
- 되돌릴 수 없는 동작에는 사람의 승인을 건다. 메일 발송, 결제, 파일 삭제, 외부 API 호출이 대표적이다. 승인 화면에는 모델의 요약이 아니라 실제 실행될 내용을 띄운다.
- 외부에서 들어온 내용을 지시로 취급하지 않도록 격리한다. 검색 결과와 첨부 문서는 참고 자료로 표시하고, 거기서 나온 명령형 문장은 실행 후보에서 제외한다.
- 나가는 쪽도 검사한다. 입력만 보면 늦는다. 시스템 프롬프트 내용, 사내 식별자, 외부 도메인으로 향하는 링크가 응답에 섞여 나가는지 확인한다.
- 배포 전에 인젝션 시나리오로 직접 때려 본다. 오픈소스 취약점 스캐너를 붙여 회귀 테스트로 돌리면 모델이나 프롬프트를 바꿀 때마다 재확인할 수 있다.
정리
프롬프트 인젝션은 모델이 똑똑해지면 사라지는 문제가 아니라, 지시와 데이터를 한 통에 넣는 구조가 유지되는 한 남아 있는 문제로 보인다. OWASP가 두 목록에서 연이어 1위에 올린 것도 같은 맥락이다. 에이전트를 도입할 때 던질 질문은 “이 모델은 인젝션에 안전한가”가 아니라 “이 에이전트가 공격자의 지시를 그대로 따랐다고 가정하면 무엇까지 할 수 있는가”에 가깝다. 그 답이 감당할 만한 수준으로 좁혀져 있다면 그때 권한을 넓히는 순서가 안전하다.