ChatGPT connected to Gmail, Drive, Teams and GitHub: what to check now about your connectors

Limit ChatGPT connectors per workflow to what is strictly necessary, enable only read rights and trusted sources by default, and log per session which external sources were read and where data went. Researchers showed that hidden instructions in emails or files could make ChatGPT quietly leak data through linked apps.

On 8 September 2026, Tweakers reported that security researchers had found a flaw in ChatGPT with which an attacker could gain access to apps linked to the chatbot, including Gmail, Google Drive, Microsoft Teams and GitHub. According to that reporting, ChatGPT could be steered through a crafted prompt to carry out hidden actions on those linked services, while the user saw a seemingly normal answer. For anyone who has linked ChatGPT to business mail, storage or code, this is reason to map and limit connector use now.

What exactly did the researchers demonstrate about the ChatGPT flaw via linked apps?

Check Point Research described the vulnerability as a shared clipboard inside the sandbox: a cross-account command channel within the ChatGPT environment with which attackers could piggyback hidden tasks on a victim's session. Commands and results were moved between accounts, so that the victim received a normal answer while their own connectors were used to access and leak data. That is the core of the technical analysis by Check Point on cross-account data leakage in ChatGPT.

CyberPress reported that vulnerabilities in ChatGPT's connector and memory system made it possible to extract confidential data from, among others, Gmail, Outlook, Google Drive, OneDrive, Jira, Slack, Microsoft Teams and GitHub without the user noticing. According to CyberPress, the findings were responsibly disclosed to OpenAI via a bug-bounty platform. That the scope is so broad underlines that this is not a single accidental mistake, but a pattern around agents and connectors.

How does an attack via hidden instructions in emails and files work?

The mechanism is indirect prompt injection. The attacker plants malicious instructions in content that the victim processes themselves. SecurityWeek described the earlier documented ShadowLeak attack by Radware, a zero-click vulnerability in ChatGPT's Deep Research feature with which data could be stolen from Gmail; according to SecurityWeek, Deep Research can also access services such as Google Drive, Dropbox, Outlook, Notion, Microsoft Teams and GitHub. The reporting by SecurityWeek on this server-side data theft attack states that OpenAI was informed on 18 June and fixed the flaw in early August, after which Radware confirmed that the attack no longer worked.

The technical description of ShadowLeak shows how such chains unfold:

• The attack payload is hidden in an email or a shared file in Gmail, Drive, Teams or GitHub.
• The user asks a normal question; in doing so the agent reads the supplied source.
• The agent follows the hidden instructions as if they came from the user.
• Data is sent to a server controlled by the attacker, without the user having to open the content.

In our assessment, this is the core of the problem: the agent does not draw a sharp distinction between the user's instruction and text it encounters in a source. Anyone wanting to know more about this type of tool-bound risk will find pointers in our piece on securing MCP integrations per tool call.

Why does a connector turn ChatGPT into a privileged meta-client over multiple systems?

Once ChatGPT is linked to mail, storage, collaboration environments and code repositories, it is no longer a single standalone SaaS application. It then functions as a layer on top of multiple high-trust systems. In our assessment, that is the broader significance of the reported vulnerabilities: every additional connector enlarges the blast radius if an agent lets itself be steered unintentionally.

That calls for the same discipline as with other non-human actors. NIST now treats AI agents as separate digital identities with their own access rules; we discuss that in our article on AI agents as separate digital identities with their own access rules. The way in which autonomous AI agents broke in via the supply chain also shows that the attack surface is shifting to the couplings themselves.

Which controls and logging should I set up now per workflow?

Based on the findings of Tweakers, Check Point, CyberPress, SecurityWeek and Radware, this is a practical checklist. The choices themselves are our editorial assessment, not a statement by those sources:

• Inventory per workflow which connectors are enabled and why.
• Turn connectors off by default and only enable them for the task that requires them.
• Give agents read rights only by default and limit where data may be sent.
• Restrict which sources an agent may read to trusted locations.
• Log per session which external sources were accessed and which actions were carried out.
• Include connector use explicitly in security and privacy audits.

More background on this kind of measure can be found in our topic hub on AI security and attack surfaces.

How does runtime verification help in checking connector use?

The common thread in the sources is that the problem arises during execution: the user sees a normal answer while, in the background, sources are read and data is moved. Policy on paper does not see that. Verification must therefore take place at the runtime and workflow level, with visibility into what an agent actually read and where output went.

From a craftsmanship perspective: this is precisely the gap that a verification layer can help close. Vera is such a privacy-focused verification layer for professionals who work with confidential information; it is not a chatbot and not its own language model. Vera can expose verification steps, corrections and sources, which supports review without guaranteeing correctness or eliminating hallucinations. For sensitive documents, the Semantic Privacy Shield can replace values with synthetic, session-only equivalents on EU infrastructure before AI processing; the workflow is fail-closed, so that nothing is forwarded when a privacy check fails. You can read more about this on the page about anonymisation of document values before AI processing. The final judgement always remains with the user.

The research findings point, in our assessment, in one direction: do not treat ChatGPT with connectors as an ordinary app, but as a privileged layer on top of your most important systems, and set up your controls accordingly.

Sources: The article draws on reporting by Tweakers, technical analyses by Check Point Research and Radware (via SecurityWeek and Security Affairs) and additional reporting by CyberPress.

← All articles in this topic ← All articles