ActionProxy Community
Run the approval boundary locally or self-host it, inspect the policy and lifecycle, and keep real-tool credentials in infrastructure you control.
Open-source approval gateway for AI agent tool calls
v0.1 developer preview · local and self-hosted evaluation
Add policy and human review to your existing agent or MCP setup. Allow routine calls, review selected writes, and keep a record of what happened. Open source and self-hosted.
Start with a local demo. No account or business credentials needed. The guided setup uses macOS, Node.js, and Docker Desktop.
docs.searchAllowAllowed by policy and executed by the local mock.
gmail.send_emailReviewHeld before execution, then approved and executed once.
dangerous.delete_customerDenyDenied by policy and never dispatched.
Deterministic mocks only—no SaaS credentials or provider effects.
We’re planning a hosted option. Tell us which AI actions your team needs to review.
Community support: GitHub issues.
Proposal to reported outcome
Supported adapters turn a concrete tool name, input, and trusted server context into one action request before policy runs.
Explicit rules choose allow, require approval, or deny. Human review stays selective instead of becoming a button on every call.
Approval binds to the action and input hashes, policy, reviewer requirements, nonce, and expiry—not to a prose summary.
Current state and policy are checked again before controlled local execution or an expiring, one-use external-runner grant.
Explore risk-based review, exact-call binding, and the correlated audit trail.
Buyer guide
Compare ActionProxy Community with six documented alternatives by use case, operating scope, and evidence date.
Compare AI agent approval tools →Choose the operating path
Run the approval boundary locally or self-host it, inspect the policy and lifecycle, and keep real-tool credentials in infrastructure you control.
The narrow boundary
Return allow, deny, or require approval from explicit rules over a normalized tool call and trusted context.
Connect the reviewer’s decision to the payload, policy, eligibility requirements, nonce, and expiry.
Follow the proposal through decision, review, dispatch attempt, and reported outcome without overstating what logs prove.
Use the boundary you need
Send supported calls to POST /v1/tool-calls and keep route validation separate from the lifecycle service.
Follow a Node.js example that proposes a file write, waits for human review, and uses the approved input to create the file.
Follow the Node.js example →Use the authenticated stdio wrapper or the opt-in Streamable HTTP resource on their documented, bounded paths.
Read the MCP approval guide →Let an existing runner consume one signed, expiring grant and report the downstream outcome without creating another policy path.
Run the real-file example →Start here
Add human approval to AI agent tool calls. Follow a Node.js file-write example, inspect the execution grant, and adapt the pattern to your own function.
Read guide →Learn where to place human approval in an MCP tool call, what the reviewer should see, and how to bind an approved request to one controlled execution.
Read guide →Design an AI agent email approval flow that reviews the actual message, binds the decision to one send, and records the downstream outcome.
Read guide →Common questions
It is a service at the tool-execution boundary that receives a structured action, applies policy, and returns an allow, deny, or pending-review result before dispatch.
No. Policy can allow routine bounded operations, deny prohibited operations, and reserve human review for actions that need judgment. The boundaries should reflect the application rather than a universal rule. See risk-based human approval for a practical starting point.
Yes, on its documented MCP paths. The authenticated stdio wrapper can gate tools/call for a configured downstream server, while the opt-in Streamable HTTP /mcp resource uses an external OAuth authorization server and currently advertises governed mock tools. The MCP tool-call approval guide explains the boundary.
Approval is evidence for authorization, not a bypass. ActionProxy revalidates current state, policy, and payload bindings before consuming one-use local authority or allowing an external runner to consume a signed, expiring, one-use grant; it then records the attempt and reported outcome. Read approval versus authorization for the layer-by-layer model.
A single authorized reviewer can approve edited input. ActionProxy preserves the original and approved payload identities and re-evaluates policy; edited input is rejected when more than one reviewer is required. The exact-call binding guide covers the integrity model.
No. Community can verify a local SHA-256 previous-hash chain, but the chain is neither keyed nor independently anchored. A storage administrator can rewrite or truncate it and recompute the chain. The audit-trail guide describes what the evidence can and cannot prove.
No ActionProxy-native production SaaS connector ships in Community. An optional example pins third-party workspace-mcp 1.22.0 behind the downstream MCP wrapper for a user-owned Google Workspace and Gmail draft proof. That downstream process owns OAuth, and its Python transitive dependencies remain outside ActionProxy's lock and SBOM. No live Google acceptance is recorded for v0.1.1.
Current project boundary
ActionProxy Community v0.1 is a developer preview for local and self-hosted evaluation, not a complete production authorization boundary or hosted SaaS control plane. Real business-tool effects use an external runner or downstream MCP server; the built-in registry is a deterministic demo surface.