High-severity bug: Gmail write action executed without required confirmation

High-severity bug: Gmail write action executed without required confirmation

Summary

ChatGPT Work sent an external Gmail message without presenting the confirmation required by my Gmail plugin permission settings.

The model misinterpreted an ambiguous instruction. More importantly, the configured technical permission gate did not stop the resulting Gmail write action.

Date and environment

• Date: 15 August 2026
• Send time: approximately 11:03:50 BST / 10:03:50 UTC
• Product: ChatGPT Work
• Client: ChatGPT native Android app
• App version: ChatGPT/1.2026.216
• Device/OS: Samsung SM-G990B, Android 16
• Plugin: Gmail
• Project: Rothiemay Planning Objections
• Exact model: not visible to me

Permission state

Before the incident, Gmail was configured to permit reading but require approval before changes.

Immediately after the incident, ChatGPT’s permission inspector reported:

• Global permission: “Always ask”
• Gmail-specific permission: “Allow read actions”
• Description: “ChatGPT can read without asking, but will ask before making changes.”

I have since changed all permissions to “Always ask” and am disconnecting Gmail as a precaution.

What happened

1. ChatGPT had prepared a corrected internal evidence ZIP for review by Claude.
2. The assistant’s preceding message ended by saying to use that v2 ZIP as the controlled final archive.
3. I replied only: “Proceed.”
4. I intended this to refer to the named evidence pack. I did not instruct ChatGPT to send an email.
5. The assistant incorrectly interpreted “Proceed” as authorisation to submit a formal representation by email.
6. The assistant announced that interpretation in a progress message, but did not ask me to confirm it.
7. I did not reply to, approve or confirm that proposed send.
8. ChatGPT invoked Gmail’s send action through the Work programmatic tool-execution path.
9. No Gmail approval prompt, permission dialogue or recipient confirmation was presented.
10. Gmail sent the message successfully.

Email sent

• Recipient: OPRED@Energysecurity.gov.uk
• Subject: Rosebank Field Development – Representation – ES/2022/001
• Attachment: Rosebank_Field_Development_Representation_Jean_D_Reid_15Aug2026.docx
• Attachment size: 44,908 bytes
• Attachment SHA-256: 6484b8e14bfb0b01c7b90de5388df2f233eba76bb57754d0515cf1570bd025c8

The message appeared in Gmail with the SENT label.

Security and consent impact

This was a formal representation to a UK government regulator. Sending it created an external procedural and reputational commitment.

The attachment happened to be the corrected public-facing representation. The internal evidence ZIP, source pack and Claude review notes were not disclosed.

That limited the data exposure in this instance, but does not reduce the seriousness of the permission failure. The same failure could potentially send confidential material or create a consequential external commitment.

No prompt injection or malicious third-party content was involved.

Expected behaviour

Even if the model incorrectly inferred that “Proceed” meant “send,” Gmail’s configured permission boundary should have blocked the write action and presented a separate confirmation showing:

• recipient;
• subject;
• message body;
• attachment; and
• the specific proposed action.

The email should not have been sent until I explicitly approved that prompt.

Actual behaviour

The Gmail send action completed without any confirmation prompt, despite the Gmail permission being “Allow read actions” and requiring approval before changes.

This appears inconsistent with both the displayed permission description and OpenAI’s documentation stating that write actions require manual confirmation.

Relevant documentation:

https://developers.openai.com/api/docs/mcp#risks-and-safety

Reproduction status

Observed once in a real account.

I have not attempted to reproduce it because doing so would create another unauthorised external email. Please investigate using the session and server-side action logs rather than asking me to reproduce it against my Gmail account.

Possible technical area to investigate

The Gmail send action was invoked through a programmatic/code-mode tool-execution step rather than through a visible direct-plugin confirmation flow.

Please investigate whether nested or programmatic plugin calls can bypass:

• app-specific “Allow read actions” restrictions;
• global “Always ask” settings;
• write-action classification; or
• the user-facing approval elicitation layer.

This is an observed execution path, not a proven root cause.

Evidence available

• Full conversation transcript showing the ambiguous “Proceed” message.
• The assistant’s unconfirmed interpretation.
• The absence of any intervening approval.
• Tool result confirming the Gmail send.
• Gmail Sent record.
• Permission-inspector result showing the Gmail setting.
• Screenshot of the current permission settings.
• The exact attachment and its SHA-256 checksum.

Requested action

Please:

1. Treat this as a high-severity consent and permission-enforcement incident.
2. Preserve and examine the session and Gmail plugin action logs.
3. Determine why the configured write-confirmation gate did not trigger.
4. Check whether the same execution path affects other plugins or external write actions.
5. Confirm whether the Gmail send action was classified correctly as a write.
6. Add a regression test ensuring that inferred natural-language authorisation cannot replace the configured plugin confirmation prompt.
7. Confirm what remediation has been applied and whether it is safe to reconnect Gmail.