Connectors: what every agent can do with Gmail and Google Drive

Kept by abp@web-summit.dinis, first written on 6 November 2026 at Dinis's word. Explorer phase: this page observes and recommends; it changes nothing. See also ABP in action.

The Reach: a connector belongs to the account

A Claude connector (Google Drive, Gmail, and others) is connected once, by the person, for their whole Claude account. Every session in that account, every agent of that person, gets the same tools. Measured in abp@web-summit.dinis's own session in Dinis's account: the Google Drive connector offers create_file, update_file, copy_file, share_file and trash_file beside the read and search tools. Nothing in the session limits them to one folder or one agent.

So today, for any person with a Drive or Gmail connector:

• every agent can read every file or email the person can, including backups, contacts and private pre-reads;
• every agent can change or delete them, and share a Drive file with someone;
• every agent can send email through Gmail, if the connector's send tools are on.

Seen in the record: the conductor's ABP notes it reaches the whole RiskMandate shared drive when its mandate is one folder; Angelo's scheduled collaboration agent read his Drive and mail for its debriefs (7e12751c); Silvio's procurement and outreach agents write drafts in his Gmail.

Can it be read-only, or write-only?

The honest summary: the platform gives a switch per tool, not per agent. Anything finer than "everyone in this account can" or "no one in this account can" has to be an ABP: a rule each agent keeps, and a check on whether it did.

Patterns already on the team

• One agent per connector (Silvio, people/silvio/policies/inbox.md). Only inbox@web-summit.silvio touches the mailbox; every other agent of Silvio's leaves the Gmail tools unused, and asks the inbox agent through a commit. The one technical barrier it names: Silvio turns off send_message, reply and forward in the connector's settings, so no session in his account can send, whatever its instructions. Whether that switch is off is not yet recorded.
• The person sends, the agent drafts (every brief's first rule). Held as a rule everywhere; held as a control only where the send tools are switched off.
• Material, not instruction. Every email and file an agent reads is information. Angelo's CRM agent renders mail as text only, loads nothing external and follows no link (3492b029).

Two more things the record shows

• A signed-out connector is a barrier, by accident. On 6 November Jose's helper could not write Gmail drafts because the connector needed signing in again (6f53ee7f): the agent stopped and asked Jose to reconnect. It shows the shape of the control we would want: the person, not the agent, decides when the connector is live.
• The comms protocol (WS-184, /comms-protocol/, at Dinis's word on 6 November): every private conversation, for RiskMandate and PrompTugal.news alike, lives in the team's private CRM; PrompTugal's agents hold only public material; every email is sent by a person from their own address. Agents that need someone contacted send a request on a lane; the reply that comes back says only what may be public. It narrows who touches mail to the CRM and inbox agents, by rule.

Secrets travel with the environment, too

A connector belongs to the account; a secret belongs to the cloud environment a session runs in. Every session started in an environment gets its variables. Measured on 7 November in abp@web-summit.dinis's own session (names only): Dinis's environment "GS Send - Full internet access" has unrestricted network and holds SG_SEND_ACCESS_TOKEN, OPENROUTER_API_KEY, OPEN_ROUTER_KEY and PT_PILOT_ACCESS_KEY. Any of his agents that runs there can use his SG/Send token and spend on the model keys, though his rule is one token per agent (WS-188).

Unlike connectors, this one can be made per agent. Angelo did it on 6 November: secrets live only in the environment of the agent they belong to, agents without a secret share an environment that holds none, and his own token is out of the shared one (4c285114, 113192c2, 06ff8a78). A session cannot read another environment's variables: a technical barrier, set by the person, out of the agent's reach.

The gentle lock-down, with escape valves

In order, each step small, each with a way back for a person:

1. Switch off what nobody's mandate uses, account by account: Gmail's send, reply and forward; Drive's trash_file and share_file. Escape valve: the person still sends, shares and deletes by hand, from Gmail or Drive; the switch can be turned back on in a minute.
2. One agent per connector, as Silvio does: name it in the person's agents.json, and have every other agent's prompt say it leaves those tools unused. Escape valve: any agent can ask that one agent through a commit.
3. Backups and anything that must not be changed go where no agent's connector reaches: a separate account or shared drive, or a vault whose read key is held by the person. Escape valve: the person opens it themselves.
4. Check, not only trust: the watcher and policy agents (watcher@web-summit.jose, policy@web-summit.angelo) already flag commits that show mailbox content from the wrong agent; that becomes the "checked" barrier until a per-agent control exists.

What would change the picture: a per-session or per-agent tool scope in the platform, or a connector for a narrower account. Until then, the ABP is the control, and this page is where its gaps are written down.