[
  {
    "startMs": 12980,
    "text": "Hi, everyone. My name is Isabelle. Um, I'm a product manager at WorkOS. Today, I'm gonna be talking about how your next user is an agent. Briefly on WorkOS, um, we do infra for auth. We help you build apps, agents, APIs. Um, we're trusted by over three thousand customers, including OpenAI, Anthropic, and Cursor. Okay. Um, for my presentation today, I'm gonna be using an app that I vibe coded with Cursor. It's called Waypoint. Um, it is a travel planning app both"
  },
  {
    "startMs": 43000,
    "text": "for individual use and for company travel. And we're gonna use Waypoint today to help plan our trip to AIE in New York City. All righty, 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? So when I think about the personal travel tier of Waypoint, um, before agents, it's, you know,"
  },
  {
    "startMs": 73020,
    "text": "really important from, like, 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 gonna be using personal agents, if they're not already, is that they're gonna 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 gonna be really important that I let agents do this with Waypoint. Now, as I got a little"
  },
  {
    "startMs": 103040,
    "text": "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, um, to real customers? And then 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, um, I can revoke it when I need to. So with those three questions in mind, let's talk through how I did them with"
  },
  {
    "startMs": 132900,
    "text": "Waypoint. So the first thing that I'm thinking about, how to let agents in. Um, if you go to this link here, um, 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, um, that, um, talks about how agents can register for accounts with applications."
  },
  {
    "startMs": 158720,
    "text": "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, um, and being able to call and use 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"
  },
  {
    "startMs": 188760,
    "text": "enforcing auth at your API. So in this auth.md file that I'm gonna talk about for Waypoint, and I'm gonna demo, um, there's two modes to it. The first mode is allowing agents to, um, 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"
  },
  {
    "startMs": 218780,
    "text": "to be able to expand the available actions, um, that I give to these agents when I can tie them back to a real user. So let's jump into the first mechanism of the AuthM-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."
  },
  {
    "startMs": 244520,
    "text": "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 something that, a claim token, that eventually is gonna 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"
  },
  {
    "startMs": 274420,
    "text": "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, um, my authorization server can issue an access token on behalf of that user to the agent, and the agent's gonna use that to call my API."
  },
  {
    "startMs": 295020,
    "text": "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 Claude Code today, when you use Muse, you're signed in, and that service has done something to verify that you are who you say they are-- who you"
  },
  {
    "startMs": 324960,
    "text": "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?"
  },
  {
    "startMs": 346440,
    "text": "Well, that's also possible with auth.md. So I'm gonna 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, so finding out about your protected resource, your API, your MCP server, um, and your OAuth authorization server. And then things get a little fun. So your agent is gonna come to you as the user"
  },
  {
    "startMs": 376316,
    "text": "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, you know, 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"
  },
  {
    "startMs": 406036,
    "text": "ID-JAG is the real deal. It's gonna see some information on you inside of it, and then your app is in control of deciding, am I gonna create an account for this user? Am I gonna link it to an existing account? What sort of access am I gonna 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."
  },
  {
    "startMs": 431316,
    "text": "So I said something, to use a Claude term, a little bit load-bearing, um, in this, ID-JAG. Has anyone here heard of ID-JAG?"
  },
  {
    "startMs": 440876,
    "text": "I see one person, and he works with me, so that's funny. Um, so if you've been following what Claude is doing, what Anthropic is doing with enterprise managed authorizations and 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 JWT Authorization Grant. This is a spec in the IETF. Um, effectively, what an ID-JAG is, is an assertion of a user's identity. It's signed by an"
  },
  {
    "startMs": 470876,
    "text": "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. Um, 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"
  },
  {
    "startMs": 500455,
    "text": "information from the agent provider on the user, so the user's name, their email, whether the email was verified."
  },
  {
    "startMs": 510236,
    "text": "And then it tells you who it's for. So the audience is my application Waypoint, and the 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, um, the signature, and it's up to Waypoint what they wanna trust in this. It's completely up to Waypoint if they want to create an account for"
  },
  {
    "startMs": 540216,
    "text": "this user, what sort of access they wanna-- what sort of scopes they wanna give in the access token that they hand back to the agent on behalf of this user."
  },
  {
    "startMs": 549236,
    "text": "So let's see what that actually looks like in action."
  },
  {
    "startMs": 554516,
    "text": "To give you a demo, um, so I am in an agent harness that I built here. This agent harness is able to issue ID-JAGs. I am logged into this agent harness as Sam Rivera. I have an email, and this is a fresh user. It-- 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, um, let's see here. Plan. I need to put down my mic."
  },
  {
    "startMs": 594636,
    "text": "Okay, so I'm telling my agent harness, \"I want you to plan my itinerary for AIE New York City, and I wanna be able to share it with my coworkers, 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, um, and it can't get through to there because it needs a browser sign up. TripLedger needs an API key, but Waypoint allows for agents to sign up."
  },
  {
    "startMs": 624796,
    "text": "And so it asks me for consent. \"Can I share your name and verified email with Waypoint?\" I'm gonna say yes. And then Waypoint in Waypoint's auth.md file also asks for some other consent for some more elevated permissions. In this example, it's allowing Waypoint to book dinner reservations with the agent."
  },
  {
    "startMs": 643536,
    "text": "So I give it my consent, and my agent harness is going to talk to Waypoint about this. Let's see what it does."
  },
  {
    "startMs": 656736,
    "text": "Okay, it's verified my identity. It created my Waypoint account. I didn't have to do anything. Totally hands-off on my point."
  },
  {
    "startMs": 668656,
    "text": "Oh, it booked a trip, dinner reservation, and my itinerary is ready to share. Okay, look at that. Um, there's my itinerary. It booked me dinner at Quality Bistro, which is quite good. If anyone has been there before, I would, I would recommend it. Um, it's given me a link that I can share with my colleagues. And all that was done without any interaction on my point. So that was pretty cool. Um, what I'll-- final thing I'll say on the ID-JAG part is that, um, what I feel really confident in,"
  },
  {
    "startMs": 698716,
    "text": "in, um, 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 gonna all need to be built on open standards. Um, we are all going to need open standards for agents to talk to services, to do things, to pay, to sign up for accounts. Um, so I'm really excited about a lot of the standardi-standardization work that's being-- happening right now, a lot of the things that were announced, like just over the past week. All right. Moving on to the last part of this presentation,"
  },
  {
    "startMs": 728616,
    "text": "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, um, 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"
  },
  {
    "startMs": 758568,
    "text": "here, Jordan. Jordan's responsible for company funds at Jordan's company. Um, Jordan's the only one that can approve budget and approval 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. Um, and it'll tell it, but it can't actually do anything. But then I built Jordan a fund agent. This fund agent is gonna actually be able to move funds around between users. Let's say that one"
  },
  {
    "startMs": 788508,
    "text": "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"
  },
  {
    "startMs": 818348,
    "text": "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 wanna be able-- I want my application to be able to revoke the agent without impacting Jordan's session and Jordan's access. And then finally, I wanna be able to limit what"
  },
  {
    "startMs": 848348,
    "text": "the agent can do. I wanna limit the scopes in the token. So the way that I've set these agents up is I've created a blueprint, like a ceiling of access for the read-only agent and for the fund agent. And when Jordan invokes them, um, 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 access. Uh, sorry, a scoped agent token."
  },
  {
    "startMs": 878628,
    "text": "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, um, all of the stuff. So I am in Waypoint as Jordan. I am looking at my team travel here. I have a team budget. There's looks like seventy dollars available. Start up my read-only agent."
  },
  {
    "startMs": 898788,
    "text": "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 Jordan has a bunch of permissions. The agent blueprint for the read-only agent's in the middle. It only has one permission. Um, it has some sess-session information, and then the agent token, it's issued by my application. The subject of the, um, agent token is the agent ID, so it's attributable"
  },
  {
    "startMs": 928748,
    "text": "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. Um, so, um, in the interest of time, I'm gonna skip the read-only agent and just move over to the fund agent 'cause it's a little more interesting. So starting up this fund agent, I'm gonna ask it to fix Alex's budget."
  },
  {
    "startMs": 969068,
    "text": "Okay, so Alex has a two hundred and fifty dollar shortfall. Um, do you want me to rebalance funds? Yes. Rebalance. It's hard to do while holding a mic."
  },
  {
    "startMs": 986828,
    "text": "All righty, so the funding agent was able to move seventy dollars 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 two thousand."
  },
  {
    "startMs": 1013188,
    "text": "So as the user, I was able to do that. The agent couldn't. Um, and then so I'm gonna tell it, \"I increased the, oop,"
  },
  {
    "startMs": 1024648,
    "text": "budget.\""
  },
  {
    "startMs": 1036868,
    "text": "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, um, 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. It's, um, yeah, you can audit it, you can revoke it, and you can make sure that you limit the permissions of that agent."
  },
  {
    "startMs": 1064048,
    "text": "All righty. Coming back in here, I just showed that demo. Um, so three takeaways here. Um, 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. Um, the one on the left for auth.md, like I said, it's an open standard. Um, and the one on the right is WorkOS Agent Auth, which is how I was"
  },
  {
    "startMs": 1093928,
    "text": "able to, um, 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."
  }
]