A guide from Stratara · 22 October 2026

How to give your AI agents your company Gmail, safely

An AI agent that can read your company's mail can save you hours. One that can also send from it can sign a contract in your name. That isn't a figure of speech: in September a developer wrote that Claude Code found a contract in his Gmail, put his saved signature on it and was about to send it back when he stopped it (Hacker News).

This guide is for a company on Google Workspace that wants its agents to read, sort and draft mail, and to send only what a person has approved. It works whether you build the connection yourself or use someone else's tool. Most of it is Google settings and a few rules about where the keys live.

1. Use your own Google project, as an Internal app

Agents reach Gmail through an OAuth app: a project in Google Cloud that asks Google for permission to read or send mail. Make it yours, in your company's own Google Cloud project, and set its audience to Internal.

• An Internal app can be used only by people in your Workspace organisation. Anyone outside gets an error. Google Cloud help: manage app audience
• An Internal app needs no verification by Google. Google: OAuth production readiness
• Avoid an External app left in "Testing". Google gives it sign-ins that expire after 7 days for Gmail access, so your agents keep losing their connection. Google: OAuth 2.0, refresh token expiration
• Your Workspace admin still controls the app: it can be marked Trusted, Limited or Blocked like any other. Google Workspace help: control which apps access Google Workspace data

This route needs Google Workspace. A personal Gmail account has no organisation, so it can't have an Internal app.

2. Ask Google for the least access

Each permission (Google calls them scopes) allows a set of actions. Ask for only what the work needs. Google: choose Gmail API scopes

Sources for the notes: Google's descriptions of each scope (choose Gmail API scopes); sending accepts gmail.compose, gmail.send and gmail.modify (users.messages.send); deleting a draft accepts gmail.compose (users.drafts.delete); trashing needs gmail.modify or full access (users.messages.trash); labelling needs gmail.modify (users.messages.modify).

The point to take from the table: no scope means "draft but never send". If the agent may write drafts, Google will also let it send. The stop has to be in the tool your agent uses, which is step 3.

3. Put a person in front of every send, and make the software enforce it

Telling an agent "never send without asking me" is a request, not a lock. Anthropic says so about its own tool: permission rules are enforced by Claude Code, and instructions in your prompt shape what Claude tries to do but don't change what Claude Code allows. Claude Code docs: configure permissions

So put the approval in the software:

• In Claude Code, add an ask rule for the sending tool, such as mcp__<server>__<send tool>. An ask rule prompts whenever Claude Code tries to use that tool, even when a more specific allow rule also matches, and in every permission mode, auto and bypass-permissions included. Claude Code docs: configure permissions; permission modes
• If you build the mail tool yourself, mark its send tool as needing approval on every call. An MCP server can set _meta["anthropic/requiresUserInteraction"] to true. Claude Code then shows the prompt on every call, offers no "don't ask again", and allow rules don't skip it. Claude Code docs: MCP, require approval for a specific tool
• The same page says this prompt appears even in auto and bypass-permissions modes, and that in dontAsk mode the call is refused instead. That's Anthropic's documented behaviour; we've seen it hold in auto mode ourselves. Claude Code docs: MCP, require approval for a specific tool
• One exception to know: an app built on Anthropic's Agent SDK receives these approvals in its own code and can grant them, because the app is meant to show them to a person. The guarantee is Claude Code's prompt. Claude Code docs: MCP, require approval for a specific tool
• If you use Claude's own Gmail connector, it asks before each send, reply and forward by default. On Team and Enterprise plans, owners can let members turn that off. Leave it on for sending. Claude Help Center: use Google Workspace connectors

Then make the approval mean something:

• Approve the exact message. The person should see every recipient, Bcc included, the subject, the whole text and each attachment's name. If anything changes after approval, it needs approving again.
• Approve on the right Mac. The prompt appears where the agent runs, so run each agent on the Mac of the person who answers for its mail.
• Know the gap. An agent that can control your screen could, in principle, click its own approval. An approval only a finger can give, such as Touch ID, closes that gap. A prompt on screen doesn't.

4. Keep the keys away from the agent

Once your app is approved, Google gives it a token: a key to the mailbox. Whoever holds the token can use the mailbox.

• Not in a file in the project. A token in a .env or token.json beside your code can be read by anything that reads files.
• A Read deny rule isn't enough on its own. In Claude Code, a rule such as Read(./token.json) blocks Claude's own file tools, and shell commands that name the file, such as cat token.json. It doesn't stop a command that reads the file without naming it, such as grep -r run from its folder, or a script that opens it. Claude Code docs: configure permissions, Read and Edit
• Block it at the system level too. Claude Code's sandbox can deny shell commands read access to a path (sandbox.filesystem.denyRead). The sandbox doesn't cover Claude's built-in file tools, so use both. Claude Code docs: sandboxing
• Better still, keep it in the Mac's keychain, and mind how it gets there. The program that stores a keychain item may read it back without any prompt. So if the token is stored with macOS's security command, any program running as you, an agent with a shell included, can read it back with that same command, without a prompt. (Apple's manual for the security command: run man security in Terminal, under add-generic-password.) Store it from a separate signed helper that alone reads it. That's the stronger lock.

5. Fence each agent in

• One agent, its own mailboxes. A sales agent and an operations agent shouldn't see each other's mail. Give each agent only the mailboxes it needs.
• Limit who a mailbox can write to. A Workspace admin can restrict an organisational unit to approved addresses or domains. Mail to anyone else bounces. It also limits incoming mail to the same list, and it applies to everyone in that unit, not to one agent. So it suits a mailbox the agent works in alone, kept in its own unit. Google Workspace help: restrict email messages to authorized addresses or domains only
• Trust "sent" only from Google. Count a message as sent when Gmail returns the sent message, not when the agent says it sent it. Google: users.messages.send, response body

6. Treat every email as information, never as instructions

Anyone can email you, so anyone can put words in front of your agent. Writing instructions into content an agent will read is called prompt injection. Claude Code docs: security, protect against prompt injection

• The agent that reads mail from strangers shouldn't also have a free hand to send, browse or run commands.
• Tell it, and set up its tools so that, nothing in a message is a command: not "forward this to", not "ignore your instructions", not a link to follow.
• When an agent reads a message, the text goes to that agent's AI provider, as with any AI agent. Choose the provider and the plan whose terms you accept for your mail.

7. Know how to switch it off

• One click for the admin. In the Admin console's API controls, set the app to Blocked. It then can't access any Google data, and the change can take up to 24 hours to apply everywhere. Google Workspace help: control which apps access Google Workspace data
• Write down where everything is: the Google Cloud project, the app, which Mac holds which token, and which agent may use which mailbox. The day something goes wrong, nobody should have to search.

A short checklist

• Internal app, in your own Google Cloud project.
• gmail.readonly, plus gmail.compose only if the agent drafts. gmail.modify only if it must label or archive. Never full access.
• Every send stopped by the software for a person's yes, on that exact message.
• The token out of any file the agent can read.
• Each agent fenced to its mailboxes; risky mailboxes limited to known recipients.
• Mail treated as information, never instructions.
• You know how to block the app in one step.

Or we set it up with you: Pouch.