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

You must now map which external systems ChatGPT can reach through linked connectors, disable all but strictly necessary integrations, grant read-only access where possible, and establish per-session logging of what data each connector accessed and where outputs were transmitted.

An analysis of 8 September 2026 of indirect prompt injection attacks through ChatGPT connectors argues that hidden instructions embedded in emails or files can cause the chatbot to leak data through linked applications without the user's knowledge. Researchers demonstrated that attackers could manipulate ChatGPT into executing unauthorised actions on Gmail, Google Drive, Microsoft Teams and GitHub whilst the user received a seemingly normal response. In our assessment, this reveals a fundamental gap: once ChatGPT is linked to high-trust systems, it becomes a privileged layer across your most sensitive infrastructure, and the controls you apply to it must reflect that elevation in risk.

What makes connectors a distinct attack surface?

When ChatGPT operates in isolation, it is a single application with defined boundaries. The moment you link it to mail, storage, collaboration tools and code repositories, those boundaries dissolve. The agent can now read from multiple sources and write to multiple destinations, all within a single user session. An attacker who can inject malicious instructions into content the user processes—a crafted email, a poisoned document, a compromised file—can cause the agent to execute hidden actions using the user's own credentials and access rights. The user sees a normal answer. In the background, data moves.

This is not a flaw in any single connector. It is a structural consequence of how agents process text without drawing a sharp distinction between user intent and content they encounter in sources. The broader significance is that every additional connector enlarges the blast radius if the agent can be steered unintentionally.

Which failure modes must you guard against?

• Indirect prompt injection — malicious instructions hidden in emails, documents or files that cause the agent to execute unintended actions on linked systems.
• Cross-account command execution — attackers using the victim's own session to access and exfiltrate data from connected applications.
• Unlogged data movement — sources read and outputs transmitted without visibility into what was accessed or where data went.
• Overpermissioned connectors — linked applications granted write access or access to sensitive repositories when read-only access would suffice.
• Scope creep in integrations — connectors added for specific workflows but left active across all uses of the application.

What concrete controls must you be able to demonstrate?

1. Inventory all active connectors — document which external systems ChatGPT can reach, the access level granted to each, and the business workflows that require each connection.
2. Enforce least-privilege access — configure connectors to read-only where the workflow permits, and restrict write access to trusted sources only.
3. Log per-session connector activity — record which sources each ChatGPT session accessed, what data was read, and where outputs were transmitted, with sufficient granularity to audit individual workflows.
4. Disable unused connectors — remove all integrations not actively required for current workflows, and require explicit approval before adding new ones.
5. Separate digital identities for agents — treat ChatGPT as a distinct digital actor with its own access rules, rather than as an extension of the user's own permissions.

How does runtime visibility differ from policy on paper?

Policy documents can specify that connectors should be limited and logged. But policy does not execute. The vulnerability emerges during execution: the user sees a normal answer whilst, in the background, sources are read and data is moved. Verification must therefore take place at the runtime and workflow level, with visibility into what the agent actually read and where output went. This is not something a connector configuration alone can provide. You need a verification layer that exposes what the agent accessed and what it transmitted, allowing you to review and correct before data leaves your environment.

What can tooling provide, and what remains your responsibility?

Verification layers can expose the sources an agent consulted, the reasoning steps it followed, and the outputs it produced, supporting human review without guaranteeing correctness or eliminating hallucinations. Some platforms can replace sensitive values with synthetic, session-only equivalents before processing, with workflows that fail closed if a privacy check does not pass. But no tool can eliminate the need for professional judgement about which connectors your workflows genuinely require, which access levels are appropriate, or whether the outputs are fit for use. The final assessment always remains yours.