MCP Night 4 recap: agent auth, auth.md, and the rise of agentic registration

Last week we packed the Regency Ballroom in San Francisco for the fourth installment of MCP Night. The theme this time was "Agent Mode", and the night ran the way these always do: a keynote, a string of lightning demos, a panel, and an after party downstairs. Here's what we covered on stage, why agent registration is the missing primitive on the web right now, and why we shipped auth.md to start fixing it.

How MCP Night got here

MCP Night started about a year ago as an experiment. Our founder, Michael Grinich, had been bouncing around meetups in San Francisco, and MCP kept coming up in every demo he saw. So we rented out a space called the exploratorium, figured 50 to 60 people would show up, and ended up with over 250. There was a line down the block. Something had shifted.

A year later, the shift has a name: agents. The part of the stack that's changed fastest — the part I want to talk about — is how we write software.

You can watch the full event here: 

Coding with agents, in three eras

A year and change ago, coding with an LLM was basically very advanced autocomplete. You prompted, you got code, you reviewed, you prompted again. You were the human in the loop, every step.

Then the models got good enough to one-shot whole features. You could decompose a problem, hand it off, and the agent would run for minutes — sometimes hours — and come back with something real. That was the start of long-running agents.

Over the last several months, people started running agents in parallel. Multiple agents collaborating on the same system. The day-to-day practice of software engineering has changed more in the last four months than in any comparable stretch we can remember.

You can see this in what companies are shipping internally:

• Ramp published a blog post about an internal system called Inspect — an end-to-end coding experience where an agent opens, writes, and lands the majority of their PRs on its own.
• Stripe has a project called Stripe Minions, named after the cartoon characters, that ships over a thousand PRs every week.
• At WorkOS we built Horizon, our internal autonomous coding system. Horizon responds to events from Slack, can be tagged or dropped into a Linear ticket, and reacts to alerts from Sentry errors or slow database queries. It opens PRs and makes code changes on its own, and it ships PRs for us in production.

The metaphor we keep coming back to is cars. Cruise control and lane assist reduce your workload, but there's still a steering wheel. These coding systems run fully autonomously — no steering wheel, no controls. You tell them where you want to go.

What it actually takes to build one

If you want to build a system where an agent writes and ships code on its own, there are five things you need:

1. A runtime — somewhere the agent can execute, with permissions, isolation, and scoped credentials.
2. Tools — GitHub, CI, observability, databases, feature flags, issue trackers.
3. Context — the codebase, product requirements, Notion, Confluence, team conversations. At a remote-first company like WorkOS, that's years of engineering and product discussion we can pipe in.
4. Feedback loops — the agent has to build, test, and verify its own work.
5. A way for humans to review — we're not flowing agent-written code straight to production. Humans are still in the loop, just further up the stack: reviewing intent and trade-offs instead of individual lines.

The combination of the model, tools, context, and runtime is what people call the harness. The engine is the model — your Opus or your OpenAI frontier model. The harness is everything around it that makes the engine useful: the chassis, the wheels, the fuel system. Every time the models jump, the harness has to be rebuilt. For autonomous coding, the harness is the product.

Agents are the new users

Once agents get good enough to write code autonomously, they start making decisions about what to build with. They pick the database, the framework, the email vendor, the hosting provider, the observability stack — and the auth.

That's a real shift. In the past, agents worked inside an existing codebase. Now they're choosing the stack. If your product can't be used by an agent, an agent isn't going to pick it. Agents are becoming consumers of your product, and in a lot of categories there will eventually be more agents than humans.

YC has that line: "make something people want." I think it's time to extend it. Necessary, but no longer sufficient. You also need to make something agents want.

The missing primitive: agent registration

Here's where things get stuck today. There are protocols for connecting to agents (MCP), there are harnesses, there are sandbox providers, there are memory systems. But there's a primitive missing, and it's a surprisingly basic one: how does an agent actually sign up for your service?

Most signup flows on the web are explicitly designed to block automation. Email + password, CAPTCHA, email verification, IP heuristics — decades of work to keep bots out. Agents don't necessarily have an email address. They don't have a password manager. Their traffic patterns trip every fraud signal we've built.

Agent registration needs different primitives: automated discovery, capability declaration, intent, identity verification, delegation.

Much as it pains us to say it at MCP Night — MCP doesn't solve this. MCP is great for tool calling and for agents talking to agents. But its auth layer still requires a human in the loop to consent. We need something automated, built on agent-native primitives.

Introducing Auth.md

So we built one. We're calling it Auth.md.

Auth.md is a spec, not an IETF-ratified standard — please don't bring the pitchforks. It's a set of ideas that lets you expose your application to agents so they can register, sign up, and start using it. Not as spam. Not as a fake human. As an agent acting as a first-class user.

A service's Auth.md file describes what the service does, how an agent can register, what identity proofs are accepted, what auth flows are supported, what scopes and entitlements exist, what free tier constraints apply, and how a human or organization can later claim the account.

The live demo

We did this in true WorkOS fashion: live on stage. Madison, an engineer on the AuthKit team, walked through it.

Madison was authenticated as madison@workos.bot inside a harness with an "acme" agent — think of acme as a Claude Code or Codex-style provider with its own identity. She asked the agent to deploy a personal website she'd been building. Localhost wasn't going to cut it for sharing with friends.

The agent went looking for a deploy provider that supported agent auth. It checked stratus/auth.md — nothing. It checked helio deploy/auth.md — nothing. It found that Cloudflare had an auth.md file. The agent confirmed it should use the acme identity (not Madison's WorkOS identity) to register a Cloudflare account, converted the acme session into an IDJag, and Cloudflare returned an API token and account ID, ready to use with the Wrangler CLI. It also swapped the default adapter for the Cloudflare adapter so the bundle would work cleanly.

Madison got cold feet about the design, so she asked for retro inspiration. The agent reached for Firecrawl, which scrapes the web and returns structured JSON from the result. Same flow as Cloudflare — issue a new ID Jag scoped to Firecrawl, exchange it for an API key, and off it goes. The agent scraped the Web Design Museum for personal home page inspiration and coalesced the results into three options: Y2K, bad and ugly, and pixel art. The room clapped for Y2K. A minute later, the site was live on Cloudflare — all without ever leaving the terminal.

Huge thanks to our partners at Cloudflare and Firecrawl for building this with us.

What's actually under the hood

The token doing the work in that demo is called an ID Jag — Identity Assertion JWT Authorization Grant. It's an existing spec, not something we invented. An ID Jag is a JWT with a specific header identifying it as an ID Jag, and it carries fields about the user — including whether their email is verified — plus the issuer and the client.

The Auth.md flow itself is small on purpose:

1. The agent discovers services via a standard / endpoint, or via listings in llms.txt or a docs file.
2. The agent sends an IDJag assertion token and receives back an access token.
3. From there, the agent hits your normal API. MCP, REST, whatever you already have.

That's it. Auth.md doesn't try to solve permissions, runtime, or every credential problem under the sun. It solves the registration problem and gets out of the way.

Critically: no single company should own this. Not WorkOS. Not anyone else. It needs to be open for the web.

Agent-ready is the new enterprise-ready

We've spent years talking about enterprise-ready — helping developers take a SaaS product upmarket and sell it to the biggest companies in the world. Agent-ready is the same project, aimed at a new kind of buyer.

If this still sounds like Silicon Valley subculture, consider Marc Benioff. Salesforce isn't a young company. And Benioff is on record, saying of Salesforce, "our API is the UI". They're exposing Agentforce and Slack as APIs, MCP, and CLI. A company that makes billions on its dashboard is telling you the dashboard isn't the point anymore.

Try it

We launched a new site for Auth.md today with docs, getting started guides, and tutorials — whether you want to be a coding agent presenting an identity or a service provider receiving one. If you're already on AuthKit, you can enable Auth.md with one click.

After the keynote, we rolled into lightning demos. First up was Karen from Agent Card — a company that's roughly two months old — talking about debit cards for AIs. More on those in the next recap.

In the meantime: go build something with Auth.md. Email us, DM Michael Grinich, or come by the office. We want to see what you make.