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.
npx @bolyra/mpp demo
v0.3.1
npx @bolyra/gateway --target http://localhost:3000/mcp
pip install bolyra-langchain or bolyra-crewai or bolyra-agents
v0.1.0
docker run ghcr.io/bolyra/gateway --target <your-mcp>
npm v0.6.0
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.
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 today — deploy inside your customer's VPC. A hosted verifier preview is live for design partners: POST /v1/verify, same External Verifier Contract, HTTP instead of local spawn — evaluate with a partner token before installing the gateway. 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. Pilot against Bolyra's hosted verifier preview today, then keep the same boundary if you self-host or swap verifier implementations later. Bolyra maintains the spec, conformance vectors, reference hosts, and managed verifier path.
Open contract. Managed operations when you need them.
Agent spend authorization pilots: 90 days, fixed fee, integrated into your payment or platform workflow in ~2 weeks.
See it in action
Interactive animated walkthroughs. Play, pause, scrub. No account needed.
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.3.1: operator-signed spend mandates verified before MPP payments execute. @bolyra/payment-protocols@0.7.0: x402 authorization and Stripe ACP spend gating against delegated scope. Try: npx @bolyra/mpp demo.
@bolyra/gateway@0.6.0: reverse proxy in front of any MCP server, per-tool policy, replay protection, signed receipts, Docker or npx. @bolyra/cli@0.7.0: bolyra verify, a spawnable external verifier any host can call. Hosted POST /v1/verify preview for design partners, same External Verifier Contract.
@bolyra/receipts@0.9.0: ES256K-signed auth and commerce receipts, hash-chained, offline-verifiable, signer discovery via /.well-known/bolyra-signers.json. 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 protocol with formal specifications, a DID method, and conformance tests.
draft-bolyra-mutual-zkp-auth-01
Formal protocol specification for mutual zero-knowledge proof authentication. Defines message flows, proof formats, and verification procedures. SDK (v0.6.x) aligns all circuits to Groth16 (REQUIRED), PLONK (OPTIONAL). Canonical 6-element Delegation public-signals layout locked for IETF submission. External Verifier Contract v1 is proof-system-agnostic (kind: classical | zk | external).
did:bolyra
W3C Decentralized Identifier method for Bolyra identities. Supports both human and agent DID documents with ZKP-aware verification methods.
67 vectors, all passing
Conformance suite covers handshake, 2-hop delegation chain, forged-token EdDSA, nullifier-per-nonce, Poseidon3/4 binding sensitivity, LeanIMT root edges, canonical 6-element public-signals layout, financial scope narrowing, and cumulative-invariant rejection.
Become a design partner
Small cohort through 2026 to harden the protocol against real deployments. We are looking for agent platforms, identity providers, and regulated enterprises with a real integration scenario. No public partner list yet — we will name partners only with their permission.