Stop AI Agents From Moving Money Without Proof.
If the agent cannot prove authority, the payment does not execute.
When an AI agent tries to pay an invoice, ExecutionProof™ verifies the agent’s identity, authority, invoice evidence, vendor approval, amount limits, and current policy — returning ALLOW / HOLD / DENY before Stripe or any payment rail is ever called.
ExecutionProof is an independent pre-execution governance layer for consequential AI actions. Payment authorization is our first deployment boundary; the same architecture can govern deployments, access changes, data release, infrastructure commands, and other irreversible actions.
We do not process payments and we are not replacing Stripe. We sit before the rail and determine whether the exact agent action is authorized, evidenced, and within policy. The payment rail executes only after ExecutionProof returns ALLOW - a downstream partner, not a competitor.
See It Work
An AI Agent Tries to Pay $50,000. The Gate Says HOLD.
How ExecutionProof governs an AI-agent vendor payment: verify identity, authority, invoice, vendor, and limits before the payment rail is called.
Walkthrough with example data. No live funds are moved.
Agent Submits Payment
An AI payment agent requests a $50,000 vendor payment. Before the payment rail is called, the agent's request is routed to the ExecutionProof gate.
Verify → HOLD
The gate checks: Is the agent registered? Is it authorized for payments? Does the invoice exist and is it approved? Does the vendor match? Is $50,000 within the agent's delegated limit? The amount exceeds the $10,000 autonomous limit — decision: HOLD.
Self-Approval Blocked
The agent attempts to approve its own held payment. The gate rejects it. The entity that initiates an action cannot approve that action — enforced at the gate, not by policy.
Human Approval Required
The boundary requires two independent approvals before release. The payment stays on HOLD until valid approval evidence is supplied by two distinct authorized approvers — each decision recorded independently, self-approval blocked. Notification and approval routing are configured per pilot deployment.
Re-Verify → ALLOW
After human approval, the gate re-verifies all checks — agent authority, invoice, vendor, amount, and execution state — before releasing. Only then does the decision become ALLOW and the payment rail is called.
Signed ProofRecord
A tamper-evident ProofRecord captures the full chain: agent identity, HOLD decision, blocked self-approval, both human approvals, re-verification, and the final ALLOW. Audit-ready from the moment the payment executes.
How It Works
One Gate. Every Payment Request.
Every AI-agent payment request passes through the Governance Gate. The decision and proof are recorded before the payment rail is called.
Proof of Verification
Every Payment Decision Creates a ProofRecord™
A tamper-evident record of the agent, authority, evidence, vendor, limits, and decision — generated before the payment executes, not after.
Internally represented as an Execution Verification Record (EVR).
The public ProofRecords shown here are demonstration records intended to illustrate structure and flow. Production deployments use stronger cryptographic signing.
The core ExecutionProof gate is live and pilot-ready. The verification API returns ALLOW, HOLD, and DENY decisions and issues a signed ProofRecord for each decision. The current pilot build supports governed HOLD resolution, independent (M-of-N) approval, re-verification before release, inline execution control, and ProofRecord generation — operational today.
Every ProofRecord is signed with hardware-backed ML-DSA-65 (FIPS 204 post-quantum) via AWS KMS — the private key never leaves the HSM. Records also carry dual HMAC integrity bindings (SHA-256 classical + SHA3-512 quantum-resilient), both of which must verify, and are written to a hash-linked, append-only proof chain where each record carries the hash of the record before it, so tampering is detectable end-to-end. Anchoring proofs to an external public ledger remains on the roadmap.
Our first design-partner pilots target a single, concrete milestone: placing the ExecutionProof gate in front of one live AI-agent payment workflow, so no agent payment clears without a signed ProofRecord. We are onboarding a small number of fintechs, enterprise finance teams, and payment-automation companies now — discovery calls and platform walkthroughs are open.
Request a Pilot
The core verification API and Boundary Console are live and pilot-ready. We are recruiting a small group of design partners to govern one high-impact action end to end: intercept, verify, honor the decision, and issue a signed ProofRecord.
- Start with one workflow and one execution boundary.
- Live ALLOW / HOLD / DENY decisions with M-of-N HOLD resolution.
- Direct access to the founder and architecture team.
Built for CFOs, controllers, treasurers, AP leaders, fintechs, and payment automation teams where AI agents are starting to move money — and the authorization gap is real.
How to Get Started
Your Path to Proof-Gated Payment Execution
Start with one AI-agent payment flow, one approval threshold, one execution boundary.
Walk us through your AI-agent payment flows.
Define which agent payments need governance.
Govern one payment type. Prove the gate.
Extend governance across agent-initiated payments.
Payment authorization is our first deployment boundary - not our only one. The same governance gate applies, unchanged, to deployments, access changes, data release, and infrastructure commands - one architecture for any irreversible action where an autonomous agent must prove it is authorized before it executes. ExecutionProof governs the action; the payment rail simply executes it once we return ALLOW.
Remnant Fieldworks also conducts research into the quality of evidence that reaches consequential systems. CIF-LAAD, the Coherent Inheritance Framework for Low-Altitude Air Domain Awareness, is a simulation-stage research program studying continuity, uncertainty, false-track suppression, and evidence provenance when observations degrade or conflict.
CIF-LAAD and ExecutionProof answer different questions. CIF-LAAD research asks what evidence or state deserves trust. ExecutionProof asks whether a proposed action is authorized to execute.
Read the research at Remnant FieldworksCore verification API live and pilot-ready. Integrations available through controlled design-partner pilots. Patent applications pending.