웹메일 CSS 공격, AI 이메일 방어의 사각지대 드러내

Google News는 2026년 4월 이후 100만 건이 넘는 피싱 메시지에서 확인된 웹메일 CSS 공격을 조명했다. 이 캠페인은 AI 이메일 보안의 근본적인 충돌을 드러낸다. 사람과 기계는 같은 메시지를 받아도 전혀 다른 내용을 읽을 수 있다.

텍스트 솔팅(text salting)으로 불리는 이 기법은 Cascading Style Sheets를 사용해 HTML 이메일 안에 채움 텍스트를 숨긴다. 이 숨겨진 내용은 수신자가 보는 화면은 바꾸지 않으면서 자동화 시스템이 메시지를 해석하는 방식을 바꾼다.

Barracuda 연구진은 보상, 기프트 카드, 로열티 포인트 또는 긴급 교환을 약속하는 소매업 테마의 피싱 캠페인에서 이 기법을 발견했다. 공격자들은 의심스러운 표현을 희석하고 악성 이메일이 자동화 필터에 더 안전한 것처럼 보이게 하기 위해 숨겨진 텍스트를 사용했다.

이는 단순한 스팸 필터 우회 기법이 아니다. 같은 가시성 격차는 반대 방향으로도 작동할 수 있다. 숨겨진 지침은 이메일을 요약하고, 답장을 작성하고, 사서함을 검색하거나 연결된 도구를 호출하는 AI 어시스턴트를 겨냥할 수 있다.

이로 인해 핵심적인 보안 상충 관계가 생긴다. AI 이메일 도구는 더 많은 맥락을 읽고 더 큰 접근 권한을 받을수록 유용해진다. 그러나 이러한 역량은 신뢰할 수 없는 이메일 콘텐츠가 모델에 영향을 미칠 때의 결과도 키운다.

기존 방어 체계는 사람이 보는 메시지와 소프트웨어가 검사하는 메시지가 대체로 동등하다고 가정한다. CSS는 하나의 이메일 안에 사람에게 보이는 버전과 기계가 읽을 수 있는 버전을 별도로 만들어 이 가정을 무너뜨린다.

당장의 압박은 Google, Microsoft, 이메일 보안 업체, 그리고 사서함 데이터를 기반으로 어시스턴트를 개발하는 개발자들에게 가해진다. 이들은 접근성과 정상적인 서식을 보존하면서 원본 메시지 분석과 렌더링된 콘텐츠를 조화시켜야 한다.

Google News 보도가 보여주는 텍스트 솔팅의 실체

중요한 변화는 공격자들이 숨겨진 텍스트를 발견했다는 점이 아니다. 오래된 우회 기법이 이제 AI 기반 판단 체계를 상대로 작동한다는 점이다.

텍스트 솔팅은 악성 메시지에 무해하거나 문맥상 관련 없는 단어를 추가한다. 보안 소프트웨어는 이 단어들을 분석하지만, CSS는 수신자가 이를 보지 못하게 한다.

Barracuda는 2026년 4월 이후 이러한 기법을 사용한 100만 건의 공격을 탐지했다고 밝혔다. 이 메시지들은 보상과 교환 제안을 중심으로 구성된 소매업 테마 캠페인에 속했다.

공격자들은 몇 가지 일반적인 CSS 속성을 사용했다. clip-path: inset(100%)는 텍스트 블록의 보이는 영역을 완전히 없앴다. 높이와 줄 높이를 0으로 설정하는 규칙은 의심스러운 빈 공간을 제거했다.

다른 규칙은 텍스트를 화면 경계 밖으로 밀어냈다. 큰 음수 text-indent는 텍스트를 왼쪽으로 수천 픽셀 이동시켰고, overflow: hidden은 이를 드러낼 스크롤바를 숨겼다.

공격자들은 글꼴 크기도 0으로 줄였다. 이 속성들 자체가 본질적으로 악성인 것은 아니다. 정상적인 이메일 템플릿도 유사한 스타일링 기법을 사용할 수 있기 때문에, 이러한 모호성은 단순한 차단 목록을 신뢰하기 어렵게 만든다.

이 캠페인은 탈취된 웹사이트나 유사 도메인에 의존한 것으로 전해졌다. 일부 도메인은 메시지가 권한 있는 도메인에 의해 서명됐는지 검증하는 DomainKeys Identified Mail, 즉 DKIM을 포함한 표준 이메일 인증을 지원했다.

DKIM은 콘텐츠가 정직한지 판단하지 않는다. 이는 도메인 수준의 메시지 처리와 무결성을 검증한다. 인증된 도메인을 통제하는 악성 운영자는 여전히 피싱을 유포할 수 있다.

이 구분은 AI 시스템이 흔히 많은 신호를 결합한다는 점에서 중요하다. 인증, 자연어, 발신자 평판, 눈에 보이는 링크, 메시지 구조는 각각 분류 결과에 영향을 줄 수 있다.

텍스트 솔팅은 언어 신호를 조작한다. 사람 수신자에게는 피싱 유인이 분명하게 보이도록 유지하면서, 분류기에는 무해해 보이는 더 많은 텍스트를 제공한다.

원본 HTML을 검사하는 필터는 관련 없는 비즈니스 활동, 고객 서비스 또는 일반적인 소매 거래에 관한 문단을 마주할 수 있다. 반면 수신자는 긴급한 보상 안내와 버튼만 보게 될 수 있다.

이는 적대적 입력의 의미론적 버전을 만든다. 공격자는 반드시 소프트웨어 메모리 취약점을 악용하는 것이 아니다. 대신 통계적 의사결정 시스템이 사용하는 증거를 형성한다.

생성형 AI는 다양한 채움 텍스트를 만드는 비용도 낮춘다. 공격자들은 메시지마다 서로 다른 무해한 문단을 만들 수 있어, 정확한 텍스트 일치의 가치를 낮춘다.

따라서 Google News의 헤드라인은 더 광범위한 변화를 가리킨다. 이제 이메일 콘텐츠는 두 개의 수신자를 위해 설계될 수 있으며, 사용자에게는 하나의 이야기를, 기계에는 다른 이야기를 전달한다.

AI 이메일 필터가 렌더링 문제에 직면하는 이유

AI 모델의 입력이 수신자에게 표시되는 메시지와 일치하지 않는다면, 이메일을 신뢰성 있게 판단할 수 없다.

많은 이메일 보안 시스템은 원본 메시지 콘텐츠에 유용한 증거가 담겨 있기 때문에 이를 검사한다. 원본 콘텐츠는 URL, HTML 속성, 메타데이터, 인코딩된 섹션, 그리고 렌더링 과정에서 숨겨질 수 있는 텍스트를 드러낸다.

이 접근법은 숨겨진 텍스트가 주로 키워드 기반 스팸 점수를 겨냥하던 시절에는 타당했다. 방어자는 의심스러운 서식을 찾고 눈에 보이는 단어와 원본 소스를 비교할 수 있었다.

대규모 언어 모델은 이 과정을 복잡하게 만든다. 긴 문맥 전반에 걸쳐 의미를 추론할 수 있지만, 그 능력은 숨겨진 채움 텍스트가 분류에 미치는 영향도 키운다.

모델은 일반적인 소매업 언어가 지배적인 메시지를 볼 수 있다. 눈에 보이는 피싱 요청은 기계가 읽을 수 있는 전체 입력 중 극히 작은 부분만 차지할 수 있다.

이 공격은 모델이 직접적인 명령을 따를 필요가 없다. 겉으로 드러나는 주제, 어조 또는 의도를 충분히 바꿔 무해한 분류 결과를 내게 하면 성공할 수 있다.

렌더링 분석에는 그 자체의 문제가 있다. 이메일 클라이언트마다 HTML과 CSS 지원 방식이 다르다. 같은 메시지도 Gmail, Outlook, 모바일 애플리케이션, 특수 웹메일 소프트웨어에서 다르게 표시될 수 있다.

접근성 기능 역시 기본 시각 렌더링에서 숨겨진 텍스트를 노출할 수 있다. 스크린 리더, 고대비 모드, 단순화된 보기 기능은 하나의 결정적인 표시 상태가 존재한다는 주장에 복잡성을 더한다.

따라서 보안 도구에는 스크린샷 이상이 필요하다. 원본 콘텐츠, 계산된 레이아웃, 접근성 출력, 그리고 일반적인 사용자가 인지할 수 있는 요소를 구조적으로 비교해야 한다.

가장 유용한 질문은 특정 속성이 단독으로 의심스러워 보이는지 여부가 아니다. 스타일링이 기계의 해석과 사람의 인식 사이에 의미 있는 차이를 만드는지 여부다.

관련 없는 단어 수백 개를 담은 크기 0의 문단은 단일 숨김 서식 레이블보다 더 강력한 신호다. 화면 밖으로 크게 밀려난 블록도 유사한 수준의 검토가 필요하다.

방어자는 눈에 보이는 영역과 숨겨진 영역의 언어적 의미도 비교할 수 있다. 로열티 보상에 관한 메시지에 관련 없는 청구서, 여행 또는 고객 지원 관련 문단이 숨겨져 있어서는 안 된다.

그러나 공격자들은 적응할 수 있다. 악성 문구를 희석하면서도 의미론적 차이를 줄이기 위해, 눈에 보이는 주제와 가까운 채움 텍스트를 생성할 수 있다.

이로 인해 콘텐츠 생성과 가시성 인지형 탐지 사이의 군비 경쟁이 벌어진다. 필터는 메시지가 무엇을 말하는지뿐 아니라, 그중 어떤 부분이 이를 받는 사람에게 중요한지도 이해해야 한다.

머신러닝이 여기서 쓸모없는 것은 아니다. 여전히 구조적 이상 징후, 발신자 패턴, 캠페인 인프라, 비정상적인 스타일링 규칙 조합을 찾아내는 데 유용하다.

문제는 아키텍처 수준의 과신이다. 언어 모델은 신뢰된 지침, 신뢰할 수 없는 콘텐츠, 보이지 않는 자료를 명확한 경계 없이 섞는 입력 파이프라인을 보완할 수 없다.

Google은 간접 프롬프트 인젝션에 대응하기 위한 다층 방어를 설명한 바 있다. 이 접근법에는 콘텐츠 분류기, 적대적 훈련, 레드 팀 테스트, 민감한 작업 전 확인 절차가 포함된다.

이러한 통제는 이메일 방어가 나아가야 할 방향을 보여준다. 특히 CSS가 관찰자마다 다른 내용을 전달할 때는, 단일 모델의 판정만으로 메시지의 안전 여부를 결정해서는 안 된다.

숨겨진 콘텐츠는 필터나 어시스턴트를 겨냥할 수 있다

같은 CSS 가시성 격차는 두 가지 상반된 공격을 뒷받침한다. 사람에게서 무해한 텍스트를 숨기거나, 사람에게서 악성 지침을 숨기는 것이다.

텍스트 솔팅은 보안 시스템에 악성 이메일이 무해해 보이도록 만들려 한다. 간접 프롬프트 인젝션은 AI 어시스턴트가 사용자가 의도적으로 제공한 적 없는 지침을 따르게 하려 한다.

OWASP는 간접 프롬프트 인젝션을 AI 시스템이 나중에 처리하는 외부 콘텐츠에 삽입된 악성 지침으로 정의한다. 누구나 많은 사서함에 입력을 보낼 수 있기 때문에 이메일은 자연스러운 전달 채널이다.

공격자는 흰색 텍스트, 크기 0의 글꼴, 화면 밖 배치, 인코딩된 문자 또는 시각 렌더러가 생략하는 HTML 구조를 사용해 지침을 숨길 수 있다.

피해자는 어시스턴트에게 읽지 않은 메시지를 요약해 달라고 요청할 수 있다. 자율 워크플로는 직접적인 요청 없이 받은편지함을 처리할 수도 있다. 어느 경우든 모델은 공격자가 작성한 지침을 마주할 수 있다.

단순한 공격은 요약을 조작할 수 있다. AI는 보안 경고를 꾸며내거나, 피싱 징후를 숨기거나, 악성 메시지를 승인된 것으로 설명할 수 있다.

어시스턴트가 다른 메시지를 검색하고, 연결된 문서를 읽고, 외부 이메일 초안을 작성하거나, 외부 도구를 호출할 수 있다면 더 심각한 공격이 가능해진다.

이때 악성 이메일은 제어 입력으로 작동한다. 사용자의 작업에서 어시스턴트를 데이터 검색, 정보 공개 또는 무단 작업으로 돌리려 시도할 수 있다.

Microsoft는 2026년 7월 Defender for Office 365에서 받은편지함 인젝션 보호를 발표했다. 이 기능은 자격을 갖춘 고객을 대상으로 공개 미리 보기로 출시됐다.

Microsoft는 이 시스템이 메일 흐름 검사 중 악성 AI 지침을 탐지한다고 밝혔다. 탐지된 메시지는 높은 신뢰도의 피싱 판정을 받고 사용자나 연결된 어시스턴트에 도달하기 전에 격리될 수 있다.

이 배치가 중요하다. 전달 전에 공격을 차단하면 사서함 검색 인덱스, 검색 시스템, 요약, 그리고 하위 에이전트 컨텍스트로 유입되는 것을 막을 수 있다.

그러나 게이트웨이에서의 탐지만으로 모든 사례를 해결할 수는 없다. 공격자는 탈취된 내부 계정, 허용된 메일링 리스트, 전달된 스레드 또는 첨부 파일에 악성 지침을 넣을 수 있다.

지침과 데이터의 구분도 언어 모델에는 여전히 어렵다. 둘 다 자연어 형태로 도착하며, 요청, 인용된 명령 또는 절차적 텍스트를 포함할 수 있다.

관리자가 보낸 이메일에는 “첨부 파일을 검토하고 답변을 보내세요”라고 정상적으로 적혀 있을 수 있다. 악성 인젝션은 직원이 아닌 AI를 대상으로 하면서도 거의 동일한 언어를 사용할 수 있다.

어시스턴트는 권한, 출처, 의도를 추론해야 한다. 자연어를 유창하게 처리하는 능력만으로는 이러한 보안 속성을 제공하지 못한다.

이 때문에 필터 공격과 어시스턴트 공격은 같은 논의에 속한다. 둘 다 표시된 콘텐츠, 처리된 콘텐츠, 권한이 부여된 콘텐츠 사이의 모호성을 악용한다.

Google News는 AI 기반 이메일 방어에 관한 이야기를 조명했지만, 그 함의는 스팸 분류를 넘어선다. 사서함에 연결된 모든 에이전트는 이 미해결 입력 경계 문제를 물려받는다.

EchoLeak은 이메일이 도구에 도달할 때 벌어지는 일을 보여줬다

AI 어시스턴트가 비공개 맥락을 검색하고 사서함 밖으로 소통할 수 있을 때, 숨겨진 이메일은 훨씬 더 위험해진다.

2025년 EchoLeak 공개는 구체적인 경고를 제공했다. 연구자들은 Microsoft 365 Copilot과 정교하게 구성된 이메일을 활용한 다단계 공격을 설명했다.

Microsoft는 EchoLeak을 CVE-2025-32711로 식별했으며, 해당 문제가 수정됐다고 밝혔다. 회사는 이를 피해자가 이미 접근할 수 있는 제한된 데이터를 노출할 수 있는 교차 프롬프트 인젝션 기법으로 설명한다.

Microsoft의 AI 보안 가이드에 따르면, 겉보기에는 무해한 메시지가 Copilot이 처리하는 컨텍스트를 오염시킬 수 있다. 이후 이 기법은 특정 조건에서 의도치 않은 정보 공개를 유발할 수 있다.

이 사건이 중요했던 이유는 먼저 사용자의 비밀번호를 탈취할 필요가 없었기 때문이다. 공격은 어시스턴트가 읽도록 되어 있는 데이터를 통해 어시스턴트를 겨냥했다.

EchoLeak은 Google News가 강조한 텍스트 솔팅 캠페인보다 복잡했다. 여러 단계와 조건이 관련된 반면, 텍스트 솔팅은 주로 분류 회피를 노렸다.

그러나 두 사례 모두 같은 가정에 의문을 제기한다. 이메일은 콘텐츠로 취급되지만, 그 콘텐츠의 일부는 AI 시스템에 대한 적대적 지시문으로 기능할 수 있다.

검색 증강 생성, 즉 RAG에서는 위험이 더욱 커진다. 이 설계는 답변을 생성하기 전에 관련 비공개 정보를 검색해 모델의 컨텍스트에 추가한다.

RAG는 이메일 어시스턴트가 프로젝트, 일정, 고객 및 이전 논의에 관한 질문에 답하는 데 도움이 된다. 동시에 가치 있는 정보를 공격자가 제어하는 메시지 콘텐츠 가까이에 둔다.

도구 접근 권한은 또 다른 층위를 더한다. 요약 전용 어시스턴트는 사용자를 오도할 수 있지만, 메시징이나 파일 도구를 가진 에이전트는 직접적인 운영상 결과를 초래할 수 있다.

개발자들은 종종 모델에 악의적인 지시를 무시하라고 알리는 시스템 프롬프트에 의존한다. 이 조치는 도움이 되지만, 단단한 보안 경계를 만들지는 못한다.

LLMail-Inject라는 대규모 연구 챌린지는 839명의 참가자로부터 208,095건의 공격 제출물을 수집했다. 연구자들은 현실적인 이메일 에이전트 환경에서 여러 방어책, 모델 및 검색 구성을 시험했다.

제출물의 규모가 중요한 이유는 적응형 공격자가 하나의 뻔한 문구를 반복하지 않기 때문이다. 이들은 변환, 프레이밍, 인코딩, 사회적 맥락 및 모델별 동작을 탐색한다.

방어자는 어떤 분류기나 프롬프트 가드도 거짓 음성을 낼 수 있다고 가정해야 한다. 민감한 작업에는 모델의 해석에 의존하지 않는 독립적인 권한 부여 통제가 필요하다.

이메일 요약기는 이메일을 읽을 수 있다는 이유만으로 메시지 전송 권한을 얻어서는 안 된다. 검색 접근 권한이 모든 메일함 폴더나 연결된 문서에 대한 접근을 의미해서도 안 된다.

도구 호출에는 각 구성요소에 현재 작업에 필요한 권한만 부여하는 최소 권한 원칙을 적용해야 한다. 영향이 큰 작업에는 명시적인 사용자 확인이 필요하다.

보안팀은 어떤 메시지가 출력이나 작업에 영향을 미쳤는지 보여주는 로그도 필요하다. 출처 정보가 없으면 사고 대응 담당자는 오염된 입력을 쉽게 식별할 수 없다.

AI 시스템용 소스 자료를 관리하는 사용자는 이와 관련된 과제에 직면한다. 명확한 정보 캡처와 소스 분리는 맥락을 보존하는 데 도움이 될 수 있지만, 애플리케이션 수준의 권한은 여전히 필수적이다.

EchoLeak의 교훈은 모든 이메일 어시스턴트가 안전하지 않다는 뜻이 아니다. 보안은 대화형 외관이 아니라 그 권한에 맞춰 설계돼야 한다는 뜻이다.

방어의 상충관계는 가시성과 유용성 사이에 있다

모든 숨겨진 요소를 제거하면 일부 공격은 줄일 수 있지만, 정상적인 이메일을 훼손하고 더 근본적인 권한 부여 실패는 그대로 남긴다.

엄격한 정제기는 AI 시스템이 메시지를 읽기 전에 CSS, 숨겨진 요소, 원격 리소스 및 복잡한 HTML을 제거할 수 있다. 이는 공격 표면을 상당히 줄일 수 있다.

그러나 이는 사용자와 모델이 정상적인 메일을 이해하는 데 도움이 되는 구조도 제거한다. 표, 반응형 레이아웃, 인용문, 서명, 접근성 레이블 및 거래 관련 서식은 유용한 의미를 담을 수 있다.

일부 숨겨진 콘텐츠는 운영상 목적을 수행한다. 프리헤더 텍스트는 짧은 받은편지함 미리보기를 제공할 수 있고, 반응형 디자인은 데스크톱과 모바일 화면에 서로 다른 요소를 표시한다.

보안 제품은 이런 사례와 분류 조작을 목적으로 설계된 대규모 은닉 블록을 구분해야 한다. 이 판단은 하나의 CSS 속성에 의존할 수 없다.

모든 메시지를 통제된 브라우저에서 렌더링하면 가시성 분석을 개선할 수 있다. 하지만 컴퓨팅 비용이 늘어나고 보안 파이프라인에 브라우저 엔진이 추가된다.

렌더링된 화면도 모든 클라이언트와 일치하지 않을 수 있다. 모바일 너비, 다크 모드, 차단된 이미지, 언어 설정 및 접근성 환경설정은 모두 결과를 바꿀 수 있다.

더 안전한 전략은 여러 표현 방식을 사용한다. 시스템은 포렌식 분석을 위해 원시 콘텐츠를 보존하고, 정규화된 보기를 계산하며, 숨겨졌거나 가시성이 낮은 영역을 별도로 식별할 수 있다.

AI 분류기는 이러한 영역에 대한 명시적 레이블을 받아야 한다. 숨겨진 자료가 눈에 보이는 콘텐츠와 같은 구분 없는 텍스트 스트림에 조용히 들어가서는 안 된다.

어시스턴트는 은닉 텍스트를 신뢰할 수 없는 메타데이터로 취급할 수 있다. 사용자가 보안 분석을 요청하는 경우에만 해당 숨겨진 콘텐츠를 요약할 수 있다.

프롬프트 인젝션 탐지기는 또 다른 방어 계층을 제공한다. Microsoft의 구현은 어시스턴트가 처리하기 전에 제목, 메시지 본문, HTML, 스타일링, 전달된 콘텐츠 및 인코딩된 자료를 검사한다.

그럼에도 프롬프트 인젝션 탐지는 확률적이다. 정상 이메일에도 프롬프트, 보안 테스트, 자동화 명령 또는 인용된 악성 메시지에 대한 논의가 포함될 수 있다.

연구팀은 실제 공격 샘플을 이메일로 받을 수 있다. 수신자가 이를 예상하더라도 보안 필터는 해당 메시지를 격리할 수 있다.

거짓 양성은 적용을 완화하라는 압력을 만든다. 중요한 메일이 너무 자주 사라지면 관리자는 공격자가 연구하고 악용할 수 있는 예외를 추가한다.

사람의 확인도 완벽하지 않다. 특히 반복 작업 중에는 인터페이스가 요청을 일반적인 단계처럼 제시할 때 사용자가 습관적으로 승인한다.

따라서 확인 절차는 제안된 작업, 대상 및 관련 데이터를 설명해야 한다. “계속”할지 묻는 모호한 프롬프트는 거의 보호를 제공하지 않는다.

가장 강력한 설계는 모델 추론과 정책 집행을 분리한다. 모델은 작업을 제안할 수 있지만, 결정론적 소프트웨어가 권한, 대상, 데이터 분류 및 승인 요건을 확인한다.

이 접근 방식은 숨겨진 프롬프트와 일반적인 모델 오류 모두에서 발생할 수 있는 피해를 제한한다. 조작된 어시스턴트는 언어 컨텍스트 밖에서 강제되는 경계를 넘을 수 없다.

그 대가는 편의성 감소다. 사용자는 고위험 작업에서 더 많은 프롬프트, 더 제한적인 통합 및 더 느린 자동화를 겪을 수 있다.

어시스턴트가 외부 메시지를 보내고, 기밀 문서를 검색하며, 기록을 수정하거나 금융 워크플로를 시작할 수 있다면 이러한 마찰은 정당화된다. 저위험 요약에는 더 가벼운 통제를 유지할 수 있다.

따라서 AI 이메일 도구는 단계적 권한을 사용해야 한다. 선택한 메시지 읽기, 폴더 검색, 답장 초안 작성 및 해당 답장 전송은 별도의 권한 수준으로 유지돼야 한다.

보안팀이 다음으로 주시해야 할 것

다음 단계는 또 다른 모델 벤치마크가 아니라 탐지 품질, 권한 설계 및 실제 악용에 대한 증거로 평가될 것이다.

첫 번째 신호는 가시성을 인지하는 이메일 검사 기능의 더 광범위한 제공이다. Microsoft의 공개 미리보기는 프롬프트 인젝션이 별도의 메일 보안 범주가 되고 있음을 보여준다.

보안팀은 공급업체가 이러한 탐지를 어떻게 제공하는지 살펴봐야 한다. 유용한 제품은 숨겨진 영역을 식별하고, 그 역할을 설명하며, 조사를 위한 증거를 보존한다.

일반적인 피싱 판정만으로는 충분하지 않다. 분석가는 메시지에 CSS로 숨긴 채움 텍스트, 인코딩된 지시문, 의심스러운 도구 지시 또는 보이는 콘텐츠와 원시 콘텐츠 간의 이례적인 불일치가 포함됐는지 알아야 한다.

두 번째 신호는 Google, Microsoft 및 제3자 개발자가 메일함 연결 에이전트를 어떻게 제한하는지다. 모델 업그레이드는 검색과 도구 사용을 둘러싼 강제 가능한 경계보다 중요성이 낮다.

구매자는 어시스턴트가 외부 메시지와 내부 지시를 구분하는지 물어봐야 한다. 검색된 콘텐츠가 발신자 신원, 위치 및 신뢰 수준을 보존하는지도 확인해야 한다.

관리자에게는 특정 작업을 위한 통제가 필요하다. 정책은 요약을 허용하되, 발신 메일, 파일 접근, 캘린더 변경 또는 제3자 API 호출을 자동으로 허용해서는 안 된다.

세 번째 신호는 검증된 악용 증거다. Barracuda의 텍스트 솔팅 데이터는 필터를 상대로 한 대규모 배포를 보여주지만, 모든 메시지가 LLM 기반 제품을 우회했다는 사실까지 입증하지는 않는다.

공급업체는 가능한 경우 방법론과 분모를 공개해야 한다. 탐지 건수만으로는 전달률, 성공적인 분류, 피해자 상호작용 또는 후속 침해를 알 수 없다.

같은 주의는 프롬프트 인젝션 시연에도 적용된다. 실험실 공격은 보안 경로가 존재함을 증명하지만, 운영 환경의 통제는 실제 신뢰성을 바꿀 수 있다.

반대로 공개된 사고가 없다고 해서 안전성이 증명되는 것은 아니다. AI 에이전트 조작은 일반적인 사용자 활동처럼 보일 수 있어, 세부 로그 없이는 사고를 식별하기 어렵다.

조직은 완벽한 측정을 기다릴 필요가 없다. AI가 수신 이메일을 처리하거나 메일함 컨텍스트를 검색하도록 허용하는 모든 워크플로를 매핑하는 것부터 시작할 수 있다.

팀은 각 어시스턴트가 읽을 수 있는 내용, 호출할 수 있는 도구 및 승인해야 하는 작업을 문서화해야 한다. 또한 숨겨진 콘텐츠와 화면 밖 콘텐츠가 포함된 메시지를 테스트해야 한다.

보안 훈련에는 두 가지 공격 방향이 모두 포함돼야 한다. 한 테스트는 분류 회피를 위해 무해한 채움 텍스트를 숨겨야 한다. 다른 테스트는 어시스턴트를 겨냥한 악의적 지시를 숨겨야 한다.

개발자는 시스템이 불확실성을 설명하는지 평가해야 한다. 상충하거나 은닉된 지시를 탐지한 어시스턴트는 중단하고 의심스러운 소스를 식별해야 한다.

사용자는 이메일 요약에 포함된 AI 생성 경고를 계속 의심해야 한다. 인터페이스가 신뢰할 수 있는 제공업체의 것이더라도, 세련된 경고는 공격자가 제어하는 콘텐츠에서 비롯될 수 있다.

정보 제공 워크플로에서는 원본 소스를 계속 이용할 수 있도록 하고, 조치하기 전에 중요한 주장을 검토해야 한다. AI 요약은 검토를 가속해야지 출처 확인을 대체해서는 안 된다.

Google News는 웹메일 CSS 공격에 대한 관심을 다시 불러일으켰지만, 지속적인 문제는 하나의 캠페인보다 더 크다. 이제 이메일은 사람, 분류기, 검색 시스템 및 자율 도구를 위한 콘텐츠를 전달한다.

이들 수신자는 같은 메시지를 동일하게 인식하지 않는다. 보안 시스템이 이 차이를 직접 모델링하기 전까지 공격자는 사람이 보는 것과 기계가 읽는 것 사이의 격차를 계속 활용할 것이다.