Agent ready episode 4 with Stytch: identity, auth + consent for AI agents

It’s time for the fourth episode of our agent-ready video series. This time, we’re tackling identity, authentication, and consent for AI agents, as well as and how MCP servers can securely expose your app’s data to these agents. Learn how to adapt trust models, extend OAuth-style delegation, and design secure, scalable flows that let agents access data safely. This video features Reed McGinley-Stempel and Max Gerber from Stytch.

Video overview

AI agents are gaining autonomy and acting on behalf of users, but most identity and authentication systems weren’t designed with agents in mind. Traditional patterns assume a human is directly at the keyboard, granting consent and bearing risk. With agents, we introduce a new layer of indirection and ambiguity. That means modeling trust relationships between users and agents, establishing authentication flows that aren’t tightly coupled to UI, and creating auditable consent mechanisms that persist across agent-initiated actions.

You'll come away with an understanding of:

• Recommended architectural patterns for agent identity
• How to extend OAuth-style delegation to agents
• Where standards exist and where they fall short
• New primitives developers may need to build — from ephemeral credentials to consent receipts — to maintain user and organizational trust

We’ll help you think through how to evolve your auth stack for an agentic future, where delegation and control are critical.

Full transcript

Reed: Hi, I'm Reed. I'm the founder and CEO here at Stytch, and I'm joined today by my esteemed colleague, Max. Max, why don't you tell us a little bit about what we mean when we're talking today about how to make your app agent ready and what you'll be covering?

Max: Yeah. So my name is Max Gerber.

I'm a software engineer at Stytch, and I've been working in the identity access management space for about. About eight years now, we are thinking a lot about how do we take existing software, existing systems, and open them up for Agent access. So how do we take things that are already out there, tools we're already using that have our data and make that data available to tools like ChatGPT or Cursor or Claude in secure and scalable way.

Max: So today I am gonna be talking a little bit about identity and access management, kind of basic concepts. I'm gonna talk a little bit about the OAuth protocol. I'm gonna talk about how you can apply the OAuth protocol to AI use cases to share your data with an agent. And then I'm also going to talk a little bit about a demo at the end showing this in action.

Reed: Great. Excited to hear that. I know throughout this video series. We'll have folks talking about how to build agents. I think what I'm particularly excited about with your talk is how do we make the current world ready for agents? How do you enable existing apps to function with agents so quickly? Excited to hear this side of the coin.

Max: Yeah. Yeah. I'm very excited to, to show it. So first, I guess we probably should mention what Stytch is, why we're talking about this, why we care. We both work at Stytch. Stytch is a consumer identity and access management company. So we help people add authentication, authorization features to their applications. Things like login and user management.

I spend pretty much all my free time trying to help people become OAuth identity providers. So we've got a nice little react component that they can drop into their application. And with the idea that if you become an identity provider, you can share data with agents and AI in a safe and secure way.

Reed: I also don't think it's an exaggeration to say that you probably do spend all of your free time helping people think about how to become OAuth2 compliant. So I'm excited for people to learn from someone like you.

Max: I’ve touched on this a little bit previously. We really wanna make existing applications agent ready.

Max: So how do we take the data that already exists, expose it to agents, expose it to LLMs, expose it to chat GPT and Claude and so on while also providing great experience. Not only for the users who want everything to just work, but also for the IT admins out there who want to have really strong control over how their organization’s data is shared.

Max: And we'll probably touch on this a lot during this video, but there's a really big difference in how data flows in consumer applications versus business applications. And when I am working with a consumer application and I'm the user, it's. It's my data. I really want to be able to push it wherever I want.

Max: I want things to just work and get outta the way for me. And that's very different from a business or an enterprise application where the data doesn't actually belong to the user. The data belongs to the company, and you're looking to get the IT admin approval for how that data moves around.

Max: If every company out there starts sharing their company secrets with ChatGPT, I'm sure a lot of IT admins are gonna be having a bit of a conniption.

Reed: Yep. We wanna keep Howard (our in-house security and IT expert) happy. As I, when we talk about how we expose agents to employees at the company and allow them.

Max: There's a frequent identity in our internal documents. Yes, where I come from is primarily this consumer or customer identity and access management use case. So we have people who have existing products and maybe they have an existing API, maybe they don't, but they're trying to repackage this API for consumption by agents that they more importantly they don't own.

Max: And I think this is a little bit different from other people who are talking about exposing data maybe within a company, like taking company data from this team, exposing it to an agent, ran by this team. We really think about how do you take data from one organization and share it outside that organization and the outside world, which has a much different set of security considerations.

Max: And this also means that. At my level of the stack, I'm not thinking too much about actually building agents. I'm thinking about building tools that agents can use. So really good example of this in the real world is Notion. A tool we use every day, a tool we love. Notion both has Agent and LLM experiences built within the platform that have access to notion data.

Max: But you can also use Notion as a tool in other systems. You can say, Hey, ChatGPT, I want you to read my Notion database and look at all the issues there. And the sharing and security model between a Notion owned asset, talking to a Notion owned asset and the notion owned asset, talking to something just out there in the world is gonna be really different.

Reed: Awesome. Makes total sense.

Max: And so we see a lot of these companies we're talking to, they want to figure out agents and what agents means for them. And for a lot of companies, this means taking their existing product, their existing data, and serving it up as a tool for these agents to consume. And really it's like a renewed interest in how do we share data?

Max: How do we decentralize the internet? And that's a really exciting, really fun thing. I, my favorite example of this there's this company BodySpec. They do DEXA scans. So they go and they stick you on a table and they scan you and they say you have this much bone density and it's a bunch of, nerdy little numbers, and they give you a PDF at the end.

Max: And I was super surprised. I got sniped by the craziest Reddit ad that was like, “hey, there's a BodySpec MCP server now”. So this company that you never even think oh, they should have an API that will be super useful. They now have an MCP server and you can take your scan data, dump it into ChatGPT, and it'll tell you, all about it and it'll give you insights.

Max: And this is something that is really beneficial for the company because they have a huge value add here. They really want to get their data to ChatGPT because it makes their existing product better and stickier.

Reed: Yeah.

Max: And they need to figure out how to do that in a safe and secure way.

Reed: And I think that's a great example. And maybe one more, if just like fleshing out a little bit of context for people on why BodySpec wanted to become agent ready. From that explanation, it sounds to me like yes, maybe they could have built like an agent embedded in their application. Probably it's not a super heavily used application after maybe couple of times that you use it and review your initial data.

Reed: And then two, my guess is they wanted to stand on the shoulders of giants, which is GBT's functionality to be able to not have to build the in-house AI expertise of what it meant to build that agent. Does that seem accurate or is there anything else that you'd add?

Max: Yeah, absolutely. Okay. I think the other thing that I'd add is when you allow ChatGPT to be in the center of it all.

Max: Now your customers can start taking data from all sorts of places. So you could take like your BodySpec data and then maybe you've got some dietary data over here. What food you ate over the last 24 hours. And you can combine that really efficiently in ChatGPT. But if BodySpec is trying to build like their own in-house chat bot and maintain integrations to all of these other systems and also become AI LLM experts, like that's a tall order for them.

Max: So the ROI of, push this data out, make it open, make it available, is much higher.

Reed: And have you already connected the BodySpec MCP server to your ChatGPT?

Max: I have, yeah.

Reed: Is there anything, any interesting insights that you did not previously realize? You don't have to share too much, but maybe the course of the feedback.

Max: Yeah I run a lot and the bone density of my legs is like 95th percentile, which apparently is common for runners, but also means I'm really bad at swimming. So I'll, it's a good, convenient excuse. I've always been a bad swimmer and now that's gonna be my excuse as to why I'm a runner.

Reed: Okay, great. No that's a fantastic example and I think to your point, makes a lot of sense why applications like BodySpec would be embracing this, just in terms of the value it can give to the users, the stickiness, and they get to skip the need to build out this massive in-house AI team, but still get all the leverage out of it.

Reed: Great.

Max: And what's also really exciting is we've been sharing data over the internet for pretty much as long as we've had an internet. There's never been a time where people weren't trying to take data from one place to get somewhere else. And there are a lot of standards and a lot of thinking that have already gone into solving this problem.

Max: And OAuth has really emerged as the dominant standard over the last couple of decades of research and experimentation.

Reed: And now I'm excited for what I think we're about to dive into, which is, a little bit more explanatory on OAuth and where this fits in. Because I have to tell you, my parents subscribe to our changelog and my parents are not technical. And so every time I see them, and I just saw 'em this past weekend.

Reed: I get a comment from either one of them where “looks really cool, but I don't understand anything that you're shipping.” And so I'm excited that I think by the end of this video or this section, that I could send this to them and maybe they'll understand what OAuth is, which is not something I've ever tried to explain before.

Max: We're gonna talk a little bit about authentication and authorization. Basic concepts and definitions. We're gonna go into the OAuth protocol and then we're gonna apply the OAuth protocol to MCP. So authentication and authorization, two words that are often in very similar domains, sound very similar, mean, quite different things.

Max: Authentication is the process of determining how do I know who you are. You say that you're Reed, but how do I actually know that you're Reed? In real life it's pretty easy, but over the internet there needs to be some way to assert someone's identity. Otherwise, your bank account is just gonna be handing out information to anyone who says that they're Reed.

Max: And there's a lot of different ways for this to happen with end users like you and me. We have, emails, we have passwords we have tools like SAML, SSO and then plenty of other things that can be added on top, like two factor SMS OTP. There's all sorts of tools that go into verifying who a user is.

Max: And in the same way that we need to verify users, we often have to verify devices or applications. So if I have a service out there, I've got a machine talking to another machine. How do you identify a call coming from a machine that might not have an email address or a phone number? And there's another set of tools like API keys or client secrets or cryptography that can help you there.

Max: Authentication is ultimately about answering a question. How do I know who you are? Yep. And authorization is the thing you want to do immediately after you answer the authentication question. Authorization is, how do I know you're allowed to do what you're trying to do? So if you're viewing, going back to that bank account example if someone is saying, I want to view this bank account.

Max: Are they authorized to do that? Do they have a relationship with this bank account? Do they have permission? Are there many different ways for systems to govern permission? There's a lot of different tools like RBAC, ABAC, like reBAC. There's FGA. It's, a lot of acronyms.

Max: And it's a very big space. And compared to the identity portion, it's a bit less standards driven. It's a lot more, there's many different approaches to solve the same problem depending on what companies need to do. But the ultimate goal is to determine, for a request coming in from the internet.

Max: Alright, we already know who you are now. Are you allowed to do the thing that you're trying to deal?

Reed: Yep. Yeah. The analogy I sometimes use with folks that you know are lessened to the off end and not see space is the airport analogy of the authentication is when you go through security they check your license or “are you Reed”, and then when you actually wanna board a flight, get on a particular seat. They have to authorize that's actually the, flight that you paid for, your seat is 5B or 15C or whatever it is. I still wouldn't say my parents necessarily get it, but they understand the shape and it a little bit more after that.

Max: This doesn't work too well with the FAA, example 'cause, but when you have these authentication and authorization concepts, you can combine them into delegation where given identity in a system can try to give its permissions what it's authorized to do to another identity in the system.

Reed: And the FAA was really the worst analysis. It could be used to tee you up on this.

Max: Yeah, if you go through security and then you go and you hand your passport to someone else

Reed: (don't try this at home)

Max: Oh, yeah. End up on some watch list by the end of this. And so the important part about delegation is I have a set of permissions, I can give those permissions to you or to an application or to an AI agent.

Max: But I can't give more permission than I have. I can only give a, preferably a subset of my permission. So if I am sharing information, let's say in Google Drive. I might share access to a single file with you, and I might give you viewer permission. I could also give you, editor or I could give you access to a folder, but I'm not giving you access to my entire Google account.

Max: I'm just giving you access to a small portion of it. And so delegation is a, again, a big topic and there's lots of different ways to implement it. Within a platform, like with Google, that delegation mechanism, Google can share what, access to what files, that's all proprietary. That's how it works within Google.

Max: But when you have delegation mechanisms between different applications owned by different people, OAuth has occurred as the most popular mechanism. Delegation is really common between users and apps. Today, I as a user will authorize some applications to access data on my behalf.

Max: And really what the agent push is about swapping in the word agent for the word “app”. I want to grant this agent the ability to edit my data to process payments on my behalf, to do things using my identity and my permissions without me necessarily being the one making every single decision.

Max: Yeah, all. Let's talk about OAuth. It's gonna be more exciting. So OAuth is a collection of protocols for interservice authorization on the web, and it's a pretty big space. There's over 40 published RFCs from multiple organizations like the IETF and the Open ID Foundation. And what I really love about OAuth is it enables you to stand on the shoulders of giants.

Max: A lot of people, much, much, much smarter than me have spent many years getting this protocol in a really good state. And if I go and use the protocol, I don't need to solve all the problems that they already solved, like borrowing decades of research and development out there available for free with a rich ecosystem. I get excited.

Reed: That's a good point you make because something I've seen maybe from folks- it seems to me- like there may be less deeply entrenched or involved in the auth community, is I'll hear people proposing net new standards for viewing this. And I'd just be curious to hear your thoughts on that.

Reed: Like I've been pitched over the last couple weeks by different folks, small companies like OAuth three, a different type of OAuth for just AI agents that's not necessarily building on all of it. And so I thought your point about everything that's already been solved, how much can we extend it to continue to solve the other challenges is just maybe a good point to share a little bit more on 'em, how you think, like why you think this will continue to be maybe the basis or primitive for budget, these experiences?

Max: Yeah. OAuth isn't static in the sense that it's a solved problem. It's still a very rapidly changing space in compared to, other fields like maybe physics.

Max: OAuth goes through a standards process and there's a standards body that meets a couple of times a year. And they will go and look at the active issues with the protocol and figure out ways to address them. But they are still participating in the ecosystem and they try really hard to build on what came before and to not make breaking changes.

Max: And so sure, you can go and start completely from scratch with something and you'll be able to go really far, really fast when you don't have to deal with legacy implementations and considerations, but you also lose all the benefits of the ecosystem. So if somebody comes up with a OAuth 3.0 that's completely different or some new authorization standard, then there's no tooling for it.

Max: There's no library for it. Versus if I go and I try to introduce somebody to OAuth, there's hundreds of hours of documentation on YouTube. There's client libraries in every single language. There's tons of OAuth identity providers out there. And that's really powerful. And attaching yourself to that ecosystem is I still think for 95% of the world is the right move.

Reed: I think that's a great explanation and I think you summed it up well, that kind of, that framing of if you want to go fast, go alone. If you wanna go far, go together. So thank you for that.

Max: So OAuth is really about taking user data from one place on the internet and sticking it somewhere else, and it describes a framework for how the user and the service provider, the one owning that data, can agree how this data should be.

Max: And OAuth flows are all over the place. I can use OAuth to sign in from one website to another. I can sign into Farmville with my Facebook account. I can use OAuth to sign in from a website to a native app. So if I go and I open up Slack, I log in using my website, using the Slack website, but I end up in the Native app experience and my favorite is native app to tv.

Max: If you're going and you're sitting on the couch and you're trying to log into your Netflix account, you get that nice QR code on the screen, you scan it with your phone, and then suddenly you're logged into your Netflix account on the TV. That's also OAuth.

Reed: Yeah. Yeah. I think it's a great reminder of, without OAuth, how painful that experience would be if you're trying to click around in order to enter a password. And so one of the many ways that lot has made our daily lives better.

Max: What is it? 12 characters. An uppercase, a lowercase, yeah. A special character on your TV remote. Yep. So we'll do a little bit of OAuth specific terminology. We've got the authorization server or the identity provider.

Max: Going back to that Netflix example, netflix.com is gonna function as our authorization server. And the authorization server's job is to validate the user's identity. You are who you say you are. And then once the server knows that it's going to issue an access token or it has the ability to issue an access token we have a resource server.

Max: This is gonna be like the Netflix servers up in the data centers that contain all of the movies. And this resource server has simple data, but it's only gonna give that data out if you give it an access token. And then finally we have an OAuth client. The OAuth client wants to access the data and the resource server but needs an access token in order to do so and this access token allows it to assume the permissions of the user. And our Netflix television, Netflix enabled television is our client. So OAuth is really all about these access tokens. They're the underlying thing that we're all here to get. Access tokens have some really nice properties.

Max: They're scoped to the user who granted them, so they have the permissions of the user and the client can't do anything the user couldn't do themselves. So they have that delegation aspect we talked about earlier. And the user can narrow down the permissions that they're granting to the client through mechanisms within the OAuth protocol.

Max: The most common is using a mechanism called a scope. So I will go and I will grant my television the “watch movie” scope, but I'm not going to grant it the “edit credit card” scope because I don't want my television to have access to my billing information. And so here is an example of the most common OAuth flow, the auth code flow.

Max: We're not gonna spend a tremendous amount of time on the details of the flow. There's a lot of really good resources out there. But the point I wanna make is we've got all of these blinds between two different applications between your app and here we, we broke from the Netflix example, we're doing Google instead and OAuth defines the lines in between.

Max: OAuth defines the mechanism by which your token can be requested. It defines the mechanism by which the server responds. It defines some intermediate steps but OAuth doesn't say anything about how your application behaves outside of these lines. Okay?

Max: So OAuth doesn't say, “this is how we user should log in”. Should they use a password? Should they use an email? Should they do something else? OAuth doesn't say how do you ask the user to consent to their data being shared? So sometimes you can say, I don't need to ask the user anything because I own this identity provider. I own the client. I don't think Netflix says, do you want to share your data with your tv? They just assume that you do.

Reed: Yeah.

Max: And then in other cases when you have third party applications being built. You want to be very careful letting the user know this is exactly how your data is gonna be shared, this is how this application says it's gonna use your data, or do you agree to share this data or not? And all of this is really up to the application to decide and to build out. Let's talk about OAuth and the model context protocol. So I'm not gonna go super far into what the model context protocol is or how it works.

Max: I am going to have some opinions about it though. Essentially the model context protocol is a standard way for LLMs and agents to access external data sources. Whether that's a file on your computer, whether that's a GitHub repo or something in Google Drive or your Slack account.

Max: Instead of having all these point-to-point integrations where ChatGPT has to integrate with Slack, and then Cursor has to integrate with Slack and Codex has to integrate with Slack everything just agrees to speak one standard unifying protocol and we don't need to deal with all that point-to-point code.

Max: Yep. And the first iteration of MCP came out of the language server protocol, and it was entirely local only. And I think that this was a false start for the ecosystem. Local only is really great for dealing with local only files, or maybe playing a song or stopping a song or doing video editing.

Max: But most of my time on the computer, most of my files, most of my important data isn't on my laptop. Yeah, it's in the cloud. It's in different providers. And a lot of early MCP tool choices like seeking to address this issue were using API keys. If you were using the Jira MCP server, the Jira MCP server asks you to go and download a piece of code to, to run locally and then go out and get an API key and then drop that in as an environment variable.

Max: And if you're watching this video if you're in this room, like that's probably totally fine. We are here because we're technical. We're having a technical discussion about AI and agents. The idea of setting an environment variable or running a little bit of code downloaded from the internet, like A-ok, by us, but that's a huge adoption barrier for the rest of the world.

Max: I remember having a conversation with my sister where she's like “what is a pip? What is a shell? What is a Python? Why do I have to go through all this? Is this a zoo?” And downloading software to be executed locally is a bit of a security nightmare for some folks. It's very difficult for non-technical people to be debugging what version of Node they have installed and why is something, not on their execution, pat and all sorts of nonsense.

Max:. API keys are hard to administer. Now, let's say you were trying to roll out some sort of LLM based learning software to a whole bunch of people on a high school campus, and you had to give every single high schooler their own API key.

Max: I don't know how well it would go. I don't think it would go very well. And so we've seen a much bigger push recently to remote first servers that are hosted in the cloud. Yep. And we've seen a much bigger push to having these servers gated through OAuth.

Reed: Yeah. Makes a ton of sense. I think just seeing the UX from some of the local MCPs to setting up just on my own, their MCP, it does feel like something I could show to my parents.

Reed: They could get the value of it. That they might not understand everything that's happening in the background, but they could, at least in their remote MCP server use case, I think could start, if they wanted to analyze their BodySpec scan and data in ChatGBT versus just not possible months ago when it was just local.

Max: Yeah. And we've seen already I think Cursor and VS code have one click MCP installations. And it's so nice. You don't have to deal with your MCP JSON file anymore. You don't have to deal with all sorts of things. It's just the click of a button, MCP server installed, and it's very nice.

Max: So mapping OAuth onto the MCP protocol, MCP clients are OAuth clients. So our agents, our LLMs and MCP servers are OAuth resource servers. They have access, they have data stored with them, and they're only going to expose that data given a valid access token. And this means that MCP servers need authorization servers to give out access tokens that the MCP servers can validate.

Reed: Great. So now I feel like we have a much better sense of OAuth and where MCP servers fit in. I'd love to make it a little bit more tangible and concrete for the audience. Is there a demo you could show us just to, walk through a little bit more visuals?

Max: Yeah, absolutely. So I'm gonna fire up the MCP inspector.

Max: This is a tool that you can use to kind of debug and diagnose, MCP servers and investigate, what you can do with them, what tools do they provide. And fortunately Stytch is an MCP server. Would you look at that? So we're gonna go and we're gonna run through first the OAuth flow in like super fine grain detail, and then we're gonna show the end result and the data that's being stored and passed around.

Max: Good. All right. We're going to go through the advanced off settings and walk through the OAuth debugger, which is a really well put together tool. And what this is gonna do is show us every single step that the MCP inspector goes through when it's kicking off an OAuth flow, and give us a peek under the hood and all the requests and responses.

Max: So the first thing that the inspector is gonna do, reaching out to this MCP server, is it needs to learn, “who is the authorization server that this MCP server trusts? Where should it direct the user to go and log in, and come back with an access token?” So it makes this request, it gets the authorization server.

Max: And then it makes a request to the authorization server and finds out information about where the user should go to authorize the request, where tokens should come from and so on, and a whole bunch of metadata here. Now the inspector is going to register itself inside the AS. We see it goes, it sends off a request.

Max: It says my name is MCP Inspector. I want to use the authorization code RAN type, and it is issued. A client ID now can use this client id to put together an authorization URL. And it's gonna ask the user to visit this. And this really kicks off the OAuth flow. This is how the MCP inspector asks the user, “Hey, please grant me access to your account with these scopes, with these permissions.”

Max: Yeah. So we'll go, we'll click through here. And we're given a little consent dialogue that explains exactly what resources the inspector is asking to access how it wants to use this data, what we'll be able to do. And of course I'm gonna allow this and so I get back an authorization code.

Max: And if I give this authorization code to the inspector, then I see that the inspector is issued an access token and we're all logged in now. Hopping out of the debug mode we're gonna go through an OAuth flow in the regular mode and we find out it worked. We're logged in. And now we have tools that can actually interact with the My Stytch project account.

Max: So let's go and create a project. We're gonna call this “Great Demo Reed and Max.” This is gonna be a consumer project, okay? And this works. Now if I go into my Stytch dashboard.

Reed: Wow. Able to control everything from the chat interface and or any other AI clients and AI chat bots. So very cool to see it all come together there. So

Max: So, my theory, my hypothesis, if you take away anything from this video, I think that you should be an OAuth Maximalist. I think that your product that you make should be an OAuth provider, and I also think that the products that you use day in and day out should be OAuth providers as well.

Max: And if you are an OAuth provider, that's gonna mean that you can share your data with these LLM’s and with these agents. And if you're using products from providers, you get to take your data from all these disparate systems and give it to your agent and let your agent do really cool things with it. And I think that's really exciting.

Reed: Awesome. Thank you Max. I'm sure you're leading the charge on the new OAuth MAXimalist terminology. Maybe there'll be a subreddit that you'll be administrator for in the future there where people can join. But in all seriousness, just wanted to say thank you for walking everyone through that. As a kind of quick reminder today we wanted to walk through what it looks like to make your existing app agent ready.

Reed: We'll be walking through a lot of similar series, but different topics around how to apps. And how has the world become agent ready? Such as how do you build agents, how do you secure them, observability, things like that. And so we hope that you join us for the rest of those sessions as well. And until then where can folks find you online if they wanna follow you or hear more about what you have to say?

Max: There's the Stytch Slack group. Oh join that and ask about agents. There's also an MCP Discord Group, I'm pretty active in. Great. Oh. And LinkedIn, Max Gerber. Awesome.

Reed: Thank you Max. And yeah, we'll be excited to bring you more content soon and thanks for tuning in.