Your AI Agent Has the Keys to Your Inbox. Who's Actually in Control?

An assistant that can write your email is useful. An assistant that can send it has entered a different profession: representing you. Before handing over the account, ask a less glamorous question than whether the model is clever. Where, exactly, does its authority stop?

The impressive demonstration ends with a completed task. Our question begins one step earlier: what prevented the assistant from completing the wrong one? A polite promise in a chat window is not the same thing as a permission boundary. Treating them as interchangeable is like hiring an accountant and accepting “I am careful” instead of deciding who can approve a transfer.

This is a documentation-based analysis, not a hands-on security test or a ranking of products. The examples below concern particular APIs and published safeguards, checked on 30 October 2026. They do not establish what any unexamined app actually requests or enforces.

Three decisions hiding inside “Connect”

We propose judging an agent through three separate questions. What information can it obtain? What change can it propose? What change can it execute? That distinction is an editorial framework, not a universal menu offered by every provider.

Reading a message, composing an answer and dispatching that answer are different jobs. Even “draft” needs a definition. Text composed locally is not a draft saved into your mailbox. The second operation changes account data; the first need not touch the account at all. If the task includes retrieving an existing message, that retrieval still needs access.

The documented permission boundaries are not identical. Google's gmail.compose covers drafts and sending; Microsoft Graph's delegated Mail.ReadWrite excludes sending, with Mail.Send listed separately. These examples describe grants, not a guarantee about an app's combined access. [C1][C2]

Our conclusion is deliberately unexciting: read the actual permission description, not the friendly name of the workflow. “Draft assistant” is a product label. Whether the software can send a message is a technical question. Both deserve an answer before the account is connected.

The inbox is not the boss

An incoming email can contain useful information and instructions that were never yours. OWASP describes indirect prompt injection as manipulation delivered through external content, rather than directly by the legitimate user. [C3] The important distinction is authority, not whether a sentence sounds professional.

Consider a hypothetical assistant asked to summarize supplier correspondence. A message tells it that an urgent administrative step is required. We are not reporting an actual incident here. The scenario illustrates the question the system must answer: is that message evidence to summarize, or authorization to act? It should not become the latter merely because the agent encountered it while doing the former.

The practical concern is not that every email is hostile. It is that a sender should not acquire your authority through persuasive prose. A system that can propose an action still needs an independent answer to whether that action is permitted. For a reader choosing a tool, that turns an abstract AI debate into a procurement question: show me where proposals become operations.

OWASP's prevention guidance recommends checking tool calls against permissions and context, validating parameters, and limiting privileges. It also warns against treating an LLM guardrail as a replacement for other controls. [C4] Our interpretation: the model should not be the sole judge of the permission to carry out its own suggestion.

A confirmation button needs something worth confirming

We would want an approval screen to show the destination, exact action and relevant content, not merely “Continue?”. This is our recommended acceptance criterion, not a claim that all current products provide it.

Imagine approving a proposed reply. Would you see the recipients, attachments and final wording? Would a subsequent change require a new decision? Could you refuse sending without losing the summary you already requested? These questions are more informative than counting the number of confirmation prompts in a demonstration.

The same reasoning applies to a supposedly read-only assistant. A narrow mailbox permission is valuable, but our evaluation should also ask what happens to the information after retrieval. Where may the application send it? What does it retain? The permission to read an account and the policy for using the result are different parts of the bargain. We have not verified individual vendors' retention arrangements in this article.

Nor should caution mean approving every tiny movement until approval becomes a reflex. Our preferred division is explicit: low-consequence preparation within a narrow scope, followed by a meaningful decision at consequential boundaries. What counts as consequential depends on the task. A proposed sentence and a message to a client are not interchangeable units of productivity.

What the vendors say, and what that proves

In its March 2026 discussion of prompt injection, OpenAI argues for constraining the consequences of manipulation even when an attack succeeds. That is the provider's account of its approach, not an independent certification by ZEVRYNTA. [C5]

Anthropic's guidance for Claude in Chrome describes layered safeguards and explicitly acknowledges a non-zero attack risk. We have not reproduced its testing and do not use its reported performance as a comparison with competitors. [C6]

These statements are useful chiefly because they challenge the wrong purchasing question. “Is your AI safe?” invites an adjective. “What remains impossible when the model makes a bad suggestion?” invites a design explanation. We prefer the second. It can be followed by a narrower demonstration and a record of what was actually checked.

The exit is part of the product

RFC 7009 specifies OAuth token revocation and recognizes that propagation delays can occur. It does not establish that every application's disconnect button behaves identically. [C7]

Our checklist therefore separates three questions: can you stop future access, can you stop work already queued, and what happens to information already obtained? A convincing answer to the first does not, by itself, answer the other two. Ask for the product-specific procedure rather than assuming that the word “disconnect” covers everything.

Before connecting a consequential account, we would ask for six concrete answers:

1. Which exact permissions will be granted, and which can be omitted?

2. Does “draft” mean local text, a mailbox change, or a grant that also permits sending?

3. Which operations require approval, and what information will that approval display?

4. Where are recipients, parameters and account permissions checked outside the model?

5. How do revocation, queued work and retained data differ in this product?

6. What evidence will show what happened if an operation is disputed?

An honest “this feature is not available” is useful information. A vague assurance is not a substitute for it. The goal is not to demand an impossible guarantee; it is to know which risks you are accepting and which capabilities you do not need to grant.

The ZEVRYNTA view

The genuinely valuable agent is not necessarily the one that asks the fewest questions. It is the one whose independence you can explain. If you cannot tell where it may read, propose and act, you are not buying autonomy so much as renting uncertainty.

Start with the smallest useful delegation. Expand it when the benefit is clear and the boundary is demonstrable. That is our judgment, not a measured promise that a particular configuration is safe. The inbox may need an assistant. It does not need an unelected spokesperson.

Related: Before an AI agent gets the keys: five questions a demo cannot answer. That earlier piece concerns evaluating enterprise demonstrations; this analysis examines account authority and the meaning of inbox permissions.

Prepared with AI assistance for ZEVRYNTA. No invented reporter, personal product testing or independent security certification is claimed. Sources and claim-level qualifications are included in the accompanying evidence ledger.*