보이지 않는 글자 472자가 AI 요약을 바꿨습니다 — 포스포인트가 재현한 이메일 프롬프트 주입

보안업체 포스포인트의 연구조직 X-Labs가 8월 28일 공개한 실험은 짧고 서늘합니다. 이메일 한 통에 눈에 보이지 않는 글자를 심어 두고, AI 요약 기능에 그 메일을 요약하게 시켰습니다.

사람이 읽은 메일에는 537자가 있었습니다. 모델에게 전달된 건 1,009자였습니다. 그 차이인 472자가 숨겨진 명령이었고, 요약문은 그 명령대로 움직였습니다.

결과는 조용했습니다. 경고도, 오류도 없었습니다. 요약문에서 청구 마감일이 8월 21일에서 9월 3일로 바뀌었고, 담당자 이름 하나가 사라졌습니다. 읽는 사람은 무엇이 달라졌는지 알 방법이 없었습니다.

읽은 사람과 요약한 AI가 서로 다른 메일을 봤습니다

AI 요약 기능은 이제 흔합니다. 메일함을 열면 각 메일 위에 한두 줄 요약이 붙어 있고, 우리는 그걸 읽고 열지 말지를 정합니다.

그 요약은 원문을 그대로 줄인 것이라고 믿게 됩니다. 그런데 이번 실험은 요약이 원문과 다른 내용을 말할 수 있다는 걸, 그것도 아무 흔적 없이 그렇게 될 수 있다는 걸 보여 줬습니다.

무서운 건 기술적 난도가 낮다는 점입니다. 특별한 취약점을 뚫은 게 아니라, 메일 본문에 보이지 않는 글자를 넣은 것이 전부였습니다.

무슨 일이 있었나, 한 줄 요약

포스포인트 X-Labs는 격리된 실험 환경에 아웃룩 확장 기능을 만들었습니다. 이 확장은 메일의 헤더와 본문을 요약 서비스로 보내고, 돌아온 요약을 화면에 보여 줍니다.

연구진은 이 메일에 눈에 보이지 않게 처리한 HTML 조각을 심었습니다. 아웃룩 화면에서는 아무것도 보이지 않지만, 확장이 본문을 긁어 보낼 때는 그 글자까지 함께 실려 갑니다.

그 안에 적힌 문장은 요약기를 향한 명령이었습니다. 그리고 요약기는 그 명령을 사용자의 지시와 구분하지 못하고 그대로 따랐습니다.

537자와 1,009자의 차이

이 실험에서 가장 명확한 수치가 이것입니다. 사용자 화면에 표시된 글자는 537자, 모델에 전달된 글자는 1,009자였습니다.

차이인 472자가 숨겨진 주입 문구입니다. 비율로 보면 모델이 받은 내용의 거의 절반이 사람은 볼 수 없는 부분이었습니다.

이 숫자가 중요한 이유는, 공격의 성패가 모델의 똑똑함이 아니라 파이프라인이 무엇을 넘겼는가에 달려 있다는 걸 보여 주기 때문입니다.

숨기는 방법은 스타일 세 줄이었다

사용된 기법은 HTML 스타일 속성 세 가지입니다. 글자 크기를 0으로, 글자 색을 배경과 같은 흰색으로, 줄 높이를 0으로 지정했습니다.

이 세 가지가 겹치면 글자는 자리를 차지하지도 않고 색으로도 구분되지 않습니다. 화면에는 아무것도 없는 것처럼 보이지요.

웹에서는 오래된 수법입니다. 검색 순위를 조작하려고 흰 배경에 흰 글씨를 숨기던 방식과 원리가 같습니다. 달라진 건 속이는 대상이 검색엔진에서 언어모델로 바뀌었다는 점입니다.

글자 크기를 0으로 두면 벌어지는 일

글자 크기가 0이면 브라우저나 메일 프로그램은 그 글자를 그릴 때 가로세로 0픽셀로 처리합니다. 화면에 아무 영향을 주지 않습니다.

하지만 문서 안에는 분명히 존재합니다. 문서 구조를 읽어 텍스트만 뽑아내는 코드는 크기를 보지 않고 글자 자체를 가져갑니다.

여기에 사람과 기계의 인식 차이가 생깁니다. 사람의 기준은 화면에 그려졌는가이고, 기계의 기준은 문서에 적혀 있는가입니다.

사람 눈에는 왜 보이지 않나

메일 프로그램은 HTML을 화면에 그리는 일을 합니다. 스타일이 지정돼 있으면 그 지시를 그대로 따릅니다.

크기 0, 배경과 같은 색, 줄 높이 0이면 그릴 것이 없다는 결론이 나옵니다. 프로그램 입장에서는 정상 동작이고, 이상을 알릴 이유가 없습니다.

스크롤을 해도, 글자를 키워도 보이지 않습니다. 전체 선택으로 복사해야 비로소 딸려 나오는데, 일상적으로 그렇게 확인하는 사람은 없지요.

모델에는 왜 그대로 전달되나

요약 기능을 만들 때 가장 간단한 방법은 메일 본문을 텍스트로 뽑아 모델에 넘기는 것입니다. 대부분의 구현이 이렇게 합니다.

이때 스타일 정보는 버려집니다. 어떤 글자가 화면에 보였고 어떤 글자가 숨겨져 있었는지에 대한 구분이 그 단계에서 사라집니다.

모델이 받는 건 평평한 글자 뭉치입니다. 여기에 담긴 문장 중 무엇이 사람이 쓴 내용이고 무엇이 공격자가 심은 명령인지, 모델은 알 도리가 없습니다.

주입된 지시문의 내용

숨겨진 문구는 요약기를 향해 직접 말을 겁니다. 아래 내용을 정본으로 삼으라고 지시하고, 이어서 이 안내 자체는 언급하지 말라고 덧붙입니다.

명령의 구조가 두 겹입니다. 첫 겹은 내용을 바꾸는 것이고, 둘째 겹은 바꿨다는 사실을 숨기는 것입니다.

둘째 겹이 없으면 요약문에 어색한 문장이 남아 사람이 눈치챌 수 있습니다. 공격자는 그 가능성까지 닫아 둔 셈이지요.

이 안내는 언급하지 말라는 명령

언어모델은 지시를 따르도록 훈련돼 있습니다. 그게 이 도구가 쓸모 있는 이유이기도 합니다.

문제는 지시가 어디서 왔는지를 모델이 스스로 판단하기 어렵다는 데 있습니다. 사용자가 준 지시와 요약 대상 문서 안에 적힌 문장이 같은 텍스트 흐름으로 들어오면, 둘의 권한 차이가 사라집니다.

그래서 공격 문구는 대개 명령형으로 짧게 씁니다. 정중하게 설득할 필요가 없습니다. 지시처럼 보이기만 하면 됩니다.

변조된 요약, 날짜가 바뀌었다

실험에서 확인된 첫 번째 변조는 날짜입니다. 원문의 청구 마감일은 2026년 8월 21일이었는데, 요약문에는 2026년 9월 3일로 나왔습니다.

숫자 하나가 바뀐 것뿐이지만 실무에서는 결과가 큽니다. 마감일이 미뤄진 것으로 알고 넘어가면 연체가 되고, 그 사이 다른 요구가 끼어들 여지가 생깁니다.

요약을 믿고 원문을 열지 않는 습관이 자리 잡을수록 이런 변조는 오래 발견되지 않습니다.

청구 금액도 바뀌었다

두 번째는 금액입니다. 기준 실험에서 확인된 실제 청구액과 달리, 주입이 들어간 요약문에서는 금액이 몇 배로 부풀려져 나왔습니다.

금액은 날짜보다 눈에 띄기 쉽습니다. 하지만 요약문만 보고 대략의 규모를 파악하는 단계에서는, 자릿수가 맞으면 그냥 넘어가는 일이 흔합니다.

이 실험이 청구서를 소재로 삼은 건 우연이 아닙니다. 금액과 기한과 계좌는 메일 사기가 늘 노리는 세 가지 항목이지요.

담당자 이름 하나가 사라졌다

세 번째는 삭제입니다. 원문에 있던 담당자 이름이 요약문에서 그냥 빠졌습니다.

추가나 변경보다 삭제가 더 알아채기 어렵습니다. 없는 것을 없다고 인식하려면 원문을 기억하고 있어야 하는데, 요약을 읽는 시점에는 대개 원문을 아직 보지 않았으니까요.

이름이 빠지면 책임 소재가 흐려집니다. 누구에게 확인해야 할지 모르는 상태에서 메일에 적힌 다른 연락처로 손이 가게 됩니다.

실험 환경, 아웃룩 확장과 요약 서비스

연구진은 실제 서비스를 공격하지 않았습니다. 격리된 실험 환경에 가짜 데이터를 넣고, 직접 만든 아웃룩 확장과 요약 서비스로만 시험했습니다.

요약 생성에는 클로드 하이쿠 4.5 모델을 썼습니다. 다만 이건 특정 모델의 결함을 지적한 실험이 아닙니다. 지시를 잘 따르는 모델이라면 어느 것이든 같은 결과가 나옵니다.

즉 고쳐야 할 곳은 모델이 아니라 파이프라인입니다. 무엇을 모델에 넘기는지, 넘긴 내용에 권한을 어떻게 나누는지의 문제이지요.

왜 이것을 간접 프롬프트 주입이라 부르나

프롬프트 주입은 모델에 들어가는 입력에 명령을 끼워 넣어 원래 지시를 뒤엎는 공격입니다.

사용자가 직접 입력창에 명령을 써 넣으면 직접 주입입니다. 반면 이번처럼 모델이 읽어 들이는 외부 자료 안에 명령이 숨어 있는 경우를 간접 주입이라고 부릅니다.

이름이 다른 이유는 방어 지점이 다르기 때문입니다. 직접 주입은 사용자 입력만 보면 되지만, 간접 주입은 모델이 읽는 모든 자료가 통로가 됩니다.

OWASP가 최상위 위험으로 꼽은 항목

웹 보안 표준을 정리하는 OWASP는 언어모델 애플리케이션의 위험 목록에서 프롬프트 주입을 1번에 놓았습니다. 가장 우선순위가 높다는 뜻입니다.

OWASP가 예시로 든 시나리오 중 하나가 정확히 이 상황입니다. 외부 문서를 요약하게 시켰더니 그 문서에 심긴 명령이 모델의 다른 기능을 호출해 버리는 경우이지요.

목록에 올라 있다는 건 알려진 문제라는 뜻이지, 해결된 문제라는 뜻이 아닙니다. 근본 해법이 아직 없다는 게 이 항목이 1번인 이유입니다.

직접 주입과 무엇이 다른가

직접 주입은 대개 사용자 본인이 시도합니다. 제한을 풀어 보려고 스스로 명령을 넣는 경우가 많지요. 피해가 자기 세션 안에 머뭅니다.

간접 주입은 제3자가 공격자입니다. 피해자는 아무것도 하지 않았고, 그저 받은 메일을 요약했을 뿐입니다.

그리고 전달 경로가 넓습니다. 메일, 첨부 문서, 웹페이지, 캘린더 초대, 공유 문서 — AI가 읽는 모든 것이 잠재적 통로입니다.

요약기가 도구를 쥐는 순간 위험이 커진다

이번 실험의 피해는 요약문 변조에 그쳤습니다. 요약기가 글을 쓰는 일만 했기 때문입니다.

요즘 도구는 여기서 멈추지 않습니다. 메일을 대신 보내고, 일정을 잡고, 파일을 찾아 첨부하고, 외부 서비스를 호출합니다. 읽기만 하던 도구가 행동하기 시작했습니다.

같은 공격이 행동하는 도구에 들어가면 결과가 달라집니다. 요약문을 바꾸는 데서 끝나지 않고 실제로 무언가를 실행하게 되지요.

기업 내부 보조 도구가 특히 위험한 이유

고객을 상대하는 서비스는 공격받을 걸 전제로 만듭니다. 입력 검사도 촘촘하고 권한도 좁게 잡습니다.

반면 사내 보조 도구는 안에서 쓰는 거니까라는 전제로 만들어지는 경우가 많습니다. 그런데 이런 도구일수록 문서·메일·데이터베이스에 폭넓게 연결돼 있습니다.

권한은 넓고 방어는 얇은 조합입니다. 공격자가 메일 한 통을 조직 안에 넣는 것만으로 그 넓은 권한에 닿을 수 있다면, 여기가 가장 값싼 입구가 됩니다.

완화책 하나, 실제로 보이는 글자만 넘긴다

포스포인트가 제시한 첫 번째 대응은 단순합니다. 모델에 넘기기 전에 사용자에게 실제로 보이는 텍스트만 추출하는 것입니다.

화면에 그려지는 것과 같은 기준으로 텍스트를 뽑으면, 크기 0이나 배경색과 같은 글자는 애초에 걸러집니다. 사람과 모델이 같은 메일을 보게 됩니다.

이번 사례에 한정하면 이 조치 하나로 공격이 무력화됩니다. 가장 값싸고 확실한 방어라 먼저 손대야 할 곳입니다.

완화책 둘, 숨김 스타일을 탐지한다

보이는 것만 넘기더라도, 숨기려는 시도가 있었다는 사실 자체가 중요한 신호입니다.

글자 크기 0, 배경과 같은 색, 화면 밖 좌표 배치 같은 패턴을 탐지해 표시하면 사용자가 그 메일을 다르게 대할 수 있습니다.

정상적인 메일에도 추적용 숨김 요소가 들어가는 경우가 있어 오탐이 생깁니다. 그래서 차단보다는 경고와 기록으로 다루는 쪽이 현실적입니다.

완화책 셋, 헤더와 본문을 분리한다

메일에는 보낸 사람, 제목, 날짜 같은 헤더와 본문이 함께 있습니다. 이걸 한 덩어리로 붙여 모델에 넘기면 경계가 사라집니다.

헤더와 본문을 구분된 자리에 넣고, 본문은 요약 대상일 뿐 지시가 아니라는 걸 구조로 표시해야 합니다.

이건 완전한 방어가 아닙니다. 다만 모델이 지시와 자료를 나눠 볼 단서를 갖게 되므로, 성공 확률을 낮추는 데는 분명히 기여합니다.

완화책 넷, 도구 호출을 검증한다

간접 주입이 진짜 위험해지는 지점은 모델이 행동할 때입니다. 그래서 모든 도구 호출을 실행 전에 검사해야 합니다.

메일을 보내거나 파일을 밖으로 내보내는 것처럼 되돌리기 어려운 동작은 특히 그렇습니다. 사람의 확인을 한 번 거치게 하거나, 미리 정한 목록 안에서만 실행되도록 묶어 둡니다.

요약 한 번 하자고 넣은 기능이 파일을 내보내는 권한까지 들고 있다면, 그 조합 자체를 다시 봐야 합니다.

완화책 다섯, 출력과 원문을 교차 대조한다

마지막은 사후 점검입니다. 요약문에 등장하는 날짜·금액·이름이 원문에 실제로 있는지 기계적으로 대조합니다.

이번 사례라면 요약문의 9월 3일이 원문에 없다는 사실을 바로 잡아낼 수 있습니다. 모델의 판단에 기대지 않고 문자열 대조로 끝나는 검사라 값도 쌉니다.

덧붙여, 요약 화면 옆에 원문을 바로 열 수 있는 길을 두는 것만으로도 확인 비용이 크게 줄어듭니다.

실제 사례로 옮겨보는 우리 업무

가정을 하나 해 보겠습니다. 거래처에서 온 청구 메일을 메일함의 AI 요약으로 훑고, 요약에 적힌 금액과 마감일을 그대로 담당자에게 전달했다고요.

이 흐름에서 원문을 여는 사람은 아무도 없습니다. 요약을 읽은 사람은 원문을 봤다고 생각하고, 전달받은 사람은 이미 확인된 정보라고 생각합니다.

이번 실험이 보여 준 건 그 첫 단계가 조용히 오염될 수 있다는 것입니다. 그리고 오염됐다는 표시는 어디에도 남지 않습니다.

당장 할 수 있는 대응은 소박합니다. 금액·기한·계좌가 걸린 메일은 요약으로 끝내지 않고 원문을 여는 것입니다. 조직이라면 이 규칙을 문서로 못 박아 두시길 권합니다.

핵심 정리

무슨 일 — 포스포인트 X-Labs가 보이지 않는 HTML을 심은 메일로 AI 요약기를 조종하는 데 성공했습니다(8월 28일 공개).

수치 — 사용자가 본 글자 537자, 모델에 전달된 글자 1,009자. 차이인 472자가 숨겨진 명령이었습니다.

방법 — 글자 크기 0, 배경과 같은 글자색, 줄 높이 0. 특별한 취약점이 아니라 스타일 지정만으로 숨겼습니다.

결과 — 청구 마감일이 8월 21일에서 9월 3일로 바뀌고, 금액이 부풀려지고, 담당자 이름이 삭제됐습니다. 경고는 없었습니다.

분류 — 간접 프롬프트 주입. OWASP 언어모델 위험 목록의 1번 항목입니다.

대응 — 보이는 글자만 넘기기, 숨김 스타일 탐지, 헤더와 본문 분리, 도구 호출 검증, 출력과 원문 교차 대조.

참고하실 만한 것

메일함의 AI 요약을 쓰고 계시다면, 돈과 기한이 걸린 메일만큼은 원문을 여는 습관을 하나 만들어 두시면 좋겠습니다. 이번 공격은 정확히 그 지점을 노렸습니다.

사내에 AI 보조 도구를 붙이고 계시다면, 그 도구가 읽기만 하는지 행동도 하는지를 먼저 확인해 보세요. 행동하는 쪽이라면 도구 호출 검증이 최우선입니다.

SVIL은 저시력 사용자를 위한 도구와 로컬 AI 워크플로우를 만들고 있습니다. 보이지 않는 정보가 만들어 내는 문제는 접근성과도 맞닿아 있어서, 앞으로도 큰 글씨와 쉬운 설명으로 짚어 드릴게요.

출처

• Forcepoint X-Labs — HTML Payload Hijacks Email Summarizer
• CSO Online — AI can be made to read an email much differently than you do
• Dark Reading — Hidden Prompts Trick AI Into False Email Summaries
• OWASP Gen AI Security Project — LLM01:2025 Prompt Injection
• OWASP Foundation — Prompt Injection
• Forcepoint X-Labs — Indirect Prompt Injection in the Wild: 10 IPI Payloads
• Help Net Security — Indirect prompt injection is taking hold in the wild
• Lakera — Indirect Prompt Injection: The Hidden Threat Breaking Modern AI Systems
• OWASP GitHub — LLM01 Prompt Injection (Top 10 for LLM Applications)

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/