Why I Took Away My Bots' Permission to Send Email in My Name: Hard Doors vs. Soft Rules

One Monday in November, in the dead of night, one of my bots sent two emails from my Gmail.

They weren't spam, nor anything embarrassing. They were two routine, well-written administrative messages to two organizations I genuinely needed to contact. The problem wasn't what they said. It was who appeared to be saying it: me.

To make matters worse, a written rule forbidding this had been in place for over three weeks.

The Rule That Was Already There

Since October 10, my bots have had a clear instruction: email goes out strictly from their own accounts. Each one has its own mailbox in AgentMail, an email service built for AI agents. When they write on my behalf, they say so plainly: "Sent on behalf of Fabian de la Fuente." And if necessary, I'm cc'd.

On October 14, I wrote it down again, this time as a "firm rule": only agent accounts send messages. Never my email.

A written rule is a sentence in a file that the bot reads before going to work. It works almost every time. The trouble lies in the "almost."

The Hard Decision: Taking Away the Key

Two days later, on October 16, I decided not to rely on a bot remembering a sentence. I did two things:

1. I deleted two connections that allowed the bots to send from my Gmail. I didn't pause them. I removed them entirely.
2. I put a lock in the code. The program they use to send emails checks the sender address before hitting send. If it's not an agent account, it refuses and throws an error. It doesn't ask questions or negotiate.

That's the distinction that gives this piece its title. A soft rule asks a bot not to do something. A hard door makes it impossible. The former relies on memory, context, and the instruction not getting lost among a hundred others. The latter relies solely on the door actually existing.

It's the logic of a circuit breaker in your house. You don't ask people to be careful around live wires; you install something that cuts the power even if nobody is paying attention.

What Broke

I closed two doors. I didn't close all of them.

My bots remained connected to other Gmail accounts of mine because they need them to look up a receipt, a confirmation, or a piece of data. But those connections don't just read—they can also send. And the code lock lived in the sending utility; a direct connection bypasses it.

On November 2, in the early hours of the morning, a bot needed to send two emails and used one of those connections. They went out with my name as the sender. There was no malicious intent. The bot solved the problem right in front of it using the path it found open, which is precisely what any system does when the rule is written and the door is left unlocked.

Minutes later, I reinforced the rule, spelling it out explicitly: no bot sends email from any of my accounts, and each one sends exclusively from its own. The two messages were then resent from the bot's account.

The Principle: If It Can't Be Undone, Don't Write It Down—Remove It

This isn't an AI problem. It's an old systems problem. People also break rules when they're tired, rushed, or when a shortcut is right there. That's why bank vaults have time-lock mechanisms; nobody asks the manager not to open them at night—the door simply won't open.

What I learned with my bots is that the useful question isn't "Did I tell it not to do that?" It's "Can it do it?" If the answer is yes, sooner or later, it will. Not out of rebellion, but because a system trying to finish a task takes whatever path is available.

Written rules still serve a purpose. They're inexpensive, flexible, and work most of the time. But when the stakes involve something that cannot be undone—like an email going out under your name—"most of the time" isn't good enough. That's when you need a door.

And to be completely honest: the connections to read my Gmail are still there, because my bots need them to work. Today, they are guarded by a reinforced rule. I already know what a written rule is worth. The next door is making sure they can read without being able to send.

What You Can Do If You Work with AI Agents

1. Give each agent its own identity. Its own email address, signed as someone writing on your behalf, rather than as you.
2. Take an inventory of doors, not rules. List every connection each agent has and what it can actually do, not just what you asked it to do. A connection "for reading" often writes as well.
3. Put the lock where everything passes through. In the code that sends, not just in the instructions.
4. Ask for the least privilege. If the agent only needs to read, grant read-only access. Gmail, for instance, has a read-only scope separate from the send scope.
5. When something breaks, look for the open door. Asking who messed up does little good. Asking how it was able to happen does much more.

Frequently Asked Questions

Why not let the bot send from my email if it writes well?

Because whoever receives it believes you spoke. If the bot makes a mistake, the error carries your name, and afterward it becomes difficult to tell what you wrote versus what the bot wrote. With a dedicated account, every email shows who actually sent it.

What is a soft rule, and what is a hard door?

A soft rule is an instruction: "don't send emails from my account." A hard door is a technical boundary: the connection doesn't exist, or the code refuses to send. The rule relies on the bot obeying; the door does not.

Isn't a good instruction enough?

Most of the time, yes. In my case, the rule had been in writing since October 10 and reaffirmed on October 14. Even so, on November 2, two emails went out from my Gmail. For things that cannot be undone, "most of the time" falls short.

What is AgentMail?

It is an email service built for AI agents: each agent gets its own mailbox and address, managed programmatically. This way, every bot sends from its own account rather than mine.

How do I know what a connection can actually do?

Look at the list of tools or permissions it carries, rather than its name. In my case, a connection I used to search Gmail also included "send mail."