Open a new chat, ask it to read your inbox, and nothing in that sentence authorises sending mail, changing labels or creating a filter. The session does anyway. A session that only reads still holds everything you ever allowed — because a conversation is not an authorisation boundary, and there is no screen anywhere that shows a person the union they are running with.
In March you asked the agent to send an apology to a client, and approved it. In June you had it file a month of receipts, and approved that. In July you let it set up a filter. Each approval was reasonable, each was for one task, and each was given in its own conversation.
Today you type read my inbox and tell me what is in it. That sentence asks for one capability. The session it runs in carries all four.
A conversation is not an authorisation boundary. It only looks like one.
Everything about the interface suggests a fresh start — a new chat, an empty history, a new request. Underneath, the credential and the approval state are the same ones as last time, and neither has a way to be less than it was.
None of this is hidden. It is the documented behaviour of two ordinary systems, which is why it is worth writing down rather than discovering.
Google's authorisation server is built to accumulate. Its own documentation: a new authorisation “returns an authorization code that may be exchanged for a token containing all scopes the user has granted the project”, and with incremental authorisation “the new access token will also cover any scopes to which the user previously granted the application access”.
The grant is per account and per application, not per task. There is no smaller token to fall back to for a session that needs less.
The approval prompt offers Always allow beside Allow once. Press it for one tool, in one conversation, for one reason, and the question stops being asked. Three prompts of that shape are in this deployment's record — send, trash, labels — each identical, each with the same button.
Whether that state is bounded by the conversation is not stated on the vendor's help page. See the table below.
The directory listing shows a single Gmail connector with a single Connect to Claude button, captured 16 September 2026. A narrower second connection — the same mailbox, read-only, for the sessions that only read — is something neither vendor's page describes.
It may be possible; it is not documented. That is an open question below rather than a claim here.
Google, Using OAuth 2.0 for Web Server Applications, read 20 September 2026. Whether this particular connector uses incremental authorisation is not published by either vendor; what is published is that the authorisation server is designed to accumulate, and that a grant belongs to an account-and-application pair rather than to a task.
Read from Anthropic's Google Workspace connector help article on 20 September 2026. The silences are not an accusation — a vendor is entitled to document what it chooses. They are recorded because a deployer cannot find the answers, and the answers decide how far a single click reaches.
| The question | What the page says |
|---|---|
| Can I turn a connector off? | Answered. “Toggle individual connectors on or off.” |
| Can I turn off a single tool? | Answered. “Individual users can also disable specific tools from the chat interface.” A real control surface, and a manual one — nothing turns a tool off because this session does not need it. |
| Does Always allow last beyond this conversation? | Silent. The page says approval is asked “before each of these actions” and that the asking can stop; it does not say for how long, or where the state lives. |
| Can an approval be scoped to one chat or one project? | Silent. |
| Can I connect a second account, or the same account with fewer permissions? | Silent. |
| Which scopes are requested, and can I choose a subset? | Silent on the scopes — it says only that “Google's OAuth screen mentions email sending permissions”. Google's screen itself offers three tick boxes, each of which can be unticked. |
It is the right instinct and it does not survive the mechanics, which the first article in this series takes apart in detail.
What the agent needs to do its job over a year, and what it needs for the next ten minutes, are different sets. Keeping the first available at all times, because the second cannot be expressed, is the oldest failure mode in access management — and the discipline that grew up around it has names for every part of the answer: roles, least privilege, just-in-time elevation, session scoping, expiry, review.
None of that tooling has arrived here. What a deployer has today, for an agent sitting on a mailbox, is:
The union is not a bug in anybody's product. It is what you get when authorisation is granted per application and work is done per task.
Everything above follows from that mismatch. It is worth stating plainly because it is invisible from inside the session — there is no screen anywhere that shows a person the union they are now running with.
A behaviour policy measures the grant once, and the grant it measures is the union — that is what measuring means. The lever a deployer still has is the other object: the mandate is written per purpose, and the delta is recomputed against each one.
| The mandate you write | Against the same six-capability grant |
|---|---|
| “Read my inbox and tell me what is in it” | one capability wanted, five in the grant and not asked for, four of them with nothing in the way |
| “Draft replies for me to send myself” | drafting is wanted; sending is not — and sending is a setting, removable in one click, so the refusal is a sentence rather than a bound |
| “Triage and file, never send” | labelling is wanted; the send tools are still present, still approved from a previous conversation, still in the grant |
A read-only connection to the same mailbox, used by the sessions that only read. Google's gmail.readonly grants no send, so the bound is enforced by somebody the grant does not include — which is the difference between a control and a preference. That shape is written up too. Whether a client can hold two connections to one provider is the open question below.
Per project, or per conversation, or per hour. Still a setting by our test — the account can still grant it — but a setting whose blast radius ends somewhere, and which a session cannot inherit silently from a conversation three months ago.
A list of what has been allowed, when, and by whom, that a person can open and revoke from. It bounds nothing on its own — but nothing can be reviewed that cannot be seen, and today the only evidence that Always allow was pressed is that the prompt stopped appearing.
Each is answerable from a vendor's own pages or from a system we are entitled to run. None is answerable by probing somebody else's, so none of them is answered here.
| Question | How it gets settled |
|---|---|
| Can one client hold two connections to the same provider, with different scopes? | The vendor's documentation of the connector model, quoted; or attempting a second connection on an account we run, and recording what the interface does. |
| Does the approval state live in the conversation, the account, or the workspace? | The vendor's own documentation. Failing that, approving in one conversation and observing the next, on an account we run. |
| Does this connector use incremental authorisation, so that consenting again widens the existing token? | Google's third-party access page for the account, which lists the scopes the application currently holds, read before and after. |
| Does unticking a scope at consent time actually narrow what the connector can do, or does the connector refuse to connect? | Connecting with one line unticked, on an account we run, and recording what happens. |
Sources. Google, Using OAuth 2.0 for Web Server Applications and Gmail API scopes, read 20 September 2026. Anthropic, Use Google Workspace connectors, read 20 September 2026. The connector's directory listing, the consent screens and the approval prompts: captured by the deployer on an account they run, 16 and 19 September 2026, transcribed in the evidence record inside the vault for this shape.
What was not done. No account but the deployer's own was touched, nothing was probed on anybody else's system, and where a page is silent this article says it is silent rather than filling the gap. No claim here is a verdict on a named company.
Every article here is built on a record you can open, and on a model published somewhere you can check it. These are the ones behind this argument.
The button that makes the union permanent, taken apart: seven things the screen cannot tell you, and who holds the barrier it offers.
Read → Article What an Agent Behaviour Policy isThe four objects — mandate elicited, grant measured, delta derived, barrier recorded — and the enforcer test this article leans on throughout.
Read → Behaviour policy Claude with the Gmail connectorThe record: six capabilities with their barriers and holders, the blocked list, the contradictions, and the scenarios that give one grant more than one mandate.
Read → Behaviour policy Gmail, read-only scopeThe narrower credential as its own shape. What a session that only reads would hold if the credential said so — a boundary rather than a preference.
Read → Essay · nhi.sgit.ai Hope is not a controlThe transitive closure of a grant, and the two hopes every broad credential carries: that the agent will not misuse what it holds, and will not find more.
Open ↗ Model · abp.sgit.ai The four barriers, publishedThe vocabulary every policy on this site is computed against, versioned and pinned, so a barrier means the same thing in two documents.
Open ↗Nobody can answer that from inside the session, which is the finding. What can be written down is the grant, the mandate for what you actually want this agent for, and the distance between the two — per purpose, with what stands in the way of each row.