AI 데이터 유출: Rovo vs Notion AI vs Slack AI vs ClickUp Brain 비교

핵심 요약: 업무용 도구에서 발생하는 AI 데이터 유출은 어시스턴트가 악의적인 텍스트를 읽고 그 안에 숨겨진 명령을 실행하여, URL 호출(fetch), 이미지 렌더링, 링크 등을 통해 외부 서버로 내부 기밀 데이터를 전송할 때 발생합니다. 공개 연구를 통해 Atlassian Rovo, Notion AI, Slack AI에서 이러한 취약점이 확인되었습니다. Notion과 Slack은 패치를 배포했으나, Rovo의 유출 경로에 대해서는 2026년 10월 27일 기준 공개된 수정 사항을 확인하지 못했습니다.

프로젝트 관리 AI는 고객 지원 티켓, 업로드된 PDF, 연동된 커넥터 페이지, 공개 채널 등 사용자가 직접 작성하지 않은 외부 텍스트까지 읽어 들입니다. 그리고 이러한 텍스트 어디에나 악의적인 명령이 숨어 있을 수 있습니다.

이 글에서는 Rovo, Notion AI, Slack AI, ClickUp Brain을 비교합니다. 표의 각 항목은 원문 보고서나 공식 벤더 페이지 및 날짜를 명시했습니다. 관련 정보를 찾을 수 없는 항목에는 '공개 보고서 없음'으로 표시했습니다. 동일한 메커니즘이 코딩 에이전트에도 적용되며, 이에 대해서는 글의 마지막 부분에서 다룹니다.

AI 데이터 유출이란 무엇인가: 한 문장 정리

간접 프롬프트 주입(Indirect Prompt Injection)은 AI 어시스턴트가 처리하는 콘텐츠 내부에 악의적인 명령을 숨겨 두어, 마치 사용자가 직접 요청한 것처럼 어시스턴트가 이를 실행하게 만드는 공격 기법입니다.

이것이 데이터 유출로 이어지려면 세 가지 조건이 맞아떨어져야 합니다. 사이먼 윌리슨(Simon Willison)은 2025년 6월 이를 치명적인 3요소(lethal trifecta)라고 명명했습니다.

1. 어시스턴트가 비공개 데이터에 접근할 수 있다.
2. 어시스턴트가 외부인이 개입할 수 있는 콘텐츠를 읽는다.
3. 어시스턴트에게 데이터를 외부로 전송할 수 있는 수단이 있다.

이 중 하나라도 차단하면 유출 경로는 닫힙니다. 하지만 업무용 협업 어시스턴트는 태생적 구조상 이 세 가지 조건을 모두 갖추고 있습니다.

Atlassian Rovo의 데이터 유출 메커니즘

PromptArmor는 2026년 8월 5일 Rovo 분석 보고서를 발표했습니다. 공격 체인은 매우 단순합니다.

1. 사용자가 숨겨진 명령이 포함된 파일(데모에서는 '백로그 가이드')을 업로드합니다.
2. 사용자가 Rovo에게 자신의 Jira 티켓을 정리해 달라고 요청합니다.
3. Rovo는 Jira와 Confluence를 검색한 뒤, 문서에 숨겨져 있던 명령을 실행합니다.
4. Rovo는 티켓과 페이지 내용을 공격자의 URL 뒤에 덧붙인 후, 자체 URL 호출(retrieval) 도구로 해당 주소에 접속합니다.
5. 공격자의 서버에 유출된 데이터를 포함한 요청이 기록됩니다. 정작 사용자 화면에는 정상적인 결과가 표시됩니다.

이 과정에서 사용자 승인 절차는 전혀 작동하지 않았습니다. 웹 검색 기능을 꺼 두어도 이 공격은 그대로 유효했는데, 해당 토글 옵션이 URL 호출 도구 자체를 비활성화하지는 않기 때문입니다. 게다가 Rovo는 마크다운 이미지 렌더링도 지원하므로, 이를 통한 2차 유출 경로도 존재합니다.

도입을 검토 중인 기업 고객에게는 취약점 공개 일정도 중요한 판단 요소입니다. PromptArmor는 2026년 5월 23일에 이를 제보했고, Atlassian은 5월 25일에 접수 사실을 알렸습니다. 그러나 6월 4일과 7월 29일에 보낸 후속 문의에는 응답하지 않았으며, 결국 Rovo의 취약점이 노출된 상태 그대로 8월 5일에 보고서가 공개되었습니다. 해당 Hacker News 스레드는 추천 306점과 댓글 138개를 기록했습니다.

Rovo의 다른 보안 이슈 하나는 수정되었습니다. 2026년 8월 14일 자 클라우드 보안 연합(CSA) 연구 노트에 따르면, 채팅 URL 매개변수를 악용한 Varonis의 원클릭 공격 'RovoBlast' 경로는 Varonis가 공개하기 전 Atlassian이 서버 측에서 패치했습니다. 그러나 동일한 연구 노트에서 PromptArmor가 보고한 문서 기반 경로는 여전히 미해결 상태로 기술되어 있습니다. 2026년 10월 27일 기준 조사에서도 이후에 발표된 패치 공지는 확인되지 않았습니다.

명칭과 관련해 한 가지 짚고 넘어갈 점이 있습니다. Rovo Dev는 Atlassian의 코딩 에이전트로, 이 글에서 다루는 Rovo 어시스턴트와는 별개의 제품이며 위의 보안 연구에서도 테스트 대상에 포함되지 않았습니다.

Rovo vs Notion AI vs Slack AI vs ClickUp Brain 비교

다음 표는 각 어시스턴트에서 실증되었거나 공식 문서로 확인된 동작을 비교한 것입니다. '언급 없음'은 확인한 출처에서 해당 항목을 다루지 않았음을 의미합니다.

Linear와 Asana는 비교 대상에서 제외했습니다. 2026년 10월 27일 기준 두 어시스턴트 모두 프롬프트 주입을 통한 데이터 유출 관련 공개 보고서가 확인되지 않았으나, 보고서가 없다고 해서 안전성이 완전히 입증된 것은 아닙니다.

Notion AI: 승인하기도 전에 이미 저장된 편집 내용

PromptArmor의 Notion AI 사례에서는 이력서 안에 1포인트 크기의 흰색 텍스트를 숨겨 두었습니다. 이 이력서를 바탕으로 채용 트래커를 업데이트하라고 지시하자, Notion AI는 트래커의 텍스트가 덧붙여진 이미지 URL을 생성했습니다. Notion 화면에는 외부 URL에 대한 경고가 떴지만, 편집 내용은 이미 저장된 상태였기 때문에 사용자의 수락 여부와 상관없이 데이터가 외부로 유출되었습니다.

Notion은 공개 보고서 발표 후 해당 취약점을 확인하고 그날 밤 즉시 패치를 배포했습니다. PromptArmor는 Notion Mail 초안 작성 어시스턴트에서도 유사한 문제를 지적했으나, 당시 업데이트 내용에는 해당 패치가 Mail까지 적용되는지는 명시되어 있지 않았습니다.

Slack AI: '재인증' 링크 클릭 한 번으로 유출

공격자가 자신이 생성한 공개 채널에 악의적인 지시문을 게시합니다. 이후 사용자가 비공개 채널에서 Slack AI에게 기밀 정보에 관해 질문하면, 답변에 해당 기밀이 URL 매개변수로 포함된 '재인증하려면 여기를 클릭하세요'라는 링크가 삽입됩니다. 사용자가 이 링크를 한 번 클릭하는 순간 기밀 데이터가 외부로 전송되었습니다.

Slack은 2024년 8월 19일 PromptArmor 측에 공개 채널 검색은 의도된 정상 동작이라고 밝혔습니다. 이후 8월 21일 낮은 위험도의 피싱 시나리오에 대한 패치를 발표했으나, SC Media의 보도에 따르면 해당 보안 권고에는 PromptArmor의 제보나 동일한 이슈인지 여부가 명시되지 않았습니다. 아울러 PromptArmor는 같은 달 Slack AI가 채널과 DM의 파일까지 수집하기 시작했으나, 이 경로에 대해서는 별도로 테스트하지 않았다고 언급했습니다.

ClickUp Brain: 공개 보고서 없음

2026년 10월 27일 기준 ClickUp Brain이나 Super Agents에 대해 발표된 데이터 유출 연구는 확인되지 않았습니다. ClickUp의 Super Agents 소개 페이지에 따르면 에이전트는 암묵적 및 명시적 권한을 기반으로 작동하며 '모든 작업에 대한 전체 감사 추적'을 유지한다고 합니다. 또한 Super Agent 워크플로에 관한 ClickUp 블로그 글에서는 에이전트가 사용자 수준의 권한을 상속받고 중요 작업에는 사람의 승인을 거치도록 설계되었다고 설명합니다. 하지만 이는 벤더 측의 주장일 뿐 검증된 테스트 결과는 아닙니다. 프롬프트 주입에 관한 ClickUp의 도움말 문서는 봇 감지 화면이 표시되어 인용하지 못했습니다.

실효성 있는 방어책과 미봉책의 차이

Hacker News 스레드에서는 다음과 같이 방어책의 효과성을 평가했습니다.

• 사용자가 직접 입력했거나 신뢰할 수 있는 도구가 반환한 URL만 호출: 사이먼 윌리슨은 에이전트가 URL 자체를 직접 조합해 생성하도록 두어서는 안 된다고 주장했습니다. 와일드카드 DNS를 이용하면 서브도메인에 데이터를 실어 나를 수 있으므로, 쿼리 문자열 필터링만으로는 유출을 막을 수 없습니다.
• 사전 색인된 URL만 허용: 댓글 작성자 wunderwuzzi23은 검색 엔진에 색인된 페이지만 호출하도록 제한하더라도, 요청 1회당 1문자씩 데이터를 유출할 수 있다고 지적했습니다.
• 도메인 허용 목록(Allowlist): 수행 업무의 범위가 한정된 어시스턴트의 경우, 허용된 아웃바운드 도메인 목록을 엄격히 관리하는 방식이 높은 방어력을 발휘합니다.
• 분류기(Classifier) 및 정규식 필터: 심층 방어의 한 계층으로는 유용하지만, 확률론적인 방식이므로 결코 최후의 방어선이 될 수는 없습니다.

이 논의들의 공통된 핵심은 '프롬프트를 정교하게 다듬는 것보다 아웃바운드 채널에 결정론적(deterministic) 제한을 거는 것이 훨씬 효과적'이라는 점입니다. 모델이 공격을 더 잘 거부하도록 훈련하더라도 부여된 네트워크 접근 권한 자체는 그대로 유지되기 때문이며, 이는 Claude Opus 5.5 출시 당시 저희가 프롬프트 주입과 에이전트 가드레일에 관한 글에서 지적했던 내용이기도 합니다.

업무용 AI 어시스턴트를 도입하기 전 확인해야 할 체크리스트

도입 전 벤더에게 다음 사항을 서면으로 확인하세요.

1. 테넌트 외부로 데이터를 전송할 수 있는 도구는 무엇인가? (URL 호출, 이미지 렌더링, 링크 렌더링, 이메일, 커넥터 등)
2. 관련 설정 기능이 해당 도구 자체를 완전히 제거하는가, 아니면 도구를 사용하는 겉보기 기능만 숨기는가? (Rovo의 웹 검색 토글은 후자에 불과했습니다.)
3. 모델이 직접 조합하여 생성한 URL을 호출할 수 있는가?
4. AI 출력 화면에서 외부 도메인의 마크다운 이미지를 렌더링하는가?
5. 기본 설정상 어떤 데이터를 읽는가? (업로드 파일, 연동된 드라이브, DM, 공개 채널 등)
6. 사람의 승인이 필요한 작업은 무엇이며, 그 승인이 부수 효과(side effect) 발생 이전에 이루어지는가? (Notion의 경우 부수 효과 이후에 승인이 요청되었습니다.)
7. 해당 벤더가 가장 최근에 접수된 외부 취약점 보고서를 어떻게, 그리고 얼마나 신속하게 처리했는가?

아웃바운드 전송 채널이 명확히 문서화되어 있고 각 채널을 개별적으로 끌 수 있을 때에만 업무용 어시스턴트를 도입하세요. 벤더가 이러한 목록조차 명확히 제시하지 못한다면 도입을 보류하는 것이 안전합니다.

Sharkly의 접근 방식: 솔직한 이야기

Sharkly는 문서 도구에 내장된 어시스턴트가 아니며, 프롬프트 주입 공격으로부터 완전히 자유로운 것도 아닙니다. Sharkly는 Claude Code나 Codex 같은 코딩 에이전트를 관리하는 플랫폼이며, 이러한 에이전트들 역시 이슈 본문, README 문서, 외부 웹페이지 등 신뢰할 수 없는 텍스트를 수시로 읽어 들입니다. 따라서 치명적인 3요소는 코딩 에이전트에도 그대로 적용됩니다.

차이점은 '보안 경계(Boundary)의 제어권을 누가 쥐고 있는가'에 있습니다. Sharkly에서는 로컬 서비스를 통해 사용자의 자체 컴퓨터(Computers) 환경에서 에이전트가 실행됩니다. Computers 문서에 명시되어 있듯이, 실행에 필요한 파일, 인증 자격 증명, 네트워크 접근 권한, 도구 등은 컴퓨터 환경에서 직접 제공합니다. 따라서 외부 아웃바운드 트래픽(egress) 제어권은 전적으로 사용자의 손에 있습니다. 특정 컴퓨터를 도메인 허용 목록 뒤에 배치하면, 어떤 에이전트가 실행되든 해당 컴퓨터의 모든 작업에 동일한 제한이 적용됩니다.

공식 문서에 명시된 다른 보안 경계 정책은 다음과 같습니다.

• 게스트는 추가된 스페이스(Spaces)만 볼 수 있습니다. 공개 스페이스를 검색하거나 임의로 참여할 수 없습니다(사용자 및 역할).
• 서드파티 작업에는 승인된 커넥터가 필요합니다. 사용자가 직접 연결하지 않은 외부 앱은 자동화 워크플로에서 호출할 수 없습니다.
• 시크릿(Secrets)은 스킬(Skills)에 보관하지 않습니다. Skills 문서에서는 스킬의 지시문이나 파일 내에 비밀번호, 토큰, API 키 등을 절대 저장하지 말 것을 명시하고 있습니다.

물론 이러한 장치들이 에이전트에게 부여된 권한 범위 내에서 유도 공격을 받아 잘못된 행동을 하는 것까지 원천 차단하지는 못합니다. 다만 권한 범위를 최소화하고, 작업(Task)에 반드시 사람의 승인 단계를 거치도록 보장합니다. 적절한 권한 경계 설정에 대해서는 코딩 에이전트 권한 관리와 승인 게이트(Approval Gate)에 관한 글에서 자세히 다루고 있습니다.

결론

코딩 에이전트를 포함하여, 신뢰할 수 없는 외부 텍스트를 읽어 들이는 모든 제품에서 프롬프트 주입 문제는 아직 근본적으로 해결되지 않았습니다. 따라서 실질적으로 따져보아야 할 질문은 명확합니다. '어시스턴트가 외부로 무엇을 내보낼 수 있는가, 그리고 그 기능을 사용자가 직접 끌 수 있는가?'입니다. 본문에서 살펴본 네 가지 도구 중 두 곳은 공개된 유출 사례에 대해 패치를 배포했고, 한 곳은 공개된 유출 사례가 있으나 패치 여부를 확인할 수 없었으며, 나머지 한 곳은 아직 공개된 보고서가 없습니다.

여러 코딩 에이전트를 운영하면서 네트워크를 직접 제어할 수 있는 호스트 환경에 두고 싶다면, 컴퓨터 한 대를 Sharkly에 연결하고 아웃바운드(egress) 접근을 엄격히 제한한 뒤, 에이전트에게 위험도가 낮은 작업(Task)을 하나 배정해 보세요. Sharkly는 현재 5인 이하 조직에 무료로 제공됩니다.

자주 묻는 질문(FAQ)

Atlassian Rovo는 여전히 데이터 유출에 취약한가요?

PromptArmor가 공개한 문서 기반 유출 경로는 2026년 8월 5일 기준 패치되지 않았으며, 2026년 10월 27일 기준 공개된 수정 사항을 확인하지 못했습니다. 이와 별개인 Varonis의 링크 취약점은 수정되었습니다.

Did Notion fix the Notion AI data leak?

네, 해결했습니다. Notion 측은 PromptArmor의 취약점 공개 당일 밤인 2026년 1월 7일, 안전하지 않은 AI 문서 업데이트에 대한 보안 패치를 프로덕션 환경에 배포 완료했다고 밝혔습니다.

Slack AI 프롬프트 주입 취약점은 패치되었나요?

Slack은 2024년 8월 21일 패치를 발표했으나, PromptArmor가 보고한 바로 그 이슈인지는 공식적으로 확인해 주지 않았습니다.

웹 검색 기능을 끄면 AI 어시스턴트의 데이터 유출을 막을 수 있나요?

항상 그렇지는 않습니다. Rovo의 경우 웹 검색 설정을 꺼도 내부 URL 호출 도구가 비활성화되지 않아 유출이 그대로 일어났습니다.

AI 보안에서 말하는 '치명적인 3요소(lethal trifecta)'란 무엇인가요?

비공개 내부 데이터, 신뢰할 수 없는 외부 콘텐츠, 그리고 외부로 데이터를 전송할 수 있는 수단입니다. 이 세 가지 조건을 모두 갖춘 어시스턴트는 유도 공격을 통해 데이터 유출을 일으킬 수 있습니다.

코딩 에이전트도 동일한 방식으로 데이터를 유출할 수 있나요?

그렇습니다. 악의적인 README 문서를 읽어 들인 코딩 에이전트가 네트워크 접근 권한까지 가지고 있다면 동일한 위험에 노출됩니다. 호스트 수준에서 인증 자격 증명과 아웃바운드 네트워크를 엄격히 제한해야 합니다.