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.
For agents that act on business data
v0.1 developer preview · local and self-hosted evaluation
Approve sensitive AI actions before they reach your tools.
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.
Local demoSimulated effects
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.
Bring one tool call
Get your first workflow connected.
Already have an agent that needs to change a ticket, update a record, or send a reply? Tell us which action needs review and whether you use an MCP server or your own code. We can help you choose a starting path.
Ask for integration help on GitHub
GitHub issues are public. A tool name and a brief setup description are enough.
Start with the complete local-file recipe →Proposal to reported outcome
Keep policy, approval, execution, and evidence in one lifecycle.
- 01
Normalize the proposed call
Supported adapters turn a concrete tool name, input, and trusted server context into one action request before policy runs.
- 02
Return one policy decision
Explicit rules choose allow, require approval, or deny. Human review stays selective instead of becoming a button on every call.
- 03
Review the exact action
Approval binds to the action and input hashes, policy, reviewer requirements, nonce, and expiry—not to a prose summary.
- 04
Authorize dispatch and record the result
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 the execution boundary, not just the approval button.
Review seven documented approval, authorization, MCP, tool-runtime, and intervention products by use case, operating scope, and evidence date.
Compare AI agent approval tools →Choose the operating path
Start with inspectable software you can run yourself.
The narrow boundary
Govern the exact action, not the conversation around it.
Deterministic policy
Return allow, deny, or require approval from explicit rules over a normalized tool call and trusted context.
Bound human review
Connect the reviewer’s decision to the payload, policy, eligibility requirements, nonce, and expiry.
Correlatable evidence
Follow the proposal through decision, review, dispatch attempt, and reported outcome without overstating what logs prove.
Use the boundary you need
Add governance without replacing the agent stack.
Submit canonical tool calls
Send supported calls to POST /v1/tool-calls and keep route validation separate from the lifecycle service.
Gate calls from application code
Use the HTTP client and gated-tool helper without moving policy, approval authorization, or audit logic into the agent loop.
Inspect Community →Govern configured MCP tool calls
Use the authenticated stdio wrapper or the opt-in Streamable HTTP resource on their documented, bounded paths.
Read the MCP approval guide →Keep provider credentials outside the gateway
Let an existing runner consume one signed, expiring grant and report the downstream outcome without creating another policy path.
Follow the evidence path →Start here
Practical guides for the execution boundary
AI Agent Approval Gateways: A Practical Architecture Guide
Learn where an AI agent approval gateway belongs, what it should bind and record, and when human review helps more than blanket approval.
Read guide →
MCP Tool Call Approval: A Practical Execution Boundary
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 →
AI Agent Email Approval Before Send
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
What an approval gateway controls—and what it does not.
What is an AI agent approval gateway?
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.
Should every AI agent action require approval?
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.
Can ActionProxy govern MCP tool calls?
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.
What happens after a reviewer approves a call?
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.
Can a reviewer edit a proposed tool call?
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.
Is the ActionProxy audit trail immutable?
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.
Does Community include production SaaS connectors?
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
Built for local and self-hosted evaluation, with limits stated plainly.
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.