ActionProxy

mcp governance

MCP tool call approval that governs the action, not just the prompt

MCP defines how clients discover and invoke tools while leaving the review experience to the implementation. Put the approval boundary after the client has produced a concrete tool name and arguments, but before anything executes. Preserve the proposal, apply policy, bind the decision to that action, and record what happened after dispatch.

For
Developers and security-minded platform teams operating MCP clients or servers that can cause business side effects.
Reviewed
Jul 14, 2026
Length
1,184 words
A guarded tool-call path flowing from an MCP client through a review checkpoint to a downstream service

MCP gives you a tool call, not a complete review system

In MCP, a client discovers tools with tools/list and invokes one with tools/call, passing a tool name and arguments. The specification deliberately leaves the user interaction model to the implementation. It recommends that applications show exposed tools, make invocations visible, and ask for confirmation on sensitive operations. That is useful guidance, but the protocol message by itself does not decide who may approve, how long a decision remains valid, or whether the executed payload still matches the reviewed payload.

Confirmation is only useful if it controls execution

Once a tool can send mail, update a CRM record, move money, or delete data, a confirmation dialog is only the start. The application still needs to ensure that the reviewed tool name and arguments are the ones that reach the executor. That is an architecture choice rather than a behavior supplied by MCP itself.

What the boundary should answer

  • Which verified or server-derived tenant and actor proposed this call, which adapter context came from transport, and which agent label remains asserted?
  • What exact tool name and normalized argument payload did policy evaluate?
  • Did policy allow, deny, or require approval, and which policy version produced that result?
  • If review was required, who decided, what did they review, and did the decision expire?
  • Did the executor receive authority for this call only, and was that authority consumed once?
  • Was the call dispatched, and did it succeed, fail, time out, get cancelled, or end with an unknown outcome?

Two MCP shapes in ActionProxy Community

The authenticated stdio wrapper is the practical path for governing a configured downstream MCP server. It discovers that server's tools, intercepts tools/call, submits the proposed call through ActionProxy, consumes the exact execution grant after authorization, forwards the approved call, and reports the outcome. The downstream command runs with the ActionProxy server process's operating-system privileges; ActionProxy does not sandbox it. Operators should configure only MCP profiles they trust.

The separate Streamable HTTP /mcp adapter is opt-in and supports the canonical lifecycle behind OAuth-protected sessions. ActionProxy is the resource server, not the authorization server, so deployment requires an external OAuth service to handle login, consent, authorization code with PKCE, client identification, and token issuance. Today that HTTP endpoint advertises bundled governed mock tools, not native production SaaS connectors.

For real business-tool effects in Community, use a configured downstream MCP server or an external runner that owns provider credentials. The built-in registry remains a deterministic demo surface. Native production connector runtimes and OAuth credential custody are not included in the Community export.

A governed MCP call, step by step

  1. The MCP client emits a concrete tools/call request. Treat descriptions and tool annotations as useful metadata, not as trusted authorization facts.
  2. The adapter derives transport identity and normalizes policy-relevant context with the tool name and arguments. Caller text cannot override verified tenant, actor, protocol, or executor authority.
  3. Deterministic policy returns allow, deny, or require approval. A deny stops before the downstream executor; an allow still crosses the controlled execution boundary.
  4. For a pending call, the reviewer sees the proposed action. The approval record binds the request, input, decision, policy, reviewer eligibility, nonce, and expiry.
  5. Immediately before dispatch, ActionProxy revalidates the current state. A one-use authorization or signed external grant is consumed for the bound attempt.
  6. On the stdio-wrapper path, the configured downstream MCP server performs the call and the wrapper reports its outcome.
  7. On /mcp, the current governed mock registry performs the demonstration call; this endpoint does not forward to production SaaS connectors.
  8. In either supported shape, proposal, policy, approval, attempt, and outcome remain correlatable in the evidence trail.

Deployment checklist

  • Put approval after argument construction and before downstream dispatch; approving a vague plan is not the same as approving a concrete call.
  • Derive identity and environment from authenticated transport or server configuration rather than accepting them from tool arguments.
  • Show reviewers the destination, resource, consequential fields, policy reason, and whether payload values are redacted in the review channel.
  • Make approval expiry, rejection, cancellation, and changed-policy behavior explicit.
  • Treat downstream commands and credentials as a separate trust boundary; grant only the access that the tool runner needs.
  • Store provider idempotency keys where available, but do not claim retry safety without a provider-specific contract and reconciliation path.
  • Protect audit storage as sensitive data. ActionProxy's local chain can reveal mutation relative to a trusted head, but it is not keyed or independently anchored and stored payload minimization remains incomplete.

Common questions

Questions developers ask

Does MCP include a built-in approval workflow?

MCP defines tool discovery and invocation messages, not one required review interface. Its tools specification recommends human confirmation for sensitive operations. Reviewer identity, policy, decision storage, expiry, and the handoff to execution are choices the application architecture still has to make.

Can ActionProxy govern an existing stdio MCP server?

Yes—put the authenticated Community stdio wrapper in front of a configured downstream server. It discovers tools, gates tools/call, consumes the approved one-use grant, forwards the call, and reports the result. Treat the child command as trusted executable configuration because ActionProxy does not sandbox it.

Does ActionProxy's Streamable HTTP MCP endpoint expose production SaaS tools?

No. The opt-in /mcp endpoint is OAuth-protected, but the tools it advertises today are governed mocks. Use a downstream MCP server or external runner for real business effects; Community does not include native production SaaS connectors.

What should be bound to an MCP approval?

Bind the authenticated tenant and requester, normalized tool name and arguments, decision and policy identity, review requirements, reviewer decision, nonce, and expiry. Dispatch should consume authority tied to that same action and execution attempt, rather than treating a reusable approval ID as broad permission.

Primary sources

External references

  1. Tools — Model Context Protocol specification — Model Context Protocol, reviewed Jul 14, 2026

Continue the path

All guides →