A Gmail-connected AI agent should not inherit every available Gmail operation just because its account can read a message. In a bounded review of Aident Loadout's staging catalog on October 22, 2026, the current Gmail integration contract contained 61 public Actions: 27 had retrieval-oriented names, while 34 had names that clearly send, forward, delete, reconfigure, or otherwise change Gmail state.

That split is useful for discovery, but it is not a permission policy. Gmail is also a different risk category than a project tracker or a chat workspace: the account that reads mail is usually the same identity that can send mail as you, and several Actions touch forwarding, filters, and delegation settings that control where future messages go. All 61 reviewed Actions shared the wrapper's conservative operationType: write label, so that flag cannot substitute for reading the exact Action name, schema, and consequence.

For a safe first Gmail test, allow only two jobs:

1. return the authenticated profile and label list so a person can confirm the connected account; and

2. list at most five recent threads from the inbox, limited to subject, sender, and snippet.

Do not authorize sending, forwarding, drafting, deleting, trashing, or any label, filter, forwarding, or delegation change as part of that reader test.

If that is the job you need, inspect the current Gmail integration in Aident Loadout before connecting an account. The useful next step is to review the live Actions and schemas, then preflight one bounded reader; it is not to enable the entire surface.

The 61-Action Audit Result

The 27 retrieval-oriented names comprise 10 get, 10 list, 3 fetch, 1 search, and 3 settings reads (settings_send_as_get, settings_get_pop, settings_get_imap). The 34 mutation-oriented names split across sending and composing (send_email, send_draft, forward_message, reply_to_thread, create_email_draft, create_filter, create_label, create_prompt_post, insert_message, import_message), label and setting changes (update_label, update_send_as, update_vacation_settings, update_imap_settings, update_pop_settings, update_language_settings, update_user_attributes_values, update_draft, patch_label, patch_send_as, add_label_to_email, modify_thread_labels, batch_modify_messages), and removal or state changes (delete_message, delete_thread, delete_draft, delete_filter, delete_label, batch_delete_messages, move_to_trash, move_thread_to_trash, untrash_message, untrash_thread, stop_watch).

This count came from an integration-scoped capability search against the exact Gmail Action enum, cross-checked against the wrapper's operationType field. It classifies names and schemas, not business impact; the next section shows why that distinction matters.

Names misclassify risk in both directions

One reviewed Action, gmail_create_prompt_post, carries the gmail tag and sits inside the Gmail integration catalog, but its schema describes a stateless one-shot prompt endpoint for a third-party content agent, unrelated to reading or sending mail. A blanket "allow everything tagged Gmail" policy would grant that unrelated capability by accident. Review the schema, not only the integration label, before approving an Action.

The inverse also occurs. gmail_get_auto_forwarding and gmail_list_forwarding_addresses are named like simple reads, and their schemas confirm they only retrieve the current auto-forwarding configuration or the account's registered forwarding addresses. But forwarding configuration is a well-known account-security signal: an undisclosed or unexpected forwarding address is a standard indicator reviewed during account-compromise and data-exfiltration investigations. A "read-only" audit that silently surfaces every forwarding address and filter rule is still privileged information, even though it changes nothing.

These two contracts make the durable rule concrete: review the current schema and consequence, not only the verb or integration tag.

What the Gmail Surface Can Reach

The 61 Actions cross several responsibility boundaries that do not exist in a project-tracker or chat-workspace integration.

Messages, threads, and attachments

Reader-style Actions can fetch messages by ID or thread, list threads, list history, and retrieve attachments. These results can contain financial information, credentials shared over email, legal correspondence, or personal data belonging to the account owner and everyone who emailed them.

Mutation Actions can delete or trash a message or thread in bulk (batch_delete_messages), permanently remove a draft, or stop an active watch subscription. A bounded reader does not need bulk delete, and an agent should never hold standing permission to remove mail it did not create.

Sending, forwarding, and drafting

send_email, send_draft, forward_message, and reply_to_thread let the connected identity originate mail that recipients will read as coming from the account owner. create_email_draft, insert_message, and import_message add content to the mailbox without necessarily sending it. Treat every send-capable Action as a one-time, explicitly approved operation with a visible recipient and body before execution, not a standing grant.

Labels, filters, and account settings

The catalog can create, update, patch, and delete labels and filters, and can change vacation responder, language, IMAP, POP, and send-as settings. A filter that auto-archives or auto-forwards matching mail, or a send-as alias change, can quietly redirect how future mail is handled without touching a single existing message. Review each of these as a standing configuration change, not a one-off action.

Contacts and people

get_contacts, get_people, and search_people return the authenticated user's contact directory, which can include names, emails, phone numbers, and organizations for people who never emailed the account directly. Scope any people-search job to the minimum query needed and avoid exporting the full directory.

Use a Gmail Permission Ladder

Start with the smallest role that completes one useful job.

A safe evaluation you can run

Test a candidate Gmail route on a non-destructive job:

Read only. Return my Gmail profile and label list. List no more than five recent inbox threads, showing subject, sender, and snippet only. Do not open full message bodies, download attachments, list contacts, read forwarding or filter settings, or send, reply, forward, draft, or delete anything. Show the Action schema and authentication state before execution.

Score the result against observable checks:

1. Did authentication complete without exposing a credential?

2. Was the Action's schema visible before execution?

3. Did the route stop at thread metadata instead of opening full bodies or attachments?

4. Did it avoid touching contacts, forwarding, or filter settings?

5. Could you identify exactly which Action executed afterward?

6. Did nothing send, forward, label, or delete anything?

Why this matters more for Gmail than for most integrations

A Gmail connection combines a large read surface, a send-as-you capability, and account-level configuration in one integration. Other communication integrations can also send as a connected identity; the Gmail-specific concern here is the combination of mail access with forwarding rules that can redirect future correspondence. Treat its default posture as narrower than a comparably sized catalog in a lower-stakes system, and require explicit approval before any send, forward, or forwarding-configuration Action executes.

The next step

Run the read-only evaluation above with one real but low-stakes Gmail account before granting anything broader. If the job only needs subject lines and senders, keep the inbox-reader role. If it genuinely needs to send or reply, require a visible recipient and body on every single send and treat that approval as non-standing.

Inspect the current Gmail Action list in Aident Loadout before connecting an account.

For the approval policy behind consequential Actions, read AI agent approval workflow: risk vs. spend. For the credential-handling pattern behind any of these connections, read Stop giving coding agents your API keys. If you have not connected Loadout yet, start with how to use Aident Loadout.

Recheck this audit when Gmail's API adds or removes scopes, when the Loadout Gmail Action contract changes, or when your workflow needs a send-capable role. The right policy follows the exact current schema, not a permanent list copied into a prompt.

Sources

• Aident Loadout live capability catalog, Gmail Tools integration, reviewed October 22, 2026: integration-scoped capability search returned 61 public Actions, all labeled operationType: write.

• Individual Action schemas inspected directly from the reviewed catalog, including gmail_create_prompt_post, gmail_get_auto_forwarding, and gmail_list_forwarding_addresses, reviewed October 22, 2026.

• Aident Gmail Tools app, reviewed October 22, 2026.