# Permissions and autonomy for agents in Command Mail

> Every Command Mail permission and autonomy level: what an agent may read, sort, draft and send, how approvals and limits work, and how to revoke access.

Updated: 2026-10-17 · Fact-checked: 2026-10-17 · Canonical: https://commandmail.app/en/docs/permissions-and-autonomy · Deutsch: https://commandmail.app/de/docs/berechtigungen-und-autonomie.md

An agent in Command Mail is limited in two ways. **Permissions** (scopes) are chosen when you connect it and apply to every mailbox in your account. **Autonomy levels** are set per mailbox and decide whether certain organizing actions by an agent take effect there, wait as a suggestion or are refused. Autonomy does not limit reading or sending.

This page describes how Command Mail actually behaves, including the places where it protects less than a level called "read" might suggest. It expands on the Scopes and Autonomy sections of the [documentation](https://commandmail.app/en/docs) and the [page for agents](https://commandmail.app/en/agents).

## Recommendation: permissions for a sorting agent

An agent that only sorts your mail gets **`mail:read`**, plus **`mail:draft`** if it should prepare replies. Do **not** grant it **`mail:send`**. With `mail:read` and `mail:send` together, an agent can delete mail for good and empty Trash or Spam, and on the `suggest` and `rules` levels those actions do not wait for your approval. Keep mailboxes on `suggest` while you want to see every cleanup, and switch to `auto` only when the agent should clean up on its own.

If the agent should send replies after you approve them, add `mail:send-approved`. Reserve `mail:send` for an agent that really should send without asking, ideally in a separate Command Mail account.

## Permissions at a glance

Every connection carries a list of permissions, whether it uses the hosted MCP server, the CLI or an API key.[^1] A call without the needed permission is refused, and the MCP server does not even offer many tools to an agent that lacks the matching permission.

| Permission | Allows | Does not allow |
|---|---|---|
| `mail:read` | read and search every mailbox; overview and morning brief; organize within the autonomy level; labels and folders; read and star flags; suggest rules; view activity and undo changes made by agents and rules; follow-ups | sending, moving to Trash, deleting for good |
| `mail:draft` | save drafts and discard untouched agent drafts in this account | sending, overwriting your edits |
| `mail:send-approved` | send the exact revision you approved, once | sending anything you did not approve |
| `mail:send` | send new mail and replies without approval from any send-enabled mailbox in the account, each with its own send key, within the daily limit | more than 20 recipients per message, replies to mail recognized as automated |
| `mailboxes` | connect addresses, prove domain ownership with a DNS TXT record, import old mail, change signatures | reading or sending mail |

Operator permissions such as `admin` are not available for customer keys.[^1]

By default, reading through MCP and the CLI leaves the read status alone; the CLI and local MCP offer an explicit option to mark mail as read. A direct REST call to `GET /api/mail/{id}` marks the conversation as read unless you add `markRead=false`; in mailboxes on `read` the flag stays unchanged either way.

### Actions that need two permissions

Some actions hand content to new recipients or remove mail. They need `mail:read` and `mail:send` together: forwarding, moving to Trash and restoring, deleting for good, emptying Trash or Spam, marking everything read, and switching on or shortening automatic removal of Spam and Trash.[^3] A key that may only send therefore cannot read your mail or wipe your mailbox.

### Actions limited to the browser session

An agent's access cannot approve drafts, confirm or dismiss suggestions, change autonomy levels, set the daily send limit, manage API keys or generate text through a model route.[^2] The server refuses these calls from a token; they only work in a signed-in browser session.

### Choosing permissions when you connect

The authorization page lists each requested permission separately, and you can switch off any of them. `mail:send` starts switched off, so by default an agent drafts and you approve.[^3] Permissions apply to every mailbox in your account.

## Autonomy levels per mailbox

The autonomy level decides whether an agent's logged organizing actions in a mailbox take effect, wait as a suggestion or are refused.[^1] These actions are archive, spam, Trash, category changes and filing into folders. The order is `read` → `suggest` → `rules` → `auto`.

| Level | Agent's logged organizing actions | Read flags, stars and labels | Your rules |
|---|---|---|---|
| `read` | refused | refused | do not act |
| `suggest` | stored as suggestions (`{"suggested": true}`) | take effect | stay suggestions |
| `rules` | stored as suggestions | take effect | enabled rules act |
| `auto` | run and are logged, at most 50 conversations per organizing call | take effect | act |

**Deleting is the exception.** Deleting for good and emptying Trash or Spam bypass the suggestion step. If an agent holds `mail:read` and `mail:send`, Command Mail runs these actions right away on `suggest`, `rules` and `auto`; only mailboxes on `read` are left untouched. Mail deleted for good cannot be recovered. That is why a sorting agent should not get `mail:send`.

**What autonomy does not limit.** Autonomy restricts neither reading nor sending. An agent with `mail:read` also reads mailboxes on `read`, and an agent with `mail:send` can send from any send-enabled mailbox in the account and reply to messages, including ones in a mailbox on `read`. If a mailbox must be off limits to an agent, it needs its own Command Mail account.

A mailbox you have not configured runs on `auto`, so check the level in Settings after connecting an address. When one organizing call touches mail from several mailboxes, the strictest of their levels applies. Filing into folders takes effect only on `auto`, waits as a suggestion on `suggest` and `rules`, and is refused on `read`. Closing or moving follow-up reminders needs `auto`. An agent may set automatic removal of Spam and Trash only when the account's default level is `rules` or `auto`.

An agent should create rules only on your explicit instruction; that is what the guidance Command Mail hands every agent through `capabilities` says, and the server cannot verify it. In mailboxes on `read` or `suggest`, an agent's rule stays a suggestion until you switch it on; on `rules` and `auto`, the agent may switch it on itself. Mail that Command Mail recognized as an invoice, payment problem, security notice, deadline, appointment or personal message is never moved to Spam or Trash by a rule. Archiving or filing such mail needs a rule that names exactly that kind, and no other protection reason may apply; other matches become suggestions.[^2] Recognition works with patterns and will not catch every invoice or deadline.

## Approving drafts: exactly this revision

With `mail:draft`, an agent saves a draft. With `mail:send-approved`, it sends that draft after you approve it, exactly the approved revision and only once.[^1]

1. The agent saves a draft, as a reply in the conversation if you like and with up to five attachments. Every change creates a new revision.
2. You review the draft in the app and approve that revision. If a newer message arrived in the conversation after the draft was written, Command Mail points it out and you approve again on purpose.
3. The agent calls `send_approved_draft` with the approved revision. If the draft changed since, or the sending address is no longer valid, Command Mail refuses.
4. If it is unclear whether the message was delivered, Command Mail does not retry. If delivery was refused before sending, the approval stays in place.

Once you edit or approve a draft, no agent can overwrite or discard it. Untouched agent drafts can be discarded by any agent in this account that holds `mail:draft`, not only the one that wrote them. Approved mail goes out without a signature added afterwards, exactly as you reviewed it, and it does not count toward the agent daily limit. Sending requires a Pro plan and a sending address that is set up for it.[^3]

## Sending on its own: send key, daily limit, recipient cap

`mail:send` is meant for agents that should reply without asking, such as in customer support.[^1] Three brakes apply.

**Send key.** Every message an agent sends needs its own `sendKey` of 8 to 128 letters, digits or the characters `_ . : -`. If an agent repeats a request with the same key, for example after a lost response or from a second window, the message is not sent twice. When delivery was certainly refused, Command Mail releases the key right away. Keys not bound to a stored message are cleaned up after 30 days. After an unclear outcome, an agent should check the send status and must not start a new request with a new key.

**Daily limit.** By default an agent sends at most 50 messages per day, counted in UTC. You set the value between 0 and 500 in the automation settings; 0 stops all agent sending.[^1] Messages with an unclear outcome count. Your own messages and approved drafts do not. The agent sees the current numbers in `capabilities` under `limits`.

**Recipient cap.** A message an agent sends on its own may have at most 20 recipients across To, Cc and Bcc.[^3] Above that, nothing is sent, and the agent should save a draft for you.

## Machine-sent mail

Command Mail blocks direct agent replies to messages it recognized as machine-sent from their headers.[^2] It looks for `Auto-Submitted` under RFC 3834 with any value other than `no`, `Precedence: bulk`, `junk` or `list`, `List-Id` and common autoresponder markers. When one of these is present and an agent with `mail:send` replies to that message, nothing is sent; the agent can still save a draft for you to approve.

This check has limits. Without those headers, Command Mail does not recognize an out-of-office note or newsletter as automated. It also covers replies only: a new message to the same address is not checked against it. It is not complete protection against mail loops.

## Prompt injection: email content is data

Email content cannot, through Command Mail, grant an agent permissions, approve drafts, create rules or change model routes.[^3] Command Mail scans subject and text for patterns aimed at an AI model, such as "ignore all previous instructions", requests to forward every invoice, or requests for passwords and codes. Such messages get a visible flag, `get_thread` reports it to the agent, and the daily overview lists the attempts.

The flag is a warning. It does not catch every phrasing, and an agent that is swayed by a message can still act within the permissions you granted. Narrow permissions therefore remain the real limit. The risk assessment looks at text, link addresses and attachment names, but never follows links or opens attachments.[^1]

## Activity log and undo

Archive, spam, Trash, category changes and folder filing are logged with the state before and after.[^1] Undo restores the earlier state only where nothing else changed it since; conflicts are counted. Undoing a change a rule made pauses that rule until you review it.

A token may undo what agents, rules and automatic classification did; your own decisions you undo yourself in the app. Suggestions wait in the log for your decision. Sent mail, mail deleted for good, emptied Trash or Spam, label changes and creating or renaming folders cannot be undone. Messages an agent sent on its own are in the Sent folder; approved drafts also appear in the log.

## Common setups

**Read and draft only.** Grant `mail:read` and `mail:draft`, plus `mail:send-approved` if you want the agent to send what you approve. Set mailboxes to `suggest`. The agent reads, proposes cleanups and writes replies for your approval. No message leaves without your approval, and without `mail:send` the agent cannot delete anything for good. It still sets read flags, stars and labels directly on `suggest`.

**Archive newsletters automatically.** Grant `mail:read` and no `mail:send`. Tell the agent which senders to archive, for example "From now on, archive the newsletters from this shop." On `rules`, it creates a rule and switches it on, so future mail from that sender goes straight to the archive, and it can apply the rule to existing mail in one step you can undo. On `suggest`, the rule waits for you to switch it on.

**Forward invoices.** Forwarding needs `mail:read` and `mail:send` together, a Pro plan and a send-enabled address, and each forward counts toward the daily limit. Keep in mind that the same permissions allow permanent deletion. Rules cannot forward; a scheduled run in your agent does that. The safer variant uses approval: grant `mail:read`, `mail:draft` and `mail:send-approved`, let the agent save a new draft with the invoice attached, and approve it.

**Let a support mailbox answer on its own.** Grant `mail:read`, `mail:draft` and `mail:send` and choose a daily limit that fits your volume. Because `mail:send` applies to every mailbox in the account and, together with `mail:read`, allows deletion, keep the support mailbox in its own Command Mail account, separate from your personal mail.

## Revoking access

In Settings, disconnect an app under connected apps. This revokes every token that app holds for your account, including a sign-in that has not finished yet, and the app must ask for access again. Revoke API keys in the API keys section of Settings; a key cannot manage other keys. To give an agent fewer permissions, disconnect it, connect it again and pick only what it needs on the authorization page.

Setup steps are in the [documentation](https://commandmail.app/en/docs), and agent workflows are on the [page for agents](https://commandmail.app/en/agents). [Start free](https://commandmail.app/login?signup=1) and connect your agent with `mail:read` and `mail:draft` first.

## Frequently asked questions

### Which permissions should an agent get that only sorts mail?

Only mail:read, plus mail:draft if it should prepare replies. No mail:send: together with mail:read it also allows permanent deletion, and that does not wait for your approval. Keep mailboxes on suggest while you want to see every cleanup.

### Does the read level fully protect a mailbox?

No. read stops an agent from sorting, flagging or deleting mail there. The agent can still read that mailbox, and with mail:send it can send from it. Separate read or send rights for individual mailboxes require separate Command Mail accounts.

### Can an agent approve its own draft?

Not through its own access. Approving drafts, deciding suggestions, changing autonomy and setting the daily limit only work in a signed-in browser session. Email content never grants permissions.

### What happens if I edit a draft after approving it?

Every edit creates a new revision and clears the approval. Only the revision you approved last can be sent.

### How do I remove an agent's access?

In Settings, disconnect the app under connected apps; that revokes all of its access. API keys are revoked in the API keys section.

## Sources

1. [Command Mail: Documentation (scopes, autonomy, let your agent reply)](https://commandmail.app/en/docs), accessed 2026-10-17
2. [Command Mail: For agents (permissions, autonomy, limits)](https://commandmail.app/en/agents), accessed 2026-10-17
3. [Command Mail: llms.txt](https://commandmail.app/llms.txt), accessed 2026-10-17

[^1]: [Command Mail: Documentation (scopes, autonomy, let your agent reply)](https://commandmail.app/en/docs), accessed 2026-10-17
[^2]: [Command Mail: For agents (permissions, autonomy, limits)](https://commandmail.app/en/agents), accessed 2026-10-17
[^3]: [Command Mail: llms.txt](https://commandmail.app/llms.txt), accessed 2026-10-17

---

Command Mail: one inbox for you and your AI agent. Start free: https://commandmail.app/login?signup=1 · Connect your agent: https://commandmail.app/en/agents · MCP: https://commandmail.app/mcp