OAuth for agents
OAuth lets a person grant a program limited access to their account without handing over a password, and the grant can be scoped and revoked. Applied to an autonomous agent it raises questions OAuth alone does not answer. Connect is an OAuth client to Google and Microsoft; it is not an authorisation server for third-party agents.
What OAuth actually provides#
Three properties, and they are worth naming separately because people reach for OAuth expecting a fourth that is not there.
- Delegation without a password
- The program never sees the account's credentials. It holds a token issued after the person approved a specific request.
- Scope
- The token carries the permissions that were asked for and granted, so 'read my mail' does not become 'send as me' by accident.
- Revocation
- The person can withdraw the grant later without changing their password, and the program's access stops.
What it does not provide is any control over what the program does inside the scope it was given. A token that may send mail may send anything, at any time, for any reason the program invents. For a deterministic client that is fine. For an agent whose next action is decided by a model reading text from strangers, the scope is a ceiling, not a policy.
The questions an agent raises that OAuth does not answer#
- On whose behalf, exactly? A token identifies the person who granted it. If an agent acts for a team, the audit trail says one human authorised something no human chose.
- How much, and how often? OAuth has no rate, no budget and no daily ceiling. Those are the application's job.
- Which actions need a person? Approval is not an OAuth concept. Deciding that a reply may be drafted but not sent is application policy.
- What was actually done? A token grants; it does not record. An audit trail that answers 'who decided this, under which rule' has to be built above it.
This is why an agent platform ends up with authority separation of its own — the agent's permissions being narrower than the person's, rather than identical to them. The reasoning is set out in Separating the agent's authority from the person's.
Does Connect use OAuth?#
As a client, yes, in two places. Google OAuth is the only way a person signs in to Connect — there is no password sign-in at all. And a workspace connects a mailbox by granting Connect scoped access to Gmail through Google OAuth or to Microsoft Graph, which is what makes reading and sending on that mailbox possible without anybody typing a password into Connect.
As an authorisation server, no. Connect does not issue OAuth tokens to third-party agents and has no consent screen of its own. A machine caller authenticates with an integration key, and that key resolves to exactly one workspace — the caller cannot name a different one in a request. See Integration keys and API authentication.
The public documentation surfaces — the MCP endpoint and the A2A endpoint — need no credential at all, because they read the same generated corpus the website serves. There is nothing there for a token to protect.
If you are designing delegated access for an agent#
- Scope to the narrowest thing that works, and expect to be asked to justify each scope. A grant request that asks for everything gets refused by cautious people and accepted by the ones you least want to disappoint.
- Bind the token to one tenant or account at issue time. If the caller can name the account, you have built a cross-account bug and not yet found it.
- Put the ceiling in the application: rate, budget, allowance, and a list of actions that need a person. Do not expect the token to carry them.
- Record the decision, not just the call — what was decided, under which rule, and what happened, including refusals.
- Make revocation visible. A person who withdraws a grant should be able to see that it stopped, not infer it from silence.
Questions#
Can I get an OAuth token for the Connect API?
No. Connect issues no OAuth tokens to third parties. Machine access uses an integration key scoped to a single workspace; the public documentation endpoints need no credential.
Why is Google OAuth the only way to sign in?
Because it removes a whole class of problem: there is no password to store, leak, reuse or reset. The trade-off is that everyone who signs in needs a Google account, which is a real limitation and is stated rather than hidden.
Does an OAuth scope stop an agent doing something harmful?
It stops the agent doing anything outside the scope. Inside it, the scope grants everything at once — which is why approval, autonomy modes and daily allowances exist above it. See What Connect may do.