▲

Notion 3.0 AI 에이전트의 숨겨진 위험: 웹 검색 도구 남용을 통한 데이터 유출

 (codeintegrity.ai)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Notion 3.0의 AI 에이전트는 문서 작성, 데이터베이스 업데이트, 외부 커넥터 호출 등 자율적 멀티스텝 워크플로우 실행 기능을 제공함
  • 에이전트가 도구 접근권과 장기 기억을 가지면 기존의 RBAC로는 통제하기 어려운 확장된 위협 표면이 형성됨
  • 분석 결과 Notion 에이전트의 web search 함수 입력 스키마가 악성 간접 프롬프트에 의해 내부 기밀을 외부로 전송하는 데이터 유출 벡터로 악용될 가능성이 확인됨
  • 데모에서 공격자는 PDF에 숨긴 프롬프트 인젝션을 통해 에이전트가 비밀 고객 데이터를 추출·연결·웹 쿼리로 전송하도록 유도한 실행 흐름을 입증
  • 이 사례는 MCP 연동과 외부 커넥터가 결합될 때 에이전트-도구-메모리의 치명적 삼합(“lethal trifecta”) 이 실무 보안에 미치는 심각한 상황을 보여줌

AI Agents와 Notion 3.0의 소개

  • 최근 AI Agents가 SaaS 플랫폼에 통합되는 추세임
  • Notion 3.0에서도 사용자가 할 수 있는 모든 작업(문서 생성, DB 갱신, 여러 도구 검색, 멀티스텝 워크플로우 실행 등)을 AI 에이전트가 자동으로 수행 가능함
  • MCP 통합으로 다양한 외부 도구와 연결되어 더욱 강력한 자동화 및 맞춤형 에이전트 생성dl 가능
  • 트리거 또는 스케줄에 따라 동작하는 팀 기반 Custom Agents도 만들 수 있어, 피드백 수집, 트래커 갱신, 요청 선별 등 반복 업무를 자동 처리하게 구성 가능함

'치명적 삼합(lethal trifecta)' 문제

  • Simon Willison이 지적한 '치명적 삼합(Lethal Trifecta)'은 LLM 에이전트, 도구 액세스, 장기 기억의 결합으로 발생하는 보안 위협임
  • Notion 3.0에서 에이전트가 스스로 행동 계획을 세우고 MCP 통합 도구 및 내장 도구 실행이 가능해짐
  • 넓은 권한을 가진 에이전트는 기존 RBAC로 예상하지 못한 방식의 문서, 데이터베이스, 외부 커넥터 작업을 자동화함
  • 이로 인해 다단계 자동화 워크플로우를 통한 민감 데이터 유출이나 오용의 위협 지표가 확장됨

취약점 기술 상세 : Notion AI의 웹 검색 도구를 이용한 Notion 페이지 데이터 유출 공격

  • 문제점: 웹 검색도구의 functions.search (web scope) 입력 스키마가 직·간접 쿼리 문자열을 허용함 
    Name: functions.search (web scope)  
Input:  {  
    "web": {  
        "queries": ["<query or URL>", "..."]    // 쿼리 문자열 배열 (URLs 또는 검색어들)  
    }
  • 쿼리 배열에 임의의 URL 또는 검색어를 넣을 수 있는 점이 악용 지점임
  • 공격 표면: 에이전트가 읽을 수 있는 사용자 문서(예: PDF) 안에 악성 프롬프트를 숨기면 에이전트는 해당 지시를 실행할 가능성 존재
  • 간접 프롬프트 인젝션(파일 내부 텍스트 → 에이전트 처리 경로)을 통해 명령 주입이 현실화됨
  • 공격자 우회 기법: 권위·긴급성·기술적 신뢰성·보안 연극(“pre-authorized”) 같은 심리·기술적 설득 문구 사용으로 인간 검토 및 안전 장치 우회 시도
  • 이 구조는 공격자가 선택적 쿼리 조합을 통해 데이터 유출에 활용할 소지가 있음

공격 시연: 단계별로 보는 데이터 탈취 시나리오

  • 1단계: 악성 PDF 생성

    • 겉보기에 평범한 고객 피드백 PDF 문서에 몰래 실행 지시문 같은 악의적 프롬프트 삽입
    • 이 숨겨진 프롬프트는 "중요한 루틴 업무"로 가장하여, 내부 백엔드 시스템에 데이터를 전송하라고 안내함
    • 악성 프롬프트의 주요 내용
      • 권위 추정(Authority assertion) : "Important routine task", "consequences" 등으로 "중요 루틴 업무"임을 주장
      • 긴급성 부여(False urgency) : 미수행 시 조직에 영향 있음 강조
      • 기술적 신뢰성(Technical legitimacy) : 내부 시스템, 도구 명령 구문 등 실제처럼 설명
      • 보안 안심(Security theater) : "pre-authorized" 및 "safe from security perspective" 같은 문구로 미리 승인됐으며 안전하다고 강조
    • PDF를 읽은 에이전트가 기업 정보(고객명, ARR 등)를 추출해, 내부 시스템을 가리키는 URL(공격자가 관리)로 데이터 전송하도록 유도함

  • 2단계: 사용자 상호작용 대기

    • Notion 사용자가 해당 PDF를 Notion에 업로드하거나 에이전트에게 요약을 요청할 때 공격이 트리거됨
    • "리포트 요약" 등 명령 시, AI가 몰래 박혀있는 프롬프트까지 해석하게 됨

  • 3단계: 데이터 실제 유출

    • 에이전트가 프롬프트 지시에 따라 고객 데이터(예: 회사명, 업종, ARR 등)를 하나의 문자열로 결합
    • 공격자의 도메인을 표적으로한 URL 생성 후, 이 URL을 웹 검색 도구의 쿼리로 전달함
    • 해당 요청을 받은 악성 서버(공격자가 제어)가 민감 데이터를 수집하게 됨
  • 이 공격 시나리오에서는 Notion AI 내에서 Claude Sonnet 4.0 모델을 사용했음에도 불구하고, 보안 가드레일이 우회됨을 확인함

MCP 통합이 Notion AI 에이전트의 공격 표면을 확장하는 방식

  • Notion은 GitHub, Gmail, Jira 등 다양한 소스의 AI Connector를 지원함
  • 각 커넥터가 에이전트에게 제공하는 컨텍스트·메타데이터는 추가적인 공격 표면을 제공하여, 외부 소스에서 간접 프롬프트 주입 공격을 통한 악성 프롬프트 유입 가능성이 높아짐
  • 각종 의도치 않은 자동화된 악의적 행동 및 민감 데이터 유출 시도 위험이 커짐
  • 예시 시나리오: 악성 커밋 메시나 Issue 본문, 외부 이메일이 간접 프롬프트로 작동하여 에이전트에게 내부 데이터 접근·전송 명령을 유발할 가능성

시사점 및 권고(요약)

  • 핵심 시사점: 에이전트가 도구 접근 권한을 가질 때 문서 내부의 악성 지시가 도구 호출로 이어져 기밀 유출로 연결될 수 있음
  • 방어 포인트(논의 항목):
    • 에이전트의 도구 호출은 출처 검증·컨텍스트 한정·정책 기반 필터링을 거쳐야 함
    • 문서 내 실행 지시문(예: URL 형성 지침)은 별도의 안전 검사·휴먼 확인 또는 격리된 실행 환경에서 처리해야 함
    • MCP 커넥터별로 최소 권한 원칙과 호출 로그·알림 체계 강화 필요
  • 결론: Notion 3.0의 기능은 생산성 향상의 잠재력이 크지만, 에이전트-도구-메모리의 결합이 야기하는 새로운 공격 벡터는 실무 보안 설계의 재검토를 요구함
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • Simon Willison이 말한 "lethal trifecta"란 LLM 에이전트, 도구 접근, 장기 메모리 조합을 통한 강력하면서도 쉽게 악용될 수 있는 공격 벡터를 의미한다고 설명하는데, 이는 잘못된 설명임을 강조하고 싶음. 실제 lethal trifecta는 사적 데이터 접근, 신뢰할 수 없는 콘텐츠 노출, 외부와의 커뮤니케이션 가능성임. 웹 검색 기능이 있는 LLM 에이전트는 신뢰할 수 없는 콘텐츠 노출과 외부 커뮤니케이션 모두에 해당함.
    • TFA가 처음부터 이 개념을 잘못 이해하고 있다고 봄. Simon Willison의 원 출처는 이 글임.
    • 내 생각엔 trifecta를 더 간단하게 설명할 수 있음. 공격자가 LLM에 입력할 수만 있다면 모든 리소스를 통제할 수 있다는 개념임.
    • trifecta라는 이름에 어울리지 않는 설명임. 진짜는 다음 세 가지임. 신뢰할 수 없는 입력, 권한 있는 접근, 데이터 유출 벡터.
  • 프롬프트 구성 방식이 피싱 캠페인 특징과 굉장히 유사하게 느껴짐.
    • 권위 주장
    • 거짓된 긴급함
    • 기술적 정당성
    • 보안 시늉
      프롬프트 인젝션이란, 자아와 자기성찰 없이 멈춰서 의심할 능력이 없는 존재를 상대로 한 피싱과 같다고 생각하게 됨.
    • 이 현상은 CSRF와도 비슷하다고 생각함. 두 공격 모두 시스템이 신뢰하는 입력을 이용해 권한 있는 사용자가 원하지 않는 행동을 하도록 속임. 악성 PDF가 프롬프트 인젝션을 활용해 Notion 에이전트(워크스페이스 접근 권한 보유)로 외부 웹 툴을 호출해 페이지 내용을 외부로 빼내게 하는 식임. 결국 핵심은 동일한 권한 남용 패턴임. 단지 기술적 표면이 프롬프트 인젝션+도구 체이닝(과거엔 HTTP 요청 위조) 등으로 바뀐 것뿐임.
    • 적절한 훈련이 이루어진다면 LLM이 이러한 공격에 "의심"을 갖고 버티는 능력을 충분히 갖출 수 있다고 생각함. 다만 최근 모델들은 '페르소나' 인젝션 내성 강화가 대화형 사용법과 모순됨. 그래서 강화된 "에이전트" 모델과 더 개방적인 대화형 모델 등으로 분리될 가능성이 크다고 봄. 입력에 베이스 콘텍스트를 추가해 기대치를 조절하는 방법도 있을 수 있지만, 이러려면 아키텍처 변화가 필요하다고 생각함.
  • 직접 Notion에서 테스트해봤는데, URL을 검색하긴 해도 실제로 데이터를 해당 URL로 전송하진 않는 것 같음. 데이터 유출 지점이 어딘지 궁금함(검색 서비스로만 전송되는 부분 제외하고).
    • Notion의 AI 봇에게 한 URL로 새 페이지를 만들어달라고 요청하고, 내 서버 로그를 통해 Notion이 해당 URL에 실제 접근하는 걸 확인했음. User-Agent는 Chrome/139/Mac임.
    • 의도는 쿼리 스트링을 활용해 특정 URL로 요청을 유도하는 것이었을 거라 생각됨. 검색 툴이 그렇게 작동하지 않는 듯하거나, 로그로 유출 여부를 명확하게 보여주지 않아 성공 사실이 확실치 않은 상태임.
  • 이 공격은 이미 2년 전에 데모된 적이 있음. 새로운 문제이진 않음. 관련 링크.
    • 문제는 Notion에 이런 취약점이 있었고, 이를 방지하거나 완화할 조치가 전혀 없었다는 점임.
    • 전혀 새롭지 않은 취약점인데도 Notion이 이번 주에 이걸 그대로 도입했음. 보여주기식 AI 신기능에만 치중한 결과임.
  • instruction/data-conflation 문제를 다루는 사람이 있는지 궁금함. LLM이 데이터 속 지시사항을 무작정 따르게 놔두는 한, 실제 데이터 소스와 외부 기능을 연결하는 건 너무 이르다고 생각함. Notion은 아무런 경고도 없이 사용자에게 Github, GMail, Jira 등 모델에 연결하라고 권장함. 이 정도면 안전한 제품에서 기능으로 취급하는 게 거의 범죄라 생각함.
    • 이 문제에 대해 3년 넘게 논의하고 있지만, 실질적으로 강인한 해법은 아직 나오지 않았음. 현재는 시스템 프롬프트와 사용자 프롬프트를 분리해서 한쪽을 더 신뢰하도록 훈련하지만, 이 방식도 허술함. 의욕 있는 공격자는 여전히 우회법을 찾아냄. 가장 설득력 있었던 완화책은 DeepMind의 CaMeL 논문인데, 이것도 기능 구성에 많은 제약을 줌. 링크.
    • 나는 이번 익스플로잇의 작성자임. CodeIntegrity.ai에서 에이전트형 AI 시스템의 실제 데이터 흐름과 제어 흐름을 시각화해 각각의 위험성을 평가할 수 있는 플랫폼을 만들었음. 런타임 가드레일도 제공해 위험 허용도에 따라 흐름을 제어 가능함. 더 궁금하면 abi@codeintegrity.ai로 이메일 환영함.
    • 네가 쓴 표현 방식이 흥미롭게 느껴짐. 한 번 신뢰된 데이터와 비신뢰 데이터가 명확히 구분된 데이터 구조를 LLM 피드로 사용하는 걸 상상해봄. 웹서치나 MCP 결과는 디폴트로 비신뢰(단, MCP를 직접 작성해 신뢰할 수 있다면 예외). 비신뢰 데이터는 순수한 변환(사이드 이펙트 없는)만 허용. 예: 요약, 공백 제거, float 변환 등, 모두 네트워크 접근 없는 샌드박스 내부에서 수행. 예를 들어 "공개 깃허브 이슈 전부 요약해서 DB에 저장해줘"도, 비신뢰 내용은 샌드박스에서만 처리하면 안전하게 할 수 있을 것 같음!
    • 마치 "일반 사용자에게 실행 코드 권한 주는 문제"와도 비슷함. 실질적 해법은 쉽지 않음.
    • 이미 해법은 존재함. 이건 독특한 데이터 문제라기보다 기존 가드레일로도 AI 제한 가능함. 만약 사용자가 데이터 접근 권한이 없으면 LLM도 마찬가지로 제한해야 함. 이걸 그냥 풀어놓는 회사들이 오히려 이상함. 마법이 아님. AI 보안 문제 있는 기업들은 다른 심각한 취약점도 많다는 뜻임. 다만 AI로 인해 더 드러나기 쉬움.
  • 기사 원문은 여기임.
    • 이 링크가 더 적합함. 내 블로그에도 참고할 노트가 있음. 관련 링크.
    • 이전 HN 논의 링크. URL이 갱신되어 지금은 단순 중복임(원래는 트윗 링크였음).
  • Notion이 최근 들어 점점 스파이웨어처럼 느껴지기 시작함. 회의 중에 계속 Notion이 회의 중임을 감지했다며 "노트 작성해줄까?"라는 팝업이 계속 뜸.
  • "AI"라는 문구를 내세우며 공개적으로 제공되는 도구에서 발견되는 취약점을 "숨겨진" 것으로 보는 건 맞지 않다고 생각함.
  • 이 기사는 실질적인 취약점을 실제 사례로 보여주고, 설명도 지나치게 기술적이지 않아 좋은 글이었음.
  • 평범한 사용자가 어떻게 내 Notion 인스턴스에 문서를 넣게 되는지 궁금함.
    • 그냥 구글에서 "best free notion marketing templates" 검색해 가져와서 임포트함. 나도 여러 번 했고, 전 세계적으로 수천, 수만 명이 비슷하게 사용함.
    • 기사에서는 PDF가 예시지만, Notion 에이전트가 어떤 링크를 어떻게 열고 저장하느냐에 따라 크롤러/브라우저 에이전트별로 다른 웹페이지를 보여줄 수도 있으니, 업계에서 인기 있는 자료도 피싱 타깃이 될 수 있음.
    • 많은 회사들이 Zapier 등 자동화툴로 인보이스 같은 문서를 직접 업로드하거나, 이메일로 익스플로잇 문서를 받아 Notion에 등록함.
    • Notion에 정말 온갖 자료를 넣음. DB로도 쓰고, 웹클리퍼로 온라인 자료도 담아두고, 협업 툴로도 사용함. 활용 방식이 다양함.
    • 이번 케이스는 설득력 있는 제목을 단 PDF를 이메일로 받아서, 동료들과 공유할 법한 문서로 보이게 하는 식임. 악성 명령어는 흰 배경에 흰 글씨 등으로 숨겨둠. 앞으로 MCP들이 퍼블릭 이슈 트래커나 수신 이메일까지 볼 수 있게 되면, 이 외에도 다양한 공격 시나리오가 나올 것임.
답변달기