# Auth for Agents: Unblock Autonomous AI with auth.md — Michael Grinich — session 2026-07-02T18:40:00.000Z → 2026-07-02T19:00:00.000Z

_83 transcript lines · 0 slides · source: full recording_

## Transcript

You are in the same character that the cap that the couple interacts with, so you mustn't fall in. There you go. Hello, everyone. Good morning. My name is Michael Greenwich. I am the founder of WorkOS, and I'm here to talk 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 are working. It was this human agent, human agent back and forth. However, as 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 the whole feature, maybe even a whole product, and maybe run for not minutes but, 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 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 do you can keep in your mind to keep all 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, it's 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 have 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, or 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 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 Well, first they need a run time, 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 with the power of the intelligence in them, it's kind of 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 they can actually run and validate, that they can check that their work is correct. And if it's not correct, keep going. And 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 it as like an It's like a really high performance, you know, I think this is a a v eight engine. You know, puts out a lot of horsepower. It 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 drive train. 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 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 need this feature and this feature, and I'm gonna need a database, and I'm gonna need, you know, this entity, you know, system to deploy, and I'm gonna need, you know, maybe this thing for imagery sizing or video transcoding or sending email or whatever. Then 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. There are 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, kind of popular thing that people say in San Francisco, 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 wanna 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 is 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 log in 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 Good automated user versus a bad automated user. If any of you have used any of these cloud based 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 When 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 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 you can bring the user's identity with it. Or if you have a, you know, open claw or like your pie harness 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, credentials, 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 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 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 m c p requires your human to still be in the loop. You give consent. You add an m c p server, say for post hog to claud, you sign in with your post hog 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 with this is a new spec we have called auth dot MD because markdown files are the future, right? Well, how does this actually work? What is auth dot md? Well, the idea here is that auth dot 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 consi- 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, you know, connective services. We're just trying to solve this narrow one around registration. 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. Often, do you can answer what does the service do? It can tell agents how to register. It can tell them what identity proofs are accepted, how an agent or a user is proving their identity, what off flows are supported. Can you sign up with SSO or email address or an K. What scopes and entitlements 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 could sign up, but you want the human to have custody later on. This is what authend is designed to solve. These are the big questions around the registration. So how does this actually work? Well, here's a little, kind of 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 whatever coding harness or system. I'm using py or cloud or something. And it says, welcome back, michaelworkos. That's actually my email, if you want to email me. Do you want to 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, local host only works on your machine, so your friends won't be able to hit it. Course. To share it, I need to deploy it somewhere real. Some providers actually let me handle the sign up 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 an example, Stratus, Helio Deploy, they don't support it. But Cloudflow here does have an authmd. And so the agent here can say, ah, Cloudflow, that's the one. Cloudflow is a winner because I can go sign For it. I can access the 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 kind of 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. Authentee 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 maybe don't want to give anything away for free. It's very application specific. So here, Cloudflare says, okay, we're willing to let you deploy, maybe for seventy two hours or something like that. Get the identity search and 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 human, I didn't go click anywhere. I didn't sign up anywhere. 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 to 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 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 authend or whatever service. We also have this working with Fire call. It's pretty cool. It sends that ID JAG, the identity, 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 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 this 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, 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 auth md 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 And 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 x four zero two. 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 or on the headless type of products, this is Marc Benioff. He's the CEO and founder of Salesforce, the guys at the big building here in town. They believe in agents more than anything. Our API is the UI. Entire Salesforce and Agent Force Slack platforms are now exposed as API, MCP, and CLI. Talk about going Agent Fort 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. Work OS 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 use our 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 January '20, 2007, I believe,

## Slides