ActionProof

Verifiable authority for safe, auditable agent actions.

Comment

Inspiration

AI agents are becoming increasingly capable of understanding context, making recommendations and calling tools. But there is an important difference between knowing what should happen and having permission to make it happen. ActionProof started from one simple rule:

AI confidence is not authority. A model may be highly confident and multiple sources may support an action. None of those things should automatically create permission for a consequential effect. ActionProof places a deterministic authority boundary between probabilistic AI reasoning and execution.

What it does

ActionProof separates three concepts that are often mixed together in agent systems:

  • Evidence — what was observed or reported
  • Reasoning — what an AI recommends
  • Authority — whether an action is actually permitted Evidence and AI output may influence reasoning, but they cannot create, strengthen or reduce the authority required to act. The jury demo makes that distinction visible. A simulated care-line event produces evidence. A read-only counterfactual shows what a confidence-driven agent would do. ActionProof then attempts the same consequential action through its real MCP path. Without valid authority, the Policy Gate returns NO_PERMIT and no governed effect occurs. The agent may request authority, but it cannot grant authority to itself. A clearly labelled simulated trusted principal can issue a short-lived scoped Grant outside the agent-callable MCP surface. The action can then be retried: Evidence → NO_PERMIT → request authority → scoped Grant → PERMIT → one governed effect ActionProof also supports an optional Amazon Bedrock reasoning adapter. Bedrock can recommend whether a confidence-driven agent would act, but it cannot issue a Grant, create an AuthorizedAction or produce the governed effect. The Alexa+ client experience is explicitly simulated. The self-hosted MCP server, deterministic Policy Gate and Execution Boundary are implemented components. ## How we built it ActionProof is a dependency-light Node.js implementation built around a deliberately small security model: Evidence / AI reasoning → Policy Gate → AuthorizedAction → Execution Boundary → Governed effect The Policy Gate is the only component allowed to construct an AuthorizedAction. A valid action requires appropriate scoped authority from a trusted issuer. Evidence, confidence scores and model output cannot manufacture that authority. The Execution Boundary revalidates authorization before releasing the governed effect. The architecture includes checks for single-use authorization, replay, stale state, expired authority, policy changes and repeated execution. The external-readiness path includes:
  • MCP 2025-11-25 Streamable HTTP
  • public HTTPS deployment
  • OAuth 2.1-style authorization code flow with mandatory PKCE S256
  • service client_credentials
  • scope-separated MCP enforcement
  • OAuth discovery and Protected Resource Metadata
  • deterministic Policy Gate
  • durable Execution Boundary abstraction
  • optional Amazon Bedrock reasoning adapter The public jury demo deliberately separates demo convenience from authority. Public/local security posture is derived from trusted startup configuration rather than request-controlled headers, demo sessions are isolated and expiring, and configured MCP authentication cannot be replaced by a demo-session token. ## Challenges we ran into The hardest challenge was preserving the authority boundary while making the system useful as an agent integration. Adding an AI model creates a tempting shortcut: if the model is sufficiently confident, why not execute? ActionProof deliberately refuses that shortcut. Bedrock is therefore outside the trusted authority boundary and is restricted to read-only reasoning. A second challenge was making one implementation useful both as a simple jury demo and as a production-shaped MCP integration. Streamable HTTP, OAuth metadata, PKCE, scopes, resource binding and public-host security interact in ways that are easy to hide behind a working UI. We therefore made the distinction explicit between implemented MCP/OAuth behavior, the public browser demo, and the simulated Alexa+ client surface. A third challenge was escalation. The agent needs to be able to say “I need authority” without gaining a mechanism for approving itself. Grant issuance therefore remains outside the agent-callable MCP surface. ## Accomplishments that we're proud of The main accomplishment is that the core invariant survives the complete demo flow: No valid authority → no governed execution. Other milestones include:
  • deterministic separation of evidence, reasoning and authority
  • self-hosted MCP 2025-11-25 Streamable HTTP endpoint
  • public HTTPS jury demo
  • OAuth 2.1-style authorization-code flow with mandatory PKCE S256
  • service client_credentials and scope-separated MCP enforcement
  • single-use AuthorizedAction semantics
  • replay, expiry, state and policy revalidation at the execution boundary
  • optional Amazon Bedrock reasoning that remains outside the authority boundary
  • explicit disclosure of what is implemented versus simulated
  • an independent MIT-licensed Authority Boundary Test Kit for testing the same class of authority-boundary failures in other agent systems The open-source toolkit provides 13 adversarial contract checks, including forgery, untrusted issuer, serialization, replay, revocation, expiry, state binding, policy-version changes and evidence/authority separation. ## What we learned The most important lesson is that agent safety cannot depend only on asking a model to behave correctly. Prompt instructions can influence behavior. They are not an authorization mechanism. We also learned that evidence and authority need different semantics. Even highly trustworthy evidence should not silently become permission. Building the MCP integration reinforced another useful principle: an agent can be allowed to propose actions, explain its reasoning and request escalation without being allowed to approve itself. Finally, integration testing needs claim discipline. Source-level regression tests, public deployment behavior and end-to-end client integration are different kinds of evidence. ActionProof reports them separately rather than treating one as proof of the others. ## What's next for ActionProof The next step is moving the reference implementation toward a production-grade authority service. Planned work includes:
  • persistent transactional storage for execution state and Grants
  • production cryptographic verification for trusted issuers
  • a real authenticated human approval adapter
  • durable audit export and tamper-evident records
  • additional MCP clients and agent frameworks
  • more policies and governed action types
  • stronger distributed crash/retry testing The long-term goal is for ActionProof to become a reusable authority layer between capable AI agents and consequential external actions. AI confidence can suggest an action. Only verifiable authority can cause it.

Built With

Share this project:

Updates

Submission history