For AI agents: The documentation index is at https://docs.digitalocean.com/llms.txt. Markdown versions of pages use the same URL with index.html.md in place of the HTML page (for example, append index.html.md to the directory path instead of opening the HTML document).

Action Gateway can require human approval before a tool executes. Configure ask in the endpoint version’s policy, then use a client that can complete the approval flow.

Prerequisites

• An Action Gateway endpoint 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 endpoint, in the same team, if handling approvals through the HTTP endpoint.

Require Approval in the Endpoint Policy

When configuring the endpoint version, 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 version 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 endpoint’s owning DigitalOcean user and team. The agent should not approve its own requested action.

For a request through an endpoint URL, use its returned MCP URL hostname and the decision path supplied in the result. Replace <gateway-origin>, <approval-id>, and <endpoint-id> with the gateway origin, approval ID, and endpoint UUID. 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-Endpoint-Id: <endpoint-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, endpoint scope, tool version, and arguments, and is consumed once. It does not authorize later unrelated calls. Endpoint-scoped grants persist across endpoint versions, while pinned-version grants are scoped to that version. The current policy still applies.

For a pinned-version or legacy session request, use the original request’s session UUID in X-Session-Id instead. Do not put the composite endpoint version ID in X-Session-Id. A decision that sends both target headers returns 400. The X-Actor-Id header is optional; if you send it, it must equal the endpoint’s or session’s actor ID, or the decision returns 403. See Choose the Target with Request Headers. Follow the returned decision hint and retain the original request’s scope.

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.