Keep the approval boundary open and self-hosted

ActionProxy Community is the inspectable execution-governance layer for developers who want policy, human review, controlled dispatch, and audit evidence around AI agent tool calls.

View on GitHubFollow the quickstart

01Agent call

02Policy + review

03Bound execution

Why open source

Inspect the checkpoint that decides what may execute

ActionProxy Community sits between a supported agent adapter and tool execution. It normalizes a proposed action, evaluates deterministic YAML policy, and returns allow, deny, or require approval before the call crosses a controlled execution boundary.

The Community source is prepared under the Apache License 2.0. The v0.1 release is a developer preview for local and self-hosted evaluation rather than a complete production authorization boundary.

A focused gateway, not another agent platform

Community keeps the security-sensitive control path visible while leaving model choice, orchestration, and business-tool credentials with the systems that already own them.

Decide with policy

Route a proposed tool call to allow, deny, or human approval with deterministic YAML rules.

Review the exact action

Bind authorization to the action, input, policy, reviewer requirements, nonce, and expiry; supported single-reviewer flows can re-evaluate edited input.

Control dispatch

Use a local executor boundary for deterministic demos or an expiring, one-use grant for an external runner.

Inspect the evidence

Correlate proposals, decisions, approvals, receipts, attempts, reported outcomes, and a limited, locally verifiable audit chain.

One lifecycle from proposal to outcome

An agent, SDK client, or MCP adapter proposes a named tool call with structured arguments.
ActionProxy normalizes supported context and evaluates the active YAML policy.
Allowed calls approach controlled execution, denied calls stop, and approval-required calls enter the review queue.
An eligible reviewer approves, rejects, or uses the supported single-reviewer edit flow.
Current authorization is checked before a local executor or external runner dispatches the call.
The resulting attempt and reported outcome join the action's receipt and audit evidence.

Bring the boundary to the tool path you already use

HTTP and JavaScript

Submit through the canonical HTTP boundary directly or use the JavaScript SDK and external-runner helper.

Downstream MCP

Put the authenticated stdio wrapper in front of a configured downstream MCP server and gate tools/call before forwarding.

Streamable HTTP MCP

Enable the partial OAuth-protected MCP resource for the canonical lifecycle; the current slice advertises governed mock tools and requires an external authorization server.

Your own runner

Keep provider credentials in an internal runner, consume the exact one-use grant, perform the call, and report its outcome.

What the Community surface includes

A local web queue with optional Slack, Telegram, and email notifications; notification delivery does not grant authorization.
Memory, SQLite, and Postgres storage behind shared interfaces, with explicit durability and contention limitations.
Service-account API-key or OIDC JWT modes for self-hosted evaluation, while disabled authentication remains local-demo only.
A bounded MCP tool-discovery doctor and source-aware consequence controls without claiming prompt-injection prevention.
Real-tool handoff through external runners or downstream MCP servers instead of bundled production connector credentials.

Continue exploring