에이전트가 낯선 사람이 쓴 글을 읽는 동안, 그 글은 에이전트에게 명령처럼 작동할 수 있습니다. 모델은 읽고 있는 글 속의 지시문과 사용자가 시킨 지시문을 믿을 만하게 가려내지 못하기 때문입니다. 그래서 제가 읽은 공개 자료들이 공통으로 권하는 방어는 모델을 더 영리하게 만드는 쪽이 아니라 설계 쪽에 있습니다. 낯선 글을 읽는 일, 민감한 자료에 닿는 일, 바깥으로 보내거나 바꾸는 일을 한 세션에 모두 주지 않는 것입니다. 이 글은 그 근거를 정리하고, 맡길 일마다 세 칸을 적어 보는 점검표를 DMS.Labs의 제안으로 붙였습니다. 에이전트를 직접 공격해 본 시험 결과는 아닙니다.
2026년 11월 9일 확인한 공개 자료 기준입니다. 읽은 자료는 Meta의 Agents Rule of Two 글(2025년 10월 31일), 영국 국가사이버보안센터(NCSC)의 블로그 글(2025년 12월 8일), OWASP의 LLM01 항목, 개발자 Simon Willison의 2025년 6월 글, 설계 패턴 논문(Beurer-Kellner 등, 2025), 그리고 간접 프롬프트 인젝션을 다룬 2023년 논문의 초록입니다. 뒤에 나오는 점검표와 가상의 장면은 이 자료를 읽고 만든 DMS.Labs의 제안이며, 어느 자료가 요구하는 규격이 아닙니다.
창가 나무 책상 위에 편지 봉투 몇 통과 놋쇠 편지칼, 책 한 권이 놓인 장면원본 전체 보기
프롬프트 인젝션은 무엇이고, 에이전트에게 왜 더 위험합니까?
프롬프트 인젝션은 모델이 읽는 글 속에 들어 있는 지시문이 모델의 행동을 바꾸는 공격이고, 쓸 수 있는 도구가 많은 에이전트일수록 피해가 커집니다. OWASP는 이를 둘로 나눕니다. 사용자의 입력이 직접 모델 행동을 바꾸는 직접 인젝션이 있고, 웹사이트나 파일 같은 외부 출처의 글에 든 지시문이 모델 행동을 바꾸는 간접 인젝션이 있습니다. 에이전트에게 문제가 되는 쪽은 주로 간접 인젝션입니다. OWASP는 사람 눈에 보이지 않는 내용도 모델이 읽기만 하면 영향을 줄 수 있다고 적고, 이미지에 숨긴 지시문 같은 사례도 듭니다.
2023년 사전 출판본 「Not what you've signed up for」(arXiv 2302.12173)는 이 문제를 일찍 짚은 글입니다. 초록에서 저자들은 LLM을 붙인 앱이 데이터와 지시의 경계를 흐린다고 주장하고, 검색될 가능성이 높은 데이터에 지시문을 심어 사용자가 모르는 사이 공격하는 방법을 보입니다. 데이터 탈취, 웜처럼 퍼지는 감염, 정보 생태계 오염 같은 영향을 분류했고, Bing의 GPT-4 기반 채팅과 코드 자동완성 엔진에서 가능함을 시연했다고 밝힙니다. 당시 초록은 효과적인 방어책이 아직 부족하다고 적었습니다. 2023년의 평가이므로 지금 상황과 같다고 단정하지는 않겠습니다.
도구를 쥔 에이전트라면 영향이 달라집니다. NCSC는 시스템이 모델의 출력에 따라 도구나 API를 호출한다면, 공격자가 모델을 속였을 때의 피해는 공격자가 그 도구에 직접 접근했을 때의 최악의 경우와 같아진다고 설명합니다. Meta는 받은편지함을 정리해 주는 가상의 Email-Bot으로 같은 점을 보입니다. 스팸 메일 한 통에 받은편지함 내용을 모아 공격자에게 전달하라는 문장이 들어 있고, 봇에게 메일 발송 도구까지 있다면 공격이 완성됩니다.
필터로 걸러 내면 되지 않습니까?
걸러 내기만으로는 부족하다는 것이 제가 읽은 자료들의 공통된 입장입니다. NCSC의 블로그 글은 프롬프트 인젝션을 흔히 SQL 인젝션에 견주지만 이 비교가 위험하다고 말합니다. SQL 인젝션은 매개변수화된 쿼리로 데이터가 지시로 실행되는 길 자체를 막을 수 있습니다. 반면 LLM 안에는 데이터와 지시의 구분이 없고 다음 토큰을 예측하는 계산만 있어서, 프롬프트 인젝션은 같은 방식으로는 완전히 막히지 않을 가능성이 높다는 평가입니다. NCSC는 이 시스템을 '본래부터 속기 쉬운 대리인'(inherently confusable deputy)으로 보라고 제안하고, 막는 것보다 위험과 영향을 줄이는 쪽으로 접근하라고 권합니다. 남는 위험을 감당할 수 없는 업무라면 LLM에 맞는 용도가 아닐 수도 있다는 문장도 있습니다.
'이전 지시를 무시하라' 같은 문구를 걸러 내는 방식에 대해서도 NCSC는 조심하라고 합니다. 같은 뜻을 다르게 쓰는 방법이 끝없이 많아서 필터를 피해 갈 수 있다는 이유입니다. Willison은 공격의 95%를 잡는다고 내세우는 방어 제품을 깊이 의심한다고 쓰고, 웹 보안에서 95%는 낙제점에 가깝다고 말합니다. OWASP는 모델의 확률적 성질 때문에 완전한 예방법이 있는지 불분명하다고 적고, 영향을 줄이는 조치로 최소 권한, 위험이 큰 행동에 대한 사람의 승인, 외부 글의 분리 표시를 듭니다. Meta도 프롬프트 인젝션을 모든 LLM의 근본적이고 해결되지 않은 약점이라고 부릅니다.
제가 읽은 자료 가운데 완전한 해결을 주장하는 것은 없었습니다. 다만 대부분 2025년에 쓰인 글이고, 이후 모델과 방어 기법이 나아졌을 가능성은 남아 있습니다. NCSC가 2026년 5월에 낸 에이전트 도입 관련 글도 있는데, 이번에는 읽지 못했습니다.
세 가지가 한 세션에 모이면 왜 위험합니까?
서랍이 조금 열린 나무 서류함의 손잡이에 작은 놋쇠 자물쇠가 걸려 있는 장면원본 전체 보기
공격이 끝까지 가려면 낯선 글을 읽고, 훔치거나 바꿀 대상에 닿고, 바깥으로 내보낼 길이 모두 있어야 하기 때문입니다. Willison은 이를 치명적 삼중 조합(lethal trifecta)이라 부릅니다. 개인 자료에 접근할 수 있는 것, 믿을 수 없는 글에 노출되는 것, 바깥과 통신할 수 있는 것, 세 가지입니다. 그는 바깥과 통신하는 길을 넓게 봅니다. 도구가 HTTP 요청을 보낼 수 있거나 이미지를 불러오거나 사용자가 누를 링크를 보여 주기만 해도 훔친 정보를 실어 보내는 길이 될 수 있다고 씁니다. 메일을 읽는 도구는 그 자체로 믿을 수 없는 글의 통로라는 점도 짚습니다. 공격자가 에이전트 앞으로 직접 메일을 보내 무엇을 하라고 쓸 수 있기 때문입니다.
Meta의 Agents Rule of Two는 이 생각을 설계 규칙으로 옮깁니다. Chromium의 비슷한 이름의 정책과 Willison의 글에서 영감을 받았다고 밝힙니다. 규칙은 프롬프트 인젝션을 믿을 만하게 알아보고 거절하는 연구가 나올 때까지, 한 세션의 에이전트에게 아래 세 가지 중 둘까지만 주라는 것입니다.
- A: 믿을 수 없는 입력을 처리할 수 있다
- B: 민감한 시스템이나 개인 자료에 접근할 수 있다
- C: 상태를 바꾸거나 바깥과 통신할 수 있다
세 가지가 모두 필요한 일이라면 문맥 창을 비운 새 세션으로 나누지 않는 한 에이전트가 자율적으로 일하게 두지 말고, 최소한 사람의 승인이나 그에 준하는 믿을 만한 검증으로 감독해야 한다고 Meta는 씁니다. Email-Bot에 적용한 예는 이렇습니다.
- BC로 두면: 친한 친구 같은 믿을 만한 보낸 사람의 메일만 처리해 공격 문장이 문맥에 들어오지 못하게 합니다.
- AC로 두면: 민감한 자료나 시스템에 접근하지 못하게 해서 공격 문장이 들어와도 피해가 없게 합니다.
- AB로 두면: 새 메일은 믿을 만한 수신자에게만 보내거나 사람이 초안을 확인한 뒤에만 보냅니다.
Meta는 한계도 적습니다. 이 규칙을 지켜도 다른 위험, 곧 환각이나 과도한 권한, 에이전트의 실수까지 막아 주지는 않습니다. 규칙을 지킨 설계도 사용자가 경고창을 읽지 않고 확인을 누르면 무너질 수 있고, 최소 권한 같은 기본 원칙을 대신하지 못하고 보태는 규칙이라고 합니다.
설계로는 어디까지 막을 수 있습니까?
에이전트가 할 수 있는 일을 좁히는 만큼 막을 수 있고, 쓸모도 그만큼 줄어드는 대가가 따릅니다. 설계 패턴 논문(Beurer-Kellner 등, 2025년 6월 개정 3판)은 원칙을 이렇게 적습니다. 에이전트가 믿을 수 없는 입력을 한 번 받아들였다면, 그 입력이 결과가 큰 행동을 일으키는 것이 불가능하도록 에이전트를 제약해야 합니다. 논문은 이를 위한 패턴을 여럿 내놓는데, 이 글에서는 제가 읽은 세 가지만 소개합니다.
- 행동 선택기(Action-Selector): 에이전트는 미리 정해 둔 행동 목록에서 하나를 고르기만 하고, 그 행동의 결과가 에이전트에게 되먹임되지 않습니다. 고객센터 챗봇이 주문 링크 안내나 설정 페이지 안내처럼 정해진 행동만 고르는 예를 듭니다.
- 계획 후 실행(Plan-Then-Execute): 에이전트가 먼저 할 일의 목록을 정하고, 이후 도구가 돌려준 외부 글이 그 목록을 바꾸지 못하게 합니다. 논문은 이 패턴이 모든 인젝션을 막지는 못한다고 밝힙니다. 계획은 고정되어도 도구에 들어가는 입력은 공격자가 건드릴 수 있어서, 일정표 내용을 상사에게 메일로 보내는 예에서는 일정표에 심은 글이 메일 본문을 바꿀 수 있다고 설명합니다.
- 이중 LLM(Dual LLM): 도구를 쓰는 권한 있는 모델과, 믿을 수 없는 글을 읽되 도구는 쓰지 못하는 격리된 모델을 나눕니다.
NCSC 글에는 이 흐름을 한 문장으로 모은 대목이 있습니다. 모델이 어떤 상대의 정보를 처리하는 동안 모델의 권한은 그 상대의 권한 수준으로 내려간다는 규칙입니다. 이메일을 처리하는 모델이라면 모르는 외부인에게 허용하지 않을 도구에는 접근하게 하지 말라는 뜻입니다. NCSC는 이 문장을 Willison과 Baibhav Bista의 대화에서 나온 접근으로 소개합니다.
내 업무 자동화에는 어떻게 적용합니까?
맡길 일 하나마다 아래 세 칸을 적어 보는 것을 제안합니다. 이 표는 위 자료를 읽고 DMS.Labs가 만든 것이고, 어느 자료가 시험한 문장이 아닙니다.
표가 넓으면 좌우로 스크롤하여 확인하세요.
| 칸 | 물을 것 | '예'일 때 먼저 할 일 |
|---|---|---|
| A. 낯선 글 | 이 일을 하는 동안 외부 사람이 쓴 글(받은 메일, 웹 페이지, 업로드 파일, 외부 게시판)을 읽습니까? | 읽는 출처를 일에 필요한 곳으로 줄입니다 |
| B. 민감한 자료 | 같은 세션에서 고객 연락처, 내부 문서, 계정 권한에 닿습니까? | 그 일에 필요한 파일 하나만 열고 나머지는 접근을 끊습니다 |
| C. 바깥으로 나가는 길 | 메일 발송, 파일 삭제, 게시, 외부 주소 요청(링크와 이미지 불러오기 포함)이 가능합니까? | 보낼 수 있는 주소를 미리 정한 목록으로 제한하고 나머지는 사람이 승인합니다 |
'예'가 둘 이하면 그 조합에 맞는 보강 하나를 정합니다. 셋이면 Meta의 설명대로 그 일을 자율로 돌리지 않고 사람의 승인 자리를 둡니다. 조합별로 어느 칸을 닫을지는 Meta의 세 구성을 업무 말로 옮긴 아래 표를 참고합니다.
표가 넓으면 좌우로 스크롤하여 확인하세요.
| 남기는 두 칸 | 닫는 칸 | 닫는 방법의 예 |
|---|---|---|
| A와 C | B | 공개 자료 조사처럼 내부 자료에 접근하지 않는 일로 한정합니다 |
| B와 C | A | 미리 등록한 거래처나 내부 직원이 보낸 글만 읽게 합니다 |
| A와 B | C | 읽고 요약하거나 초안을 만드는 데서 멈추고, 보내는 일은 사람이 합니다 |
가상의 장면으로 써 보겠습니다. 직원 다섯 명의 견적 접수 업체가 있다고 가정하겠습니다. 실제 사례가 아니라 설명을 위해 만든 장면입니다. 이 업체가 에이전트에게 문의 메일함을 읽고, 고객 연락처 시트를 참고해, 답장을 바로 보내게 합니다. 세 칸이 모두 '예'입니다. 문의 메일은 누구나 보낼 수 있으니 A이고, 연락처 시트는 B이며, 답장 발송은 C입니다. 점검표대로라면 발송 칸을 닫습니다. 에이전트는 초안을 임시 저장함에 두는 데서 멈추고, 보내는 일은 사람이 맡습니다. 낯선 메일 속 문장이 연락처 목록을 밖으로 실어 나르는 길이 막히는 대신, 발송할 때마다 사람이 한 번 확인하는 시간이 듭니다.
위험도 남습니다. 사용자가 경고를 읽지 않고 확인만 누르면 설계가 무너진다는 Meta의 지적을 떠올리면, 승인 화면에는 받는 주소와 본문 전체가 보여야 한다고 생각합니다. 제가 확인한 자료에는 이 방식이 실제 업무에서 승인 피로를 얼마나 줄이는지 잰 값이 없습니다. 이 장면의 효과도 직접 시험하지 않았습니다.
이 점검표가 막지 못하는 것은 무엇입니까?
제가 보기에 가장 큰 한계는 세 칸을 정확히 적는 일이 사람 몫이라는 점입니다. C에는 메일 발송 같은 뚜렷한 행동만 있지 않습니다. 앞서 본 Willison의 설명처럼 외부 주소로 나가는 요청이나 이미지 불러오기도 C가 될 수 있고, OWASP의 사례처럼 웹 페이지 요약 중 삽입된 이미지 링크가 대화 내용을 바깥으로 보낼 수도 있습니다. 그래서 도구 목록을 읽을 때 이름보다 그 도구가 바깥으로 요청을 보낼 수 있는지를 봐야 합니다. 도구 연결 전에 확인할 점은 MCP 서버 연결 전 확인 다섯 가지에 정리했습니다.
두 번째 한계는 계획 후 실행 패턴이 보여 준 틈입니다. 일 자체를 막아도, 일에 들어가는 입력이 공격받으면 결과물이 오염됩니다. 이 점검표는 결과가 큰 행동의 길을 줄이는 도구이고, 결과물이 맞는지를 가려 주지는 않습니다. 결과물의 검수자를 정하는 방법은 AI 결과 검수자 정하기에 썼습니다.
마지막으로, NCSC는 시스템이 공격자의 목표와 정상 동작을 이해하고 모델의 입출력과 도구 호출을 충분히 기록해 의심스러운 활동을 알아볼 수 있어야 한다고 권합니다. 실패한 도구 호출은 공격의 초기 단계일 수 있어서입니다. 점검표만 만들고 기록을 남기지 않으면 뚫렸는지도 알기 어렵습니다.
이번 주에 무엇을 해 볼 수 있습니까?
지금 쓰는 자동화나 AI 도구 하나를 골라 세 칸을 적습니다. '예'가 셋이라면 어느 칸을 닫을지 정하고, 닫기 어렵다면 그 일에 사람의 승인 자리를 먼저 둡니다. 이 글이 확인하지 못한 것을 정리하면 이렇습니다. 직접 공격을 시험하지 않았습니다. 점검표가 실제 업무에서 피해를 얼마나 줄이는지는 모릅니다. Meta 글의 사례도 가상이며, 2025년 자료를 중심으로 읽었습니다. 표와 가상 장면은 DMS.Labs의 제안과 가정이고 고객 사례나 현장 측정이 아닙니다.
다음에 볼 것
업무 자동화에 AI를 어떻게 붙일지는 DMS.Labs 업무 자동화 페이지에서 볼 수 있습니다. 자동화에 어디까지 권한을 줄지 단계로 나누는 방법은 AI 자동화, 권한을 세 단계로 나눠 주기에 정리했습니다. 도입을 검토 중이시라면 문의 페이지에 상황을 적어 보내 주십시오.
참고한 자료
2026년 11월 9일에 확인했습니다. 이 글의 사진 두 장은 AI로 만든 예시 이미지이며 실제 작업 기록이 아닙니다.
- Meta, 「Agents Rule of Two: A Practical Approach to AI Agent Security」, 2025년 10월 31일: 원문 (전문 읽음)
- NCSC, David C, 「Prompt injection is not SQL injection (it may be worse)」, 2025년 12월 8일: 원문 (전문 읽음)
- OWASP, 「LLM01:2025 Prompt Injection」: 원문 (전문 읽음)
- Simon Willison, 「The lethal trifecta for AI agents」, 2025년 6월 16일: 원문 (전문 읽음, 개인 블로그)
- Luca Beurer-Kellner 등, 「Design Patterns for Securing LLM Agents against Prompt Injections」, arXiv 2506.08837 v3: 원문 (패턴 소개 부분을 읽음)
- 「Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection」, arXiv 2302.12173 v2: 원문 (초록만 읽음)
