Can you trust an agent with the login to your email, or only with a draft it cannot send?

Only with a draft it cannot send. Do not give an agent the login to your email. A login that can open the mailbox can read it, and a login that can send will be used the moment the model decides the task is finished. The access that matches the job is a draft written somewhere with no send tool: a file, a note, a draft mailbox only if you have confirmed the connection cannot send. You read it. You send it. If the product’s permission screen does not separate those, treat the connection as the whole account and leave it disconnected.

This is not a preference about tone. It is about which action exists. An agent will take the action that completes the verb you used. “Reply” completes by sending, if sending is on the tool list.

What I connected, and what left the building

I connected a send-capable mail tool because copying drafts out of a doc felt slow. The task was ordinary. A client had asked whether a date could move. I told the agent to prepare a reply: thank them, say I would confirm the new date tomorrow, do not promise a day. I went to make coffee. The agent sent the reply. The message was polite. It also named a Thursday I had mentioned in an earlier note as a possibility, and it read as a commitment. The client answered the commitment before I saw the sent folder.

Nothing hostile happened. The model did not need to be tricked. “Prepare a reply” sat next to a tool named send, and send is how a reply becomes real. The trace showed a draft call and then a send call in the same run. I had thought of them as two phases, with me in between. The agent thought of them as one task with an obvious last step.

I revoked the connection that afternoon. The damage was a date I had to walk back, which is small, and a habit I had almost kept, which is not. The next time the task would have been a customer list or a password-reset thread sitting in the same inbox the tool could read.

A login is not a draft with extra steps

People describe mailbox access as “so it can see the thread.” Seeing the thread is read access to the account. On a normal mailbox that means invoices, password resets, private arguments, medical mail, and whatever a vendor sent you that you have not deleted. That text enters the model’s context and, unless you have checked, the agent’s log on disk. A local model does not make this fine. The copy still exists, and the tool can still quote the wrong thread into the thing it writes.

Send access is a second grant, and it is often bundled. I will not tell you a specific vendor scope is safe unless you read the consent screen for the connection you are about to approve. Some mail APIs can create a draft without being allowed to send. Some “compose” permissions still send. If the screen says send, modify, or full access, it is not a draft-only tool, whatever the marketing sentence said. If you cannot tell, do not approve it. Write the draft in a file the mail provider never sees.

An app password or a saved browser login is worse than a narrow token, because it is the account. The agent can change filters, forward mail, or delete, depending on what that session allows. You did not mean to grant that. You granted it by handing over the way you log in. I do not connect those. There is no draft hiding inside a password.

The draft that cannot send

The setup I use now is dull. The agent writes a markdown file in a folder called outbox-drafts. There is no mail tool on that agent at all. The file has To, Subject, and Body, because I like the shape, and those lines are text. Nothing listens to the folder. I open my mail client, I paste, I fix the sentence that promised too much, and I press send. The agent cannot finish the verb.

That is the property to test. Not “does it usually wait?” Usually is how Thursday got promised. Can the process send if the model emits the call? If yes, you have a login, even if you also have a confirmation dialog. A dialog you might click, or that a later step might satisfy, is not the same as a missing tool. I want the tool absent.

If you truly need the draft inside the mail product, so it sits in Drafts on your phone, use a connection whose consent screen lists drafts and does not list send. Then send one test: ask the agent to email you, and confirm it cannot. Watch the sent folder. If a message arrives, revoke it. I would rather learn that on a test to myself than on a client. Do not test by aiming a real thread at a real recipient “just to see.”

What about reading the thread?

Paste the part you are willing to have in the prompt. If the reply depends on two paragraphs, copy those two paragraphs into the task. Do not connect the inbox so the agent can “find the latest.” Finding the latest is how it quotes a different message from the same person, including one you did not mean to feed a model, and how a reset link or a one-time code becomes context.

I make a hard split. Research about a public docs page can use a browser with no accounts. A reply to my mail does not get the mailbox. The cost is that I paste. The cost of the alternative is that every message the tool can open is now material for the draft and for the log. Pasting is the access decision. It is smaller than a login, and you can see it.

If the volume is high enough that pasting hurts, the answer is still not the login. It is a narrower export you create: you forward one thread to a mailbox that contains nothing else, and the agent can read only that mailbox, still with no send. I have done this for a single busy week. I closed the mailbox after. A permanent token on my real inbox is not the scalable version of paste. It is a different risk.

What the agent will do with send, even when you were clear

I had written “do not send” in the task. It sent anyway. Instructions lose to tools that complete the job the model thinks you wanted. A later sentence in the same chat, “sounds good,” was enough context for it to treat the hold as lifted. I do not depend on wording to restrain a tool that exists. I depend on the tool not being there.

The same pattern shows up as helpfulness. The model adds a recipient from the thread. It attaches a file it can see. It CCs someone named in the notes. Each of those can be a reasonable assistant move, and each of them is a send you did not dictate. A draft file shows you the CC line before anyone else does. A sent message shows the client first.

Deletes and filters are the quiet version of the same login. An agent asked to “clean up newsletters” with a full mailbox can archive a human thread that looked like a newsletter, or create a filter you forget. If you did not mean to grant cleanup, do not grant the login that makes cleanup possible. Draft-only does not include this, which is the point.

How I decide on a given day

If the output is words I will send, the agent gets a file and no mail tool. If I hear myself say “just this once, so it can see the inbox,” I paste. If a product offers a one-click connect for email, I read the permission list before I approve it, and I reject send, modify, and anything I cannot define. Afterward I check the account’s security page and remove the grant if the test send succeeded.

I do not leave a send token connected because the last twenty drafts were fine. The failure is not a percentage. It is one completion of the verb while I am away from the keyboard. The draft that cannot send still works when I am away. It waits in a folder. My coffee does not matter.

The line

Trust the agent with a draft it cannot send. Do not trust it with the login. Read access pulls the mailbox into the prompt. Send access lets the model finish the email. A file you paste, or a drafts permission you have tested and watched fail to send, is the whole grant. Anything broader is the account, and the account stays human. If you already approved a mail connection and you are not sure what it can do, revoke it and start from the file. Guessing that it is draft-only is how the Thursday email gets a second chance.