如何让 AI 智能体安全注册你的应用：WorkOS 的 Isabelle Williams 谈身份验证与授权

Brief Description

Using the Waypoint travel-planning app, this talk explains how agents can discover authentication options, try an app anonymously, connect their work to a real user through claims or identity assertions, and operate with scoped tokens that can be audited and revoked.

Table of Contents

• Intro
• The demo app: Waypoint
• Three questions for agent-ready apps
• auth.md: a front door for agents
• Anonymous mode and claiming an agent's work
• Skipping signup with identity assertions
• What is an ID-JAG?
• Demo: an agent signs up and plans a trip
• Why this needs open standards
• Limiting and revoking agents
• Demo: a scoped funding agent
• Takeaways

Intro

Hi everyone. My name is Isabel. I'm a product manager at WorkOS. Today, I'm going to be talking about how your next user is an agent. Briefly on WorkOS, we do infra for auth. We help you build apps, agents, APIs. We're trusted by over 3,000 customers including OpenAI and Propel and Cursor. For my presentation today, I'm going to be using an app that I live coded with Cursor. It's called Waypoint.

The demo app: Waypoint

It is a travel planning app both for individual use and for company travel. And we're going to use Waypoint today to help plan our trip to AIE in New York City. So, over the past year, but especially in the past few weeks with Muse and Instinct and the rise of personal agents, I've been thinking a lot about what this means for Waypoint. The first thing that I've been thinking about is how do I let agents into my app?

Three questions for agent-ready apps

So, when I think about the personal travel tier of Waypoint, before agents, it's really important from a product-led growth perspective to think about how human users discover my application, get signed up, and get to that aha moment really quickly. But when I think about how I'm using personal agents, and how I think others are going to be using personal agents if they're not already, is that they're going to be turning over a lot of that research, product discovery, and getting started with the product, and getting to that aha moment totally over to their agents.

So, I'm thinking about how it's going to be really important that I let agents do this with Waypoint. Now, as I got a little further into that thinking, the next question that I have is how do I connect those agents that are getting started with my product in this mode to real customers?

Finally, as I think more about how Waypoint works for company travel for corporate teams, there are compliance and financial risk elements to that. So, it's really important to me to make sure that I can limit what an agent can do and revoke it when I need to.

auth.md: a front door for agents

So, with those three questions in mind, let's talk through how I did them with Waypoint. So, the first thing that I'm thinking about, how to let agents in. If you go to this link here, it ends in auth.md. So, this is a real link. You can actually go to this, but it's not meant for us. It's meant for agents. auth.md is an open protocol that talks about how agents can register for accounts with applications. auth.md is a markdown file that you host with your application. And again, you can go to it and read it, but it's not meant for us. It's meant for your agent. It's where an agent can discover how to get started with your application.

It describes the mechanisms for getting access, for creating an account, and being able to call your API.

One thing that's important to remember with auth.md is that it describes access and operations, but your application, so in this case Waypoint, is the one that's enforcing auth through the API. So, in this auth.md file that I'm going to talk about for Waypoint and I'm going to demo, there's two modes to it. The first mode is allowing agents to try my application in anonymous mode. So, I want agents to be able to take limited actions to prove that my application has value without having to sign up and create an account. But to the second question I posed earlier, I really want these agents to be acting on behalf of users.

So, I want to be able to expand the available actions that I give to these agents when I can tie them back to a real user.

Anonymous mode and claiming an agent's work

So, let's jump into the first mechanism of the auth.md protocol for how that can happen. So, this flow goes from letting an agent try things out in an anonymous mode, and then a user coming in and claiming what that agent did and transferring the actions over to the agent account. So, the first part of this protocol is an agent being able to take anonymous actions at my API. So, in the end of this, the agent gets an access token, and then they get a claim token that eventually is going to let a user claim what the agent did and move it under that user's account.

So, the flow to this one, at some point when the user wants to take ownership of what their agent is doing, the agent can give them a link and a one-time code. The user comes over to my application, Waypoint. They sign up, they sign in, they enter the code.

They've claimed what the agent has done, they've brought it under their account. And finally, using OAuth, my authorization server can issue an access token on behalf of that user to the agent, and the agent is going to use that to call my API.

Skipping signup with identity assertions

So, this lets the agent do things, but you might have noticed there is a link and a sign-up flow and entering a code and verifying my email. And if you know anything about product-led growth, you know this is where you lose your user. But, doesn't my agent already know who I am? Like, when you guys use Cloud Code today, when you use Muse, you're signed in. And that service has done something to verify that you are who you say you are because they care about ensuring that you are probably a real person. So, they verified your email or something to that extent.

So, if the agent knows who I am, why can't the agent provider just tell my application who I am and let me in without me having to take manual actions? Well, that's also possible with auth.md.

So, I'm going to break down this protocol and the standard called ID-JAG that it's built on and I'll show you a little demo of how this works. So, to break this down, this starts with your agent discovering how to authenticate with your API. This is like standard OAuth parlance of finding out about your protected resource, your API, your MCP server, and your OAuth authorization server. And then things get a little fun. So, your agent is going to come to you as the user and ask for consent to share your identity and your email with the application Waypoint. If you consent, the agent goes to the agent provider.

So, your Claude agent goes to Claude and says, "Hey, give me an ID-JAG." Put a pin in that. I'll come back to what that is in a second. So, the agent gets the ID-JAG, sends the ID-JAG over to your API's authorization server.

Your application, your authorization server is going to verify that that ID-JAG is the real deal. It's going to see some information on you inside of it and then your app is in control of deciding, am I going to create an account for this user? Am I going to link it to an existing account? What sort of access am I going to give back in the access token to this agent? Your app is completely in control of that. And so finally, with that access token, the agent can call your API on behalf of the user. So, I said something, to use a Claude term, a little bit load-bearing in this ID-JAG. Has anyone here heard of ID-JAG?

I see one person, and he works with me, so that's funny.

What is an ID-JAG?

So, if you've been following what Claude is doing, what Anthropic is doing with enterprise managed authorizations in the MCP spec, what Okta is doing with cross-app access, that's using the same spec, the same protocol called ID-JAG. Let me break down what that is. So, ID-JAG, Identity Assertion Joined Authorization Grant. This is a spec in the IETF. Effectively what an ID-JAG is is an assertion of a user's identity. It's signed by an issuer. So, in this flow, the agent provider is the issuer. And it's sent for a specific audience. So, again in this flow, the specific audience is my application.

And let's break down what's in this. In the header, it tells you that this is of type ID-JAG, the algorithm used for signing, and the signing key. In the payload, this is where things get interesting.

It tells you who issued it, which in this case is the agent provider. It gives you information from the agent provider on the user. So, the user's name, their email, whether the email was verified. And then it tells you who it's for. So, the audience is my application Waypoint, and a client ID is a client that's known to Waypoint. And then finally, it tells you how long it's valid. And most importantly, it's signed by the issuer, the agent provider's public key. So, Waypoint, their authorization server, gets this ID-JAG. They are going to verify the signature. And it's up to Waypoint what they want to trust in this.

It's completely up to Waypoint if they want to create an account for this user, what sort of access and scopes they want to give in the access token that they hand back to the agent on behalf of this user.

So, let's see what that actually looks like in action.

Demo: an agent signs up and plans a trip

I am in an agent harness that I built here. This agent harness is able to issue ID-JAGs. I am logged in to this agent harness as Sam Rivera. I have an email, and this is a fresh user. Waypoint doesn't know anything about this user. It's never seen this user before. And I am going to say to my agent harness, let's see here. I need to put down my mic. So, I'm telling my agent harness, I want you to plan my itinerary for a New York City and I want to be able to share with my co-workers and I want you to find a tool that's going to do the planning and make it easy to share, all that good stuff. So, my agent harness is going and looking at tools.

It's finding some other travel itinerary planning tools like Maple itinerary, and it can't get through to there cuz it needs a browser sign up, TripIt needs an API key, but Waypoint allows for agents to sign up.

And so it asked me for consent. Can I share your name and verified email with Waypoint? I'm going to say yes. Waypoint's auth.md file also asked for some other consent for some more elevated permissions. In this example, it's allowing Waypoint to book dinner reservations with the agent. So, I give it my consent. And my agent harness is going to talk to Waypoint about this. Let's see what it does. Okay, it's verified my identity. It created my Waypoint account. I didn't have to do anything. Totally hands-off on my part. Oh, it booked a trip, dinner reservation, and my itinerary is ready to share.

Okay, look at that. There's my itinerary. It booked me dinner at Quality Bistro, which is quite good. If anyone has been there before, I would recommend it. It's given me a link that I can share with my colleagues. All that was done without any interaction on my part.

Why this needs open standards

The final thing I'll say on the ID-JAG part is that what I feel really confident in kind of this era of agents accessing other things is that for us to be able to do this safely and securely and in a trusted manner, it's going to all need to be built on open standards. We are all going to need open standards for agents to talk to services, do things, pay, and sign up for accounts. I'm really excited about the standardization work happening right now. A lot of things were announced just over the past week.

Limiting and revoking agents

Moving on to the last part of this presentation. How can I limit and revoke what an agent can do? So, for me this is really important in Waypoint because I allow for corporate travel booking. And I want to let corporate employees responsible for travel booking use agents. I want to build agents for them. But with this, there's real corporate money on the line. I need to be able to audit. I need to be able to make sure that money is not thrown around in ways that it shouldn't be. So, introducing a persona here. Jordan, Jordan's responsible for company funds at Jordan's company.

Jordan's the only one that can approve budget and approve the rules. Now, I've built a couple of agents into Waypoint for Jordan to use. The first one's read only. It's your classic chatbot that Jordan can ask, "Hey, what's wrong with the budget?" or whatever. And it'll tell it, but it can't actually do anything. But then I built Jordan a fund agent. This fund agent is going to actually be able to move funds around between users. Let's say that one user is flying from San Francisco and flights are really expensive compared to the user coming in via train from Boston.

And so Jordan wants to be able to move funds around, but as long as it's happening within the budget and the approved rules, Jordan doesn't need to manually do it himself. He can use the agent. But it's really important to Jordan that the funding agent can't go rogue.

It can't change the budget. It can't change the approval rules to make things work. So, how do I make this happen within my application? So, Jordan invokes an agent. And on the back end of my app, my app issues agent tokens. So, it's really important to me that I don't just hand an agent Jordan's user token. There's a few reasons for this. One is auditing and attribution. Two is revocation. I want Jordan to be able to revoke the agent. I want my application to be able to revoke the agent without impacting Jordan's session and Jordan's access. And then finally, I want to be able to limit what the agent can do.

I want to limit the scopes in the token. So, the way that I've set these agents up is I've created a blueprint or like a ceiling of access for the read-only agent and for the fund agent.

And when Jordan invokes them, the agent token that's issued for the agent, the scopes in it is the intersection of Jordan's user permissions and the scopes in the ceiling of the agent blueprint. And so then finally, the agent can call my API with a scoped agent token. So, I'll just briefly show you what that is and then I'll end with some QR codes here so you guys can check out all of this stuff.

Demo: a scoped funding agent

I am in Waypoint as Jordan. I am looking at my team travel here. I have a team budget. There is $70 available. Start up my read-only agent. All right. So, my read-only agent is started. If I take a look here at the session details, what we were talking about earlier with Jordan's user token, it's here on the left. I can see that Jordan has a bunch of permissions. The agent blueprint for the read-only agent is in the middle. It only has one permission. It has some session information. And then the agent token, it's issued by my application. The subject of the agent token is the agent ID, so it's attributable to the actual agent.

It's acting on behalf of Jordan the user, so I have that information in there as well. And the permissions are the intersection between Jordan's user token and the agent blueprint.

In the interest of time, I'm going to skip the read-only agent and just move over to the fund agent cuz it's a little more interesting. So starting up this fund agent, I'm going to ask it to fix Alex's budget. Okay, so Alex has a $250 shortfall. Do you want me to rebalance funds? Yes, rebalance. Hard to do while holding a mic. All righty, so the funding agent was able to move $70 over to Alex, but they can't fix all of it because there's no more budget available left. And the funding agent doesn't have the ability to change the budget, but I as Jordan do. So my user is still able with their user token to change the budget.

Let's change it to 2,000. So as the user I was able to do that. The agent couldn't. And then so I'm going to tell it I increased the budget. Okay, there we go.

And so the agent was able to fix Alex's budget. So really what we showed here is that how you can build agents into your application putting a ceiling on their permissions and they operate using an agent token with that scoped access instead of taking your user's token or an API key. So you can audit it. You can revoke it and you can make sure that you limit the permissions of that agent. All righty.

Takeaways

Coming back in here, I just showed that demo. So three takeaways here, how you can let agents into your application with an auth.md file, how you can connect them to a customer using the user claim flow in auth.md or the ID-JAG identity assertion, and then finally how you can limit actions by enforcing permissions and revocation. I'll end with some QR codes. The one on the left for auth.md, like I said, it's an open standard. And the one on the right is WorkOS agent auth, which is how I was able to build agents into my application with limited permissions using an agent token. And I will end my talk there. Thank you all so much.

And if anyone has any questions, I'm happy to talk about it after.