---
title: Connections (public)
description: Action Gateway connections authorize provider accounts for an actor, belong to the creating DigitalOcean user, and keep credentials out of model …
product: Managed Agents
url: https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/connections/
last_updated: "2026-10-14"
---

> **For AI agents:** The documentation index is at [https://docs.digitalocean.com/llms.txt](https://docs.digitalocean.com/llms.txt). Markdown versions of pages use the same URL with `index.html.md` in place of the HTML page (for example, append `index.html.md` to the directory path instead of opening the HTML document).

# Connections (public)

Action Gateway gives applications and AI agents governed access to tens of thousands of tools through a managed MCP endpoint or SDK. See [What You Can Build](https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/details/what-you-can-build/index.html.md) for example use cases of Action Gateway with Harness Runtime.

An Action Gateway *connection* authorizes tools to access an account at a provider such as GitHub or Linear. It associates that authorization with an [actor ID](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/actors/index.html.md). A session uses its actor ID to select the connection for each provider it calls.

A [tool provider](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/overview/index.html.md#tool-providers-and-tools) defines the available tools. The connection determines which provider account those tools use. Several tools from one provider can use the same connection, subject to the account’s scopes and the session’s tool policy.

## Connection Ownership

New connections belong to the DigitalOcean user who creates them, within the selected team. They are not automatically shared with every team member. Sessions created through the Control Panel or public API are also user-owned.

To use a connection, create the session 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. A team owner can inspect connection records for administration, but that visibility does not authorize using or changing another user’s connection.

You can reuse a connection across sessions you own. For a given owner, actor, and provider, there is one connection. To use different accounts at the same provider, assign them different actor IDs and select the intended actor when creating a session.

## 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 supplies authentication material. A connection associates that credential or authorization with an actor for its owning user. Network settings are separate from the authentication type.

Depending on the provider, you can use DigitalOcean’s OAuth application, register your own OAuth client, or provide your own API key. An OAuth flow requires the user to sign in to the provider and approve the requested scopes. An API key uses the permissions already assigned to that key.

A provider credential can be explicitly made reusable by the team. This lets team members create their own connections using that credential; it does not turn an existing user-owned connection into a shared connection.

The gateway resolves credentials when the tool executes. The model receives tool inputs and results, not the stored provider secret. Never put provider secrets into session instructions, tool arguments intended for ordinary data, or an agent conversation.

## 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 session 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](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/use-private-tools/index.html.md) for the setup sequence and [Configure a Private Connection](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/manage-connections/index.html.md#configure-a-private-connection) for the network fields.

## Authorization Scope

You grant scopes in the third-party system. A full-access credential retains that access when used through Action Gateway. We do not reduce its provider-side scopes. Pair a least-privilege credential with an appropriately restricted [tool policy](https://docs.digitalocean.com/products/managed-agents/action-gateway/concepts/tool-policies/index.html.md).

## Connection Lifecycle

You can authorize a provider before running a workload or complete authorization when a tool reports that a connection is required. Pre-authorize connections for unattended workloads that cannot stop for a provider sign-in.

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 session’s owning user and authorize the same actor the session uses. 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 as 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, delete the connection and authorize the actor again. A connection that a Harness Runtime Environment Config depends on is marked deletion protected and refuses an ordinary delete until that dependency is removed.

See [Authorize Providers with Connections](https://docs.digitalocean.com/products/managed-agents/action-gateway/how-to/manage-connections/index.html.md) for the Control Panel and SDK procedures.

## Existing Team-Scoped Connections

Older connections created without a user owner remain supported for compatibility. If no connection exists for the session 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.