Action Gateway is in public preview.
Connectionspublic
Last verified 5 Nov 2026
Action Gateway connects applications and AI agents to tools through a managed MCP endpoint or SDK, with the accounts and permissions you choose. See What You Can Build for standalone agent examples.
An Action Gateway connection saves access to an account, such as your GitHub account, so your agent can work with it. You grant access by signing in to the service and approving its requested permissions, or by supplying an API key. Action Gateway stores the credentials and uses them for tool calls without giving them to the agent.
A service that supplies tools is called a tool provider. A tool is an operation, such as listing GitHub issues. One GitHub connection can support several GitHub tools. You do not sign in again for each operation. Public tools that do not require your own provider credentials do not need this account-connection step.
How a Tool Uses a Connection
Assign the connection the same actor ID as the endpoint that uses it. This label tells Action Gateway whose connected accounts to use. For your own coding agent, you can keep the Control Panel default. For another person, use the label you assigned to their endpoints, such as user-123.
For example, an issue-triage agent can use both GitHub and Linear connections assigned to user-123. When it calls a GitHub tool, Action Gateway looks up that actor’s GitHub connection. A Linear call uses the Linear connection instead. Each call reuses the saved account access.
A connection is not a list of allowed tools. The endpoint version’s tool selection and tool policy control which operations can run. A Toolbelt groups operations for reuse, but contains no account authorization.
Connection Ownership
New connections belong to the DigitalOcean user who creates them, within the selected team. Create the endpoint and connection as the same DigitalOcean user, in the same team, with the same actor ID. Another team member using that actor ID does not gain access to your connection.
The person granting access to the external account can be different from the DigitalOcean owner. For example, your backend can create a connection and endpoint while an application user signs in to GitHub and approves access. That user does not need a DigitalOcean login for provider consent, and consent does not grant them direct access to your MCP endpoint. See Connect an Application User’s Account.
You can reuse a connection across endpoints you own. Within a team, each owner and actor has one connection per provider. To use different accounts at the same provider, assign them different actor IDs.
Credentials and Connections
A connection identifies a provider, an actor ID, and an authentication type: none, OAuth, or provider secret. Select none when the provider requires no authentication. OAuth authorizes a provider account, and a provider secret supplies a stored credential such as an API key.
A provider credential stores a secret, such as an API key or OAuth application credentials. A connection links account access to the actor that uses it. Network settings are separate from the authentication type.
Provider sign-in, DigitalOcean sign-in, and tool approval serve different purposes:
| Step | What it permits |
|---|---|
| Authenticate the MCP client or SDK with DigitalOcean | Access Action Gateway resources owned by that DigitalOcean user in the selected team. |
| Connect a provider account | Use the account and permissions granted at GitHub, Linear, or another service. |
| Approve a tool call | Run that call under the endpoint version’s policy. Approval does not sign in to a provider or grant additional provider permissions. |
Keep provider credentials and consent links out of agent conversations, endpoint instructions, and tool arguments intended for ordinary data. Present consent links only to the intended account holder.
Private Network Connections
A connection can also specify a VPC and a list of allowed destination hosts and ports. Calls through that connection use its private network settings. Creating the connection saves the settings. Action Gateway establishes the private execution path when needed.
VPC networking must be enabled for your team and is available in ric1. The VPC must belong to your team. For private MCP tools, the connection must match the server’s registered VPC ID and region and allow the MCP endpoint’s host and port. If the endpoint version has a VPC attachment, its region must match the connection’s region.
A private MCP server with no upstream authentication still needs an active connection. Its credential kind is none: the connection grants private transport without storing a secret or starting an OAuth flow. A missing or revoked connection does not make the server publicly reachable.
The actor selects the connection within its owner and team. The VPC does not select the actor or replace authorization. See Access Tools and MCP Servers on a Private Network for the setup sequence and Configure a Private Connection for the network fields.
Authorization Scope
Provider permissions, often called scopes, determine what the connected account permits. An API key uses the permissions already assigned to that key. An endpoint policy can further restrict tool calls, but cannot grant access the account does not have. Pair a least-privilege credential with a restricted tool policy.
Connection Lifecycle
Connect accounts before an unattended workload starts. For interactive work, you can also complete authorization when a tool call requests it.
A connection may need attention when its authorization was not completed in time, it is revoked in DigitalOcean, it lacks a required scope, or it needs provider-specific settings. Follow the returned connection guidance as the endpoint’s owning user and reconnect the account using the endpoint’s actor ID. Tool approval and provider authorization are separate decisions. Approving a call does not grant OAuth scopes.
DigitalOcean does not detect authorization revoked at the provider, so the connection continues to show Active and returns no connection guidance. Each tool call or git command that uses it then fails with the provider’s authentication error. To recover, revoke the connection and authorize the account again using the same actor ID. A connection that a Harness Runtime Environment Config depends on is marked deletion protected and refuses an ordinary delete until that dependency is removed.
Action Gateway refreshes OAuth access tokens when the provider supports refresh and the refresh credential remains valid. If access is revoked or cannot be refreshed, the account holder must authorize again.
Endpoints look up the connection on each tool call, so reauthorization does not require new endpoints or MCP URLs. A compatible MCP client can continue a call still waiting for consent. Failed calls are not replayed automatically. Check for earlier effects before retrying. See Restore Provider Access for recovery steps.
Revoking a connection removes account access for subsequent calls through all endpoints that use it. Changing an endpoint’s tools or policy does not revoke the connection.
Reusable Provider Credentials
Depending on the provider, a connection can use DigitalOcean’s OAuth application, your own OAuth application, or an API key. Registering an OAuth application’s client credentials sets up the sign-in integration. The account holder still needs to grant consent.
A provider credential can be explicitly made reusable by the team. This lets team members create their own connections using it. It does not turn an existing user-owned connection into a shared connection.
Existing Team-Scoped Connections
Older connections created without a user owner remain supported for compatibility. If no connection exists for the endpoint owner, actor, and provider, the gateway can use a matching older team-scoped connection. If a user-owned connection exists but needs attention, the gateway does not switch to the older connection to bypass that problem.