Agent payment authorization
Bolyra verifies delegated spend mandates before x402/MPP payments and emits signed receipts for audit, disputes, and compliance. The same verifier boundary generalizes to verified agent actions: policy enforcement, signed action receipts, and a tamper-evident audit trail in front of any MCP server or agent platform. Two independent implementations reproduce it in public, from pinned commits.
khandrew1: 27/27 host vectors (v0.5.0) at 17642a5
·
StillOS: 39/39 own corpus at 35e209d
·
draft-kondoju-evc-02
Evidence
Every claim is pinned to the implementation commit it was verified at, and bolyra-suite claims to a vector-set digest as well; each replays from those pins alone. Not our word for it: other people's code, run by anyone.
Host side
An independent EVC host in the mcp-use framework. 27/27 host_behavior vectors, vector set 0.5.0, at pinned commit 17642a5.
Verifier side
An independent verifier. 39/39 of the kit's own pinned corpus reproduces in a network-isolated container at 35e209d. An own-corpus reproduction, not Bolyra-suite conformance.
The contract
The External Verifier Contract, an Internet-Draft on the IETF datatracker, with the mcp-use implementation cited in its implementation status. A draft, not a standard: the document can still change.
Read the draft →The problem
Any agent can attempt any payment. No mandate, no limit, no proof of who authorized it.
Mandate verified before payment. Over-scope fails closed. Every decision, allow and deny, gets a signed receipt.
npx @bolyra/mpp demo
What crosses the wire
issueMandate({
agent: "shopper-bot",
audience: "api.merchant.example",
tier: "small", // < $100
expires: "+1h"
})
One operator signature binds agent, payee audience, spend tier, and expiry into a tamper-evident mandate.
GET /api/report ($25)
→ 200 ALLOW
GET /api/bulk-export ($500)
→ 403 DENY, before payment
{ "code": "request_mismatch",
"title": "Mandate Does Not
Cover This Request" }
Verified before any payment logic runs. Over-scope and missing mandates fail closed with RFC 9457 problem details.
seq=1 allowed=true $25 merchant=api.merchant.example signer=0x688c…2f4e payloadHash=0x7358…7635 // ES256K, hash-chained // verifyReceiptChain → true
Every decision, allow and deny, emits a signed receipt on one hash chain. Verifiable offline by anyone with the public key — and instance-bound: a third party can recompute exactly which action instance a decision governed from the receipt alone.
All three are real output from npx @bolyra/mpp demo: real verification path, stub transport.
Every call, checked
verifyBundle() checks ZKP proof, delegation chain, scope commitment, expiry. 401 on failure.
YAML config maps tool names to permission bitmasks. read_file needs READ_DATA, delete needs WRITE_DATA. 403 on insufficient.
Session nonce checked against MemoryNonceStore or Redis. Same nonce twice = rejected.
ES256K-signed receipt for every decision. Allow or deny. Timestamped.
Beyond payments
Spend mandates are one instance of the verifier boundary. The same gate sits in front of any MCP server: authenticated in 60 seconds.
Then curl localhost:4100 -- unauthorized calls get 401, authorized calls pass through with X-Bolyra-* headers.
For agent platforms
If you sell agent infrastructure — a payment rail or agent wallet, an MCP gateway, an agent framework, a hosted runtime — your enterprise customers are about to ask who authorized each agent action (and each agent payment), and for proof. Bolyra plugs in as an external verifier, without you rebuilding auth. Start on Bolyra Core — classical crypto: policy, replay protection, signed receipts. Upgrade to Bolyra ZK when your customers need verification without disclosure — same verifier contract, same gateway integration path.
Which agent can invoke which tool, for which user, under which credential and scope. Enforced per call, not per session.
Every allow and deny decision emits a signed, timestamped receipt your customers can verify independently.
Receipt chains produce audit evidence your customers can retain and independently verify. Evidence, not telemetry.
Self-hosted gateway — deploy inside your customer's VPC. Open-core protocol, Apache-2.0.
The External Verifier Contract is Bolyra's open host-to-verifier boundary: a host sends one verification request and gets a fail-closed allow/deny verdict from a classical, ZK, or external verifier. Run the published conformance suite, explore the reference implementations, or verify locally with bolyra verify. Bolyra maintains the spec, conformance vectors, and reference hosts.
Revocation can be enforced at the host↔verifier boundary. In examples/managed-revocation, an allow requires a trusted signing key and an active, registered binding. After revocation, the next presentation is denied. Revocation is terminal for that binding: it cannot be re-registered. The example demonstrates register, allow, revoke, and deny, while an independent credential continues to receive an allow verdict.
To request a managed-revocation pilot, email your operator public key to hello@bolyra.ai.
Prove it yourself. @bolyra/evc-conformance@0.7.0 tests both sides of the boundary, regardless of implementation language, with no project install step and no Bolyra runtime: 30 host-behavior vectors against any HUT-compatible host process, and 11 domain-agnostic wire-envelope vectors against any spawnable verifier (no assumptions about proof-bundle semantics). The contract is specified in draft-kondoju-evc on the IETF datatracker (revision -02, September 2026), and a first independent external implementation (khandrew1/mcp-use-evc-example) was built from the spec text alone and passed 27/27 host-behavior vectors from vector set 0.5.0 at commit 17642a5 — listed with permission in IMPLEMENTER.md §9. A second independent external implementation (stillmarcus24/x402-authority-verifier-kit) is a verifier built from the spec text against the x402 authorization-evidence profile. We reproduced its 39/39 result against its own pinned corpus in a network-isolated run at commit 35e209d, and it has since passed the Bolyra suite on the verifier side: 11/11 wire-envelope vectors at commit 1aa9d88, plus the §7.1 config-fault vector, which asserts that a corrupt trust configuration yields deny code=internal_error with a non-zero exit and never fails open. That is wire-envelope and exit-contract coverage, not full EVC conformance. It is also listed in §9 with the author's explicit permission. Every published claim, with its pins, is on the conformance page:
npx @bolyra/evc-conformance --host "/path/to/your-host --flags"
npx @bolyra/evc-conformance --verifier "/path/to/your-verifier --flags"Exit 1 on failure, --json emits the vector-set SHA-256 for CI. Full pass path: spec/IMPLEMENTER.md.
$5,000 for a two-week acceptance exercise covering one customer-operated agent workflow. Feasibility and your reviewer’s written acceptance criteria are agreed before signing.
The deliverable is an evidence report: for each claim a reviewer might make about one run, whether the record supports it, by which file and field, and what the record cannot show. The report keeps signed assertions, observations, derived checks, missing evidence, and failed checks visibly separate. It does not establish execution, human consent, or subject authentication.
What a finding in that report establishes, by the status the tool prints:
| The report marks | That establishes | It does not establish |
|---|---|---|
| SIGNEDdecision, reason text, simulated subject identifiers, permission mask, nonce, proof hashes | An authenticated assertion by whoever holds the anchored signing key. | That the assertion is true. Who holds the key: the signer anchor is reviewer-supplied and the bundle cannot prove it. That any subject was authenticated. |
| DERIVEDsignature recovery and payload hash, intact hash chain, count and head against the supplied anchors, recorded action against the signed descriptor, a repeated nonce met by a signed deny, the required mask parsed from the denial text | The named check passed over its stated inputs: the receipts verify and chain as supplied, and match the anchors the reviewer typed. | Completeness beyond those anchors. That the decision was signed before dispatch. That authorization preceded whatever the endpoint did. Replay or permission enforcement in production. |
| OBSERVEDhost-recorded action, dispatch attempt, upstream status, dry-run and ephemeral-signer flags, host-side counts | What the trial host wrote down, signed by nothing. | That the endpoint executed anything. That the recorded configuration was the enforced one. |
| ABSENTalways: execution, human consent, mandate or spend limit, who receives funds or controls a settlement address, production credentials or registry, proof verification, decision signed before dispatch, the required permission as configured | Nothing. The row is printed so the gap is visible instead of omitted. | Anything. |
| FAILEDa check failed or two sources contradict | Shown in place, never filtered. Changing payload.decision.allowed in a receipt without re-signing fails signature verification; an id-only edit fails the report’s own id check. |
Input scope: the report reads one supported bundle format today, the operator-trial bundle (receipts.jsonl, summary.json, signer.json, VERIFY.txt). A separate verifier in examples/audit-log-evidence checks one approval bound to one exact action over synthetic JSONL in the WorkOS Audit Logs metadata shape plus the retained receipt and action artifacts; its staging test showed seven metadata string occurrences survive that product’s CSV export, and it provides no CSV ingestion and establishes no human consent. Neither reads an arbitrary audit export. An exercise on another export shape starts with the feasibility check, which is why feasibility is agreed before signing.
Simulated sample: a published report generated from the operator-trial dry-run fixture, with its JSON and the exact input bundle. Simulated credentials, an ephemeral signer, no proof verification, a built-in localhost echo endpoint. It shows the deliverable’s form and limits, not a customer run. To produce one yourself, follow the operator-trial README. This exercise requires no Bolyra-hosted service.
See it in action
Interactive animated walkthroughs. Play, pause, scrub. No account needed.
Mandate in, verdict out, receipt signed. The question a relying party's gate asks, its checks in order, and where it applies.
Unprotected MCP server to gated auth proxy. Agent requests verified, rogue requests rejected, signed receipts emitted. One command: npx @bolyra/gateway.
Stripe ACP spend gating with delegated scope. Authorize vs confirm flow, fails-closed without SIGN_ON_BEHALF, signed commerce receipts with bolyra-receipt-verify CLI.
OAuth proves a token is valid. It can't prove what an agent is allowed to do — privately. Side-by-side comparison: bearer tokens vs circuit-enforced scope with ZKP privacy path.
Packages
Plug Bolyra into your agent framework, wallet, or payment flow.
@bolyra/mpp@0.7.0: operator-signed spend mandates verified before MPP payments execute; every gate decision receipt carries the signed instance block whenever the spend facts are resolved. A mandate authorizes a spend tier for each request, with no cumulative spending budget. Since 0.6.0, coversAmountUsd selects that tier, and issuance reports the authorized range. @bolyra/payment-protocols@0.9.0: x402 authorization and Stripe ACP spend gating against delegated scope, plus the x402 EVC authorization-evidence profile: the x402 retry carries authorization evidence alongside the payment credential; the resource server checks it fail-closed before payment logic proceeds. Since 0.9.0 the profile also supports payer-side enforcement (spec §4.2): for a 402 leg with a placeholder payTo and an issuer-signed quote, an agent-side host verifies the quote against the configured payee identity using a public key you provision out of band, checking the product, price, validity window, and settlement fields. Single-use enforcement requires your shared durable store and is scoped to one enforcement authority. This establishes who quoted the product at that price within that window, not who ultimately receives funds; an unbound derived on-chain payTo still denies. Try: npx @bolyra/mpp demo.
@bolyra/gateway@0.6.0 npm v0.6.0: reverse proxy in front of any MCP server, per-tool policy, replay protection, signed receipts, Docker or npx. @bolyra/cli@0.9.0: bolyra verify, a spawnable external verifier any host can call. @bolyra/evc-conformance@0.7.0: npx @bolyra/evc-conformance --host "<cmd>" for hosts, --verifier "<cmd>" for verifiers — 42 wire-contract vectors, zero runtime dependencies.
@bolyra/receipts@0.11.0: ES256K-signed auth and commerce receipts, hash-chained, offline-verifiable, signer discovery via /.well-known/bolyra-signers.json. New: receipt instance binding — a domain-separated, third-party-recomputable reference (birv1:) binds each decision to the specific action instance it governed, so a relying party derives it from the action’s own facts with no callback to the issuer. The spec was design-reviewed in public with the author of argentum’s action_ref, and verifyInstanceBinding() is public API: signature validity and instance validity are different claims, and bolyra receipt verify checks both. Replay Check GitHub Action: replays receipt history against policy on every PR.
@bolyra/mcp@0.6.5: middleware with dev mode, per-tool gating, stdio and HTTP. @bolyra/shield@0.2.0: stdio auth proxy with learn mode that writes a default-deny shield.yaml from the server's tool list. Both on the official MCP Registry.
TS SDK at v0.6.1 and Python SDK v0.5.0. Adapters for Vercel AI SDK, OpenAI Agents, LangChain, and CrewAI. @bolyra/circuits: prebuilt Groth16 artifacts, no Circom compiler needed. ZK upgrades use the same verifier boundary when privacy-preserving delegation is needed.
Adoption
6 packages listed on the official Model Context Protocol registry: gateway, shield, mcp, sdk, circuits, and receipts. Discoverable by any MCP client.
Agent identity guide merged into the docs of the community MCP server for Robinhood's Agentic Trading platform.
4-scenario demo protecting a mock Robinhood MCP server. Verified trade, unauthorized agent blocked, replay attack rejected. Read the writeup or try the playground.
Agent wallet with human-set spend limits for x402 micropayments on Base. 6 scenarios: research, inference, and market data allowed; premium report denied (per-request cap); daily cap enforced. Try the playground or view the code.
Differentiation
| Capability | OAuth / JWT | Bolyra |
|---|---|---|
| Delegated scope narrowing | Manual policy engine | Circuit-enforced, one-way |
| Per-tool permissions | Custom middleware per tool | YAML config, one gateway |
| Replay protection | Token expiry only | Nonce store (memory / Redis) |
| Signed audit trail | Application logging | ES256K receipts on every call |
| Privacy-preserving upgrade | N/A | ZKP path: verifier never sees identity |
Standards
Not just code: a written contract, a DID method, and a conformance suite anyone can run.
draft-kondoju-evc-02
The External Verifier Contract: how a host asks a verifier for a verdict on an agent's proof bundle, and what a verdict and receipt must contain. Registry closure, fail-closed precedence, implementation status. On the datatracker; the document can still change.
did:bolyra
W3C Decentralized Identifier method for Bolyra identities. Supports both human and agent DID documents with ZKP-aware verification methods.
125 vectors, set 0.10.0
spec/test-vectors.json covers handshake, delegation chains, enrollment, proof envelopes, session tokens, receipts, host behavior and the verifier envelope; CI runs the suite on every change; experimental classes are skipped by the runner and say so. 42 of them, 30 host-behavior, 11 domain-agnostic wire-envelope, and the §7.1 config-fault, ship as @bolyra/evc-conformance@0.7.0 to test any implementation, in any language, with no Bolyra runtime.
npx -y @bolyra/evc-conformance@0.7.0
One operator question
If you run agents that spend, or a platform that lets them, that question is what we want 20 minutes on. Not a pitch: a 60-second mandate-gate demo, then how you handle it today.