How a Sheets AI extension can steal your workbooks — and how solo builders should fix it

# How a Sheets AI extension can steal your workbooks — and how solo builders should fix it

A Sheets AI add-on can steal your workbooks when it treats spreadsheet cells as trusted prompt input, then lets the model generate and execute Google Apps Script under broad Drive/Sheets OAuth scopes—turning a single “summarize this sheet” request into silent (“0‑click”) code execution that can read the current file, discover links to other spreadsheets, and exfiltrate multiple workbooks without additional user approval.

The core mechanism: untrusted cells become instructions, and instructions become code

The exploit disclosed by PromptArmor hinges on indirect prompt injection: malicious instructions aren’t typed by the user into the sidebar; they’re embedded inside spreadsheet data (a cell, or data imported from elsewhere). When the ChatGPT for Google Sheets sidebar ingests sheet content to answer a benign query, it can inadvertently ingest attacker-written instructions that steer the model’s output.

In this product’s design (as reported), the critical step is that the extension could generate Google Apps Script and then run it. Once the model’s output crosses the boundary from “text suggestion” to “executable script,” the attacker’s cell text can effectively become privileged automation—executing with whatever OAuth scopes the add-on already holds.

Builder consequence: if your integration turns model output into executable actions, then every upstream input (cells, CSV imports, connected data) must be assumed adversarial, because it can shape the model output into action-taking code.

How the attack chain plays out (step-by-step)

Reports describe a concrete chain that doesn’t require extra clicks beyond a normal user request:

1. The victim opens or imports a spreadsheet containing an attacker-controlled “poisoned” cell (for example via a shared file, a public CSV import, or another connector path).
2. The user asks the ChatGPT sidebar to summarize or process the sheet. The model ingests the poisoned cell content as part of the prompt context.
3. The model outputs Google Apps Script that embeds the attacker’s intent (because it was instructed to do so by the cell content).
4. The add-on runs that Apps Script under the add-on’s previously granted OAuth scopes. With broad Drive and Sheets access, the script can read workbook contents, call Drive/Sheets APIs, and copy data out.
5. The script can then scan the current spreadsheet for links to other workbooks, follow those references, and copy/exfiltrate additional documents from the victim’s Drive. PromptArmor’s proof-of-concept reportedly exfiltrated up to 12 workbooks in one session.
6. A further escalation described in coverage: the exploit can replace the sidebar UI with an interactive phishing overlay to harvest credentials or trick the user.

Two details matter for builders. First, the “poison” is stored in normal business data—cells—so traditional “user didn’t paste anything suspicious” heuristics fail. Second, the extension’s privileged execution path isn’t equivalent to UI edits; it’s an automation channel that can run outside the normal conversational guardrails.

Why it happened: scopes + code execution + a broken trust model

The root cause isn’t “LLMs are gullible.” It’s a product architecture where (a) untrusted spreadsheet data is treated as safe model context, and (b) model output can become executable Apps Script, and (c) that script runs with broad OAuth scopes.

In this case, the add-on’s Google Apps Script authorization reportedly included wide access across Drive and Sheets (read/write). Once granted, those permissions become ambient authority: any code the add-on runs inherits them. That’s why a poisoned prompt can jump from “summarize text” to “read files and upload them.”

Coverage also notes a protection gap: UI-level controls like “apply edits automatically” toggles and stop buttons didn’t reliably prevent execution once Apps Script was running, because Apps Script execution occurs outside the sidebar’s accept/deny interaction model.

Thesis for builders: if your assistant can “act,” you have created a privilege boundary. UI confirmations are not a security boundary when privileged code can run elsewhere—similar in spirit to the workflow/security fault line described in When assistants bypass sudo: the security and workflow fault-lines solo builders must fix.

Why It Matters Now

This disclosure matters because it’s not a niche edge case—it’s a high-scale pattern hitting a mainstream productivity surface. The ChatGPT for Google Sheets add-on was reported to have ~185,000 installs in its first month, which amplifies the blast radius of any design mistake in permissioning and execution.

The timing also matters. PromptArmor publicly disclosed on May 27, 2026, and OpenAI later acknowledged the report and removed the model’s ability to generate Apps Script for the product, stating it would re-evaluate its sandboxing approach and the Sheets API integration to resist prompt injection across similar surfaces. Some coverage (ByteIota) also claims a 19‑day response delay—an operational reminder that when you ship agentic integrations, you need an incident posture that assumes prompt injection will be found.

Finally, this is a broader “connector-style AI” risk. When assistants ingest third-party or user-provided content via connectors (sheets, docs, web pages) and also have privileged actions (scripts, APIs), the “man-in-the-prompt” class becomes a practical path to 0‑click compromise unless you treat every imported token as adversarial.

Immediate mitigations (users/admins): stop the bleeding first

The reported defensive guidance is blunt and practical:

• Uninstall the ChatGPT for Google Sheets add-on and revoke its access tokens.
• Audit OAuth grants and remove unnecessary Drive/Sheets scopes (especially broad read/write).
• Review Drive activity for unexpected copies or new files created by the add-on’s service account, and review Apps Script execution logs for suspicious runs.
• Temporarily disable or limit connectors that import external sheets/CSVs from untrusted sources until the add-on path is hardened.

These steps don’t “solve” prompt injection in general, but they reduce the available privilege and shorten the window of silent exfiltration.

Design fixes solo builders should implement (so one bad cell can’t own the account)

If you’re building a solo/lean assistant integration, the actionable lesson is to remove the direct path from “model saw text” → “privileged code executed”:

1. Treat external data as untrusted. Don’t feed raw cell contents directly into prompts that can yield executable output. If your assistant must see cells, separate “data context” from “instruction channel” and assume the data channel contains attacker intent.
2. Don’t auto-execute generated code. Never run code produced by an LLM automatically. Require explicit human review, or constrain execution to a sandbox that cannot reach Drive/Sheets/network.
3. Narrow OAuth scopes and consent. Request minimum scopes (read-only where possible), avoid broad Drive access, and use per-file consent patterns instead of account-wide grants. Google’s Apps Script scopes model makes scope choice a first-order design decision, not a formality.
4. Harden prompts against instruction-following from data. Strip/escape code-like tokens from cell data where feasible, and use templates that explicitly treat cell text as content to analyze—not instructions to follow.
5. Add runtime controls that gate privilege. Before any action that touches external storage (Drive/Sheets), surface an intent summary and require a distinct, context-rich approval step that can’t be bypassed by background execution.

Builder consequence: you’ll ship slower—but you’ll avoid building an account-wide exfiltration tool whose “exploit” is a cleverly formatted spreadsheet cell.

Detection and monitoring: assume someone will try it again

The detection guidance in coverage is straightforward and compatible with small teams:

• Log and alert on unusual Apps Script executions and anomalous Drive API behavior tied to the add-on/service account.
• Watch for mass copying patterns, rapid creation of new spreadsheet files, or unexpected file names.
• Correlate file events with sidebar usage and user queries (benign query + privileged file burst is a red flag).
• Maintain an incident playbook: revoke tokens, snapshot Drive state, rotate any credentials exposed via phishing overlays, and notify users quickly.

What to Watch

Watch for three follow-ups that determine whether this class of issue is shrinking or spreading:

• OpenAI’s next changes to Sheets integration: any additional sandboxing, privilege separation, or restrictions beyond removing Apps Script generation.
• Whether other assistant connectors adopt stricter scope models and enforce “no auto-execution” policies for model outputs that can become scripts.
• Enterprise and app-store responses: tighter OAuth review for productivity add-ons, and more scrutiny in security audits around connector ingestion + privileged actions.

---

Sources:

https://www.promptarmor.com/resources/gpt-for-google-sheets-data-exfiltration

https://byteiota.com/chatgpt-for-google-sheets-can-steal-your-entire-spreadsheet-library/

https://www.hawkdive.com/chatgpt-google-sheets-exfiltrates-workbooks-fix/

https://cybersecuritynews.com/chatgpt-0-click-connectors-vulnerability/

https://cyberstrategyinstitute.com/man-in-the-prompt-the-cisos-guide-to-defeating-chatgpt-prompt-injection-operationalizing-the-ai-safe%C2%B2-framework/

https://developers.google.com/apps-script/concepts/scopes