GitHub

v0.6

First-class access for personal AI assistants

A personal AI assistant opens an account at an online service, reads what it offers, books, orders, posts, pays, and hears back when something happens. It registers with no email and no password. Extensive usage is tolled with memory-hard compute.

Get the source code Read the specification

Apache 2.0, self-hosted, free

The problem, as I ran into it

I sent the assistant on my laptop to book a table for two. It was shown a CAPTCHA, blocked by the CDN, and banned by the service.

Cloudflare lets an assistant through when it is a Verified bot, one that signs its requests, obeys robots.txt and keeps reasonable request rates, or when the site owner allows it. eBay's terms forbid every buy-for-me assistant that eBay has not approved, and OpenAI's is approved. Amazon sued Perplexity over its shopping assistant. Walmart, Etsy and Shopify signed on to sell inside ChatGPT.

Hermes with DeepSeek 4.1 Flash on my laptop has none of that.

Why Kiosk

I'm a builder, so I built Kiosk for every personal assistant and every online service that wants to serve it. It is an open protocol, free to implement: nobody signs a deal or gets on a list first. A visitor brings the assistant they like, cheaper, more private or simply their own, and the service lets it in.

Nothing in Kiosk knows what the service sells. The same protocol carries a grocery order, a hotel booking, a classified ad and a to-do list shared between two housemates' assistants. A social network that people reach only through their assistants would run on it too.

Watch it order

The same Hermes, messaged from my phone over Telegram: one photo of a handwritten list and one sentence. It orders at the grocery demo and pays with the card saved there earlier. The wait is sped up; the counter shows real seconds.

How it works

  1. Find. The service serves the standard discovery files: agents.txt, auth.md, an API catalog (RFC 9727) and /.well-known/kiosk.json, and OAuth server metadata (RFC 8414).
  2. Register. The assistant makes a new key for that one service and registers it as an OAuth client (RFC 7591). It signs a client assertion with that key for each token (RFC 7523). Its access tokens are bound to that key (DPoP, RFC 9449). There is no email and no password, and nobody vouches for it. Another service gets a different key, so the key gives two services nothing to connect.
  3. Pass the toll. A CAPTCHA asks whether the caller is human, and the customer sent a robot on purpose. Kiosk asks for work instead. Registration and every 10th call cost a memory-hard proof of work: 9 to 20 seconds on one Apple M3 laptop core. The service checks it in about 20 ms. Fewer proofs come with a good reputation, and the operator picks how to measure it. By default it is spend. The more the customer spent at the service in the past week, the more calls pass between two proofs, up to no proof at 100 euros. At a classifieds board the measure could be the stars on a person’s posts instead.
  4. Call. Each query and action the service declares has its own REST path, listed in a public catalog. One skill file teaches an assistant to use every Kiosk operator.
  5. Pay. The service signs a checkout with the exact items and price. The assistant pays it with two signed AP2 v0.2 mandates, and the service answers with two signed receipts. The human saves a card once, on the service's own Stripe page, and the skill forbids the assistant to touch that form. After that, every payment at that service needs no form and no click.
  6. Events. Some answers arrive on somebody else's clock: the hotel confirms, the courier sets off, a housemate ticks an item off the shared list. The assistant holds one WebSocket to the service, subscribes to the topics the service declares in the catalog, and resumes from the last event id after a disconnect. The protocol runs both ways: the assistant calls, the service pushes.

For operators

  • Direct. Your customers' personal assistants come to you directly. You keep the customer relationship and the data.
  • Your queries and actions. Declare what your service offers; the reference implementation serves the protocol around it. Read the guide.
  • Events. Declare a topic and emit an event when something happens on your side.
  • Linked assistants. A human links their assistants to their account. Each assistant has its own spending cap, and the human can revoke it alone.
  • Anonymized checks. Gate an action on anonymized attributes such as “18+” or a licence category.
  • Your own Stripe. Payments go through your own Stripe account. Kiosk takes no cut.

For visitors/customers

  • One key per service. Your assistant makes a new key at each service, so two services have nothing to connect.
  • A check shares one fact. When a service needs “18+” or a licence category, a broker signs that fact for that one service. The service learns the fact and nothing behind it; the broker is the one party that could connect two services.
  • The card stays with Stripe. You enter it once, on the service's own Stripe page. The service sees no card number, and the skill forbids your assistant to touch that form.
  • Each assistant has its own cap. Where a service offers one, you set a spending cap per assistant on its page and unlink an assistant there. Your own login stays.
  • Nothing passes through kiosk.tech. This site is static files. Your assistant talks to each service directly.

Compatible assistants

Should work too: Codex CLI (with network access on), OpenClaw and pi.

An assistant that reads the skill needs:

Add an assistant after a run: send a pull request.

Try it with your personal assistant

Seven sample operators run the reference code. Copy a prompt and give it to your assistant.

What ships

Built on open standards