Inverted Podcast #28 - Agentic AI Meets Digital Identities with Nick Steele

Speaker A: Foreign.

Speaker B: To another fresh episode of the Inverted podcast, where we talk about when success is when nothing happens. Products in security, AI quality infra. When you're building those or selling those or working with those, you're in the right place because we have some experts that talk about the different and unique challenges of these things. And, um, today, my usual experts are there. Dana and Dario. So good to see you. And we are joined by special guest nick Steele from OpenAI. Thank you so much for taking the time to join us.

Speaker C: Thanks for having me.

Speaker B: Yeah, Nikis has a long career in, uh, security, so a bit of 1Password Etsy. He's been part of the Fido alliance and the W3C. For those of you who don't know what that is, those are some of the bodies that, to build the standards that make everything you use every day work without you having to think about it. There's a lot of things going, uh, on behind the scenes, and Nick is kind of a celebrity in that world, so we are very honored to have him here. And I can't express enough the thanks to Nick, but also Dario and other members of the Fido alliance, uh, and all those bodies that govern so that my Android phone can just work without me having to worry about things. And normally we talk about more security things, but AI is kind of changing all of that. And, uh, I guess I want to start with reminding us, or remember reminding this story, um, that happened a few months ago, where this AI completely dropped the production database of the small company and the founder ended up working an entire week, um, you know, just a weekend, just to get everything back online. And, um, Nick, I just wanted to. I wanted to start with you. Um, what do you think about that story? Like, what went wrong and how can we build systems that don't do those kind of things?

Speaker C: Yeah, um, well, you know, it's funny, I think that a version of that story has appeared several, several times for different companies. But I know the one you're talking about specifically. But I do remember seeing the trend of. When I first saw a, uh, story get posted around, um, an agent dropping a database, uh, or an agent doing something that was bad for the business. The response was, oh, my gosh, this is the agent's fault. But slowly, uh, the responses that I saw, uh, to those types of events changed.

Speaker A: Ah.

Speaker C: And m. After the most recent incident, um, a lot of the responses were, oh, no, no, this is your fault. You configured the agent wrong. Um, you configured like, you know, you gave it too much access. So I think that Folks are starting to figure out how to um, how to provide those permissions or provide um, you know, the right access to agents. But it's been a bit of a slow ramp. Um, and you know, I think when a new technology, especially like um, like AI and um, agents for coding and codecs, sort of, they come out and hit the scene, right? The expectation or the general sentiment is like, oh, everything must change. Well, not everything, right? Like some things are going to remain the same. In fact, I think we already have a lot of the tools necessary, uh, to provide meaningful identity and access management for agents. Um, you know, we've spent years working on workload identity, uh, developing uh, specifications and standards like Spiffy Inspire, ah, to help manage workload identity. But what's really changing, right, is we're separating the idea of work from the workload. Um, and that's a very new concept because traditionally when you.

Speaker B: Can you explain that? What do you mean by work from the workload? If you're not work. If you're not a coder, like what do we mean?

Speaker A: Yeah, yeah.

Speaker C: So generally, right, things were pretty deterministic for a long time. When you ran code you had a pretty clear idea of what it was going to do. Um, so when you created a new service or a new application and you spun this up in your infrastructure, in your um, AWS, uh, uh, EC2 that you might be running, you had a pretty clear idea of what it was going to do and it would generally run for a period of time and then probably stop running, um, unless it's something longer lived like a website. But when you run that, because you know what it's going to do or what it should be doing, um, it's very easy to give that runtime or that workload, ah, a set of permissions and say that it's only going to need these permissions for the length of time that it needs to run and those permissions aren't going to change. Um, but now what we're saying is, well there's this runtime, this agent that is going to exist for some amount of time and over the length of its existence it might do different things and those things are going to vary from the m. Deterministic uh, uh, paths we had before where it was just going to operate, uh, to one goal and now, uh, agent might operate to achieve many different goals and those goals may change uh, while it's running because it might get uh, some information that says, oh, I actually need to approach this problem a different way. So we have to Decouple that idea of uh, the task or the goal. Um, I think other folks call it an intent or a mission. Uh, but we need to decouple the permissions that we give it from just the agent itself to uh, the tasks and the goals it's trying to achieve. So I think that there's things we can absolutely take from the long history we have already of how we uh, permit, uh, uh, runtime identities, as we call them, uh, and workload identity, uh, in past and apply them to agents. But a couple of things need to change.

Speaker A: So just trying to give like a normal, like an example that people would understand in the past. You'd have like an agent to say you wanted to, like you had a product and it went and built like sub websites or like, um, a set of functionality out. And your agent would have these tasks they would know how to do, like create a directory, copy all these files, change some text. It have a list of stuff that it could do, um, uh, add permissions or make sure you have rights to these directories. The agent or service would just go out and do that, those set of tasks maybe on your behalf and then it would be done. But with these AI agents, you say, like, hey, go create a sub website that's called this and make it nice and it should look like my brand. And then the agent goes out. The AI agent goes out and figures out everything it needs to do all the different tasks, tasks that you didn't even think about. Right. And then part of that might be, hey, I need to give this permissions, but it gives it too much permissions or the agent doesn't have the permissions so it asks for the permissions itself. Um, so can you talk a little more about how you go from kind of the. You try in these agents to give guardrails, but the agents kind of figure out based on their knowledge what exactly to do, which is where the slippery slope sometimes comes in, right? Yeah.

Speaker C: And I think in the past, um, if I was to have a system that was going to, if I was going to design an application to go build websites based off of some input that I give, um, might look something like I have a service that I create that might be able to go read Jira Tickets or Linear Tickets, and it might go look at some information in, and then it will probably have a set of templates that it uses to go and say, okay, I'm going to turn this into some page. Um, and it will use that template design. Um, it'll use the information from that Ticket I might include, uh, some regular expressions or regex, as we call it, to try to pull out information in that service to match it up to this page I'm building. But with AI agents, a lot of that is abstracted away from me. Um, I don't need to go and necessarily have these template files to provide just like this is the pick in place. Go get this information from the linear ticket, put it in the page, generate this common page. The agent can generally figure out how that should be built on its own. But while it's building that, it might need to go and get some additional information. It might actually request input from me of saying that, hey, um, I came up with these three page designs. Which do you want me to do? It might say, do you want it to be a specific color? Do you want me to get uh, additional information about X? It might proactively go and get additional information about X. And that's the extra permissioning that we need where it determines that, hey, maybe in the ticket or, uh, the information that's been given, it says, hey, uh, this is actually related to a, uh, conversation that was had on Slack and it'll go, okay, well I should probably go look at that Slack channel and read that message at that point. That's really when we want to step in and say, oh, well, it probably shouldn't have permission to read Slack right off the jump. Um, and we want to be able to have moments where I can consent or authorize the agent to get, uh, these additional permissions to go and get something. Because I don't want it to read Slack by default all the time, um, necessarily.

Speaker D: But yeah, uh, you mentioned, I mean, that's super interesting. So you really see that role also within a human. I mean, people talk about human in the loop or, um, accountability on the outputs that people should have on the AI. Um, when I think back at how software engineering was done just a few years ago, where people would approve each other's change requests, the volume was relatively limited. How do we keep up as humans being human in the loop to make these decisions? How do we keep up when we have not just one agent doing stuff on our own, but like, um, dozens of agents that we coordinate at some point? Don't we become the bottleneck and how we, how can we keep the quality up, um, when the limitations are really on our side on what we can verify?

Speaker C: Yeah, and that brings up a really interesting point too that I think is a big differentiator where, um, workload identities are these applications that I might run in the cloud. They're not very, um, uh, personal in that they kind of run on behalf of a business. Right? Like when I run my web service, it's part of my company's infrastructure. It's considered kind of just like a part of my company. Whereas agents can have much more of like a personal relationship, right? They can run on my behalf, specifically, they can absolutely run on behalf of my business or on behalf of a team. But, uh, when my Codex agent is off writing a pull request for uh, uh, some code that we want to commit, um, it feels like that's my agent running, it's not my company's agent. Um, although there's definitely that sort of concept there too. So, uh, I think that makes delegation and how we authorize things, uh, very different than our previous model of it kind of running on behalf of a single account or, uh, under this sort of group identity of the enterprise. When there's much more of this personal, individual, uh, binding too, where, uh, my agent is connected to me, and that's different than my team's agent or the some, some slack agent I might have running that, that you know, represents uh, uh, some other concept like, uh, like maybe notion, you know.

Speaker D: Well, it's a really interesting concept. Like if I think back at like that used to be like cron jobs. Like if an employee has, like, people would have a few cron jobs that automate certain things that we didn't want to do manually, and then if that account would be disabled, deactivate, because that employee would leave the company, those cron jobs would usually just cease to exist on purpose because that was more part of their own work environment than something of the company's infrastructure. Do you see there, uh, a similar stage we're in where AI agents support you as an individual contributor in your work, um, and not particularly the whole organization. And maybe that is the context in which they, in which they exist.

Speaker C: I definitely see, uh, I mean, you brought up a good point too, right? Of if I have a cron job running and then leave a company, hopefully that cron job stops running. That's not always the case, right? Like I've seen, you might want it

Speaker B: to keep running, right? If it's like a weekly update of some database, then you are the one who created. But you might want it to keep running.

Speaker C: Oh yeah. I've seen incidents in the past at other companies in both directions where someone's left and then we have a ticket that says, oh, this job has stopped running. That turned, uh, out to be load bearing for this entire database, uh, and now we're not getting these updates. And then the opposite direction we see, oh, this code is running and we have no idea why it's running because it no longer has a user assigned to it. And so that attribution is really important. And then also figuring out what does need to continue running and what needs to be revoked or stop running at a certain point is hard. And I think that same binding really needs to exist with agents too, especially as they become more tightly bound to a single user, uh, when they're performing tasks on my behalf. And um, maybe my uh, status in the company changes or even m, maybe the posture in which, uh, the service is running, maybe my model changes, or um, maybe my laptop has, uh, some code that is deemed malicious, which is what I mean by posture here. M. Or maybe it's not even malicious. Maybe it's just out of date and the business no longer wants to choose it. And that's kind of what we can figure out with what we call, uh, EDR tools, endpoint detection response tools. When those changes occur, we need to take that into account. When these agents are making decisions, um, especially if they're running on my device, um, or uh, on services that I need to account for. So there's definitely a lot of nuance in there and there's a lot of things we need to figure out how to build a proper policy for and good enforcement decision making around. Um, and I think those are kind of where the biggest changes lie from what we've had to deal with traditionally.

Speaker B: So I wanted to summarize what we've talked about so far because we've covered a lot of ground already. And then I have another question. So we've basically established that these agents are kind of the next level of AI. They're no longer this fixed piece of software with fixed outcome. They can go and have a whole bunch of outcomes. The way they achieve the outcome is not predetermined. It's kind of determined by the agent along the way. They're asynchronously, they can run without you, they can do things on your behalf or on their own behalf. And we have to be careful what permissions we give them. And if they need to stay, these persons need to stay around, set strong guardrails and observe them. So what I'm actually hearing, and this is maybe some cliche, is that these agents are actually like virtual team members. And if I'm hiring a new employee, I already have to decide what they have access to. And if that should be there. So it sounds like we're just revisiting a problem that we had before, but just at a scale that makes it unmanageable. So it's like we're giving every employee at a company the ability to have five direct reports. But they're all virtual and instead of salary they cost tokens. Right. So can we apply some of the similar principles?

Speaker C: Yeah, I think so. And I think the big difference between these human identities and agent identities in terms of permissions and how we think about spinning them up and onboarding them is I think you're totally right in that they could be thought about as these virtual team members, um, in a lot of ways, or at least uh, a very good intern in terms of

Speaker B: team member has a different category.

Speaker C: But when human identities are provisioned they generally have that access or ah, a lot of access baked into their roles already. If I join and I'm a member of the security team and the engineering team, um, that generally gives me by default, um, uh, a lot of access already to different tools within a business. Um, however, when agents spin up we really want to provide this uh, more I think what OWASP calls path of least agency, where the base uh, identity of the agent, uh, no matter how durable it is, has a pretty limited scope of what it's uh, allowed to do by default. And instead of uh, binding the permissions to the role of the agent as we do with human identities, we bind those permissions uh, more to the tasks that it's trying to complete. Those tasks can run for uh, a fairly long time. It could be something that is, is a fairly autonomous task or a long lived goal, um, but we want to tie it to that. So when that task is completed, um, those permissions and those authorizations for what it's allowed to do are also kind of finished at that point. And that's sort of like the big delta between I'd say what human identities are capable of with their roles and agent identities. I don't think this means that Ancient identity could not have base permissions, but I think we generally want to limit them a lot more.

Speaker B: So I have one follow up on that like, because I've also already met companies uh, that are able to do least privileged access in real time. And if you like need to, if it's Friday afternoon they'll give you access to like your CRM system and then they remove it again or like stuff like that. But I think there's one fundamental difference. Even though some of the challenges we face with these Virtual team members, whether they're interns or whatever you want to call them, but these virtual employees or team members, a lot of things are the same. One thing is that they can have superhuman abilities combined with superhuman stupidity. Right. So if, if I have a human employee and I give them access to my inbox, for them to delete 5,000 emails, that's quite a big task. They have to go page by page and then select all, delete, select all the lead. There's a chance that I discover it. Uh, the human has a kind of common sense. And then, um, you know, they know they'll be fired afterwards and they care about that because they need a salary. Whereas an agent could just decide that that's the right thing to do and drop my inbox. So that's the, I think the fundamental difference. And the second fundamental difference is that we come from the era of OAuth, where if I want to give an app access to my account, I use sign in with Google or sign in with Microsoft, and then it says, do you want to give this app access to your email? And I say yes. But then behind it could be one of those agents with superhuman ability and superhuman stupidity, and it might all of a sudden drop my inbox. So when we are building and when we're thinking about our users, how can we deal with this sort of weird situation that we have?

Speaker C: Yeah, um, well, I've seen superhuman, uh, stupidity accomplished pretty well by humans, uh, yes, on their own already. Um, but yeah, when it comes to agents, we need to take those sort of abilities, not even if it's really good or even really stupid right into account, um, in that we want to be able to, uh, limit those scopes of access, uh, up front. So, I mean, I think OAuth is a really good, uh, control plane for agents as well. Um, and, you know, I think that there's been a lot of work in, uh, model context protocol spec, which is a, uh, spec to help provide, you know, what I think they call tools to agents. But are these kind of API endpoints with additional context for how they can.

Speaker B: It allows agents to call apps. It allows an agent. If I'm a company and I define mcp, it basically tells an agent, if you want to talk to me, don't open a browser and click my buttons on my ui, but actually just call this programmatic endpoint.

Speaker C: Yeah, but through MCP as well, it provides a clear way to go get authorization to go do things. And the layer for that that they're using is OAuth. And um, I think Aaron Parecki over at Okta is working on the Cross app access protocol, which is part of this MCP step, uh, for allowing a more streamlined way to provide these grants of access to agents. Um, but even when you cut these tokens and say, okay, yes, it can go, uh, read Slack, it can go read GitHub, it can go read some database, in my infrastructure, we really want to be more, uh, judicious sometimes when we say, oh, but can it write to that database? Can it delete the database? Uh, by default? I've seen a lot of orgs say, you know, that their agents can read and write certain things, but hard no on being able to delete anything. It has to post and then call it done. And if it ever is required to delete something, then you need to go through what we call this human in the loop flow, where it needs additional authority or consent, um, to go do something.

Speaker B: Sorry, go ahead, Dana.

Speaker A: I was going to say, hopefully the agent doesn't figure out that it could just write stuff to delete it and, uh, get around the delete permissions by that way.

Speaker B: I can imagine you select all and you just put one character and that's the same, but at least then you have versioning and stuff like that. Um, but you're saying bringing the human in the loop, right? This is one of the answers of the industry to this agentic risk. When unsure, bring the human in the loop. Now, let's imagine that, uh, you hire a new employee, a junior coder that works for you. And every five minutes they're coming to your desk and they might ask you, can I go to the bathroom? Uh, can I change my keyboard? Can I take a different operating system? And you're like, yes, yes, yes. Don't come to me. Answer to all yes. And then later at the end of the day, they come and they say, oh, I dropped the production database. You're like, why? Yeah, you said everything was. Yes. So of course I'm giving, uh, extreme examples. But this is, I think, a problem. Right. This is, again, something that's new for the industry. We have to figure this out. So what are your thoughts on that?

Speaker C: Yeah, it's definitely. Finding a balance is very much necessary. And then also it depends on what your risk profile is for the business. As you can imagine, uh, at OpenAI, we are fairly agentic internally. So when I run agents, I want to be able to consent and delegate and move fast. And we see a lot of benefits from that. And I personally see a lot of benefits from That I run um, my own agents. I have an open claw deployment that I run off of uh ah, Arduino Uno, just a tiny hardware chip. Um, and the way I provide uh, that agent, the tools that it needs is actually through a uh, credential manager. I have uh, a 1Password uh vault that I use uh with the 1Password developer tools to uh, give it access to a ah M file with a minimum set of credentials that might need to go uh, update a notion page for my to do list and add uh, uh events to my calendar. But I, you know for when, when, when the, when it gets access to those I'll actually get a message that says hey, it's, it's using this credential right now. How do you feel about that? And generally I know what it's, I, I know what it's doing and I know the direction it's going. So if it's using a credential to you know, if I've given it a task that says update my to do list and then look at my uh, my mail, my email and if there's anything I should be adding to that list or adding to my calendar, let me know. I know that it runs this job at 9am and so when I see these credential requests come through that's kind of my user in the loop consent flow right now. Um, and uh, the other day I got a message from it around uh 4pm because it was looking for a credential to update my calendar. And I was like well that's not when that job runs. That seems odd. And it was because someone had sent me an email that says if you could respond to this around 4pm that would be great. So it just waited until 4 to figure out what it should do. Um, that brings up another issue that I think is folks are concerned about uh, in the space right around like how do prompts and prompt uh, injection or prompt poisoning as it's been called sort of affect these flows. Um, but generally when these agents run um, I should have a pretty clear idea of what they're doing as the user and insight into why they're going in that direction. And even when agents seem to go kind of in a different direction or might actually you know, uh, start getting uh, going in these, in these directions where you know it's having trouble updating a git repo so it starts trying to rebase something and it starts trying, you can see it starting to get kind of frustrated with what it's doing. Um, you can start to Kind of, kind of see a pattern of like, okay, so maybe I should step in here, maybe I should help. But also, you know, to your point, right, you need to strike a balance of me staying, you know, staying, uh, observant of the agent and giving the agent the ability to move on its own.

Speaker A: Nick, you mentioned our credential manager, like one of the long running, um, industry talking points or issues. When you think back about the like, service counts and just normal agents running is like, how is that identity used? Does it use impersonation or delegation? Right. It's very important and it's, it seems like my opinion.

Speaker B: What do you mean, what do you mean by impersonation or delegation?

Speaker A: Impersonation is you basically give. Impersonation is you basically give the agent your credentials or the equivalent of your credentials, um, and it logs in as you basically, the agent is basically running as you where delegation is like, I give you, you have permissions to do things for me, but you're not me. You're an agent working on my behalf. Right? And um, the big thing is like when you're first bringing up systems and everything, impersonation is like the easy path. It's the easy button, right? You just give the agent credential your credentials and it does things and accesses things as you would, but security wise, it gets messy, right? And you don't know who's taken actions or who's done things or if now the agent has all your permissions. So I assume that you guys are thinking one way versus the other.

Speaker C: Yeah, I mean, I don't even think it's specific to OpenAI. We've had a lot of conversations in the Fido alliance and W3C and these other standards bodies about how we want to approach this. And I definitely don't think the flow that we're looking for is going to be impersonation. I think we really, really want to make sure that, um, agents have their own strong and durable identity that uh, you know, can, can persist as, as long as the user and you know, their, their enterprise want it to persist. And when, when those identities, you know, appear, they are, they're very much associated, uh, and tied to the actions they're performing, but then also bound in some way back to, uh, to a workforce identity, um, that, that they're acting on behalf of. And I think that's a really hard problem in the enterprise. It's kind of a. I, I don't want to say it's a solved problem, but I think that this is much easier to deal with within your own infrastructure, you probably already have an idp, um, that allows you to create these identities and gives you this ability to observe it. But out on the Web, it becomes a much harder problem of saying, oh, well, this was an agent doing something, or this was an agent, uh, logging in with my credentials. In fact, traditionally, if, if that sort of flow happened or was observable, then it was considered a bad thing. Like if a site thought that, uh, a bot was logging in with your creds, then you'd probably be blocked or banned or at least informed that, oh my gosh, something bad is happening because these agents or uh, well, those types of authentication flows. And that type of impersonation was traditionally not good. It meant your account had been compromised. But now we're kind of subverting that flow.

Speaker A: Right.

Speaker D: Yeah. You mentioned like standard bodies like W3C and Fido. Um, really also looking into this and how it fits there. How can standards be a part of a world that's moving so fast? I mean, the way we used AI agents last year is very different than now and it will be completely different next year probably. Um, so how, yeah. In your experience working in standard bodies, how can standards bodies add value to this discussion that is going so fast?

Speaker C: That's a great question, and I don't know if I have a great answer for it yet. I think that, uh, the historical speed of standards bodies is at odds with the speed at which this is being developed. But I do think that there are a lot of good standards in place already that allow for agents to operate more securely, uh, and with this tight identity binding to other users and to access credentials, um, that are already available today. And I think that we're busy filling the smaller gaps in a way that shouldn't slow down. I, um, think the speed at which these agents are being developed and deployed. Um, I do think that there are changes that we can make to some of the types of tokens and credentials that we use today, uh, to better support agents and even just make these flows, uh, not only more agent friendly, but more trustworthy to the, um, relying parties, the websites, the authorization servers that need to. The need to take them and then actually say that this is a trustworthy, verifiable thing. Um, one of the things that comes to mind is a lot of the work that, uh, folks, uh, in FIDO and the oidf, the Open Identity foundation, um, are doing, uh, around payments and how we can better handle payments for users with agents in the flow. Um, and there's a lot of work being done with what are called DPCs digital payment credentials, uh, which are essentially these stronger uh, uh, payment tokens. If you think about Google Wallet or Apple Wallet and Apple Pay, um, those sorts of credentials uh, can be updated or extended to support a flow where if I ask my agent to go, uh, potentially buy me Taylor uh, Swift tickets, uh, I can pre authorize a certain amount of money into this credential that has been issued by Visa and put uh, in my Android wallet and it's tied to a credential that is trusted there and then it can be presented by this agent and when it's presented I might need to be in the flow and actually consent to its release. That has a lot of really great properties in it. Right. We have that strong binding. It's not impersonation, it's delegation and we can trust all the parties involved. And so I'd like to have more credentials that actually operate um, really well for agents and then again for the folks that have to verify and trust those uh, credentials as well.

Speaker D: So the good news is we don't have to invent everything from scratch. Like there's really actual solutions that are still valid for this new world.

Speaker C: Absolutely, yeah.

Speaker B: And I was thinking when you were saying this Taylor Swift example, right, like uh, maybe an agent is the only way to get a Taylor Swift ticket with the demand and supply uh, queue that there is. Maybe that's the only way to get a Taylor Swift ticket. Um, but what if you are the person who's building the system that actually sells Taylor Swift tickets, right? So I maybe want to close today with your final question to you is like what if you are building a product uh, that is not necessarily agentic in its core, but um, you are asked two things like build agentic stuff in it or agents are going to come and interact with our stuff. How do we, how do we prepare for that? What are some of the two or three main things? Because you can't say everything that you would want to say to such a person and has to face this challenge of how to deal with agents.

Speaker C: Oh absolutely. Um, so I mentioned this idea a lot when I work um, on standards. We should be building for the happy path, um, we should be building happy paths not just for the user, um, but for agents as well. So building flows for agents to use I don't think is very difficult and exposing um, those flows is even easier. I think if I was to build a site today that I didn't want to potentially be agentic on its own or have an MCP server, I would at least provide, um, elements in the page probably hidden. And I've seen this before where it says, hey, if you're an agent, you can use these API endpoints like this. You can get this information in this way. And the more ability you provide to uh, the agent to operate on this happy path that you want, the agent will prefer to use that. Um, similar to a human, um, being able to give it entry points that are clearly agentic. Uh, I don't think needs to necessarily be an MCP server, although building one does help and I do think it's fairly easy to get one up and running. There's a lot of tools to do so. Um, but being able to account for the fact that agents might be visiting your web server or your web application, um, and giving them sort of a clear neon pointing sign of, hey, this is the direction you should go if you're ah, this type of agent is really helpful and that's a great place to start.

Speaker B: So it's been a great conversation today, as always. Um, so we've learned and realized that agents are different, but they're also kind of like humans, but then with some superhuman abilities. And we've talked a lot about how to handle their credentials and their abilities and other things and we've ended on kind of the truth. I think everybody knows, but doesn't want to embrace that agents are coming and you should embrace them if you're a company and build a front door for them because then they'll go through that and you have a better way to manage them and deal with them because agents also prefer the happy path. And so thanks so much, uh, as always, Dario Dana, for joining. Special thanks to Nick, uh, for sharing your wisdom and thanks for all the work that you and others do in Fido and W3C. It's much appreciated. And uh, for those of you listening or uh, watching this, thank you so much, uh, for dialing in, as always, for connecting with us. You can find us on LinkedIn on the inverted podcast.com and we look forward to seeing you in the next one.

Speaker C: Bye. Bye. Thanks so much folks.