Auth for Agents: Let AI Sign Up for Your Product with auth.md — Michael Grinich, WorkOS

Hello, everyone. Good morning. My name is Michael Grinich, I am the founder of WorkOS, and I'm here to talk to- with you today about agents, and specifically about how we can make agents more autonomous and allow them to access more services on the web. So let's jump in and get started. Shout out to those of you in the front row also. I see you out here.

So about a year ago, software engineers were writing code like this. We were using AI, but we would prompt it, and then we'd write a little bit of code, and then prompt it again, and it would write some more code. And you would continue to do this human-in-the-loop interactive software engineering. Later in the year, we had things like Ralph loops, if any of you remember those, where we kind of automated this. But more or less, this is the way that we were working. It was this human, agent, human, agent back and forth. However, as the models got better and better, they were

able to write more and more code and run for longer periods of time. And so today, a lot of software engineering looks like this. You write a single prompt, and then the agent can spit out a lot of code. And sometimes it can actually build a whole feature, maybe even a whole product, and maybe run for not minutes, but, uh, hours and hours or even days and days. This has really transformed the way that we all write code. I don't write code by hand anymore. Probably you don't as well. And it's not just this one thread. You can actually parallelize

this. So there's many different tools out there, including, you know, the major co- coding harnesses from the labs, that allow you to run many of these in parallel. The limiting factor here, really the bottleneck, is your brain. How much context you can keep in your mind to keep all of these going at once. And this has transformed software engineering. People can be more productive. I think we've all seen in the industry how much faster things are moving. At the root of all of this is actually agentic engineering, agents. Going from these token prediction

language models to reasoning and now long-running processes that can actually do things autonomously for us. And what I think we've seen in software engineering here around agentic workflows is gonna come to a lot of different categories. It won't just be engineers that have this way of working. It'll be people in many different fields. Agents are the next big thing.

I think a good reference for this, a way to think about it, is actually what's been happening with vehicles. So, you know, this looks like a pretty modern car. It has a, you know, digital display on it. This is probably what you would've bought in the last, you know, five to ten years. But if you live in San Francisco or one of the cities with these autonomous vehicles, you've probably seen that we're starting to delete the interface. No longer do you get inside of the car and actually, you know, pull up your phone and get maps, where you as the human are in the loop. There might be cruise control, but you're still in the loop. Instead, these are autonomous

systems. You just say where you wanna go, you get in the car, you don't even say anything, and it just takes off and takes you to your destination. I remember the first time I got into a Waymo, I was blown away, mind totally blown, and then after about three seconds, I pulled out my phone and started scrolling X. It became commonplace. And I think we've seen this already happen with engineering. The power of agents allows us actually to work and think at a higher level, for us to, you know, exercise more of our executive function versus just planning and execution.

There's a question here of what do agents need to be successful? Actually, when they execute, what do they need? Well, first, they need a runtime, a sandbox. They need somewhere that they can run that needs to be safe, secure, performant. They also need tools. They have to be able to go do stuff in the world. An agent's not very useful if it can't take actions, so it needs tools. Third, it needs context. You know, these new models, the power of the intelligence in them, it's kinda like taking the smartest person you know and dropping them into a company or a project or a team where they don't know anything. They can't

really get anything done. They need to have context, information about the system, information about the goals. They need feedback, so a way that it c- they can actually run and validate, that they can check that their work is correct, and if it's not correct, keep going. Then last but not least, of course, they still need human review. This might be code re- review. This might be other forms of evals. This might be forms of checking their work to make sure that these agents are sort of aligned with your goals.

The LLM, the intelligence engine, this new technology we've created in the last, last few years, you can think of as like an engine. It's like a really high performance, you know-- I think this is a, a V8 engine. You know, puts out a lot of horsepower, can convert fuel into, you know, output. But an engine by itself isn't very useful. For a car, you need to drop this into the actual car itself. You need the chassis. You need the transmission. You need the drivetrain. You need the wheels. And only with all of that is it gonna be effective to take you

places. And this is what a lot of people refer to as the harness. Harness engineering is this new domain where if the models get better but you don't have a good harness, you know, it's not gonna be very effective. So as the models improve, we change our harnesses, we adapt them to it, and those things that I mentioned earlier are sort of a form of a harness. So agents execute within these harnesses to get stuff done, and they, they need all of those elements to actually be effective. And when they drive, they drive really, really fast.

So say you have one of these agents that's going off. You prompt it to go build something for you. You know, it spins for a while. It says, "Okay, I'm gonna need this feature and this feature, and I'm gonna need a database, and I'm gonna need, you know, this ent- uh, you know, system to deploy, and I'm gonna need, you know, maybe this thing for image resizing or video transcoding or sending email or whatever." And your agent can actually go do all this research and build all these systems. And today, what's happening with agents is they're actually selecting vendors. You've probably seen the rise of some of these systems where, you know, like, the CEOs will

tweet about their growth graph, and it really takes off, and it's because agents are picking them. They're picking their systems for sending email or deploying code, their systems for storing data. Today, actually, it might be more important to build for agents than to build for people. Agents are kind of this new consumer class. I'll talk about that in a bit. There's this, uh, kind of popular thing that people say in San Francisco and Silicon Valley, "Make something people want." This comes from Y Combinator, you know, the startup factory from Paul Graham. And

I think it's time to maybe edit this a little bit, and going forward, we also need to think about making something that agents want. There will be more agents in the future than people, maybe even today. They'll be faster to spin up. They'll do things quicker. They'll be making decisions on our behalfs. And so if you want to build for the next era of consumers, you should be building for agents as well as people.

But there's a problem today. You can access the web, you can access mobile, but agents themselves can't really access systems. Your business probably isn't open for agents today, even though there's a lot of them out there, they can spawn very quickly. The door's not open.

And we think this is because there's a missing primitive: agentic registration, agent registration. There's a lot of great stuff around agents connecting and bringing context to systems and different open source frameworks, but that first step of an agent actually signing up for a service is actually missing, hasn't been solved, and is a huge blocker to getting adoption.

For the last, like, twenty years, maybe thirty years, automated traffic on the web has been bad. We've tried to block all of it, and so there's all these systems that we've put in place to detect automated actors and stop them in their tracks. DDoS prevention, credential stuffing and attacks. The login box, for example, is very hardened against agentic registration today. Not intentionally, but just because of the legacy systems of what we've built. And it's very hard to distinguish between what's

a good automated user versus a bad automated user. If any of you have used any of these, like, cloud-based, uh, browser execution environments, one of the selling features they often have is to break CAPTCHAs, which is pretty wild. You know, we're trying to go backwards. The CAPTCHA today, though, is, is still kind of dead. There's rampant abuse. There's lots of token fraud. And so we need to find a better way to allow the good agents in and then block the bad agents, right? Because like I said earlier, if you don't build for the agent economy, your product might

not win. It might not be successful.

Today's sign-up flows assume that a human can read the landing page, that they can fill out a form, you know, put their email address, their password in it, that they can solve a CAPTCHA, that they can verify their email, not just put it in, but go click something somewhere. Remember, an agent probably doesn't have an email address. If it's signing up for a service, it needs to have a-- you know, a human can choose a plan to pay for it. You know, a human can copy the API key out, paste it somewhere, use it somewhere else. And really even a dashboard, think of a dashboard experience. It's not really

agent native. All this stuff is built for people. It's kind of a human interface, not an agent interface. Agents need something else. They need native discoverability. Can they register for a system? Are the doors open for agents or not? Capability declaration. What can it do? Registration intent. Why are you registering? What are you trying to do within this? Or the intent to actually just sign up. There's a lot of stuff around risk here. So for an agent native registration, maybe you wanna-- you're not sure if the agent signing up is

gonna be good or bad, so you need to actually do an, a risk assessment of that. There might be different forms of identity verification for an agent. If something like Claude is going and signing up, maybe it can bring the user's identity with it. Or if you have a, you know, OpenClaw or, like, your PyHarness or something else, maybe it doesn't bring the user's identity and gets verified out of band. There's the whole thing around organizations doing this. So if I'm building something within a company, how does my company identity come in? You know, my organization.

Entitlements, permissions, credential is-issuance, auditability, the list goes on. There's so many things that need to be changed. In fact, probably most things need to be changed going from, you know, human registration to agent re-registration, agent native systems.

I'm sorry to say MCP is not enough. Probably more than anybody, I'm a big MCP fan. We've done a bunch of events in San Francisco around MCP. I see somebody wearing one of our Run MCP shirts up here that we made. Love MCP. MCP is great for connecting, for providing tools, skills, context, but it doesn't solve the registration step. Today, authentication through MCP requires your human to still be in the loop. You give consent. You add an MCP server, say, for PostHog to Claude. You sign in with your PostHog

credentials. What we're talking about here for agent native registration needs to happen without the human involved, or at least not involved initially.

So we've been working on this for a while, and our proposal to this is a new spec we have called Auth.md because Markdown files are the future, right?

Well, how does this actually work? What is Auth.md? Well, the idea here is that Auth.md tells agents how they can become legitimate users. It's a set of instructions that tells an agent registering for a service, "This is what you need to do to sign up and be considered legit and for me to give you access." And the goal here is to give these service providers, you know, people that are building, building services, an agent native sign-up experience, but it's built on existing standards instead of inventing a crazy new religion or

something really complicated. With Auth.md, we're not solving the whole problem around agent identity, you know, permissions, long duration, uh, you know, connective services. We're just trying to solve this narrow one around registration because I think it's a huge blocker. Let's start small and grow from there. This is built on open standards. It's built on a bunch of work that's already been done across the OAuth spec, specifically tailored to that registration step.

AuthMD can answer what does the service do? It can tell agents how to register. It can tell them what identity proofs are accepted, how do- how, how an agent or a user is proving their identity. What auth flows are supported. Can you sign up with SSO or email address or MFA? What scopes and entitlements in- can exist? Kinda what capabilities are here. What free tier constraints apply? You might have a system where you wanna give an agent a little bit of free capacity, but not too much until they verify or pay in some way.

And then, of course, how does the human get involved later? A human or an organization claiming it afterwards. So an agent can sign up, but you want the human to have custody later on. This is what AuthMD is designed to solve. These are the big questions around the registration stuff. So how does this actually work? Well, here's a little, uh, kinda cartoon demo that I'll show you. And all this works by the way. You can go try it after this. So say I'm here in, um, whatever coding harness or system using Py or

Claude or something, and it says, "Welcome back, Michael at WorkOS." That's actually my email if you wanna email me. "Do you wanna keep working on your spelled app?" I'm like, "Yeah, sure. I'd like to share this with my friends, but they can't access it." And the agent's like, "Oh, well, localhost only works on your machine, so your friends won't be able to hit it, of course. To share it, I need to deploy it somewhere real. Some providers actually let me handle the signup, so, you know, you wouldn't have to sign up and do this. You want me to look around for you?" "Yes, please."

And then the agent can go look for services that advertise through AuthMD that they support registration. Just some examples, Stratos, Helio Deploy, they don't support it. But Cloudflare here does have an AuthMD, and so the agent here can say, "Ah, Cloudflare, that's the one. Cloudflare's a winner 'cause I can go sign up for it. I can access this service. I can actually use it. So I can do the whole thing. Do you wanna go with it?" "Yeah, let's do it." This is the registration step. This is kinda where the magic happens.

What my agent is actually doing is minting an identity assertion and giving that to Cloudflare, and then Cloudflare is able to verify that or not. Cloudflare can choose actually to verify out of band. AuthMD is very flexible. There's different ways you can dial it in depending on the behavior that you're looking for. One size does not fit all. Every application is different. Constraints are totally different. If you're building something that's like a database service where there's gonna be very little amount of information, you might wanna give away a little bit of traffic for free. But if you're building something

maybe like an email service or something certainly if you access the physical world, you s- you maybe don't wanna give anything away for free. It's very application specific. So here Cloudflare says, "Okay, we're willing to let you deploy maybe for 72 hours or something like that." Get the identity assertion, boom, boom, boom, go through. It's called ID-JAG is what the standard is. And then it returns back and says, "You're set up with a Cloudflare account now." In this experience, my, you know, human, I didn't go click anywhere. I didn't sign up anywhere. It just, it just got the token. I can make a couple small

tweaks. It knows how to use Wrangler. Want me to make those changes? Go ahead. Does anybody prompt their agents like this? It's just like, "Yes, yes, do it, please." Not really saying much. It's able to write the Wrangler, get the thing set up, go through the full deployment process, and then boom, it's live. We actually have this working as a live demo. We did some collaboration with Cloudflare on this too. It's pretty cool. And you can tell the prompting that I was giving through this, not exactly rocket science. The agent could just run through the whole thing actually. There's nothing actually

that I was doing through prompting it other than just approving, approving, approving. It should be able to do this one shot.

This is what it looks like graphically. So agent registration with AuthMD, you have your agent harness, Py for example. Within that is your LLM, maybe your memory, different, you know, context layers. It connects to your backing identity service, so this is the user identity. And when that agent goes and registers, it sends the discovery call to Cloudflare. It looks for that AuthMD or whatever service. We also have this working with Firecrawl. It's pretty cool. It sends that ID-JAG, the identity, uh, JSON

access grant. It's essentially a signed credential that represents the user. Says this is an identity. Receives back the access token, actual API token, and then boom, it's, it's done. You can make normal API requests. You can call MCP. Everything else still works. So you can see that AuthMD is just for the registration step. Your normal API keeps working. The rest of your docs don't have to change. It's just that registration step for agents. But with the simplicity comes actually an enormous amount of power

because suddenly it lets agents do things end to end.

I hate the planning step . When I write something, I just want the agent to go do it. Usually, it kind of knows what I'm trying to get at, and I wanna come back to actually a running prototype and not like, "Hey, here's my long plan and here's a bunch of services to sign up for." If I'm building new prototypes especially, I would prefer it just to get deployed on something for free so I can see it and click around and not put me through the burden of going signing up for all these different vendors, and that's what AuthMD allows for. And if you're a service provider, if you're building APIs or services, this allows you to become a customer of those

systems, and you can think about it increasing your growth funnel. Starting from, you know, maybe just humans and adding the whole world of agents on top. Pretty great.

We think this is gonna be huge. Your door will be open for agents to actually sign up, register, use your services. This should be an immediate growth boom for your products. And I'm not saying everything that agents are gonna build will be useful. Maybe not everything they build will go into production or last that long, but some things will. Just like with PLG or freemium before that, this is the way to grow your business and get more customers and actually become, you know, larger and more successful. And where there's usage, we believe there's also intent to

pay. There's a lot of interesting work being done for agents to actually... pay for stuff. There's crypto-based protocols like x402. There's other things that the payment providers are building. But we think that should be downstream. We don't want payments to be upfront. We don't want to have to force your agent to sign up with a credit card. That seems backwards. We moved away from that in the world of SaaS. With AuthMD, agents can sign up, they can register, they can start using it, and then downstream choose to pay on your terms based on your own pricing, based on your own model.

If you don't believe me around the headless type of products, this is Marc Benioff. He's the CEO and founder of Salesforce, the guys with the big building here in town. They believe in agents more than anything. Our API is the UI. Entire Salesforce and Agentforce Slack platforms are now exposed as API, MCP, and CLI. Talk about going agent for-- first. A company that many people consider to be sort of a legacy SaaS vendor really invented the category of software as a service. They're getting rid of their dashboard and UI. I mean, they're not getting rid of it, but

they believe that agents are the future. So if you're not thinking about this, I definitely encourage you to start building some prototypes talking to users because you don't want to miss, miss this. If you want to use this, this is available today. We have an open spec for it. There's a GitHub repo. You can actually have your agent go implement it. I know it's kind of meta. It's an open spec. WorkOS doesn't control it. We have a version of it that we host, but you can build it yourself. You can run it yourself in your existing systems. I think this is so important that no single vendor owns this.

It's one-click enabled if you're a user of stuff, but you can build it on whatever platform you want instead.

Last thing I'll close with, this actually happened almost twenty years ago, I think actually here at Moscone, which is pretty awesome. In, uh, January of twenty-- uh, two thousand and seven, I believe, Steve Jobs introduced the iPhone. And I was in college, and I remember-- Or, yeah, like first year of college, and I remember this super, super clearly. It was the next great software platform that got built. So many companies got started because they could build on top of these devices, the smartphone revolution.

And there hasn't really been a moment like this since, I think, in the, the era of technology, at least for, for me. The stuff we did around B2B SaaS and cloud and all that is great, but this was a totally new paradigm, a new software platform.

And I think agents are this. Agents are the next big wave. And so what I would say to all of you is go out and build. With AuthMD, we're hoping to unlock this for you, unlock this for your business and for your growth. But we want to hear from you, hear the places you get stuck, and I think together we can build for this next exciting era of software and build for the agentic revolution. Thank you so much.