OAuth providers

OAuth integrations let the agent reach your existing tools — read your inbox to summarize threads, check your calendar before proposing meeting times, pull a Google Doc into a research subagent's context. Connections are per-user (each member authorizes their own account); revocation is one click.

Supported providers

Cloud edition has all four. Self-host ships with Google + GitHub out of the box; Microsoft + Slack require the operator to register OAuth apps with those providers (free, but a manual step). See Self-host config for the env vars.

Connecting

Settings → Integrations → click the provider → authorize in the popup → done.

The platform:

• Stores only the encrypted refresh token (never the access token).
• Requests minimal scopes.
• Refreshes access tokens on demand, never sooner than needed.
• Persists the granted scopes so the UI can show what's actually connected (vs what was requested).

If the provider revokes the token externally (you removed the app's access from your Google Security panel), the platform detects on next use and surfaces a "reconnect" prompt — no silent failures.

What the agent does with each integration

Google / Microsoft Mail

• summarize_thread subagent — given a thread URL or subject, fetches the full thread, returns a structured summary + outstanding- questions list + suggested reply draft.
• Inbox-watcher (opt-in) — when a contact-of-interest emails you, surfaces a Today card with a draft reply you can confirm or edit.
• The agent never sends email on your behalf without explicit confirmation through the Inbox.

Google / Microsoft Calendar

• Pre-meeting brief — 15 minutes before each calendar event, the agent can generate a brief (read attendees → research each → surface in Today).
• Conflict-aware scheduling — when proposing meeting times in drafted emails, the agent checks your calendar for availability.
• Time-zone aware — uses the calendar event's timezone, not just the user profile timezone.

Google Drive / Microsoft Files

• Read-only — the agent can pull documents you reference in a prompt ("summarize the Q3 plan doc"), but doesn't enumerate or index your drive without prompting.
• The doc's content is loaded into the agent's context for that single turn; it isn't persisted into the knowledge graph unless you explicitly say "add this to my knowledge base."

GitHub

• search_issues — find issues matching a query in repos you've granted access to.
• read_issue / read_pr — fetch a specific item.
• The agent never modifies GitHub (writes are scope-excluded). Use an MCP server if you want write access.

Slack (cloud)

• summarize_channel — N hours of activity in a channel, structured summary + open-questions list.
• find_thread — semantic search over your channel history.
• Read-only; posting back requires an explicit Slack-write MCP connection.

Scope discipline

We deliberately request read-only scopes for every OAuth integration. Writes (sending email, creating events, modifying files) go through dedicated integrations (Ayrshare for social, explicit MCP servers for everything else) where the boundary is clearer.

This is a security choice: an OAuth token leak is bad, but a leak of a read-only token is far less bad than one with write access to your inbox.

Per-user vs tenant connections

OAuth integrations are per-user. The agent acting on user X's behalf uses user X's connections. There's no "tenant-level Google account" — that'd be hard to make work cleanly given Google's auth model.

This means each member needs to connect their own integrations. The tenant admin can encourage but not mandate this.

Revocation

Settings → Integrations → Disconnect. Three things happen:

1. The platform's stored refresh token is destroyed.
2. The provider's revocation endpoint is called (best-effort).
3. Any pending in-flight requests using the token return their normal "auth failed" error.

You can revoke from the provider side too (Google Security panel, etc.) — the platform detects on next request.

Data retention

Email/calendar/file data fetched via OAuth is NOT persisted by the platform unless explicitly turned into a knowledge graph entry (e.g. via "add this thread to my CRM as an activity"). Fetched data lives only inside the single agent turn that requested it.

This is different from the Knowledge graph's standard retention — deliberate, because OAuth-fetched personal data is much higher sensitivity than tenant-owned data.

Self-host operator note

OAuth integration requires the operator to register OAuth apps with each provider:

1. Google: Cloud Console → APIs & Services → Credentials → OAuth client ID. Authorized redirect: https://<your-domain>/auth/v1/ callback.
2. Microsoft: Azure → App registrations → New. Redirect URI same shape.
3. GitHub: Settings → Developer settings → OAuth Apps → New.
4. Slack: api.slack.com → Your Apps → Create New App.

Each provider's client ID + secret goes in .env. See Self-host config for the variable names.

Read next

• Settings → Integrations — the UI side.
• MCP servers — the open-ended extension path for tools not covered by these four providers.