Inside Action Gateway in Managed Agents

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 useful distinction between authentication and authorization:

• Authentication answers “who is making this request?”. A DigitalOcean API key or Console session identifies a customer caller; a trusted internal integration presents service identity and caller context.

• Authorization answers “may this caller run this tool with this policy?”. Action Gateway makes that second decision for its tools. A valid API key is not a universal pass to every provider action.

The same distinction applies to an external account. Being able to connect a GitHub account does not, on its own, mean every agent may create issues in it. The connection provides a way to act with that account, and Action Gateway policy decides whether a particular tool call proceeds. The provider’s own permissions still apply.

Consider a team with two connections to the same provider: a read-only account for investigations and a separate account that can write to a project. The provider name alone does not identify which authorization to use. A call needs to resolve the intended connection, and policy must apply to that actual choice. A team can then keep routine lookups easy while making changes to the external system, subject to a tighter rule. A single global “GitHub access” switch can’t make that distinction.

What does a human approval actually cover?

A human approval should describe a concrete proposed action. If an agent requests permission to create an issue in one repository, changing the target or the issue contents after approval would make that approval meaningless. The design binds approval to the tool, arguments, and connection being used, then checks them again at dispatch. A refused, expired, or unsupported approval is designed not to result in an automatic allow.

The exact way a person sees the prompt depends on the client. Some MCP clients can present an interactive request; other applications carry approval through their own interface. A developer should confirm that their chosen integration can surface an ask decision before relying on an approval-gated workflow. Where approval transport is unsupported, the call is designed not to complete rather than to proceed without the safety check…

The provider sees a credential, not the agent

For an external service, a connection is a saved authorization to use an account. Depending on the provider and configuration, an operator might register an API key, authorize an application once for an agent, or ask an end user to authorize access to that user’s account through OAuth. OAuth is a consent flow in which the user authorizes an application without handing the application their password. A headless workflow cannot complete a new end-user consent flow without a person taking that step.

If a call needs a connection that has not been made yet, the system can direct the user to a hosted connection flow. The invocation waits until the person completes authorization and the caller tries the action again.

The credential service stores the provider token. The Gateway stores connection information and obtains an authorization for the specific call. The component making the outbound request consumes that authorization when it calls the provider. The model sees the tool result, not the token. A model-written program in a sandbox also uses governed tool calls rather than receiving the provider credential in its environment.

The account holder authorizes a connection; later calls use it through the execution path. Lines show responsibility and data flow at a conceptual level, not the credential protocol.

The architecture is designed to keep provider credentials out of the model’s prompt, the calling agent, and model-written sandbox code on this path. It does not promise that an authorized action cannot reveal other sensitive information. An authorized call can disclose or publish data that the tool or permutation of tools available to the agent is allowed to reach, e.g. a tool may be allowed to read a document or post a message. Scoping the session and external account privileges is the control for that exposure.

Teams should still give an agent the smallest useful Toolbelt, narrow the external account’s privileges, and use approvals where a consequential action merits human review.

DigitalOcean’s own tools use the caller’s DigitalOcean permissions rather than borrowing a third-party provider connection. That is another reason not to describe all tools as sharing one secret. Identity, Gateway policy, and provider or platform permissions are related checks with different jobs.

Connections can also be revoked: a saved connection is not an irrevocable promise that future calls will work. If the external grant is removed or becomes invalid, a subsequent action must stop or request reconnection. The agent may retain a useful description of the tool, but a cached description cannot revive an expired authorization.

Coordinate a chain of tool calls

An agent searches for an existing issue. If it finds one, it adds a comment; otherwise it creates a new issue. The next call depends on what the search returns, including the issue ID when there is a match. Sending the full search response back through the model just to make that choice adds another round trip.

For calls that do not depend on each other, action.invoke can run several at once. The Gateway checks permission and limits for each one. When the calls depend on earlier results, action.code runs a short program written by the model in an isolated environment. The program can extract an ID, adapt it to the next tool’s input, and return a compact result after the sequence finishes.

The model-written program never receives a provider credential. When it calls a tool, that call goes back through Action Gateway for the same policy and connection checks as a direct invocation. If a step requires human approval, the program waits while the original calling application asks the person, because it cannot approve its own next step.

The program handles intermediate results. Every tool call still passes through policy, including later steps in the chain.

action.code is separate from running a shell command in Harness Runtime. A coding agent already has its files and processes there. Moving a local test or git diff into action.code would add another environment without progressing the task. The isolated program is for coordinating Gateway tools that need the governed path.

Reliable execution

Before opening a GitHub issue, the agent searches the repository for one that already exists. The provider returns a temporary server error. That search is a read, so repeating it should not create or change an issue. If the tool’s policy allows a retry, the execution path waits briefly and tries again within the call’s deadline. The agent receives a single result from its tool call, even if the provider received multiple attempts.

Issue creation is different. The provider might create the issue and then lose the response. Sending the request again could create a duplicate. Some APIs accept an idempotency key—a unique value that tells the provider to treat repeated requests as one operation. For a tool whose provider documents and enforces that behavior, the execution path uses the same key on each attempt. We do not assume the issue API has that protection. Without it, the write gets one attempt. If the response is lost, verify the outcome with the provider first. Resubmitting could create a duplicate.

The tool definition records which of these cases applies: verified read, provider-protected write, or no safe replay. The model does not decide that a failed write is safe to repeat. Even for an eligible tool, the execution path retries only specific failures, such as timeouts or temporary provider errors. It can wait for a rate-limited provider when that wait fits the deadline. Attempts run one at a time, with a bounded backoff between them. Each attempt counts against relevant usage limits, which is designed to prevent a provider outage from turning one agent request into an unbounded stream of calls.

Other failures require a different response, and sending the provider request again won’t help:

• An expired connection needs reconnection.

• Invalid input needs correction.

• A denied permission requires a policy change.

• A call awaiting approval needs a person’s decision.

A provider’s authorization rejection and other client errors also stop the call, as do cancellation and deadline expiry. In those cases, the caller receives a structured error rather than a silent retry.

If the Gateway loses the response from the execution path, it does not submit the whole invocation again, because the provider may already have completed a write. The caller needs to verify that state before starting a new logical call. Retry policy inside one invocation cannot make a later, separate invocation safe by itself.

Configuration changes and tool calls have different paths. If the admin interface is unavailable, an already configured call may still run. If the execution path cannot resolve the tool, policy, or connection safely, it stops.

The result and trace can tell an operator whether the call was authorized, how many attempts ran, and whether the retry policy was exhausted. They need not copy credentials or raw provider responses into logs. A safe read may recover without another model turn. For an uncertain write, the useful next step is to check what the provider did.

This article describes Action Gateway’s architecture and intended behavior as of the date of publication. It is informational only: it is not a security guarantee, does not create any warranty, representation, or commitment, and does not modify the terms governing your use of DigitalOcean services. Statements about planned or expected functionality are forward-looking and subject to change without notice. Third-party product and company names are the property of their respective owners and are used here for identification only; their use does not indicate affiliation, sponsorship, or endorsement.