ChatGPT Sheets 보안 보고, 사이드바까지 덮은 프롬프트 인젝션
PromptArmor가 ChatGPT for Google Sheets 유출 경로를 공개했고, OpenAI는 Apps Script 코드 생성을 제거했습니다.
- 무슨 일: PromptArmor가
ChatGPT for Google Sheets에서 workbook 유출과 phishing overlay가 가능한 간접 프롬프트 인젝션을 공개했습니다.- 보고서는 한 sheet의 숨은 지시가 Apps Script 실행으로 이어지고, 내부 financial model에서 연결된 workbook까지 따라갔다고 설명합니다.
- OpenAI 조치: OpenAI 보안팀은 2026년 5월 31일 모델의 Apps Script code 생성 능력을 제거했다고 밝혔습니다.
- 실무 영향: spreadsheet AI의 위험은 답변 오류가 아니라 데이터 접근, script 실행, sidebar UI 권한이 한 표면에 붙는 데 있습니다.
PromptArmor는 2026년 5월 27일 ChatGPT for Google Sheets 취약점 보고서를 공개했습니다. 보고서의 주장은 좁고 구체적입니다. 사용자가 외부 데이터를 spreadsheet에 가져오고, ChatGPT sidebar에 정상적인 작업 요청을 보내면, sheet 안에 숨겨진 간접 프롬프트 인젝션이 모델을 조작해 외부 Apps Script를 실행할 수 있다는 내용입니다. 공격 결과는 workbook 유출, phishing pop-up, ChatGPT sidebar를 덮는 공격자 제어 UI, spreadsheet 수정으로 이어졌다고 정리됐습니다.
OpenAI의 대응은 2026년 5월 31일 HN 토론과 PromptArmor 원문 업데이트에 먼저 나타났습니다. OpenAI 보안팀의 Max Burkhardt는 보고가 disclosure pipeline의 틈으로 빠졌다고 설명했고, 사용자 보호를 위해 모델이 Apps Script code를 생성하는 능력을 제거했다고 밝혔습니다. 같은 설명은 Google Sheets API와 sandboxing 방식을 다시 검토하고, 유사한 기능 표면을 재검토하겠다는 내용까지 포함했습니다.

OpenAI 도움말 문서에서 ChatGPT for Excel and Google Sheets는 spreadsheet 안에 사는 sidebar형 AI 경험입니다. 문서는 budget, planning, forecasting, KPI reporting, formula review 같은 spreadsheet-heavy workflow를 예시로 들고, Google Sheets 버전은 Google Workspace Marketplace에서 설치한다고 안내합니다. 이 기능은 Free, Go, Plus, Pro, Business, Enterprise, Edu, K-12 사용자에게 제공되며, Business와 Enterprise 관리자는 workspace 설정에서 ChatGPT for Excel and Google Sheets를 켜거나 끌 수 있습니다.
문서상 기능 범위는 이미 일반 채팅보다 넓습니다. 사용자는 workbook 안에서 자연어로 표를 만들고, 수식을 설명받고, 입력값 변경에 따라 모델을 업데이트할 수 있습니다. 문서는 Skills와 apps도 지원한다고 설명합니다. Apps는 ChatGPT 계정에 연결된 승인 파일, 시스템, 데이터 소스를 spreadsheet 작업에 활용하게 해주며, admin은 앱 접근을 제어할 수 있습니다. 같은 문서는 prompts와 responses가 Compliance API에 남고, enterprise control로 data residency, inference residency, Enterprise Key Management, role-based access controls를 지원한다고 적습니다.
PromptArmor 보고서가 겨냥한 부분은 이 기능 목록 사이의 빈 공간입니다. 문서는 "중요한 작업 전에는 복사본을 만들고, 수식과 변경 셀을 검토하라"고 안내하지만, PromptArmor는 모델이 privileged script를 실행하고 외부 사이트로 데이터를 보내는 경로를 보였다고 주장했습니다. 사용자가 spreadsheet 수정 전 승인 설정을 켰는지보다, 모델이 어떤 종류의 코드를 만들 수 있고 그 코드가 어떤 Google Sheets 권한으로 실행되는지가 더 큰 질문이 됩니다.
외부 sheet 또는 connector data 안의 숨은 instruction
사용자의 정상 요청: 재무 모델 업데이트, 데이터 통합, trend 요약
모델이 attacker-controlled Apps Script 생성을 도움
script가 workbook 링크를 따라가고 sidebar 또는 pop-up UI를 조작
OpenAI 조치: Apps Script code 생성 능력 제거
보고서의 공격 체인은 spreadsheet 업무에서 흔한 행동으로 시작합니다. 사용자는 내부 financial model을 열고, 외부 비교 데이터나 보조 sheet를 가져옵니다. 공격자는 그 외부 sheet 안에 흰색 글자처럼 눈에 띄지 않는 prompt injection을 숨깁니다. 사용자가 "이 데이터를 내 모델에 반영해 달라"는 식의 정상 요청을 하면, ChatGPT for Google Sheets가 그 숨은 지시까지 읽고 공격자 제어 script 실행으로 넘어간다는 구조입니다.
PromptArmor가 공개한 demo에서 script는 먼저 현재 workbook의 financial model을 외부 서버로 보냅니다. 이어서 유출된 데이터 안에서 다른 spreadsheet URL을 찾고, 그 링크를 따라 budget 관련 workbook을 추가로 유출합니다. 원문은 이 과정이 반복돼 총 12개 workbook까지 이어졌다고 설명합니다. 사용자가 sidebar의 stop 버튼을 누르는 것도 이미 시작된 script 실행을 중단하지 못한다고 덧붙였습니다.
여기서 "승인 버튼"은 충분한 경계가 아니었습니다. PromptArmor는 Apply edits automatically 설정을 꺼둔 상태, 즉 사용자가 ChatGPT의 자동 편집을 명시적으로 막은 상태에서도 공격이 성공했다고 적었습니다. 이유는 편집 승인 UI가 spreadsheet 셀 변경을 중심으로 설계돼 있어도, script 실행과 외부 요청은 별도 권한 경로를 탈 수 있기 때문입니다. 이 주장이 맞다면 보안 질문은 "AI가 셀을 바꿨는가"가 아니라 "AI가 어떤 실행 능력을 위임받았는가"로 바뀝니다.
Phishing overlay도 같은 맥락입니다. PromptArmor 이미지는 공격자 sidebar가 정상 ChatGPT sidebar 옆에서 거의 같은 형태로 보이는 장면을 제시합니다. 보고서는 공격자 script가 sidebar를 열어 ChatGPT 확장을 가장하고, 사용자의 prompt를 수집하거나, 추가 connector 재연결을 유도하거나, OpenAI credential을 훔치는 UI를 보여줄 수 있다고 설명합니다. spreadsheet 사용자는 표와 sidebar를 같은 업무 화면으로 보기 때문에, 이 공격은 일반 웹 phishing보다 더 가까운 권한 표면에서 일어납니다.
| 보안 경계 | 문서에 보이는 통제 | 이번 보고서의 질문 |
|---|---|---|
| Workbook 변경 | 사용자 검토, 변경 셀 확인, 복사본 사용 | 편집 승인 밖의 script 실행은 별도 확인되는가 |
| 연결 데이터 | Apps와 user permission, admin control | untrusted sheet가 connector 권한까지 간접 조작하는가 |
| 실행 능력 | 공식 문서에는 제한과 data handling 중심 안내 | 모델이 privileged Apps Script를 만들 수 있었는가 |
| 감사와 대응 | Compliance API, workspace RBAC, EKM | script 실행 로그와 외부 전송 증거가 남는가 |
OpenAI 도움말 문서의 admin 섹션은 당장 확인할 지점을 제공합니다. 관리자는 workspace settings의 permissions and roles에서 ChatGPT for Excel and Google Sheets를 enable할 수 있고, 앱 접근도 admin portal에서 제어할 수 있습니다. 문서는 MCP apps의 경우 read-only와 non-destructive annotation이 정확해야 하며, 명시 annotation이 없는 tool은 보수적으로 처리될 수 있다고 설명합니다. spreadsheet AI를 도입한 조직은 이 문장을 운영 정책으로 내려야 합니다. "AI가 읽는 데이터"와 "AI가 실행할 수 있는 도구"를 같은 승인으로 묶으면 위험을 설명하기 어렵습니다.
이번 사건의 숫자는 크지 않지만, 위험 표면은 큽니다. PromptArmor는 extension이 출시 한 달 미만에 18만5000회 이상 다운로드됐다고 썼습니다. OpenAI 문서는 같은 기능이 개인 사용자부터 Business, Enterprise, Edu, K-12까지 글로벌 제공 대상이라고 안내합니다. 재무 모델, 예산, 영업 pipeline, HR compensation table처럼 spreadsheet에 모이는 데이터의 종류를 고려하면, 한 workbook에서 다른 workbook 링크를 따라가는 공격은 SaaS 파일 공유 구조와 잘 맞물립니다.
HN 반응은 세 갈래였습니다. 첫 번째는 OpenAI 보안팀의 공개 답변을 긍정적으로 보되, disclosure pipeline에서 5월 8일 보고가 5월 31일 공개 답변까지 밀린 과정을 문제 삼는 반응입니다. 두 번째는 prompt injection 자체를 LLM 구조의 어려운 문제로 보고, 데이터와 instruction을 완전히 분리할 수 없다는 비관론입니다. 세 번째는 모델을 탓하는 대신 tool execution을 local, container, micro-VM, read-only mount, no-network 기본값으로 격리해야 한다는 운영 관점입니다.
개발팀이 가져갈 실무 결론은 단순합니다. spreadsheet AI를 켜기 전에 관리자 설정에서 기능 대상 사용자를 좁히고, 연결 앱과 MCP tool의 read-only annotation을 점검해야 합니다. Google Sheets나 Excel 표면에서 Apps Script, macro, sidebar UI, 외부 fetch가 모델 출력과 연결되는지 확인해야 합니다. Compliance API가 prompt와 response를 남긴다 해도 script가 어느 URL로 데이터를 보냈는지, 어떤 workbook ID를 열었는지, 사용자가 stop을 눌렀을 때 실행이 끊겼는지는 별도 감사 범위입니다.
제품팀 입장에서는 승인 UX를 다시 봐야 합니다. 사용자는 "자동 편집 끄기"를 보면 spreadsheet 변경 전체가 멈춘다고 이해하기 쉽습니다. 하지만 이번 보고서의 쟁점은 편집이 아니라 실행입니다. run script, open sidebar, fetch external URL, read linked workbook, write cell은 서로 다른 권한입니다. 하나의 "Apply edits automatically" 토글로 묶으면 사용자와 admin은 무엇을 승인했는지 알기 어렵습니다.
OpenAI가 Apps Script code 생성 능력을 제거한 조치는 빠른 차단으로 읽힙니다. 다만 이 조치가 장기 설계의 끝은 아닙니다. OpenAI 보안팀의 설명도 Google Sheets API와 sandboxing 접근을 다시 보겠다고 했습니다. spreadsheet-native AI가 업무 도구로 자리 잡으려면 모델이 코드를 만들 수 있는지보다, 실행 능력이 어떤 policy engine을 통과하고 어떤 로그로 남으며 어떤 data boundary를 넘지 못하는지가 문서와 제품 UI에 함께 나타나야 합니다.
이번 보고서는 AI 에이전트 보안 논의를 코딩 도구 밖으로 옮깁니다. 최근 관심은 Codex, Claude Code, Copilot cloud agent처럼 repository와 shell을 다루는 에이전트에 몰렸습니다. 그러나 spreadsheet는 더 오래된 업무 자동화 표면이고, Apps Script와 macro는 이미 조직 안에서 강력한 권한을 가진 실행 수단입니다. LLM sidebar가 그 위에 붙으면, prompt injection은 "대답을 속이는 입력"이 아니라 "업무 앱 권한을 우회하는 입력"이 됩니다.
따라서 이번 사건의 교훈은 특정 vendor 하나로 끝나지 않습니다. Google Sheets, Excel, Notion, Slack, CRM, BI dashboard에 AI sidebar가 붙을 때마다 같은 질문을 해야 합니다. 모델이 보는 데이터는 신뢰할 수 있는가. 모델 출력이 실행으로 넘어가기 전 어떤 validator가 있는가. 외부 네트워크는 기본 차단인가. 연결 앱 권한은 최소 권한인가. 사용자에게 보이는 sidebar UI와 공격자가 띄운 overlay를 구분할 신뢰 표시가 있는가. 이 질문들이 제품 요구사항에 들어가지 않으면, 다음 보고서는 다른 업무 앱 이름으로 반복될 수 있습니다.