The Best Routes Are Behind a Login. Nobody Has to Share One.

· updated · Lewis Tham

Nobody pays an agent to read a public search page.

They pay it to download last month's invoices. Update the CRM. Pull a report out of the supplier portal. Move a booking.

Every one of those sits behind a login.

I'm Lewis Tham. I run Unbrowse, and I'm first author of "Internal APIs Are All You Need". This is how we plan to map the signed-in web without anyone handing anyone a password. It's a design, and I'll mark what runs today at the end.

Public-only networks map the cheapest part of the web

A crawler sees what a logged-out visitor sees. Product pages, search results, news, prices.

That's useful. It's also the part anyone can already scrape, which is why nobody pays much for it.

Our own public registry is built the same way today: scrubbed, read-only routes that carry no secrets. We did that on purpose. It also means the routes people would pay the most to run are the ones a public registry can't hold. I made the customer's side of this argument in The Invoice Is Right There.

So a network that only maps the public web is mapping the lobby. The work happens upstairs, behind a badge reader.

The recipe travels, the login stays home

Here's the trick. A signed-in route has two parts: how the site works, and who you are.

The first part is the same for every account. The second part is yours.

So an account holder maps the recipe and strips everything that's theirs:

RECIPE  billing.example.com  (illustrative)
routes:   GET /api/invoices?from={date}&to={date}
          GET /api/invoices/{id}/download
inputs:   date range, invoice id
sign-in:  email + password, then a one-time code;
          session cookie set by /login
returns:  list of {id, date, amount, status}; a PDF

stripped: cookies, tokens, account ids, names,
          emails, addresses, every real value

What's left is the knowledge of how the site works. What's gone is everything that makes it an account.

A map of the building doesn't open anyone's flat.

Callers bring their own login

When my agent runs that recipe, it signs in as me. It gets my permissions and nothing more.

Part of this exists today for your own routes. A saved login sits in Unbrowse's server-side vault, sealed per workspace, and the agent fills it into the sign-in form without ever seeing the value. When a replay hits a 401, Unbrowse signs in again with that saved login and reuses the session. The plan adds a second home for it: a program on your own machine that keeps the password in your OS keychain.

The mapper never touches my session. I never touch theirs. The recipe is the only thing that moved.

mapper     own account   -> learns route, strips secrets -> recipe
registry                 <- recipe (no cookies, tokens, personal values)
caller     own account   -> signs in as themselves -> runs route
verifier   own account   -> replays with own login -> checks shape
mapper                   <- paid on verification, then on use (plan)

A second account checks the first

Never trust the recorder. A mapper could submit a recipe that doesn't work, or one that quietly sends data to a domain it never declared.

So another account holder replays it with their own login.

Their invoices aren't mine, so comparing values is pointless. They compare shape: the status, the schema, the fields that must be there. Same shape, the route works.

Where there's no second account holder handy, there's zkTLS: a proof that a response really came from the site over its encrypted connection, without revealing what was in it.

You can prove "billing.example.com returned a list of invoices in this shape" without showing anyone the invoices.

In the plan, the mapper is paid when the route is verified, and again when people use it. You map your accounting software once, and every agent that later runs it on its own account counts. None of that pays anyone today.

Why we won't let you rent out your login

There's a shorter path, and it's obvious: let people lend their logged-in accounts to the network and get paid per job.

We won't build it.

Account sharing bans the owner, not the agent. When the site notices, the ban lands on your name. Your order history, your saved cards, your years of reviews, gone, for a few cents a job.

Licensed data is licensed to one person. That research database, that market feed, that paid journal: you agreed to read it yourself. Renting out your session resells something you never owned.

Your account is full of other people. Your inbox holds your clients' emails. Your CRM holds your customers' phone numbers. None of them agreed to become a job input.

Fraud systems exist for exactly this. One account signing in from forty cities in an afternoon is what a stolen account looks like. The site's risk team will treat it as one, and honestly, fair enough.

Someone else's job on your credentials can be unauthorized access. That phrase belongs in a statute, and nobody wants to learn their local version on behalf of a stranger.

The legitimate version of "rent access to a signed-in site" already exists. The site sells it: an API with a price, or a fee per call.

We'd rather help sites do that than help users get banned. Delegated account access for your own agent is a different and harder question, which I took on in In Defense of Muse's Most Uncomfortable Idea.

Where this actually is

Live today: learn a site's request once in a browser and replay it over HTTP. The public registry of scrubbed, read-only routes, with a publish gate and revalidation. A server-side vault for your own saved logins, which the agent fills without seeing.

Status as of 12 October 2026. In testing: local browsing through your own browser with the CLI.

Built, not yet switched on in production: a browser extension relay, so agent calls run through your own browser. A program on your own machine that Unbrowse can reach is merged but not in production, and keeping passwords in your keychain is still a design.

Plan, not built: signed-in route mapping, verification by other account holders, zkTLS checks, and paying mappers. None of the recipe sharing in this piece runs yet.

It's one MCP server: unbrowse.ai/mcp. Setup is in the docs. Your agent can already sign in to your own accounts with a saved login today; the shared recipes are what comes next.

Map with your account. Run with mine. Nobody lends a password.

Get new articles by email

At most about once a week. One click to unsubscribe.

We email a confirmation link first.

All posts