Vyana is the broker and open protocol that lets AI agents create accounts and make payments on your behalf — bounded by a consent mandate you sign once, verified through a seven-layer chain, and provable with signed receipts.
Agents create real accounts at any ASP-aware merchant — no shared passwords, no card sitting on file.
Every action is checked against your User Consent Mandate — per-transaction, daily, and monthly caps.
Each signup and payment returns a signed receipt (ACR / AOC). Credentials are vaulted, never exposed.
Most “agent payment” tools stash an API key and hope. Vyana issues a cryptographic User Consent Mandate, then verifies every request against it — in fixed order — before a merchant ever sees it. The mandate is yours: scoped, capped, expiring, and revocable.
Money is always integer paise. Authority is always signed. Nothing an agent does exceeds what you allowed.
Vyana isn’t a single endpoint — it’s an open protocol family under one revocable User Consent Mandate and one provenance chain. ASP and APP are specced today; the rest extend the same trust model across the agent-commerce lifecycle.
Can this agent create or connect this merchant account — with proof the user authorized it?
Can this agent spend this amount with this merchant, and did settlement actually happen?
Bounded, signed, verifiable delegation — extended past signup and payment into the full agent-commerce flow.
In September 2025, Google announced AP2 with roughly sixty partner organizations — Mastercard, PayPal, American Express, Coinbase, Stripe, Adyen, and counting. April 2026 brought spec v0.2.0, with three SD-JWT Verifiable Credentials replacing the original draft. Vyana implements that spec natively. Every AP2 mandate is signed by the same Ed25519 keys that sign our native ASP/APP objects — no new trust root, no rewrite of the payment path.
Delegated authority. The user authorizes future checkouts within stated constraints.
Pay this specific cart, signed by the merchant inside.
Execute the payment against that cart — the chain closes here.
The broker sits between your coding agent and the merchant — it never lets a request through until it clears the chain, and it hands back receipts both sides can prove.
A signed request enters · Vyana verifies and signs · the merchant fulfills — every step provable.
Right now your agent pairs over MCP or the CLI and signs each request with the paired device key.
The same consent rails extend to the wider agent ecosystem — anywhere an agent needs to sign up or pay on your behalf.
Every signup and payment runs the same chain — and each layer appends a provenance event, so the whole decision is auditable end to end.
One signed mandate sets per-txn, daily, and monthly caps plus the services an agent may touch.
Account-creation (ACR) and ownership (AOC) certificates — every action is provable after the fact.
AES-256-GCM per-user envelope encryption. Agents get capabilities, never raw long-lived secrets.
Drops into your coding agent over MCP, or runs from the terminal — pair, provision, pay, audit.
Passkey, hardware security key, or TOTP — with real step-up re-auth at consent & identity boundaries.
Run several accounts from one machine; switching identity requires a fresh step-up.
Install the MCP server, pair this device under your consent, then let your agent provision — the credentials land in your project, the receipt lands in your dashboard.
We're onboarding developers in waves. Tell us what you're building and we'll reach out with an invite. Prefer to look around first? Try the live demo →
Thanks — we'll email with an invite. Want a head start? Try the live demo →