エージェントにも OAuth2 が必要だ

Hey, your open finance prototype works. Now, make it production ready with MasterCard APIs. Access permission financial data at scale on infrastructure designed to meet the security and reliability standards that financial services demand. Head to developer.mastercard.com. Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we are on the floor at the LDX3 conference, and we are talking about what's OAuth 2 mean in the agentic era. And my guest for that is Dan Moore, who's a senior director of science strategy at FusionOff and contributor to the Stack Overflow blog. Welcome to the show, Dan. Thanks for having me, Ryan. At the top of the show, we like to get to know our guests. Can you give us a little field of how you got into software and technology?

Sure. So I remember helping my parents out. They ran an insurance brokerage, and the thing that got me into software was mail merge, believe it or not, because it just saves so much time in terms of physical letters. Kids use mail stuff via physical letters, and after that, I was kind of hooked on solving people's problems with technology, which is something that I still do at FusionAuth today. With AI agents, people are letting AI agents operate on their software and their accounts run rampant. And there's this, you know, questions of identity and user access. And, of course, you know, you've written for us really great guide to OAuth 2. What does OAuth 2 mean in the AI agentic era? Is it the same sort of thing? I would say that OAuth 2 is both the same kind of thing and different. And the reason why I love OAuth and other standards is that they are foundational building blocks that can be adapted over time. And so we are seeing some standards that are decades old that have been incorporated into some of the newer things,

like some of your listeners may have heard of the model context protocol. Sure, yeah. And when that came out in early 2025 or late 2024, it had no identity, no security, and it was still useful. and so people adopted it. And over the past year and a half, OAuth 2 has been integrated into it, and not just OAuth 2, but related to standards. So things like the resource URL, OAuth 2.1, some of the metadata stuff. And so what you're seeing is, wisely, I think, some of the groups that are talking about solving problems with AI are building on top of these really foundational, solid standards. Right. Is there an implementation attached to that, or is it just the standards and additions of standards? So it really is referencing the standards. Because both MCP and OAK2 are standards. You have to implement it yourself. Yes, correct. I will say that MCP is also driving some standards too. There's one called the Client ID Metadata Document, which is dealing with the problem of OAS and its foundation

kind of expects the thing that is asking for the token to be something that's known to the authorization server. And MCP clients like agents or other AI tools don't know which authorization server they're going to talk to to get that token to be able to talk to the MCP server. It's kind of nice because there's this interplay. OAuth is a supporting set of standards, but it's also being driven a little bit by some of the new needs of this agentic era. The OAuth 2.0 standards, it's pretty comprehensive. There's a lot of stuff in there that is optional and not much used. But I know sort of foundational part of it is the redirect to the login provider. Is that changing for AI agents? So a couple of things. One is actually OAuth 2.1, which has been in progress for a while. It's an effort by the OAuth Working Group to sum up all of those different standards in the kind of one kind of refinement so that everything we've learned since 2012 is incorporated. The redirect is still important because the AI agent basically gets a marker that says the user has authenticated

and then can exchange that for a token. And it's not necessarily the LLM, but it's the stuff around it. But, I mean, one thing that's worth noting is that is the case where the human is delegating authority to an agent, which is one major use case. There's another whole use case of the agents acting on their own, which is kind of a different set of situations. Yeah, that's the sort of case where it's like the human can't go in and sort of log in for them, right? Are there ways that the agent can sort of autonomously do it? 100%, yes. So listeners may be familiar with service accounts, and so there's a similar kind of mindset with agents. The difference there is less on how you get the token, which is still kind of like the straight-up client credentials grant, and more bounding what the agent can do outside of it. Because when you're doing stuff with service accounts, you know, it's deterministic software that you're writing that's like going to a calendar and pulling stuff every day or, you know, doing this data processing. Whereas with agents, you want to set the bounds more firmly because the software you're writing isn't going to do that for you.

It could do anything. Anything it's allowed to, yes. Yeah. I mean, my next question was like, should you let it log in directly? but it sounds like there are ways to really bound what the agent is allowed to do with that account. Yeah. You know, we kind of have a couple of different principles around AI agents at Fusion Office. One is the agent needs its own identity. And because if it's riding along with your identity, like, then it's really hard to audit. It's really hard to, like, differentiate. The people who let agents drive their browsers terrify me. And another is that the bounds around the agent need to be deterministic software. It's not like enough to say, hey, Claude, don't break anything or, you know, be good. Because they will try to do whatever they can to accomplish their goal, as we've seen. And so you need to have bounds around that. I remember when OpenClaw was first released, people were buying new computers for it. I'm sure for that very reason. Because it's just this YOLO software.

It's just like running wild. Totally. I think that's fine for experimentation. there's actually one of the people that I follow in the identity space has a an agent that's running open so I believe called Clottery Hepburn and she's giving it all its own account yeah and if it gets a credit card it has limited spend and that's kind of balance you need to set up and one of the issues that we have right now is that it's possible to do but hard you have to be a techie to do it and we want to make it easier for everyone to do that it's a really important thing They're limiting, yeah. I've seen some solutions where it's very, very tightly controlled. The usage like Timebox or single use or something. You think about things like that? Yeah, so I think that you can think about it a couple different ways. The first is like how do you actually layer this kind of control onto an existing piece of software system, which that is limited to either gateways or you have some kind of intermediary to like downscope tokens or downscope permissions. then there the question of how we can raise awareness for folks to kind of be thinking about this kind of stuff and actually asking for it which is going to drive providers to give this

kind of granular data and then the last thing i would say is you want to think about what can we automate right like what can we say okay the agent's done this all the time it keeps asking for this permission now we're going to play that for the human being so that people can start from a position of like default least privilege instead of default most privilege is what people are doing right now. I think that there's a lot of security software that sort of starts with that least privilege, which is best practice, but you run into a lot of user inconvenience that way. Totally. Right. I've had a couple where I had a just-in-time approval and running Codex, it runs Node for everything. Right. So I have to approve every instance of Node. You probably 10 times and then you finally you're like, YOLO, approve, you know, in general. I yelled at IT. Right, which is, you know, not a good experience. I mean, the whole point of agents is that we want them to take stuff off our plate, not put more things back on our place. Right, right. I've heard of agents are goal-achieving machines. I've heard of them getting authorization and approvals by, you know,

going into the session or, you know, other things like that. Like, what happens to that sort of session management and refresh tokens? Yeah, I mean, we always have been advocates for, like, taking care of those tokens to the kingdom because they are. But this is even more important, right? Like, now. So there is some move to have agents. Again, if you give them their own identity, this problem becomes less prevalent because they are not searching for your identity, especially if they're in a sandbox. And so I guess that would be my recommendation is, like, start to build these systems so that agents can do stuff on their own. even if it's associated with the user. Yeah, you talk about giving them their own identity, sandboxing them. How isolated did that be? Like, can you run that agent sandbox on your main computer? Do you need to give it a sort of other computer? Do you need to air gap your agent? I mean, I think it depends on what you're asking them to do. I feel comfortable with some of the sandboxes that are, like, on my own computer.

But honestly, I think the future of agents is probably not going to be running on our computer. You know, the interface will be on a device that we control, but it'll be up in the cloud somewhere. Then you don't have to worry about, like, batteries running out or anything else. And it's also possible to constrain things of network layer a lot more carefully. You don't have to walk around with your laptop half open. I know. That's going to be so 2026. Right. In 10 years, people will be making memes about that. Air's media is defined by its flaws, right? Totally, totally. You mentioned that sort of AI agent in 2026. You also had a presentation where you talked about the state of the AI in 2026 that had some survey data around it. Yeah, so this was really an interesting survey we did in partnership with LeadDev, and this was really focused on AI and software development. So some of the stuff you and I have been talking about previously was just like AI in the general, like employee or consumer use case. This was really focused on AI and software development, and we surveyed hundreds of engineers, and it's about a 40-page report.

And you can find all kinds of interesting answers in there. But the thing that was most shocking to me is that 69% of people surveyed did not have a plan for measuring the effectiveness of AI as a tool in their software development lifecycle. Yeah. Maybe I shouldn't say it's shocking. I'm pleasantly surprised it might be a better word. Right. That comes down to what do you mean effectiveness? because I think people have been trying to measure performance and effectiveness with software engineers for a long time. Yes. I actually had a conversation at Table Topics right after that where a guy pushed me on that, and we basically came to the conclusion that we didn't know before and we don't know now. We have some directional signals. Yeah. And that made me actually start to think about, like, when is software actually done? Because I think people are thinking about, like, AI and, like, pushing more software through, and something that we've been struggling with a little bit of Fusion Office where downloadable software is we don't have the insights that someone does in SaaS. And to me, software is really done when the user knows about

and is using your feature and is happy with it, which I think churning out more software can help you get to that point. It's definitely a step along the path, but that to me is the ultimate business outcome because that's what drives the people to go back to your software and use your software well. I don't think SaaS companies agree that software is never done. Move the margins, make the hero images bigger and smaller. Change the color of the button. Yeah, yeah, yeah. It is not done. Sure. It's not done until the user stops using it. I guess I was thinking more in terms of, like, when is a feature done? Like, it's not when it's been deployed to production. In the SaaS example, it's actually when the user discovers it and wants to use it and has found it. Yeah. So, yeah, yeah, yeah. interesting to think of like, do you have any sort of inklings of what measuring AI looks like? Sure. So I think that right now we're kind of in the era of measuring what you can because you want to measure something. So that's kind of the token usage or even something like,

you know, lines of code or PRs pushed. And I think that finance departments are getting involved because the expenses have gotten big enough. It doubled from 15% of people in 2025 had ROI or infrastructure spend as a metric way tracked to like 30-ish percent now. Yeah. So that's definitely coming in. And I think you're going to want to see outcomes. And honestly, this is where I'd start to go back and look at the stuff like DORA that worked in the before times and I think still is our best directional signal towards software effectiveness now. Right. Engineering is still engineering, right? You know, I think about six months ago, people were, especially executives in some senses, were wishing that it wasn't anymore. That it was like a magic genie. And even at this conference, you've seen people talk about the great things about AI, which there are plenty, and that the negative things, architecture drift, logic bugs, huge PRs. And so, yes, I 100% agree. Engineering is, I mean, that's such a milquetoast take.

Yeah, yeah. But it is, I think, once you live through a number of different transformations, right, like to memory managed languages, to the cloud, like you start to recognize that there's a hype cycle. And getting something that's software to do what people want when they don't actually know what they want is the core of engineering and will be around for a long time. Yeah. And I think it's the core of all engineering. I was talking to somebody. They were having a discussion whether software engineering is real engineering. And it's like, yeah, you are looking for faults. You're building a system. You're building a process. You are shoring up that process. We're building bridges. Totally. I think that we're a young engineering discipline in the same way that chemical engineering is younger than structural engineering. But yeah, I 100% agree that we're engineering. We also had a survey people have heard of. Our developer survey found on the topic of the sort of token cost. People want outcomes, but the outcomes are not necessarily financial right now.

We asked whether people had switched models because of performance or cost And about three quarters two thirds three quarters switched because of performance Mm And maybe a third switched because of cost And these were developers? Yeah. I think that that's a really interesting point, and I think that what I take from that is that developers are one of the highest leverage professions when it comes to token costs. And if an engineer can deliver a feature in 70% of time, but it costs twice as much, Most people will take that all day long. I think in other professions, you're going to start to see lower-cost models come in more and more because they're maybe not as high leverage. Right. If we had surveyed CFOs, it would be a different story. There's that, too, for sure. For sure. What else was in the survey? 40 pages of CFOs. Yeah, yeah, yeah. I mean, the other high-level things were that I think it was in the 40% range. I don't remember the exact number. People, they've seen their teams lose debugging ability.

which makes sense, given all the AISRE companies that are out there. And then the other thing is 24% of folks are letting their AI agents reuse the human credentials, which brings back to the original topic. And again, it's terrifying, but in the coding situation, it's maybe a little more understandable because you have these gates of PRs and code review, and hopefully no one's letting people just ship AI code directly to production, or any code for that matter. You do have to own the code. If AI wrote it, you still own it. But I think one of the things I talked about was zombie PR reviews, right? Zombie code review, where AI has created so much code that people are just like, I'm not going to read this. 400 line PR. Yeah. LGM. Do they say that or do they just let it linger? Oh, they just kick it through. Yeah. There's the old stuff. You want a detailed code review, push 10 lines. If you wanted to prove the needle, you'd push 100. It's a bike-shaking problem. Yeah. I mean, actually, I had a conversation last night with someone,

and she was saying, why do we accept that? Like, why do we accept a 400-line or, you know, 4,000-line PR from AI when we wouldn't from our coworkers? Why wouldn't we go back to the AI and say, actually, you need to break this down into, like, 10 smaller things that I can actually review and understand? And I think that is part of us learning to adjust to this new tool is for us to build cultural norms that say, actually, just because the AI wrote it doesn't mean you have to kind of accept it as is. You can push back the same way you would with a colleague. Yeah, GitHub actually had a feature rollout recently that is breaking up commits into smaller pieces. Does that do it kind of automatically, or is it more like a UI? I'm not sure. Okay. Or by the headlines. Stack VRs, folks, if you want to learn about it. I think that's what it was called, but I don't know the actual details of it. Yeah, and this... specific problem of the agents pushing the code, that's the interesting portion of ID, right, where it has to be tied to the developer. So in that case, how can an AI agent use your

credentials and not get you in trouble? In the code context where you're pushing stuff up to GitHub? Yeah. That's a case, I think, for collapsing identity. Because again, the action is to push the code up, you know, you're not merging it necessarily. I think you could mark them as kind of co-authored by an agent or something like that. But to me, that's your point that, like, I think AI agent identity is not a hard and fast rule in all situations. Where there are other gates, the accountability collapses to the coder and engineers are totally understanding what the AI agents are doing and it doesn't have necessarily rule of ramifications past the gates. Yeah. And so, in my mind, collapsing that identity is actually probably okay. You have to because I think everybody is writing agenda code. You know, I was thinking about this the other day. It feels to me a little bit like software was one of the last things where you could be a craftsperson. Yeah. And I think there's still definitely room for craftsmanship.

But now it's in shaping the environment that the AI is executing in as opposed to the code itself. We figured out how to build a software factory. We did. Yeah. We did. Goes with all the other factories. I think it used to be you were an artist who spun wool, and now people do it for a hobby. Unfortunately, I think that's where software is headed. Well, fortunately and unfortunately, right? It's two-sided going because it does let us lever up in terms of abstraction and more things we can deliver. I guess it depends on where that nets out, right? Is it just a server somewhere chugging away, like on a CEO's share of tickets? or is it actual software engineers still monitoring, still working on it, still being like the people who determine what the factory builds? It's funny. I actually just had another conversation about that too today. It's a great conference, by the way. Yeah, yeah. Lots of good conversations. Yeah, for sure. And we were saying like it is fantastic that a single solo CEO or someone who's a business person who has a great idea can go out

and use Claude or Codex to build a MVP. That is fantastic because it makes for a richer experience. They can put something that works in front of possible customers. But I guarantee you that anybody who takes their MVP that Claude or Codex built who doesn't have a technical background and just shifted to production is in for a world of hurt if things get successful. So when software becomes cheaper to write, all the other things around running a software product or business become more valuable. So that's operational stuff, that's security, that's scalability. And I think those are all engineering disciplines that are not going to go away, if anything, they're going to become more important. Yeah. I think it's also interesting. I saw a video somebody did that was going through all these engineering blogs and being like, Meta rewrote Facebook for 10% to 15% performance. Someone else did rewrote for 10% to 15%. All these companies rewrote their entire software for this small amount of performance because at some point you're going to need it. Totally. And if you're in front of one person,

a second pause is not a big deal. If you're in front of 100 million or a billion people, it starts to happen in terms of just expense and user impact. We've talked about the developer and their agent and the state of the industry. Are you personally hopeful? About software development? Yeah, yeah. I am. I think that the analog or the analogy I've been using is that this is very similar to how system is, must have felt in 2010. I feel some grief. I know other people have. I've read other blogs about some of the grief of the death of craftsmanship or the death of knowledge. But I also think that we talked a little earlier about how I like to solve business problems. And I think that if you're an engineer who cares about the craft of programming and where braces go and tabs for spaces, you're in for a bad time. If you're an engineer who cares about solving real problems, you're in for a great time because someone who cares about customers and product and still has a technical background or is willing to learn the technical pieces

is going to be able to build so much faster and learn so much more. And that to me is really exciting. I think it's telling with a stereotypical developer burnout job. It like making furniture upstate Totally They not working in a furniture factory right They doing the work Totally totally You know I felt for a while that a lot of developers are essentially kind of blue workers because they are doing that very hand-packed stuff. And now you're getting this larger kind of management role for somebody who's an artisan. How do you get them on board? Well, first of all, I'd say that, like, the spectrum of companies is vast and wide, and I guarantee you that there are still companies out there that are running Microsoft Access databases that were handcrafted. And so I think that if your company is all on AI, you can find another company that is less in on AI. Some companies are more conservative, right? And so that's an option.

I think the other thing is to take a step back and think about why you really became a software developer in general. And the last thing I'd say, and this is kind of a bummer, but I was around during the dot-com boom. And there are a ton of people who are pulled in for the money, and then they washed out because there was no money in and whatnot. And so if you are pulled in because you like solving problems with code, some percentage of people might get washed out when that is no longer a viable thing. Now, is that going to be this year? I don't think so. Is it going to be in five or ten years? Depends on whether we're in an S-curve or an exponential curve, and I don't know enough about the LLMs to be able to help you there. There's a lot of shifts going on. I had a conversation about SaaS yesterday, where it's like SaaS is probably going to get wrecked a little bit, but there's still stuff that's indispensable. Right. SaaS is like everything from the micro business that's like a widget you put on a website to Salesforce. So if someone said that statement, which is a pretty bold statement,

say SaaS is going to get wrecked, I'm going to say, which SaaS? Right. Because Salesforce, I think, is going to be totally fine, at least for five decades. Anything that someone can define that isn't mission critical is going to get replicated by at least some percentage of people. That's one of the things that I'm excited about FusionOff for is that identity is not something, and security around customer identity is not something that you want to get wrong. But I guarantee that there are going to be people who will say, Claude, make me a login system. and that will, again, work fine for an MVP. It might not work well for a production system. If you are rolling your own identity or you have a lookup table for whatever, you might have the engineering know-how to get it sort of right, but what would you say are pitfalls that anybody rolling their own is going to hit? Sure. I mean, I think there's a couple of different kinds. The first is making sure that you pick an algorithm. Let's just take username and password, right? That's a pretty basic scenario that a lot of people want.

You know, you want to make sure that you pick the right factor and the right algorithm to hash your passwords and that you use a salt and a pepper. I mean, part of the issue with AI is that you have to kind of know what questions to ask. Now, someone could always say, like, hey, how do I build a secure password system? And AI might guide you a little bit through that. So there's kind of just the knowledge layer. Then there's the maintenance layer because now you need to be on top of new standards or what was a good factor 10 years ago is not a good factor now. What was a good algorithm then is not an algorithm now. And then there's the final thing of just new things, like pass keys have come on. And I worked for an identity vendor, but swap out a database. Would anybody want to build their own database? And the answer is you could as an intellectual exercise and for 0.0001% of people, it makes sense to do it as part of their product. But go build more features that differentiate your product and bring the database or the identity system in

that solves 95% of your problems and someone else maintains. Yeah, I think the old build versus buy question always stands, like what kind of company do you want to be? Totally. Right. Do you want to be an identity company? Do you want to be a database company? Do you want to be a to-do list company? Do you want your agents or your engineers who are directing agents to be focusing on troubleshooting identity bug or database bug, or do you want to let them focus on building features that your customers actually care? Back to the point about customers being able to discover and use your features. I've never heard anybody say, oh, my God, you've got to check out this login page. People just don't. They want to get through it to the awesome features that you're building. And I think that there are other categories of developer tooling that are very similar to identity systems where I think you're going to see agents leverage existing solutions rather than build their own. So boring software wins again? Dude, more and more boring. Actually, I was thinking about this the other day.

I think that boring languages are going to win too because they're the ones with the biggest training corpus. Yeah. I mean, I had a conversation recently about Java being one of the best languages for AI agents because it has so much history. Totally. And honestly, at the end of the day, you care about it from a runtime and an operations perspective, but if your agents are all writing your code and you're just interacting through that interface, do you really care whether it's Java or Go or Rust or anything? You don't. Taking that step up in abstraction level. I talk about OAuth as a foundation. I've actually seen a couple of documents come through where people are trying to build a full agent management system on top of standards like OAuth and Spiffy and some other things. And I would just encourage anyone who's interested in this stuff to don't reinvent your wheel the same way we talk about not reinventing the wheel for password hashes. Go look at how people think about agent interaction and authorization in the standards bodies. And if you have a lot of implementation, you can add your own stuff in there too, right?

A hundred percent. Like, you can find an open source or commercial product and, like, bolt your stuff on to some extent. Or if you have a home world system. I mean, the whole reason that I'm involved in identity standards is because there are a whole lot of people who are very smart, who are thinking about this stuff and thinking about all the edge cases. Yeah. And you don't want to discover those buzz saws yourself. Right. You want to let somebody else discover them for you. I've been Ryan Donovan. I host the podcast, edit the blog here at Stack Overflow. If you have questions, comments, concerns, email me at podcast at stackoverflow.com. We love ratings and reviews. please drop those on your favorite podcast provider. And if you want to reach out to me directly, you can find me on LinkedIn. I'm Dan Moore. I'm Senior Director of Sciam Strategy and Identity Standards at FusionAuth and love to hear from people to talk about OWASP, authentication, password hashes, and algorithms. And would love to talk to you about your identity and agentic use cases.

You can find me at fusionauth.io or email me at dan at fusionauth.io. Thank you for listening, everyone, and we'll talk to you next time. Thank you.