ChatGPT for Sheets 데이터 유출 버그가 AI 보안에 대해 시사하는 점

PromptArmor라는 보안 기업은 2026년 5월 27일, 185,000회 이상의 다운로드 수를 기록한 OpenAI의 확장 프로그램인 ChatGPT for Google Sheets가 단 한 번의 평범해 보이는 요청을 통해 사용자의 스프레드시트를 훔치도록 유도될 수 있음을 보여주는 보고서를 발표했습니다. 4일 후인 5월 31일, OpenAI는 수정 사항을 배포했습니다. 요약하자면, 숨겨진 지침이 포함된 시트에 실제 사용자가 입력한 하나의 무해한 질문만으로도 해당 사용자의 계정에서 연결된 12개의 워크북(Workbook)을 유출하고, 어시스턴트를 가짜 피싱 챗봇으로 교체하기에 충분했습니다.

저는 이것이 어떻게 작동했는지 자세히 살펴보고자 합니다. 왜냐하면 그 메커니즘이 헤드라인보다 훨씬 더 중요하며, 우리가 직접 작성하지 않은 데이터에 AI 어시스턴트를 결합하는 모든 곳에서 동일한 형태의 문제가 계속해서 나타날 것이기 때문입니다.

발생한 사건

이 공격은 교과서적인 간접 프롬프트 주입 (Indirect Prompt Injection) 사례입니다. 사용자는 아무런 잘못도 하지 않았습니다. 사용자는 시트를 가져오거나 커넥터를 통해 데이터를 불러오는데, 그 데이터 어딘가에 공격자가 제어하는 텍스트 블록이 자리 잡고 있습니다. PromptArmor의 시연에서 악성 지침은 흰색 배경에 흰색 텍스트로 작성되어, 시트를 훑어보는 사람의 눈에는 보이지 않지만 셀을 파싱(Parsing)하는 모델에게는 완전히 읽힐 수 있는 상태였습니다.

나중에 사용자가 어시스턴트에게 일반적인 질문을 던지면, 모델은 해당 숨겨진 지침을 포함한 전체 컨텍스트 (Context)를 읽고 이를 마치 사용자가 보낸 것처럼 취급합니다. 주입된 텍스트는 어시스턴트에게 외부 스크립트를 가져와 실행하도록 명령합니다. 이 스크립트는 확장 프로그램이 이미 보유하고 있는 권한으로 실행되는데, 이는 현재의 워크북을 읽고, 그 안에 링크된 다른 워크북의 URL을 찾아내어 외부로 확장해 나갈 수 있음을 의미합니다. PromptArmor는 단 한 번의 트리거로 총 12개의 워크북을 유출한 후, 그 위에 가짜 채팅 인터페이스를 띄워 사용자가 다음에 입력하는 모든 내용을 수집했다고 보고했습니다.

가장 우려해야 할 세부 사항은 그들의 보고서에 담긴 다음 문구입니다: 사용자가 자동 편집 기능을 명시적으로 비활성화했을 때조차 공격이 성공했다는 점입니다. 모든 이들이 안전장치(safety net)로 지목하는 '인간 참여형 승인(human-in-the-loop approval)'이 이를 잡아내지 못했는데, 이는 악성 작업이 승인 흐름(approval flow) 외부에서 실행되는 외부 스크립트 내부에서 발생했기 때문입니다. 가드레일(guardrail)은 실재했습니다. 공격자는 그것을 우회했습니다.

OpenAI의 대응은 직접적이었습니다. 그들은 성명을 통해 "모델의 Apps Script 코드 생성 능력을 제거함으로써 위험을 없애야 한다"며 "사용자를 보호하기 위한 즉각적인 조치를 취했다"고 밝혔으며, 샌드박싱(sandboxing)을 재평가하고 다른 제품 전반에 걸쳐 유사한 기능을 검토할 것이라고 말했습니다. 코드 생성 기능을 제거하는 것은 투박한 해결책(blunt fix)이지만, 이처럼 최근에 발생한 사고에 대해서는 합리적인 조치입니다. 이는 이번에 뚫린 특정 문을 닫는 역할을 합니다.

투박한 해결책이 올바른 결정인 이유, 그리고 그것만으로는 충분하지 않은 이유

Apps Script 생성을 차단하는 것은 정확히 이 취약점(exploit)을 무력화합니다. 하지만 이는 근본적인 문제, 즉 모델이 자신을 위해 일하는 사람의 지시와 읽도록 요청받은 데이터 내부에 있는 지시를 구분하지 못한다는 문제를 해결하지는 못합니다. 이러한 혼란은 여러분이 올해 읽은 거의 모든 프롬프트 인젝션 (Prompt Injection) 사례의 근본 원인이며, 단 하나의 기능(capability)을 제거한다고 해서 사라지는 것이 아닙니다.

다른 모든 시스템에서와 마찬가지로 신뢰 경계(trust boundary)를 생각해 보십시오. 웹 보안에서 우리는 아주 오래전에 입력값(input)을 절대 신뢰해서는 안 되며, 입력값이 데이터 평면(data plane)에서 제어 평면(control plane)으로 넘어오게 해서는 결코 안 된다는 것을 배웠습니다. SQL 인젝션 (SQL injection)이 바로 그것입니다. 데이터여야 했던 문자열이 명령어로 해석되는 것입니다. 프롬프트 인젝션도 동일한 실패 모드(failure mode)를 보이지만, 차이점은 파서(parser)가 언어 모델(language model)이고 "쿼리(query)"가 대화 전체라는 점입니다. 모델에는 준비된 문구(prepared statement)와 같은 대응 수단이 없습니다. 컨텍스트 윈도우 (context window)에 있는 모든 것은 설계상 모델의 다음 행동에 영향을 미칠 자격이 있습니다.

그 점이 바로 이 문제를 어렵게 만드는 요소입니다. SQL 인젝션 (SQL injection)에 대한 해결책은 구조적이었습니다. 엔진이 쿼리 (query)와 데이터를 절대 혼동할 수 없도록 쿼리와 데이터를 분리하는 것이었죠. 우리는 아직 언어 모델 (language models)을 위한 깔끔한 구조적 해답을 가지고 있지 않습니다. 우리가 현재 가질 수 있는 실질적인 완화 조치 (mitigations)들은 다소 지루한 것들입니다. 권한 범위 (scope permissions)를 엄격하게 제한하여, 보조 도구 (assistant)가 해킹당하더라도 접근할 수 있는 범위를 줄여야 합니다. 모든 외부 데이터 가져오기 (fetch)나 코드 실행 (code execution)을 별도의 게이트 (gate)가 필요한 특권 작업으로 취급해야 하며, 이를 단순히 "사용자가 이 세션을 승인함"이라는 일반적인 권한으로부터 상속받게 해서는 안 됩니다. 사용자가 무엇을 요청했는지뿐만 아니라, 보조 도구가 실제로 무엇을 수행했는지 로그 (log)를 남기십시오. 그리고 업로드된 파일이 페이로드 (payload)를 담고 있을 수 있다고 가정하는 것과 마찬가지로, 신뢰할 수 없는 소스로부터 모델에 입력하는 모든 데이터는 명령 (instructions)을 포함할 수 있다고 가정해야 합니다.

솔직한 견해

이것이 OpenAI의 버그인지 아니면 기술 자체의 내재적 특성인지에 대해 Hacker News에서 상당한 논쟁이 있었으나, 솔직한 답변은 '둘 다'입니다. OpenAI는 대화를 통해 데이터를 유출하도록 유도될 수 있는 확장 프로그램을 출시했으므로, 그들이 해결의 책임을 지며 실제로 빠르게 해결책을 내놓았습니다. 하지만 이러한 모델을 기반으로 제품을 구축하는 모든 이들은 이제 OpenAI가 처했던 것과 동일한 상황에 놓여 있습니다. 만약 당신의 제품이 사용자가 작성하지 않은 데이터를 읽고, 당신의 보조 도구가 실제적인 결과가 따르는 행동을 취할 수 있다면, 당신이 아직 인지했는지 여부와 상관없이 이러한 종류의 취약점 (vulnerability)을 안고 있는 것입니다.

저는 소규모 모니터링 및 보안 도구를 개발하며, 제가 계속해서 되새기는 교훈은 보안의 지루한 부분들이 결국 당신을 구한다는 사실입니다. 최소 권한 원칙 (least-privilege scoping)이나 통합 서비스가 수행하는 모든 외부 요청을 로그로 남기는 것에 대해 열광하는 사람은 아무도 없습니다. 하지만 바로 그러한 통제 장치들이 이번 사건을 12개의 워크북(workbook)이 유출되는 침해 사고에서 단 하나의 의심스러운 로그 라인으로 끝낼 수 있었던 방법입니다. 화려한 AI 기능은 데모 (demo)의 주인공이 되지만, 지루한 경계 설정 (boundary)이 당신을 구합니다.

만약 당신이 실제로 중요하게 생각하는 어떤 작업에 대해 AI 기능 (AI features)을 평가하고 있다면, 질문은 "모델이 충분히 똑똑한가"가 아닙니다. 질문은 "이것이 어디까지 접근할 수 있는가, 그리고 누군가 모델이 읽는 데이터 안에 지시 사항 (instructions)을 숨겨둔다면 어떤 일이 발생하는가"가 되어야 합니다. 제품을 출시 (ship)하기 전에 모델에게 물어보십시오. 공격자들은 출시 후에 분명히 물어볼 것이기 때문입니다.

제가 사용하는 도구들과 주의해야 할 도구들에 대한 더 솔직한 기록은 tools.thesoundmethod.me에서 계속 업데이트하고 있습니다. 제휴 마케팅을 위한 과장 없이, 실제 사용 환경에서 견뎌낸 것들만 담았습니다.

출처 (Sources)

• PromptArmor, "ChatGPT for Google Sheets Exfiltrates Workbooks": https://www.promptarmor.com/resources/gpt-for-google-sheets-data-exfiltration
• Hacker News 토론 (301 points, 109 comments): https://news.ycombinator.com/item?id=48349487
• PromptArmor 공개에 대한 RuntimeWire의 보도: https://runtimewire.com/article/promptarmor-chatgpt-for-google-sheets-exfiltration
• PurpleSec, "Data Exfiltration Via AI Prompt Injection": https://purplesec.us/learn/data-exfiltration-ai-prompt-injection/