How to Configure Server-Side Approvalpublic

Last verified 21 Sep 2026

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 for example use cases of Action Gateway with Harness Runtime.

Action Gateway can require human approval before a tool executes. Configure ask in the session’s policy, then use a client that can complete the approval flow. The gateway enforces the decision across clients using that session.

Prerequisites

  • An Action Gateway session with the intended actor and selected tools.
  • A client that supports MCP elicitation or can display a returned approval request for a person to resolve.
  • A DigitalOcean personal access token for the user who owns the session, in the same team, if handling approvals through the HTTP endpoint.

Require Approval in the Session Policy

When creating the session, set Default Action to Ask to require approval for otherwise unmatched invocation calls. Alternatively, set a tool’s Action to ask while allowing routine tools explicitly.

The gateway accepts allow, ask, and deny. Use deny for calls that must never run; an approval cannot override a deny rule. Allow the required meta tools separately when the session uses a restrictive default. See Tool Policies.

Approve Through MCP Elicitation

A client that supports MCP elicitation can display an approval request while the tool call waits. Review the tool, its arguments, and the account it affects. Approving lets that call continue; denying prevents it from running.

If the client cannot complete elicitation, or the inline wait ends, the gateway returns information for a separate approval flow. Restarting a client does not add elicitation support.

Resolve a Separate Approval Request

An out-of-band approval result includes an approval_id, an expiry, and a decide hint. A person must review and submit the decision using a token for the session’s owning DigitalOcean user and team. The agent should not approve its own requested action.

Use the hostname from the session’s returned MCP URL and the decision path supplied in the result. Replace <gateway-origin>, <approval-id>, and <session-id> with those values. Keep the token in the DIGITALOCEAN_TOKEN environment variable, not in the command text:

curl --request POST "<gateway-origin>/approvals/<approval-id>" \
  --header "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  --header "X-Session-Id: <session-id>" \
  --header "Content-Type: application/json" \
  --data '{"decision":"approve"}'

To reject the request, send deny instead of approve. After approval, have the client invoke the same tool with the same arguments. Approval is bound to the team, session, tool version, and arguments, and is consumed once. It does not authorize later unrelated calls.

Follow the expiry in the result. For an expired request, invoke the tool again to obtain a fresh approval request rather than resubmitting a decision for the expired one.

Keep Provider Authorization Separate

A tool may also need an actor connection. The gateway resolves tool approval before asking for missing provider authorization. Approving a call does not create a connection or grant provider scopes.

Setting a policy to allow removes the gateway approval requirement for matching calls. It does not ensure that your client prompts instead; configure and verify any client-side approval behavior separately.

We can't find any results for your search.

Try using different keywords or simplifying your search terms.