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↗.

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.