MCP Gateway for AI Agents: Connecting AI Agents to SaaS Tools Without Sharing Your Credentials using DigitalOcean Action Gateway

Picture a support agent closing one ticket. It looks up the order in a database, issues a refund through Stripe, and posts a summary in Slack. Three systems, three integrations, three sets of credentials. Wire them yourself and you own the parts nobody puts in a demo: where each token lives and how it rotates, who is allowed to approve a refund, what happens when Stripe returns a rate-limit error at 2am, and whether anyone reconstructs what the agent did a week later. Add a fourth tool and you do all of it again.

A second problem starts once the tools work. The agent sends a malformed argument and loops on the rejection. A vendor returns a bare 401 and the model guesses whether to retry, re-authorize, or stop. A database query returns 40 KB of JSON, and every later turn in that session pays for those tokens. Teams end up staffing an execution layer around the agent instead of building the product their customers bought.

Action Gateway addresses both. Credentials resolve outside the agent, so a leaked transcript does not leak a token. Approved tools are configured once and reused. Failures come back as structured errors an agent recovers from rather than raw status codes. Tool discovery happens through search, so the model sees the few tools a task needs instead of a full catalog on every turn. You give up some control over the execution path in exchange for not maintaining it.

1. Harness Runtime gives your AI coding agents (Claude Code, Codex CLI, OpenCode) or custom LangGraph/CrewAI agents an isolated, persistent cloud sandbox that keeps running independent of your laptop, with no infrastructure to build or manage.

2. Action Gateway gives those same agents governed access to the tools they need, like GitHub, Jira, Notion, Linear, Postgres and 1000+ SaaS tools, without you wiring up credentials one by one.

Managed Agents Runtime Services has the following capabilities:

Sessions start in under a second and resume from a pause in as little as 200 milliseconds, preserving files, processes, and working state. Supported agents include Claude Code, Codex CLI, and OpenCode, along with agents built on LangGraph or CrewAI. Rather than rebuilding your agent around a proprietary framework, you define an environment template packaging your harness, dependencies, tools, and configuration. For Action Gateway, DigitalOcean names GitHub, Jira, Notion, Linear, and Postgres as governed services, with authentication, permissions, approvals, and audit controls managed centrally.

The three use cases are practical rather than abstract: continue a session from another device, hand work to a teammate mid-task, and run several agents in parallel without multiplying infrastructure setup.

• Action Gateway does not load a tool catalog into your model context. The endpoint exposes exactly three tools: action_search to find tools by use case, action_invoke to run up to 10 of them in parallel, and action_code to execute Python in an ephemeral sandbox.
• Inside a Managed Agents sandbox, the gateway resolves to an internal DigitalOcean address, not a public hostname, and the client config carries no bearer token.
• DigitalOcean-managed tools need no credential setup. A web search through the gateway succeeded with no API key in the session file and none in the sandbox.
• Tools requiring user authorization return a structured unauthorized error carrying a sign-in link, a verification code, and a recovery_hint field, rather than a bare 401.
• A permission default of ask does not work for gateway tool calls. The API returns a warning saying so at session creation. Use explicit allow rules.
• Permission enforcement on gateway tools is labeled best-effort in the policy delivered to the sandbox, and a direct call from inside the sandbox ran under a default-ask policy with no rules. Treat the policy as a guardrail on the agent’s tool path, not as a network boundary.

Arcade.dev raised a $60 million Series A in June 2026, bringing total financing to $72 million, and stated the problem clearly in We saw the action layer coming. Now we’re going to own it.

Their framing is clear: agents do not fail because models are weak. Agents fail because no system proves this agent, acting for this user, is permitted to perform this action on this resource. They report tool-call volume up 25x in six months and more than 8,000 agent-optimized tools.

Please read that as market evidence rather than a DigitalOcean claim. A round of that size in a dedicated action layer means the problem became a product category rather than glue code each team writes once.

DigitalOcean’s position is adjacency. Serverless Inference serves the model. Harness Runtime runs the sandbox. Action Gateway brokers the tools. One account, one token, and the data sitting next to the compute.

Abstract comparisons are hard to evaluate, so use one workload throughout. A hosted coding agent working on a benchmark repository, with three tasks of increasing difficulty:

1. Read raw results and rerun an analysis script. Filesystem and Python only.
2. Create a branch, edit a file, commit, push, open a pull request. Git plus one credential.
3. Look up current pricing on the public web, list Droplet sizes, add a dated note, file a ticket. Web access, cloud APIs, and a third-party system.

Task 1 needs no external tools. Task 2 needs one credential. Task 3 is where the wiring choice starts to cost you, and where Action Gateway earns its place.

Each step on that staircase is one way to hand an agent a tool. Going right, the password moves further away from the agent. Going up, you get more say over what runs and more evidence about what happened afterward. The small grey line at the bottom of every block is the part people skip when choosing: what you see when the thing breaks at 2am.

1. Local sandbox tools. The agent gets a shell, files, and git inside its own machine, and nothing else. There are no passwords to leak because nothing leaves the box. When something fails you get an exit code, the same as a script that died.

2. Credentials in the environment. You paste an API key into the session file. Five minutes of work and it runs. The key also sits in plain text right next to the agent, so anything with a shell reads it. That is the amber warning on the block. On failure you get whatever the vendor sent, usually a bare number.

3. Provider OAuth on the spec. You authorize GitHub once for the team and point at a slot instead of pasting a token. Nothing secret sits in your YAML, which is the real gain. The token still lands inside the sandbox, so the agent still reads it, and failures are still raw git or API errors.

4. One MCP server per vendor. You run a server that speaks a standard protocol, so Claude Code, Codex, and Cursor all reach it without rewriting the integration three times. Portability is the win. The bill arrives at scale, because ten vendors means ten servers, ten logins, and ten different shapes of error to decode when a workflow stalls.

5. Connector catalog. Someone else already built and maintains hundreds of app integrations with the logins prewired. You get breadth on day one. What you do not get is a say in whether a specific call should run, or any shaping of the response before your model reads it.

6. Action Gateway. The password never enters the sandbox, because it gets attached after the request leaves. Each end user authorizes their own account, so one person’s access stays out of another person’s reach. A failure arrives labeled, with a recovery_hint field telling the agent whether to retry or send the user to log in again, instead of a 401 it has to guess about.

The benefit of Action Gateway, as illustrated by the image in this section, is that it provides a secure, flexible way to connect agents to external tools without exposing credentials in the agent sandbox.

As you move up the staircase, Action Gateway represents the highest level of control: the agent never receives direct access to the credentials or raw API keys. Instead, the gateway centrally enforces authentication, permissions, approvals, and audit controls for each tool invocation.

Action Gateway moves the trust boundary away from the agent. The agent asks for a tool. The gateway checks policy, attaches the credential, and returns a result the agent can use.

This walkthrough does three things, in order.

1. Harness Runtime starts a Claude Code session named anish-claude-code-test and gives it a Linux workspace plus GitHub.
2. Action Gateway lets that same session search for a GitHub tool and call it, without putting a GitHub API token in the spec.
3. A chat with the agent creates a branch, opens a pull request, and merges it.

Every command below ran on a live Private Preview session on 2 September 2026 with doctl 1.168.0-beta. The public result is pull request #1 on anishsingh20/serverless-inference-tail-latency-study. Tokens and connect codes are redacted.

M.A.R.S. is invite-only during Private Preview. Request access before you start. Agent commands return 403 until the feature is enabled on your team.

What you need

• A DigitalOcean account with a payment method on file. Sign up at cloud.digitalocean.com if you do not have one.
• Preview access to Managed Agents Runtime Services on your team.
• A terminal. On a Mac, open Terminal. On Windows, use PowerShell or WSL.
• A DigitalOcean personal access token with full access, created under API in the control panel. See the API quickstart.
• A GitHub repository you can push to. This walkthrough used anishsingh20/serverless-inference-tail-latency-study.

You do not need an Anthropic key. I have used DigitalOcean Serverless Inference for this walkthrough.

You can do the same work in the DigitalOcean control panel. After preview access is on, open Managed Agents in the left nav. Harness Runtime is where agents live. Action Gateway is where tools, connections, and sessions live.

Open Harness Runtime, click Sessions, and you should see your agent. This one is anish-claude-code-test. I had already created this Agent by importing the agents.yaml file that you will create in Step 4.

P.S. You can also create an Agent from the GUI(cloud control panel) or by directly importing the agents.yaml file.

On clicking the above import agent.yaml button, you will be prompted to upload the agents.yaml file or you can also select from a predefined list of agents.yaml manifests templates and edit them as per your needs.

This will create an Agent with the name anish-claude-code-test and the adapter claude-code.

Adapter is Claude Code. Status is Running. Click the name to open the live chat. Create Session on the right starts a new run. Create Agent in the top right starts a new one from scratch.

The console wizard is five steps: adapter, connections, configure, capabilities, permissions. This tutorial uses Claude Code and a YAML spec, then the CLI, so you can copy the same setup. The console path is the same product.

But before we do that, let’s install the doctl CLI and set up the environment.

Step 1. Install the doctl beta

The agent commands ship in a beta build, not in Homebrew or Snap. Install the prebuilt binary from GitHub. No Go compiler is required.

Find the latest -beta tag on the doctl Installing Beta Releases page. This walkthrough used v1.168.0-beta.1.

On an Apple Silicon Mac:

curl -sL https://github.com/digitalocean/doctl/releases/download/v1.168.0-beta.1/doctl-1.168.0-beta.1-darwin-arm64.tar.gz | tar -xzv
mkdir -p ~/.local/bin
mv ./doctl ~/.local/bin/
export PATH="$HOME/.local/bin:$PATH"

On Linux amd64, swap the archive name for doctl-1.168.0-beta.1-linux-amd64.tar.gz. On an Intel Mac, use darwin-amd64.

Confirm the beta, then confirm the agent commands exist:

doctl version
doctl agent --help

This is the output you should see:

doctl version 1.168.0-beta
Git commit hash: e2d11070

doctl harness-runtime
Managed Agents Runtime Services (M.A.R.S)

Managed Agents Runtime Services (M.A.R.S) — run a coding agent (Claude Code, OpenCode, Codex, …) in a DigitalOcean sandbox.

Create a session and attach in one step:
╭────────────────────────────────╮
│ doctl harness-runtime run \    │
│   --harness claude-code \      │
│   --gh-repo owner/repo \       │
│   --prompt "Review the README" │
╰────────────────────────────────╯

Create without attaching (ready summary only), then attach later:
╭─────────────────────────────────────────╮
│ doctl harness-runtime start \           │
│   --harness claude-code \               │
│   --gh-repo owner/repo \                │
│   --prompt "Review the README"          │
│ doctl harness-runtime attach my-session │
╰─────────────────────────────────────────╯

Session commands accept a session ID or an exact unique name.
Usage:
  doctl harness-runtime [flags]
  doctl harness-runtime [command]

Aliases:
  harness-runtime, agent, agents, ohr

Available Commands:
  approve      Resolve a pending HITL request out of band
  attach       Attach to a session
  auth         Connect an external provider (e.g. github) for agent git operations
  checkpoint   Manage session checkpoints (save points)
  config       Manage reusable agent configs
  download     Download a file from a session workspace
  exec         Run a command in a session's sandbox
  fork         Fork a session into independent child sessions
  list         List your sessions
  logs         Replay the event history for a session
  pause        Pause a session
  port-forward Forward local TCP ports into the session's sandbox
  remove       Remove a session
  resume       Resume a paused session
  rollback     Roll a session back to a checkpoint in place
  run          Start one session and attach
  show         Show one session
  sizes        List available sandbox sizes
  start        Start a new session
  start-proxy  Bridge the Codex CLI to a hosted session
  triggers     Manage webhook and cron triggers for hosted agent runs
  upload       Upload a file into a session workspace
  validate     Validate an agent manifest

Flags:
  -h, --help   help for harness-runtime

Global Flags:
  -t, --access-token string   API V2 access token
  -u, --api-url string        Override default API endpoint
  -c, --config string         Specify a custom config file
      --context string        Specify a custom authentication context name
      --http-retry-max int    Set maximum number of retries for requests that fail with a 429 or 500-level error (default 5)
      --interactive           Enable interactive behavior. Defaults to true if the terminal supports it (default true)
  -o, --output string         Desired output format [text|json] (default "text")
      --trace                 Show a log of network activity while performing a command
  -v, --verbose               Enable verbose output

Use "doctl harness-runtime [command] --help" for more information about a command.

doctl agent --help lists start, attach, list, pause, resume, remove, exec, auth, logs, and validate. If you see unknown command agent, the shell is still using a general-availability build. Run rehash or open a new terminal, and check which doctl points at the beta.

The first two lines prove you have the beta. The command list is what you use for the rest of this tutorial. auth is how you connect GitHub later. attach is how you chat with the agent. exec is how you run a command inside the sandbox without attaching. logs replays the chat after you detach.

Step 2. Sign doctl into your account

doctl auth init
doctl account get

Paste the token when prompted. Validating token: OK means the CLI can reach the API. doctl account get prints your team. If agent commands then return 403, the preview flag is not on that team yet.

Step 3. Connect GitHub once for the team

Harness Runtime can clone and push using a team GitHub grant. You authorize once. You never paste a personal access token into YAML.

doctl agent auth github

The CLI prints a URL and opens a browser. Approve access. Wait until it reports connected. Every session on the team then shares that grant. This is the grant gh and git push use inside the sandbox. Action Gateway GitHub API tools use a second connection, in Step 8.

Step 4. Write a spec for Claude Code Agent

The agents.yaml file is the spec this walkthrough uses. Keep this file in your current directory.

name: anish-claude-code-test
agent: claude-code
size: mv-2vcpu-4gb
persistent_workspace: true
repos:
  - anishsingh20/serverless-inference-tail-latency-study
env:
  HARNESS_INFERENCE_BASE_URL: "https://inference.do-ai.run/v1"
  HARNESS_INFERENCE_MODEL: anthropic-claude-4.6-sonnet
  ANTHROPIC_BASE_URL: "https://inference.do-ai.run"
  ANTHROPIC_MODEL: sonnet
secrets:
  HARNESS_INFERENCE_API_KEY: "${DIGITALOCEAN_ACCESS_TOKEN}"
  GITHUB_TOKEN: "oauth/github"
tools:
  - do.actions
permissions:
  default: ask
  rules:
    - tool: bash
      match: { command: "git *" }
      action: allow
    - tool: bash
      match: { command: "gh *" }
      action: allow
    - tool: mcp
      action: allow

What each block does:

• agent: claude-code picks the coding agent.
• size: mv-2vcpu-4gb is the default sandbox, 2 vCPUs and 4 GB of memory.
• repos records which repository the session should work on. It does not clone the files for you. You clone in the next step.
• env points Claude Code at DigitalOcean-hosted inference. Nothing in env should be a secret.
• secrets.HARNESS_INFERENCE_API_KEY is your DigitalOcean token, used as the model key.
• secrets.GITHUB_TOKEN: "oauth/github" is the team GitHub grant from Step 3.
• tools: [do.actions] turns on Action Gateway for this session.
• The mcp allow rule is required. Gateway tool calls have no in-band approval prompt. An ask default fails those calls.
• The gh * allow rule lets the agent open and merge a pull request without stopping for every gh command.

You can also use the GUI to create the Agent. Open Harness Runtime, click Agents, then Create Agent.

The GUI console wizard is five steps: adapter, connections, configure, capabilities, permissions. This tutorial uses Claude Code and a YAML spec, then the CLI, so you can copy the same setup.

Step 5. Validate, then start the session

export DIGITALOCEAN_ACCESS_TOKEN="dop_v1_..."
doctl agent validate agents.yaml

✓ Manifest looks valid

validate runs on your machine. It catches missing keys and secrets placed in env. The API is still the final check.

doctl agent start for Claude Code checks ANTHROPIC_API_KEY against api.anthropic.com from your laptop. A DigitalOcean token fails that check with HTTP 401. Post the spec to the sessions API instead:

sed "s|\${DIGITALOCEAN_ACCESS_TOKEN}|$DIGITALOCEAN_ACCESS_TOKEN|" \
  agents.yaml > /tmp/agent.yaml

curl -sS -X POST https://api.digitalocean.com/v2/agents/sessions \
  -H "Authorization: Bearer $DIGITALOCEAN_ACCESS_TOKEN" \
  -H "Accept: application/json" \
  -H "Content-Type: application/x-yaml" \
  --data-binary @/tmp/agent.yaml

{
  "session": {
    "name": "anish-claude-code-test",
    "agent_kind": "AGENT_KIND_CLAUDE_CODE",
    "status": "SESSION_STATUS_READY"
  }
}

The session came back READY. If the API warns that an ask default cannot approve gateway calls, that is expected. The spec already has the mcp allow rule, so gateway calls can run.

doctl agent list
doctl agent show anish-claude-code-test

  Session  anish-claude-code-test
  Agent    Claude Code
  Status   ● ready

Next step
  attach   doctl harness-runtime attach anish-claude-code-test

The green ready line is the status that matters. attach opens a live chat with the agent. This tutorial uses exec first so you can see the machine, then attach so you can see the agent do the work.

The same session also shows up under Action Gateway → Sessions on the Control Panel. That page is the gateway view of who the agent acts for, and which MCP endpoint it received.

Step 6. Use Harness Runtime: the agent has a machine

Harness Runtime is the first half of Managed Agents Runtime Services. The session is a Firecracker microVM with a shell, Python, Node, and git. Talk to the agent with doctl agent attach anish-claude-code-test, or run one command with exec.

doctl agent exec anish-claude-code-test -- sh -c \
  'uname -srm; python3 --version; git --version; ls /workspace'

Linux 6.1.176 x86_64
Python 3.12.3
git version 2.43.0
claude-code.log
mcp-config.json

repos did not fill the working tree. Clone the study repo. Run the clone as the agent user, or the agent will not be able to write later:

doctl agent exec anish-claude-code-test -- sh -c '
  git clone --depth 1 \
    https://github.com/anishsingh20/serverless-inference-tail-latency-study.git \
    /workspace/serverless-inference-tail-latency-study
  chown -R agent:agent /workspace/serverless-inference-tail-latency-study
  git -C /workspace/serverless-inference-tail-latency-study log -1 --oneline
'

Cloning into 'serverless-inference-tail-latency-study'...
5ce6d3b Add link to published DigitalOcean tutorial in README

This is Harness Runtime doing its job. The agent has a computer. The repository is on disk. Git works. gh is already logged in as the GitHub account from Step 3. No Action Gateway is involved yet.

If the session pauses, resume it. The workspace stays:

doctl agent resume anish-claude-code-test

Step 7. Turn on Action Gateway and find the GitHub tool

Action Gateway is the second half of Managed Agents Runtime Services. In the console it is the next item under Managed Agents.

Tools is the catalog. Each card is a provider. View tools opens the actions for that provider.

The tools: [do.actions] line in the spec added earlier in Step 4 agents.yaml file attached a gateway endpoint to the session. Let’s confirm it:

doctl agent exec anish-claude-code-test -- cat /workspace/mcp-config.json

{
  "mcpServers": {
    "do_actions": {
      "type": "http",
      "url": "http://trusted-actions.vpc-endpoint.internal.digitalocean.com/mcp/session/<SESSION_ID>"
    }
  }
}

The URL is internal to DigitalOcean. Traffic from this sandbox stays on the DigitalOcean network. There is no bearer token in the file.

The gateway does not dump a catalog into the model. It exposes three tools: action_search, action_invoke, and action_code. Let’s search for GitHub pull request tools first:

doctl agent exec anish-claude-code-test -- sh -c '
URL=$(echo "$HARNESS_MCP_SERVERS" | base64 -d \
  | sed -n "s/.*\"url\":\"\\([^\"]*\\)\".*/\\1/p")
curl -sS -X POST "$URL" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d "{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\"params\":{
        \"name\":\"action_search\",
        \"arguments\":{\"queries\":[
          {\"use_case\":\"create a GitHub pull request and merge it\"}
        ],\"limit\":5,\"providers\":[\"github\"]}}}"
'

github_create_pull_request     score=31.67
github_get_pull_request        score=28.09
github_get_pr_review           score=26.88
github_list_pr_commits         score=26.78
github_list_pr_reviews         score=26.78

providers: ["github"] keeps the list on GitHub. The top result, github_create_pull_request, is the tool for opening a PR through the gateway.

You can browse the same catalog in the console. Open Action Gateway → Tools, type github, and click View tools.

Step 8. Call the GitHub tool. The first call asks you to connect

doctl agent exec anish-claude-code-test -- sh -c '
URL=$(echo "$HARNESS_MCP_SERVERS" | base64 -d \
  | sed -n "s/.*\"url\":\"\\([^\"]*\\)\".*/\\1/p")
curl -sS -X POST "$URL" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d "{\"jsonrpc\":\"2.0\",\"id\":4,\"method\":\"tools/call\",\"params\":{
        \"name\":\"action_invoke\",
        \"arguments\":{
          \"rationale\":\"Confirm the study repository is visible to GitHub tools\",
          \"tools\":[{\"tool\":\"github_search_repositories\",\"arguments\":{
            \"q\":\"repo:anishsingh20/serverless-inference-tail-latency-study\",
            \"max_results\":1}}]}}}"
'

The first call does not search GitHub yet. It asks you to connect GitHub for Action Gateway. That grant is separate from the doctl agent auth github grant in Step 3. Step 3 is for git clone, git push, and gh inside the sandbox.

Step 8 is for GitHub API tools on the gateway.

{
  "total_count": 1,
  "success_count": 0,
  "error_count": 1,
  "results": [
    {
      "tool": "github_search_repositories",
      "result": {
        "status": "failed",
        "error": {
          "class": "unauthorized",
          "message": "Tool \"github_search_repositories\" requires an OAuth connection for provider \"github\" ... Open https://cloud.digitalocean.com/security/connectlinks/confirm?token=<CONNECT_TOKEN>&region=nyc3 to authorize.",
          "retriable": true,
          "recovery_hint": "refresh_auth"
        }
      }
    }
  ]
}

You can finish that sign-in from the console as well. Open Action Gateway → Connections, then Add connection, and pick GitHub. Connections are shared with the team. That is the page the recovery link is sending you to.

Three things to notice here.

1. The spec still has no GitHub API token. The sandbox still has no GitHub API token for this path. The gateway is asking a person to sign in.

2. The error is labeled. class is unauthorized. retriable is true. recovery_hint is refresh_auth. An agent can read those fields and send you the link, instead of guessing at a bare 401.

3. The verification code is there so you confirm the page matches the request. Treat the connect token and the code as secrets. Do not paste them into tickets or chat.

Let’s open the link, match the code, finish GitHub authorization, then run the same action_invoke again. After that, the gateway attaches the credential at execution time and returns repository results.

This walkthrough continued without waiting on that second OAuth. Harness Runtime already had GitHub through Step 3, so the agent could still open and merge a pull request with git and gh. That is the next step.

Step 9. Chat with the agent to open and merge a pull request

This is the step that was missing if you only wired tools. Attach to the session and ask it to do the work.

doctl agent attach anish-claude-code-test

Then send this prompt from the terminal:

Work in /workspace/serverless-inference-tail-latency-study.

1. Use Action Gateway action_search to find GitHub pull request tools.
2. Create a branch named docs/action-gateway-walkthrough from main.
3. Add only ACTION_GATEWAY_WALKTHROUGH.md, a short note that this session verified Harness Runtime and Action Gateway.
4. Commit, push, open a pull request into main titled "Add Action Gateway walkthrough note".
5. Merge the pull request. Squash is fine.
6. Reply with the PR URL, whether it is merged, and the merge commit.

If the agent pauses on an approval, type y in the attach session. Commands that are not git *, gh *, or mcp still use the ask default.

On 2 September 2026 the agent did this:

1. Called Action Gateway action_search and got github_create_pull_request back. The gateway was attached and answering.
2. Created the branch docs/action-gateway-walkthrough.
3. Wrote ACTION_GATEWAY_WALKTHROUGH.md.
4. Committed, pushed, and opened pull request #1.
5. Merged it. Merge commit 66be5f1481e0ca0cf6bd338ff562d8a8e29af186. State MERGED.

Let’s replay the same run from the CLI to confirm the pull request was merged:

doctl agent logs anish-claude-code-test

All steps completed successfully.
PR URL:  https://github.com/anishsingh20/serverless-inference-tail-latency-study/pull/1
Merged:  Yes
Merge commit:  66be5f1481e0ca0cf6bd338ff562d8a8e29af186
Who created the PR:  gh

gh pr view 1 -R anishsingh20/serverless-inference-tail-latency-study \
  --json url,state,title,mergedAt,mergeCommit

state   MERGED
title   Add Action Gateway walkthrough note
url     https://github.com/anishsingh20/serverless-inference-tail-latency-study/pull/1

That is the full loop. Action Gateway found the GitHub tools and asked for its own connection. Harness Runtime already had GitHub, so the agent finished the pull request. You can click the PR URL to view it.

Step 10. Pause the session

Sessions pause when idle. Pause on purpose when you are done:

doctl agent pause anish-claude-code-test

✓ Session <SESSION_ID> paused

Resume later with doctl agent resume anish-claude-code-test. The workspace is still there.

Harness Runtime is the machine. Use it whenever the work is files, a shell, and git. Action Gateway is how that machine talks to the rest of your stack without holding the keys. Reach for the Action Gateway as soon as the agent has to act in another product.

Action Gateway is the default once the demo has to become a product. The coding agent in this walkthrough already needed two halves: Harness Runtime to hold the repo, and Action Gateway to find the GitHub tools without a token in the spec. Add Jira, a database, or a second user, and the gateway is the piece that scales. You configure the tools once. Every session after that searches and invokes, instead of growing a new integration for each vendor.

Skip Action Gateway only when the job is local. If the agent never leaves /workspace, the sandbox is enough.

The moment it has to act on GitHub, Jira, Slack, Stripe, or your database, use the Action Gateway. That is the point of Managed Agents Runtime Services: the machine and the keys are separate products, on the same account.

1. What is Action Gateway?

Action Gateway is DigitalOcean’s managed service for giving an AI agent access to tools, APIs, and SaaS systems. You choose the tools, connect credentials, and set permissions. The gateway exposes that setup through one MCP endpoint. The agent searches for the right tool and runs it. You do not wire each vendor into the agent yourself.

2. Can Action Gateway help reduce my token cost?

Yes. Agent workflows can become expensive when tool calls fail, return noisy outputs, trigger retries, or require extra model turns to recover. Action Gateway helps reduce that waste by improving tool calling before, during, and after execution: tool search helps choose approved actions without loading every tool into context, validation and repair reduce malformed calls, automatic retries and timeouts are bounded to prevent runaway execution, and result compression limits unnecessary data returned to the model. Action Gateway also records cost and usage context across workflows so teams can see which tools, retries, and artifacts are driving spend.

3. Can I register my own MCP server and tools to Action Gateway?

Yes. You can register MCP-compatible servers and tools through Action Gateway. Action Gateway imports the tool definitions exposed by the MCP server and can route approved calls through the gateway. DigitalOcean governs calls, not whatever a customer-owned MCP server does internally. For customer-owned tools, Action Gateway controls policy, dispatch, trace, retries where configured, and action records. The customer-owned MCP server still controls its own logic, outputs, side effects, compliance posture, and tool annotations unless the tool is routed through a trusted DigitalOcean-controlled execution path.

4. How is Action Gateway different from the tools already inside the sandbox?

Harness Runtime already gives the agent a shell, a filesystem, and git. Those tools live on the machine. You govern them with the permissions block in the spec. Action Gateway is for work outside that machine: GitHub issues, Jira tickets, Slack messages, a database query. Credentials, retries, and the shape of a failure are handled on the gateway, not in your YAML.

5. What does Action Gateway cost?

Action Gateway surfaces with direct infrastructure or provider cost, such as Code Interpreter compute and Web Search, Web Fetch, Browser Automation are metered separately. DigitalOcean Inference and Managed Agents follow their own pricing.

Tool Calls:

• GA: $0.299 per 1,000 non-native calls

Code Interpreter Tool:

• $0.05/vCPU-hour on CPU-optimized DigitalOcean compute, $0.015/GB Memory

Browser Automation Tool:

• $0.09/vCPU-hour on CPU-optimized DigitalOcean compute, $0.020/GB Memory

Web Search Tool:

• $7.00/1K requests

Web Fetch Tool:

• $3.00/1K requests

Note: The prices are dynamic and may change based on usage. Once Action Gateway is generally available, the prices will be published.

6. How does Action Gateway handle secrets?

Credentials never enter the model context. This is the biggest differentiator. Not redacted. Never there. The agent requests the action, the gateway executes it.

You connect an API key, a shared OAuth app, or per-user OAuth. The gateway attaches the credential when the call runs. Tokens do not land in the agent or the sandbox. When a user must sign in mid-call, the gateway returns a link and a verification code, then continues after they finish.

Credentials resolve at execution time and exist only for a single call before being discarded. Tokens never reach the agent, the sandbox, or the end user, and refresh tokens stay locked in the DigitalOcean Secrets Manager. Every call requests only the scopes it needs, bounded by a maximum you set per connection. There’s no credential cache, so rotations and revocations take effect on the very next call with no stale window, and unreachable secrets fail closed rather than falling back. Every access is audited by reference, never by value.

7. Can I use Action Gateway with Claude Code, Codex, or Cursor?

Yes. Any agent that speaks MCP can call the gateway. First-class support includes Claude Code, Codex, and Cursor. This tutorial used Claude Code on DigitalOcean Serverless Inference.

8. How is this different from a SaaS connector catalog?

A catalog tells the agent which apps exist. Action Gateway decides whether a call should run, keeps the credential off the agent, and returns a failure the agent can recover from. That matters when one workflow crosses GitHub and another system. Breadth of apps is the catalog’s strength. Completing the workflow is the gateway’s job.

Basically, connector catalogs expose what an agent can call. Action Gateway helps agents call the right tools correctly and turn those calls into governed and reliable production actions. The gateway increases tool calling efficiency by managing context bloat and providing optimized tool search resulting in lower costs and lower failures.

This tutorial showed how to use Action Gateway to give an agent access to GitHub tools without putting the token in the spec. You can use the same pattern to give an agent access to Jira, Notion, Linear, Postgres, Slack, Stripe, and any other SaaS system. Managed Agents Runtime Services is a powerful way to scale your agent workflows across multiple systems and Action Gateway helps your agents use approved tools in a managed way.

It secures access to 1,000+ tool integrations through a single endpoint, so teams ship production workflows with lower cost, fewer failures, and no infrastructure to manage.

Sources

• Salman Paracha(SVP, Engineering), Private Preview: DigitalOcean Managed Agents Runtime Services, DigitalOcean, 25 August 2026.
• Private Preview: DigitalOcean Managed Agents Runtime Services on X, DigitalOcean, 1 September 2026.
• Alex Salazar, We saw the action layer coming. Now we’re going to own it, Arcade.dev, 12 June 2026.
• Live session anish-claude-code-test, 2 September 2026: doctl 1.168.0-beta, Claude Code on mv-2vcpu-4gb, DigitalOcean-hosted inference. Merged PR #1. Tokens and connect codes redacted.
• doctl beta releases, Inference documentation, inference pricing, coding agents guide, doctl reference.