Releases: selfradiance/ActionProof
ActionProof v0.2.0 — Form Submit Intent Gate
ActionProof v0.2.0
ActionProof v0.2.0 adds a second narrow proof surface: form_submit.
The original v0.1 surface, send_email, remains supported and unchanged. The new form_submit path evaluates a JSON description of a proposed browser-agent form submission before execution and returns a deterministic allow or deny decision with a rule trace.
This release does not control a browser, intercept live browser activity, execute form submissions, verify human identity, verify signatures, or enforce decisions against an agent runtime. It evaluates intent JSON only.
Added
form_submitrequest type- Discriminated request schema for
send_emailandform_submit formSubmitpolicy section- Deterministic rule trace for form submission decisions
- Structural
approvalAssertedobject for declared human approval - Fixtures for allowed and denied form-submit cases
- Tests for missing approval, malformed approval, blocked domains, unlisted domains, blocked field names, unsupported methods, and deterministic first-failure behavior
DECISIONS.mddocumenting v0.2 scope decisions
Validation
npm testpassednpm run typecheckpassednpm run buildpassed
Boundary
ActionProof remains a local deterministic pre-execution gate. No network calls, LLM decisions, browser automation, MCP, AgentGate, signature verification, or runtime enforcement were added.
v0.1.0 — Deterministic Pre-Execution Gate for a Credentialed Tool Request
ActionProof v0.1.0 is the first narrow public release.
What it does:
- evaluates one credentialed, side-effecting tool request before execution
- stays locked to a single proof surface:
send_email - validates request JSON and policy JSON with Zod
- applies deterministic rule-based evaluation in a fixed order
- returns exact decision codes and human-readable reasons
- writes a machine-readable JSON decision artifact
Current scope:
- local CLI only
- TypeScript / Node.js 20+
- Vitest
- no database
- no network calls in product behavior
- no real Gmail integration
- no GitHub API integration
- no MCP
- no AgentGate integration
- no sandboxing
- no LLM in the critical path
What it proves:
A credentialed, side-effecting tool request can be evaluated before execution by explicit machine-readable rules, with a narrow and inspectable allow/deny decision.
Important limits:
- this is not DLP
- this is not broad policy orchestration
- this does not secure all tools
- this does not execute the action; it only decides whether the request should be allowed
Included in v0.1.0:
- request schema
- policy schema
- deterministic evaluator
- CLI entrypoint
- readable terminal output
- machine-readable JSON artifact
- sample allow/deny fixtures
- Vitest coverage for clear allow and deny paths
Verification at release:
- npm test passed
- npm run typecheck passed
- npm run build passed
- CLI smoke-tested on one allow path and one deny path