Connections

Connections link your personal accounts to the services available through the gateway. Each user authenticates independently, so an agent calling one of these services uses that user's own credentials and permissions rather than a shared account.

Connections (this article) link an end user's account to a service — each user signs in separately. They are distinct from the organization's OAuth client credentials, which determine which OAuth app the gateway uses to start that flow. See Credential modes for how organizations choose between using SecureAuth's app and bringing their own.

How connections work

1. An agent tries to use a tool that requires authentication (for example, sending a Slack message)
2. The gateway returns a link prompting the user to connect their account
3. The user clicks the link and completes the OAuth flow with the service provider
4. The gateway stores the credentials securely — encrypted at rest — and uses them for future requests

Once connected, all subsequent requests to that service use the user's credentials automatically — no re-authentication required. This exchange only happens for calls a policy already allows — a denied call never reaches the upstream service, so no connection is needed.

Per-user isolation

Connections are strictly per-user. An agent acting for one user cannot access another user's connections. This means:

• Each user only has access to the data their own account can see
• Actions are attributed to the correct user in the upstream service
• Revoking a connection only affects that user

Managing connections

Navigate to Connections in the dashboard to see the services that require a connection, each with its status and when it was last used.

• Connect — click to start the OAuth flow and link your account
• Disconnect — removes the connection and its stored credentials outright

Both actions need the manage_connections permission. Without it the page is read-only and neither button appears.

For admins: sharing and verifying

Connections are per-user, so each person links their own accounts. Two admin actions make that easier to hand off and to check:

• Copy portal link — on Agent Registry and Agent Instances (and in the empty Agent Trail view) copies the URL of the user portal. Share it so users know where to go to connect their agents.
• Connect — on a resource's detail page (Resources → your MCP) opens that resource's connect flow in the user portal and starts it right away, so you can confirm authentication works and tools populate before handing the resource to users. It appears only for resources that need a per-user OAuth connection.

Connection statuses

The page shows each service as Connected or Not connected. Two things keep it that simple:

• Tokens refresh on their own. The gateway renews expiring access tokens in the background and retries once if a provider rejects a token mid-call, so a working connection keeps working without you signing in again. Nothing lands in an expired state for you to clean up.
• Disconnecting removes the connection. It doesn't leave a lapsed record behind — the credentials are deleted and the service goes back to Not connected.

The case that does need your attention is revocation by the provider. If the upstream invalidates the grant — you revoked the app's access in the provider's own settings, an admin removed it, or the refresh token stopped being accepted — the gateway marks the connection revoked and records a connection-revoked audit event. The next tool call that needs that service returns the connect link again; click through it to reconnect.

Next steps

• Credential modes — how your organization chooses the OAuth app behind these connections.
• Policies — decide which calls are allowed to use a connection at all.
• Audit log — see connection-created and revoked events.