Inside Action Gateway in Managed Agents

Inside Action Gateway in Managed Agents | DigitalOcean

© 2026 DigitalOcean, LLC. Sitemap .

AI/ML

Inside Action Gateway in Managed Agents

By Ben Batha and Tyler Gillam

Updated: October 13, 2026 11 min read

<- Back to blog home

A coding agent finishes a change and wants to open a GitHub issue with a link to its results. The agent can describe the issue, but creating it belongs to a different system. It needs a tool that can access GitHub, a connection with permission to use the correct account, and a decision on whether this particular agent is allowed to open an issue. If the request needs human approval, the person must be able to see what is being proposed before the call runs.

Harness Runtime provides the agent’s working environment within DigitalOcean Managed Agents , handling the outward-facing action. The same Gateway can also serve an agent running elsewhere through Model Context Protocol (MCP), a standard interface for connecting AI applications to tools. GitHub, MCP, and other third-party names appear here only to illustrate how the Gateway works and do not indicate any affiliation, sponsorship, or endorsement.

This walkthrough traces what happens to a request, including the point where an unreliable provider leaves the outcome uncertain. The principle is straightforward: a model’s suggestion to call a tool is a request, not authority. Action Gateway resolves the tool and caller, applies policy to the specific action, and dispatches an authorized call. The system is designed so that provider credentials remain outside model context and model-written code.

Managed execution and governed external action are different jobs. The figure abstracts away internal services and does not depict every network hop.

Start with the tool boundary

Agent work falls into two groups: what happens inside its own environment and what reaches out to other systems. In a coding environment, reading a file, running pytest, or editing a repository happens in the agent’s own workspace. Moving those operations to another service separates them from the files and processes they need. Creating a GitHub issue or updating a ticket is different. That call reaches an external API, often with a credential and a change that other people can see.

Action Gateway governs that external work: the calls that reach outside the agent’s environment. It holds definitions for tools it can execute in terms of 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. Think of 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 boundary is important for security. Action Gateway cannot govern a shell command that an agent runs locally or a network call made outside its tool path, because the host runtime and its own network controls govern that environment. Conversely, putting a credentialed API behind Action Gateway gives the team one place to decide whether the agent may call it and one dedicated path for executing it.

The MCP endpoint lets an MCP-compatible client connect without a custom integration for each provider. The Gateway can expose concrete tools for a small, curated Toolbelt.

For a much larger collection of tools, 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

The model need not read hundreds of schemas before it can ask for the one it needs.

This is also why the same Gateway can serve several kinds of clients:

A managed coding agent may already know its session and team through the Managed Agents integration.

Another application may attach as an MCP client using its own DigitalOcean identity.

A person may configure tools and connections in a console.

Whichever way a request arrives, the same rules decide whether it’s allowed.The caller’s identity and configuration must be resolved before a tool is dispatched.

Why does search only look at authorized tools?

Imagine a support agent with access to ticket lookup, repository issues, deployment status, and internal reporting. A request such as “find the failed deployment and add a note to the incident” crosses more than one tool. Search helps locate a relevant capability without flooding the model’s context with every tool definition.

The order is important. The Gateway first resolves which tools the caller is eligible to use. Search then ranks candidates from that set. A result from search is still not permission to execute: action.invoke checks the current policy and connection when the call is made. If permission changes between discovery and invocation, the earlier search result does not overrule the later check.

Search quality and output shaping are separate concerns. Ranking helps the model choose the right tool. Output shaping keeps large provider responses out of the model’s context. Neither changes the authorization boundary. The detailed ranking implementation can evolve without changing the contract that search only considers eligible tools and execution checks again.

Follow an action from request to result

The agent proposes an action and its arguments, such as a repository and issue text. The calling application authenticates to DigitalOcean, or, for an integrated runtime, presents a trusted service identity and the relevant customer context. The Gateway resolves that identity and the tool definition before it uses a provider credential.

Next, it 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, while an ask call waits for a decision through the calling application’s approval interface. An ask is not intended to become an allow where the client can’t display the prompt. After approval, the proposed tool and arguments must still match the action that will run.

After those checks pass, the execution path contacts the provider. It uses the connection authorized for this caller, applies the tool’s limits, and returns the result or a structured error. A call trace can help operators understand what happened without treating a raw provider response as the only source of evidence.

A tool request is checked before dispatch. Approval is a decision about the proposed call, not a blanket grant for later calls.

There is a...