Security starts with the exact action

ActionProxy narrows authorization to a concrete tool call, revalidates the decision before dispatch, and records correlatable evidence without presenting a developer preview as a compliance product.

Read the security policyRead the exact-action guide

01Identity

02Exact authority

03Audit boundary

Enforcement boundary

Ask whether this payload may run now

ActionProxy's security model is built around an inspectable action rather than broad trust in an agent. Supported canonical paths normalize the tool call and sourced context before deterministic policy chooses allow, deny, or require approval.

A human decision is not a bypass. Approval authorization binds the current tenant, requester, action and input hashes, policy, review requirements, nonce, and expiry before execution may proceed.

Four control layers in one lifecycle

Trusted request boundary

Canonical HTTP, SDK over HTTP, authenticated stdio MCP, and opt-in HTTP MCP normalize supported policy context at the server boundary.

Deterministic decision

YAML rules return allow, deny, or require approval and fail closed when the canonical policy provider fails.

Bound authorization

Approval and execution authority carry exact action, policy, reviewer, attempt, executor, expiry, and nonce identities.

Correlatable evidence

Proposal, policy, approval, receipt or grant, attempt, and reported outcome records can be followed through local storage and audit views.

Identity and review controls

Self-hosted deployments can use hashed service-account API keys or OIDC JWTs with explicit scopes; disabled authentication is local-demo only.
Supported transport, tenant, actor, adapter, protocol, and environment context is derived from authenticated server or session state, while caller-supplied agent identity remains asserted.
Eligible reviewers can approve or reject; supported single-reviewer edits preserve original and approved identities and trigger policy re-evaluation.
Multi-reviewer approvals reject edited payloads because votes cannot safely span different payload versions in the current model.
Slack, Telegram, and email notifications do not authorize execution by delivery alone; the local web queue remains canonical.

Execution is a separate authorization step

Local demo closures require a current, one-use process-local execution authorization before invocation.
External runners consume a signed, expiring, one-use grant bound to the approved action and current lifecycle state before dispatch.
The external runner owns provider credentials and reports the downstream outcome; ActionProxy does not claim that an untrusted runner proves the exact provider bytes.
A timed-out, cancelled, or unknown result is recorded as such and is never treated as permission for automatic retry.
Provider reconciliation, takeover, and explicit retry authorization remain unimplemented.

Audit evidence has a defined integrity boundary

Community storage correlates the proposal, policy decision, approval, receipt or grant, attempt, and reported outcome. Proposed inputs, original and edited approval payloads, and execution results remain in raw storage; response redaction does not remove them from JSONL, SQLite, Postgres, volumes, or backups.

A local SHA-256 previous-hash chain can detect ordinary breaks when verified against the stored sequence.

The chain is not keyed or independently anchored. An administrator with storage access can rewrite events and recompute it, cross-process append serialization is not claimed, and evidence minimization and formal retention remain incomplete. Protect JSONL, SQLite, Postgres, volumes, and backups as sensitive data.

MCP support is explicit about trust

Stdio wrapper

The wrapper gates configured downstream tools, but profile commands run with the server process's operating-system privileges and are not sandboxed.

Streamable HTTP MCP

The opt-in resource uses OAuth-protected sessions but depends on an external authorization server and currently exposes governed mock tools.

Credential ownership

Production-shaped Community integrations keep real provider credentials in downstream MCP servers or external runners.

Content consequences

Verified transport scopes can narrow later actions after classified content is released; this does not detect prompt injection or grant instruction authority.

Continue exploring