## The section is called Articles, and a session carries every approval you ever gave

**The menu says what the thing is.** *Writing* described the activity; *Articles* describes what a
reader will find. Two releases old and renamed at the lead's ask, which is the right time to do it.
The page, its addresses and the two published pieces are unchanged.

**The third article:** [*A session that only reads still holds everything you ever
allowed*](article-union-of-every-session.html).

You open a new chat and ask the agent to read your inbox. Nothing in that sentence authorises
sending mail, changing labels or creating a filter — but a conversation is not an authorisation
boundary. It runs on the credential you granted months ago and the approvals you clicked in other
conversations for other reasons, and there is no screen anywhere that shows a person the union they
are now running with.

The union forms in three places, each documented by the party that built it. **At the credential:**
Google's own words — 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”. A grant belongs to an account and an application, never to a task. **At the
client:** the approval prompt is per tool, and *Always allow* is pressed in one conversation for one
reason. **At the deployment:** one connector, one account, one *Connect* button.

**The centre of the article is a table of silences.** Six questions a deployer would ask, read from
the vendor's help page on 20 September 2026. Two are answered — a connector can be toggled off, and
individual tools can be disabled from the chat interface, both real and both manual. Four are not:
whether *Always allow* lasts beyond the conversation, whether an approval can be scoped to a chat or
a project, whether a second and narrower connection to the same account is possible, and which
scopes are requested. The silences are recorded rather than filled, and they are not an accusation —
a vendor documents what it chooses. They are the reason a deployer cannot work out how far one click
reaches.

Then the name the problem already has: standing privilege, arriving somewhere with none of the
tooling the discipline built for it — no roles, no session scoping, no expiry, no record of what was
approved or when. And the one lever a deployer still holds: the grant is the union by construction,
so the mandate is written per purpose and the delta recomputed against each one, which is why the
vault for this shape carries several scenarios rather than a single mandate.

**Four open questions**, each with how it would be settled, none of them answered by probing
somebody else's system. Whether one client can hold two connections to a provider is the first, and
it is the one that would change the most.

**Not changed.** The five queued articles on the index are still marked *not written*. Nothing here
narrows anybody's credential; it says where the union comes from and what a document can do about it.