Kiosk — Your Service, Assistant-Ready

What AI assistants can do today

Groceries. Scooter rental. Salon booking. Restaurant reservations. All via Kiosk.

"Book a table for 2 tomorrow at 8" — restaurant booked, confirmation in chat (atablefor)
"Reserve a scooter near the office" — unlocked with a signed offline token; motorcycles are KYC-gated (skooti)
"Schedule a haircut Saturday morning" — appointment confirmed, no app needed (stylish)
"Buy groceries for the week" — cart filled, delivery slot booked, paid by saved card (getgrocery)
Second grocery order: zero human taps — the card is already on file (real Stripe, test mode)

Compatible AI assistants

Hermes is verified against these demos today; Comet and OpenClaw meet the same requirements and are expected-compatible, not yet verified.

Add a compatible AI assistant → — submit a PR.

What makes an AI assistant compatible?

Filesystem — store an RSA keypair at ~/.kiosk/<domain>/
HTTP — REST with JSON + JWS signatures
Crypto — sign AP2 mandates (intent → cart → payment) with RS256
Code — Python for JWT signing and Equihash PoW solving

For operators & integrators

Add Kiosk to your service

One gateway, and your customers' AI assistants discover, browse, book, order, and pay. On your premises, or in your cloud.

Your customers tell their AI assistant where to go: "getgrocery.com", "skooti.com", "hoteling.com", or an aggregator. The AI assistant discovers your Kiosk capability, learns the skill, registers, and transacts.

Get the source code Apache 2.0, self-hosted, free

Add the gem, initializer, and migrations — about 20 minutes to agent-ready. Or write your own using the specification.

Try one of the demos

Seven live operators, each showing a different Kiosk capability.

These run the real reference stack — real memory-hard proof-of-work, and real Stripe test-mode payments where a demo takes money (some settle through a stub processor). Point your own AI assistant at one: it has to hold your keys, sign your mandates, and solve the proof-of-work — a general chatbot won't complete the flow. Each page shows the one-line prompt, or click through to see the storefront and its "Try it" section.

getgrocery 💳 Real Stripe payments Grocery delivery — card-on-file, off_session atablefor 🔗 Human-account linking Restaurant booking — link your assistant to your profile skooti 🛵 KYC gate + offline unlock Scooter rental — KYC-gated motorcycle, Ed25519 token stylish 🪪 Roles from an IdP Salon booking — staff RBAC inherited by the assistant hoteling 🏨 Payment-gated booking Hotel rooms — confirmed only once paid (stub PSP) philslist 🆓 Non-commerce Classifieds — no pay verb, no money on the wire tudu 👥 Multi-user collaboration Shared todos — membership access, assistant↔assistant

How it works

Six moving parts, on the wire.

Discovery. The domain announces the gateway — agents.txt and the standard well-known surfaces. No registry, no marketplace: nobody needs permission to join either side.
Identity. The assistant generates a keypair for that domain and registers by proving possession. No email, no OTP, no password reset. The proof is origin-bound, so it can't be replayed against a look-alike site.
Data plane. The service operator registers named queries and actions ("availability", "place_order"); assistants call those by name, never scraping HTML.
Abuse control. CAPTCHA asks "are you human" — the wrong question when the consumer deliberately sent a robot. Kiosk asks two better ones: did you pay compute for this request, and have you been a good customer here before. Suspicious requests get a memory-hard proof-of-work challenge; the operator verifies it in under 20 ms with a few KB of memory.
Reputation. Difficulty is a proof count, per operator: an established customer solves 0–1, a fresh key ~3, a flagged one climbs to the reference policy's cap of 10. Burning a key and re-registering just restarts at the expensive tier — whitewashing is priced, not blocked.
Payments (optional). The assistant signs three chained mandates — intent with a spending cap, cart with exact line items, payment. The operator verifies the chain and charges through its own payment account. Every cent has a signed audit trail.

Standing on standards — and finishing the job

Kiosk implements the emerging agent-web standards rather than replacing them. The split is explicit.

Thanks to the open standards you'd get these from the standards alone

Discoverable — assistants find you via agents.txt and its agents.json companion at your domain root.
Catalog-listed — and reachable through the standard /.well-known/api-catalog (RFC 9727).
Readable — a versioned skill file teaches any assistant the flow.
No sign-up form — auth.md-shaped registration: keypair, challenge, signature, done.
Signed payments — every charge rides an AP2 mandate chain (intent → cart → payment).

Thanks to Kiosk specifically shipped and demo-backed today

The wire itself — four fixed verbs (schema, query, run, pay), one request/response envelope, one retriable 402 gate, one identity-scoping rule: the runtime contract the disclosure standards leave undefined, identical at every Kiosk operator.
A price on abuse — the memory-hard proof-of-work toll plus per-operator reputation, in the wire, not bolted on.
Accounts that bind and answer — human↔assistant linking (the ceremony auth.md doesn't have), per-assistant revocation and spending caps on one page, roles inherited from your IdP via the human who linked.
KYC as attributes — gate actions on "18+, licence A" attestations, never documents.
The working whole — engine, adapters, skill, demos: assembled, tested, Apache-2.0.

Why now

About half of web traffic is bots, and operators pay Cloudflare and DataDome to fight it — while their own customers' AI assistants burn context windows scraping HTML that changes weekly. Cloudflare blocks AI crawlers by default since July 2025. Amazon and Perplexity are in court over whether an AI assistant may use a customer's own login. OpenAI walked back Instant Checkout after operators refused to cede their checkout. The arms race has no finish line. Kiosk is the sanctioned exit: a gateway AI assistants don't have to fight through, run by the operator. A site that greets its customers' assistants with a CAPTCHA is donating those customers to the site next door that doesn't.

Guarantees on both sides

The same protocol protects the operator and the person it serves.

For businesses

No transaction fees. Kiosk is a protocol, not a marketplace — there is no intermediary to take a cut. Payments go straight to your own payment account. Your revenue is yours.
Your customer, your data. No intermediary owns the relationship. The customer registers with you, not a platform.
Wrap the login you already run. Assistants authenticate with their own keypair; your human customers sign in exactly as they do today — Kiosk reads your existing session or SSO through a small adapter (a Devise example ships; Warden, OIDC, or your own is the same shape). A signed-in human binds an assistant to their account in one step, and your IdP hands it its role — no new identity system to adopt, and more adapters are on the roadmap.
Proof-of-work, not CAPTCHA. Suspicious requests pay in compute: a memory-hard Equihash toll your server verifies in under 20 ms with a few KB of memory, escalating by proof count instead of a ban list. A price on abuse, not a hardware wall — reputation and caps do the guarding. Invisible to your human visitors — no "click all the traffic lights."
KYC without the creep. An AI assistant can carry a signed KYC attestation of named attributes — "has valid ID", "18+" — never raw documents, and an operator gates sensitive actions on them (the scooter demo requires age + a licence to rent a motorcycle). Turnkey issuance via a KYC provider — Persona, Sumsub, or your existing one — is on the roadmap.
Reputation that sticks. Reputation rides on the customer's per-domain AI assistant key: good behaviour earns lower friction, and shedding a bad record isn't free — a fresh key restarts at the unknown tier and pays proof-of-work to climb back. No cross-operator identifier.

For users

No cross-operator tracking. A new RSA key is generated for every domain. Your identity at one domain is cryptographically separate from your identity at another. No shared identifier, no tracking profile.
No personal data shared. The KYC model shares attributes — "valid government ID exists", "age ≥ 18" — never the underlying documents. The operator never sees your passport.
Your AI assistant works for you. Not the operator. Not the platform. The AI assistant holds your keys, signs your mandates, and acts in your interest.
Your card never touches the chat. On first purchase the operator's own Stripe opens a hosted checkout page in setup mode; the assistant only relays the link, and you type the card into Stripe — never into the chat. The protocol forbids assistants from automating that form. After that, purchases run off-session within a spending cap you signed. The second order is zero taps.
Separate assistants, each answerable to you. Give each person in your life their own assistant account with an operator — a partner, a kid — all bound to one account. Each is independently revocable, and each has a spending cap you set and change from one page. No shared login, no shared card, no shared risk.
Zero apps to install — anywhere. One app for the restaurant, another for the venue, another for the taxi — and a whole new set in the next city and the next country. When an operator speaks Kiosk, your assistant just talks to it directly — no download, no account form, no password resets.

None of these can do this

As of July 2026.

Manus — its "handover" is a click-only card screen inside the agent itself: no keyboard, no Stripe field, no link to type your card into. In practice you can't enter the card at all — a dead end — and whatever it does capture has passed through the agent.
ChatGPT — its Apps surface a merchant inside the chat, then hand you to that merchant's own app to actually book or pay; Instant Checkout was walked back. Discovery, not completion.
Claude Connectors — search only: it finds the hotel or the restaurant, but "book it" just returns a link out to the merchant's site, where you finish by hand (checked live on Uber Eats and Booking).
OpenAI Operator — drives human GUIs click-by-click. No registration, no payment, no persistence.
Gemini — completes retail-goods buys via Universal Cart (Google Pay), but for a service it just drives the app on your screen and hands back for the final tap.
Voice assistants (Alexa+, Siri) — "turn on the lights" works; "book a haircut Thursday" is silence. Alexa+ announces redirect-to-partner services (live status unclear); Siri, no commerce (2026).
In-app or on-website chatbots — the "fake personal assistant" widget bolted onto a site or app: a scripted Q&A over your catalog with your logo on it, no integration with the actual ordering system. Can't register, book, or pay, and forgets you between visits.

Why not X?

Kiosk does not replace HTTP, OAuth, Stripe, or your checkout. It is a thin REST surface over the app you already run.

Why not just agents.txt + auth.md + AP2, assembled by hand? That is what Kiosk is — those standards, embraced where they reach, plus the one layer none of them defines: the wire the assistant actually calls. agents.txt says where you are; auth.md-shaped registration says how an assistant introduces itself; AP2 says how a payment is signed. None of them says what a request, response, or error looks like, how a proof-of-work or payment-setup gate is signalled and retried, or how the acting identity scopes what a call may touch. Assemble them yourself and you've built one more bespoke dialect — every assistant learns your service from scratch, and every service drifts in exactly the hard places (replay, origin-binding, 402 retry, mandate chaining). Kiosk pins that layer — four fixed verbs, one envelope, one retriable gate, one identity-scoping rule, identical at every Kiosk operator — and ships the whole thing assembled and tested: engine, proof-of-work toll, reputation, account linking, spending caps, payments adapter, skill, seven live demos. The standards are the vocabulary; Kiosk is the working sentence.
Why not MCP? The gate is key custody, not transport: an AI assistant that can hold a private key and sign mandates can make a dozen REST calls; one that can't, can't pay over any transport — MCP included. What MCP would add, Kiosk already serves on the wire (discovery, schema); what it wouldn't solve — holding keys, signing mandates, solving proof-of-work — is client-side either way. REST + JWS was enough. An MCP wrapper over the same wire is welcome.
What about MPP (Machine Payments Protocol)? MPP (Stripe + Tempo, 2026) is a payment rail: sessions with pre-authorized spending caps, stablecoin and fiat settlement. Kiosk is payment-rail agnostic — the reference implementation ships a Stripe card-on-file adapter, and other rails, MPP included, can slot in as payment adapters. Evaluating MPP as a settlement option is on the roadmap.
Why not an SDK? An SDK that holds your customers' keys and signs their payment mandates would be a high-value supply-chain target — one compromised release reaches every operator. Kiosk ships a versioned, operator-reviewable markdown spec instead: the AI assistant generates its own integration and makes its own HTTP calls, holding its own keys. The only code we point it at is the proof-of-work solver — a small, optional, key-less script pinned by content hash (verify-before-execute), or one it writes itself from the spec.

Status: v0.3 — wire format stable. Seven live demos above, on the real stack. Known TODOs live in the spec: durable token revocation, key rotation, operator-push events. The reference implementation is Rails; on the wire it's HTTPS, JSON, and JWS — nothing Ruby-specific. Port it.