Mashable reported that Claude can now send Gmail messages without asking first. Whatever you think of that specific change, it marks a threshold worth understanding: the point where an AI assistant stops suggesting things and starts doing them.
The security model for that is different, and most people are about to grant these permissions without thinking about it.
Read access and write access are not the same risk
An assistant that can read your mail has a confidentiality risk. If it goes wrong, information leaks.
An assistant that can send mail has an integrity risk. If it goes wrong, things happen in the world under your name: messages your contacts believe came from you, replies that commit you to something, forwarded threads that cannot be recalled.
The second is much harder to undo. A leaked document is bad; an email sent to your entire address book is a different category of bad, and there is no delete that reaches other people’s inboxes.
The problem specific to language models
Ordinary software does what it was programmed to do. A language model does what its input tells it to do, and it cannot reliably distinguish instructions from you from instructions embedded in the content it is reading.
This is called prompt injection, and it is the central unsolved problem in this area. If an assistant reads your inbox, and an email in that inbox contains text addressed to the assistant, the model may follow it.
An attacker does not need access to your account. They need only to send you a message. The instruction can be hidden in white text, in an HTML comment, or buried in a long quoted thread, and it never has to be seen by you.
Combine that with send permission and the shape of the attack is obvious: a message arrives, the assistant reads it while summarising your inbox, and follows an instruction to forward your password reset emails elsewhere.
This is not hypothetical. It has been demonstrated repeatedly against production assistants, and no vendor has claimed a general fix, because there is not one yet.
What to check before granting access
- Can you scope it? Read-only, or a single label, is dramatically safer than full mailbox access. Take the narrowest option that does the job.
- Is there a confirmation step for outbound actions? A draft you approve is a different product from a message that leaves. Prefer draft-only where offered.
- What is logged? You need to be able to see what it did, after the fact, without relying on memory.
- How do you revoke it? Find the revocation screen before you grant, not after something goes wrong.
- Does it touch other services? Calendar, contacts and files are frequently bundled into one consent screen.
Practical settings
Both Google and Microsoft accounts have a page listing every third-party application with access, and it is worth reading now rather than when something looks wrong. Most people find several they no longer recognise.
For a work account, this is not your decision alone. Connecting an assistant to a corporate mailbox may be a policy breach and, depending on your sector, a regulatory one.
A reasonable middle position: allow reading and drafting, withhold sending. You keep nearly all of the usefulness and none of the irreversibility.
The general principle
Grant the smallest permission that makes the tool useful, and add more only when you have a concrete reason.
That is ordinary security practice and it applies here with more force than usual, because the failure mode is not a program crashing. It is a system that behaved exactly as designed while following an instruction from someone who was not you.
For a real example of agents going far beyond their task, see our timeline of the OpenAI Hugging Face incident.
Join the discussion