Connectors

A connector is a tool that reaches an external system as the user. It is the platform's answer to the hardest part of enterprise agents: letting an agent act in ServiceNow, a calendar, or a mailbox without ever holding a shared god-credential.

The core idea: delegated identity

Each user connects their own account once. From then on, when an agent calls a connector on that user's behalf, the platform resolves that user's OAuth token at call time and sends only that. Two people asking the same agent the same question get their own data back.

Operations

Each connector exposes a small set of named operations, and every operation is tagged. The tag is what governance keys on:

Available connectors

Browse these in the app under Catalog → Connectors, which shows each connector's operations and whether you've connected it.

Plus ITSM, CRM, developer and privileged-access connectors — the full list is in Catalog → Connectors. Mail, calendar and contacts come in two families: Microsoft 365 above, and Google (gmail, google_calendar, google_drive).

Custom connectors: any REST API, no code

When an internal or niche tool has no built-in adapter, an org admin can configure a custom HTTP connector — from Settings → Connectors → Add a custom connector — with no code and no deploy. A custom connector is a description, not a program:

• a base URL and an auth method — OAuth 2.0 (authorize/token URLs, client, scopes) or a static bearer token entered per user;
• a list of operations, each a method + path with {braces} for path parameters, tagged read or write.

What you configure becomes a real connector: an agent declares it by slug like any other, the call is delegated as the requesting user, writes park for approval, and every call runs through the one execution path. Path parameters are filled from the model's arguments and, for a write, the remaining arguments become the JSON body.

Knowledge sources (Confluence, Google Drive) also use delegated OAuth, but they are not agent-callable tools — they sync documents into knowledge collections, mirroring each document's source permissions so retrieval stays permission-aware.

Using a connector in an agent

Add the connector name to the agent's tools. That's the whole grant.

---
name: exec-assistant
model: default
tools:
  - calendar
---

# Role
Book meetings on the user's calendar. Always confirm a slot before creating it.

The model sees one calendar tool whose schema lists the available operations, and picks an op plus arguments.

The connect flow

1. Consent

   The user starts a connection (from settings, or from a Connect card in chat). The platform builds an authorization-code + PKCE request and redirects to the provider.

2. Callback

   The provider redirects back with a code, which the platform exchanges for tokens server-side.

3. Vault

   Tokens are encrypted at rest and referenced indirectly. They are decrypted only server-side at call time and never returned through the API.

4. Use and refresh

   A background sweep refreshes tokens before expiry. If a run parked waiting on the connection, completing consent resumes it automatically.

Lifecycle and safety

• Revocation is immediate — credentials are resolved per call, so a disconnected connector stops working on the very next call, not at the next token refresh.
• Deprovisioning cascades — removing a user revokes all of their connector credentials, disables their automations, and cancels their runs.
• Health checks — each connector exposes a cheap liveness probe that runs on a schedule.
• DLP applies — data read back from an external system is screened before it reaches the model, and outbound arguments are screened too.
• Everything is audited — connect, disconnect, every invocation, and every approval decision.

How connectors differ from MCP servers