Gmail agent permissions: read-only, draft and send

By KYN AI Advisory Team — AI implementation specialists, Singapore

Give a Gmail agent the narrowest permission that does the job. Read-only lets it sort and summarise mail. Draft access lets it prepare replies that a person sends. Send access lets it send on its own, and it should be switched on only for narrow, approved cases. Google classes the read and compose scopes as restricted, which brings a verification step for apps other people use.

What permission levels does Gmail offer?

Gmail's API uses OAuth scopes. Google lists them on its Gmail API scopes page. The four that matter for an agent:

| Scope | What it allows | Google's sensitivity class | |---|---|---| | gmail.readonly | View email messages and settings | Restricted | | gmail.compose | Create and manage drafts, and send email | Restricted | | gmail.send | Send email on the user's behalf | Sensitive | | gmail.modify | Read, compose and send; no immediate permanent deletion | Restricted |

Two points in that table surprise people.

First, gmail.compose includes sending. It is not a "drafts only" scope. If you want an agent that can draft but cannot send, you cannot get that from the scope alone. You enforce it in your own code, by routing every send through an approval step that the agent has no way to skip, and by never exposing a send function to the agent's tool list.

Second, gmail.send alone is the narrowest way to send, and it cannot read mail. A notification agent that only sends from a template can run on it.

Which level fits which job?

Match the job to the lowest level that works.

• Triage and labelling. Read-only plus the ability to add labels. Reading is gmail.readonly. Applying labels to messages needs gmail.modify, so check whether you can live with read-only and keep the labels in your own database.
• Bills from email. Read-only. The agent fetches the message and attachment and writes the extracted bill to your finance system. It does not need to write to the mailbox.
• Reply drafting. Draft creation. In practice this means gmail.compose, with your code allowing only draft creation.
• Reply sending. Send behind approval. A person clicks approve in your review screen, and your backend sends. The agent's own account holds no send capability at all.
• Templated notices. gmail.send only, for a fixed set of templates, with a daily cap.

The common mistake is to grant gmail.modify or full mailbox access because it is easier. That gives a prompt-injected agent the ability to read everything and send as the user. See prompt injection in business AI agents.

What does restricted mean in practice?

Google says restricted scopes require a restricted-scope OAuth verification. If an app stores or transmits restricted-scope data on its servers, a security assessment is also required, per the same scopes page. Sensitive scopes require standard verification.

This applies when you publish an app for users outside your organisation. For a system you run inside your own Google Workspace, a Workspace administrator controls which apps can use which scopes. Two routes are common:

• User consent. Each user authorises the app for their own mailbox. The administrator can restrict which apps users may authorise.
• Domain-wide delegation. A service account acts as users in the domain. It is broad, and the administrator should limit it to the exact scopes and the specific mailboxes the system needs. Prefer a dedicated shared mailbox over delegation across the whole domain.

Whichever route, record the scopes granted, who granted them and when, and review the list each quarter.

How do you separate mail the agent should see from mail it should not?

A full mailbox holds mail that has nothing to do with the job: HR, legal, personal messages. Reduce exposure:

1. Use a dedicated mailbox or alias. Bills go to bills@ and the agent reads that mailbox only. Sales replies go to a shared sales mailbox.
2. Filter at the source. A Gmail filter labels the relevant mail, and the agent reads only that label.
3. Skip sensitive senders. Add a deny list: HR, legal advisers, the bank.
4. Do not forward whole mailboxes. Forwarding rules copy mail you may not mean to share.
5. Keep a retention limit. The agent's own database keeps the extracted fields and a link to the message, not a second copy of every email.

The privacy duty is yours. In Singapore, the PDPC enforces the Personal Data Protection Act, and mail contains personal data. An agent that reads a mailbox is a processor of that data, so limit what it sees and log what it reads.

What controls make send access safe?

If you do enable sending, add these controls before the first message goes out.

• Approval gate. Outbound messages to new contacts, anything quoting money and any reply to a complaint wait for a named person.
• Allow-list of templates. The agent fills fields in approved templates. Free-text sends are reviewed.
• Rate cap. A fixed number of sends per hour and per day per mailbox. A runaway loop hits the cap, not your sender reputation.
• Suppression list. Checked before every send, shared across channels. An unsubscribe stops the contact everywhere.
• Authentication. Your domain should have SPF, DKIM and DMARC set. Google's email sender guidelines set requirements for senders.
• Kill switch. One setting that stops all sends from the agent, without a deployment.
• Full log. Message ID, recipient, template, approver, time.

How do you roll out access in stages?

1. Week 1: read-only in shadow. The agent classifies mail and writes labels to its own database. People compare its labels with what they would have chosen.
2. Week 2 to 3: drafts. The agent writes drafts for common replies. People send or edit. Track the share sent unedited.
3. Week 4 onward: gated send. Approved categories send after one-click approval. The agent still has no unattended send.
4. Later, only if justified: unattended send for one narrow, low-risk category, with a cap and a kill switch.

At each stage, measure error rate on a real sample. Move on only when the error rate is acceptable to the person who owns the mailbox.

Where KYN fits

KYN builds mail agents in your cloud account with the narrowest scope per job. For an insurance brokerage, outreach is drafted with one checkable first line and replies are sorted by a reply desk, while outbound messages wait for a named person. Each agent has its own restricted account, every action is logged with the actor, and credentials sit in a secrets manager you control. See sales systems and security.

The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days.

Frequently asked questions

Can I give an agent draft-only access in Gmail?

Not from the scope alone, because gmail.compose also allows sending. You enforce draft-only in your own code: expose a create-draft function and no send function, and route sending through an approval step the agent cannot call.

Which scope is safest for an agent that reads bills?

gmail.readonly on a dedicated mailbox. The agent extracts the bill and writes it to your finance system, and it holds no ability to change or send mail.

Should we use domain-wide delegation?

Only if you need it, and then limit it to specific scopes and mailboxes. A single shared mailbox with user consent is easier to audit and exposes less.

Checked 30 October 2026.

Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.

Start Building →