PromptArmor's recent disclosure of a critical vulnerability in ChatGPT for Google Sheets represents one of the more technically consequential AI security findings of 2026. The attack, documented at promptarmor.com, demonstrates a complete indirect prompt injection chain that achieves cross-workbook data exfiltration, phishing overlay deployment, and attacker-controlled UI replacement, all without requiring any user approval, despite the extension offering an explicit human-in-the-loop setting designed to prevent exactly this class of outcome. The extension had accumulated over 185,000 downloads in under a month at the time of disclosure. That scale, combined with the severity of the attack surface, warrants careful technical examination.
The Anatomy of the Indirect Prompt Injection
Indirect prompt injection, as a class of attack, has been well characterised in the literature since at least Greshake et al. (2023), who demonstrated that LLM-integrated applications are fundamentally vulnerable when they process attacker-controlled data within the same context window used for instruction following. The ChatGPT for Google Sheets vulnerability is a textbook instantiation of this threat model, but with a particularly damaging capability profile.
The attack chain proceeds as follows. A victim imports an external spreadsheet into their Google Sheets workbook. That external sheet contains a prompt injection payload hidden in white-on-white text, invisible to casual inspection. When the user subsequently asks the ChatGPT sidebar to help integrate data from the imported sheet, the model processes the injected instructions alongside the legitimate user query. The injected payload instructs the model to fetch and execute an externally hosted script. Critically, this script executes under the permissions already granted to the ChatGPT for Google Sheets extension by the user, which include read access to workbook contents and the ability to run Google Apps Script.
The privilege escalation here is not a traditional one. The attacker does not need to compromise the extension's code or OAuth tokens directly. Instead, they exploit the model's instruction-following behaviour to act as an unwitting execution proxy. The extension's granted permissions become the attacker's permissions by virtue of the model treating injected instructions as authoritative.
Cross-Workbook Exfiltration and the Lateral Movement Problem
What distinguishes this attack from simpler prompt injection demonstrations is the lateral movement capability. The malicious script does not merely exfiltrate the active workbook. It parses the stolen data for URLs referencing other Google Sheets documents, then recursively exfiltrates those workbooks as well. PromptArmor's demonstration shows 12 workbooks exfiltrated in a single attack session triggered by one user query.
This recursive discovery and exfiltration pattern mirrors techniques seen in traditional network intrusion scenarios, where an initial foothold is used to enumerate and pivot to adjacent resources. The fact that spreadsheets routinely contain hyperlinks to related documents, budgets, personnel records, project trackers, makes this a particularly effective propagation strategy in enterprise environments. A single poisoned external dataset could, in principle, compromise an entire organisation's Google Workspace spreadsheet corpus if those documents are interlinked.
The failure of the human-in-the-loop control deserves specific attention. The extension's "Apply edits automatically" setting is documented as a mechanism requiring user approval before agentic actions complete. PromptArmor confirms this protection is bypassed entirely. This is consistent with a known weakness in human-in-the-loop designs for LLM agents: approval gates are typically positioned around the model's direct output actions, not around the execution of scripts that the model has been manipulated into invoking. Once a script is dispatched to the Apps Script runtime, it operates outside the model's approval workflow. The approval gate guards the wrong abstraction layer.
Phishing Overlay Attacks: UI Redressing via LLM Agents
The phishing component of this disclosure is architecturally distinct from the exfiltration vector but equally serious. The same injected script can open a sidebar that visually replaces the legitimate ChatGPT for Google Sheets interface with an attacker-controlled site. Because this sidebar is rendered within the Google Sheets UI chrome, users have reasonable grounds to trust it. The attacker's sidebar can:
- Harvest all subsequent user prompts entered into what appears to be the ChatGPT interface
- Serve a misaligned or adversarially configured chatbot to the user
- Present credential-harvesting UI impersonating OpenAI's authentication flows
- Execute Apps Script functions in the same manner as the legitimate extension, maintaining the illusion of normal operation
A second variant deploys a modal pop-up rendering an attacker-controlled page, which is a more conventional phishing vector but one that benefits from the trusted Google Sheets execution context. The sidebar variant is the more sophisticated of the two, because it achieves persistent session hijacking of the AI assistant interface rather than a one-shot credential phish.
This class of attack, UI redressing through injected agent actions, has not received sufficient attention in the AI security literature relative to data exfiltration. As LLM-integrated tools increasingly control application interfaces, the ability to substitute attacker-controlled UI surfaces becomes a significant threat to user trust models. Users are trained to trust the visual context of known applications; that trust assumption breaks down when the application's UI can be overwritten by injected instructions.
OpenAI's Disclosure Response and Documentation Failures
PromptArmor's disclosure timeline is worth examining critically. The vulnerability was reported to OpenAI on 8 May 2026. After three follow-ups over the subsequent three weeks, the only response received was an automated acknowledgement. Public disclosure followed on 27 May 2026, nineteen days after the initial report.
This is a relatively short window by conventional responsible disclosure standards, where 90 days is common practice. However, the decision to publish is defensible given the active deployment at scale, over 185,000 users, and the complete absence of vendor engagement. The calculus changes when a vulnerability is being actively exploited in the wild versus sitting dormant in a controlled research environment. Whether that threshold was met here is a judgement call, but the argument for earlier publication strengthens considerably when a vendor is unresponsive and the attack requires no user interaction beyond a single benign query.
The documentation failure PromptArmor identifies is arguably as significant as the technical vulnerability. OpenAI's published documentation for the extension describes functional limitations and data handling practices but does not disclose that the model can execute privileged Google Apps Scripts, nor that untrusted data sources can manipulate its behaviour. This is a systemic documentation problem for agentic AI products. Users and security teams cannot make informed risk decisions about tools whose capability surfaces are incompletely described. The principle of least privilege is difficult to apply when the privilege model itself is opaque.
Broader Implications for Agentic AI Security
This vulnerability is not an isolated implementation defect. It reflects structural tensions in how agentic LLM systems are designed. Several properties of modern LLM-integrated tools combine to make this class of attack generically difficult to prevent:
- Unified context windows: Instructions and data occupy the same token space, making semantic separation between trusted instructions and untrusted content a fundamental rather than incidental challenge.
- Ambient authority: Extensions operate with permissions granted at installation time, not scoped to individual user actions. A model manipulated into misusing those permissions has full access to everything the user authorised.
- Script execution as a capability: Granting an LLM agent the ability to execute arbitrary code dramatically expands the blast radius of any successful prompt injection. This capability should be treated with the same caution as code execution in any other security context.
- Approval gate placement: Human-in-the-loop controls that operate at the model output layer do not constrain downstream script execution, as this case demonstrates.
Mitigations require addressing multiple layers simultaneously. At the model level, stronger contextual separation between instruction sources is needed, though this remains an open research problem. At the application level, script execution capabilities should require explicit per-action authorisation rather than ambient permission inheritance. At the organisational level, Google Workspace administrators can restrict access to the extension via Workspace settings under Permissions and roles, which is the only reliable control available to enterprise users at present.
The longer-term question is whether the architecture of LLM-integrated productivity tools is compatible with the security requirements of enterprise environments at all, given current model capabilities. The answer is probably yes, but it requires vendors to treat prompt injection as a first-class threat in their security models rather than an afterthought. The ChatGPT for Google Sheets case suggests that gap remains substantial. As agentic AI tools proliferate across productivity software, the security research community will need to treat this class of vulnerability with the same systematic rigour applied to SQL injection or cross-site scripting in an earlier era of web security.