DigitalOcean explains how Action Gateway governs agent tool calls

October 13, 2026Source: DigitalOcean

DigitalOcean has published a walkthrough of Action Gateway, the component of its Managed Agents product that handles an agent's calls to outside systems. According to the company, a model's suggestion to call a tool is "a request, not authority", and the Gateway decides whether the call actually runs.

Key points

DigitalOcean's Action Gateway governs an agent's calls to external systems in Managed Agents, not local shell commands or network calls outside its tool path.
A tool call can be allowed, denied, or marked ask, which requires human approval tied to the specific tool, arguments and connection.
Meta-tools action.search, action.invoke and action.code let large tool collections be used without loading every schema into the model's context.
Search only ranks tools the caller is eligible for, and action.invoke checks policy and connection again at execution.
According to DigitalOcean, provider credentials are designed to stay outside model context and model-written code.

Separating the agent's workspace from external actions

DigitalOcean splits agent work into two groups: what happens inside the agent's own environment and what reaches out to other systems. Reading a file, running pytest or editing a repository happens in the agent's own workspace. Creating a GitHub issue or updating a ticket is different, because the call reaches an external API, often with a credential and a change other people can see.

Action Gateway governs only that second group. It holds definitions of the tools it can execute, including what a tool does, the shape of its inputs, and the connection and policy it requires. A customer's Toolbelt is a curated collection of those tools for an agent or task. DigitalOcean describes it as a menu, not a permission slip: a tool can be on the menu and still be denied by policy or lack a valid connection.

The company states the limits plainly. Action Gateway cannot govern a shell command an agent runs locally or a network call made outside its tool path, because the host runtime and its own network controls cover that environment.

Search, meta-tools and MCP access

The Gateway offers a Model Context Protocol (MCP) endpoint, so an MCP-compatible client can connect without a custom integration for each provider. For a small Toolbelt it can expose concrete tools. For a much larger collection it can expose a smaller set of meta-tools:

action.search finds candidate tools within the authorized set
action.invoke runs selected tools
action.code coordinates dependent calls

This means the model does not need to read hundreds of schemas to ask for one tool. The order matters, according to DigitalOcean: the Gateway first resolves which tools the caller is eligible to use, and search then ranks candidates from that set. A search result is not permission to execute. action.invoke checks the current policy and connection at call time, so if permissions change between discovery and invocation, the later check wins.

The same rules apply whether the request comes from a managed coding agent, another application attached as an MCP client, or a person configuring tools and connections in a console.

Policy, approval and connections

When an agent proposes an action, the calling application authenticates to DigitalOcean, or an integrated runtime presents a trusted service identity and customer context. The Gateway resolves that identity and the tool definition before using any provider credential. It then evaluates policy for the specific call. A team can allow a tool, deny it, or mark it ask, meaning a human must approve.

A denied call stops. An ask call waits for a decision through the calling application's approval interface. DigitalOcean says approval is bound to the tool, arguments and connection, and these are checked again at dispatch. A refused, expired or unsupported approval is designed not to result in an automatic allow. Developers should confirm that their chosen integration can show an ask decision before relying on an approval-gated workflow.

The post also separates authentication, which answers who is making the request, from authorization, which answers whether that caller may run this tool under this policy. A valid API key is not a universal pass to every provider action, and connecting a GitHub account does not by itself mean every agent may create issues in it. The provider's own permissions still apply.

Connections matter too. A team might have a read-only account for investigations and a separate account that can write to a project. Because the provider name alone does not identify which authorization to use, a call must resolve the intended connection, and policy applies to that actual choice. According to the company, a single global GitHub access switch cannot make that distinction.

What it means for teams building agents

DigitalOcean says the system is designed so that provider credentials remain outside model context and model-written code. For teams, the stated benefit of putting a credentialed API behind Action Gateway is one place to decide whether an agent may call it and one dedicated path for executing it. Routine lookups can stay easy while changes to an external system face a tighter rule.

The source text provided ends partway through its discussion of connections and OAuth, so details on that part of the design are not covered here.