Insecure Agents — Episode 43: Dick Hardt, Founder of AAuth, with Karl McGuinness, Ian Livingstone & Herman Errico
Podcast: https://insecureagents.com
Listen: https://open.spotify.com/episode/4AICT73coaj4AFk8u2nRn7
Transcript (auto-generated, lightly edited for clarity).

Allie Howe: Welcome to the panel portion of tonight's event. Obviously we just saw a lot of Auth concepts in action. But to give you a little bit more background on what those concepts actually are what are we using today, like what's what are we using with like OAuth? How do we secure the best practices we have today? But also let's look forward into the future to Auth and help us understand, okay, what's coming down the pipeline? What can we actually expect and how do we prepare for that future while also understanding like what are the best practices we have to use what we have today and work with that.

So on our panel today, we have Dick Hardt, which we all just met, very familiar with, founder of Auth. We have Ian Livingstone, CEO and co-founder of Keycard. We've got Herman Errico, founder of AARM or Arm which is part of Cloud Security Alliance. Arm defines what a runtime security solution must do. It's a new framework. And then we've got Carl Mclnnis, which we saw in the beginning identity expert ex-chief architect at Okta. So super excited. There's a lot of knowledge on this panel. And by-- I wanna kick off the panel by starting with understanding, like why do we need a new protocol in the first place?

What's wrong with OAuth? And I thought there's no better person to answer that question than the man that created OAuth and now says we need Auth for agents. So Dick, why?

Dick Hardt: I mean, we've chatted about this here, but OAuth was m-- was in a world where we had two servers. They were talking to each other. We wanted to get rid of the anti-pattern of people giving this server, this server's username and password so that this server could go and crawl it. And it was a world where things were very predetermined, and we knew-- we were writing software where we knew what it needed to do ahead of time. We knew which resources it needed to call, we knew what scopes it needed, you know, and we could put that all together and run it. And agents don't work that way, right?

We, we wanna go and enable-- tell an agent, "Go do this," and figure out how to do it along the way. And so it's much more of a dynamic world where we don't know what it wants to do, we don't know what re- what permissions it needs to do along the way, and, you know, that dramatically changed it. And As we were designing this, one of the things that, you know, became clear is what we needed the agent to have an identity. Realized we also needed the resource to have an identity. And as we started to look at having the agent have an identity, we reali- I realized we've solved how in HTTP ter- HTTP terms, servers, we've solved server identity with TLS, DNS, Let's Encrypt, right?

That's like free, cheap, everything's TLS now. HBS is everywhere. But we haven't yet solved how a client has identity. And so that kinda fell out of what we needed for A Auth. And so I was super excited when I started chatting with Scott, and what he was trying to do with get rid of API keys. It's like, wow, we're also solving this other base problem, right? And that these primitives around a piece of, a client code having its own identity helps us solve a whole bunch of other problems that we haven't done as sort of a base primitive for the internet, which I think is pretty exciting.

It isn't just for agents. It's really solving some other things that I think are gonna get popularized because of A Auth. That was more than the question, wasn't it?

Allie Howe: No, that's, that's wonderful context. And I think like practically in practice, like what does A Auth allow us to do more so than maybe what OAuth does? And I think a good example of that is the act claim 'cause like right now in OAuth, if you've got a multi-agent like delegation chain, say, you know, Agent B told Agent B B do something, and then B told C, you would see an array in OAuth where it's just a static string of A, B, C. But with A Auth, you actually get a cryptographic identity for who is A, who is B, who is C. So for anyone on our panel, what's the unlock there?

Like, what does that give you if you're a developer, if you're a security runtime solution? Like, what's the value there of that?

Ian Livingstone: Sure. I'll talk about it. We, we both look over. It's definitely Carl. Yeah. Mr. ID Jag here definitely has to, like, explain this.

Karl McGuinness: Let's just say that I, I also had to spec how to make this work on OAuth, and so providence and accountability, right? So when you make these hops, how do I make sure that from an accountability perspective, it's who I think it is? 'Cause if it's all bearer tokens or you all trust the issuer, then how do I verify from an auditability perspective that it was this actor acting on behalf of this user in this context, in this way? So you get the chain of custody from a cryptographic perspective, and that's just a base auditability, accountability layer. And then on top of that, you can start understanding some of the trust issues, which is when you cross the trust boundary do I trust the metadata station issuer of who that upstream party issued about this in my downstream system?

And all that starts bringing in trust issues about when you think about multi-hop scenarios. So I think we're built OAuth very successfully for a single trust domain. Most OAuth deployments and people touching OAuth today deal with a single authorization server, a single client accessing an API. We've had this thing called token exchange for a long time. That's sort of the, the sort of, you know, escape route of like, oh, just magic token exchange. Everything's just gonna be solved for you. And you hop over this magic boundary, and everything becomes undefined, does not compute. We don't know what's going on. Figure it out. Choose your own adventure.

Here be dragons. And so A Auth has a, a pretty clear direction for how to bake that into the, in the protocol. For OAuth, we're patching a bunch of stuff. We'll have the adoption challenge. We'll have thousands of deployments that still don't speak whatever profile spec and A Auth has it ba-baked in. So I think realizing that that's a fundamental prime concern is key, and not treating this as a sort of add-on, bolt-on later is a challenge that the OAuth community is kinda gonna have to deal with. But its value is in providence and ensuring authenticity across the trust boundary.

Ian Livingstone: Can, can I... I'll concretely, like, I often answer this question for, for customers when we're talking about Keycard. One, one of the cleanest, simplest examples is like, okay, imagine in the future I ask an agent to go buy me, like, the best pair of jeans, right? And I can spend $50. How do you know whether cryptographically it was the user or the agent along that chain when you're the credit card processor? Right? And how do you know that, that nobody messed with that along the way or c- you know, triggered a printing or whatever it does? And so the cryptographic identity, when it gets into the audit log of that credit card processor, when we get there, we'll be able to be like: "Oh, no, we actually know it was Carl."

Yeah. And, or, "We know it actually was, you know, this agent." And we can say definitively that like, "No, you don't get a chargeback because you actually did tell this thing to do this action," one way or the other, right? And so when you think about how we get to a world where agents are driving not just internal enterprise workflows and coding agents, but they're actually driving the way that we interact with computing in general, it becomes incredibly important because at the end of the day, the biggest thing that actually drove the internet and drove-- was, was payments and commerce. It's also why TLS exists.

And so this is just the next layer of like the-- what, what do we do for TLS at the app layer is a way to think about it. So we--

Karl McGuinness: I, I mentioned this at the intro, which is just, it's a new accountability, is that it's not acting as a user, it's not acting as session, it's not acting as workload. And then I think sort of going back to early conversations I had with Dick and like why he called it a person server, is giving that sort of binding at the person server level of how an agent's acting in a authoritative context, whether it's as an organization or as an individual that's gonna carry forward to that auditability piece of, well, when you actually do remediation or actually do remittance or, and payments, there's a bunch of other domain-specific problems, that you now have a meaningful layer to talk about the au- the authority that was joined between those, versus saying it's acting on behalf of user, it's acting on behalf of session, it's acting on behalf of a workload.

Herman Errico: I think Ian, y- you're definitely saying something that in terms of like payments The concept of like non-repudiation is probably key because if I wanna like relate to what Dick said before about the contract, now you wanna create an identity assigned to the agent that is authorizes accountability, but also non-repudiation. Because then you, you wanna say, "Okay, the agent was authorized to make the payment. It did pay. It paid on my behalf," and now I cannot go back to the credit card tomorrow and say, "Well, no, I didn't authorize that."

Ian Livingstone: Bingo. And now you have like your kinda like full loop, and yeah, that's why we all love AI. That's the f- that's the future. And, and the crux of it is like when you-- because what's going on is we're moving from this world of like human driven, like humans interacting, pointing, clicking. We're now deferring intent to these agents, these agents going off and doing work on our behalf. The fundamental question is like who owns the liability? Yeah. Right? And so we have to defer whether this was like, "Hey, is, is this a decision that a user like I generated, or is this a decision someone else generated?"

And today, with the existing, like, you know, API key sprawl and everything, there's no way to actually deal with any of that stuff. It's, it's just, it's the worst. And so if we want a future, right, where the interface is this like reasoning layer between humans and core systems, we have to be able to carry these identities down in a non-repeatable way.

Allie Howe: I think another big feature of A Auth that m-make-makes it very different from OAuth, in my opinion, is this concept of the mission and being able to track over time, okay, this is like what the agent intended to do or what the human intended to do, is it still on track to be doing that thing? And there could be many different tasks that, you know, make up this holistic mission. But keeping the agent on track and honoring its mission throughout the entire course of its actions is super difficult. But with this concept of the mission, my question is for like the runtime people in the room, like the Ian and Herman, how do you use the mission to make a runtime security solution better?

Herman Errico: So if we really think about core primitives of security systems you really have a agent, so, a user that is... or a machine that is authorized to do something. Agents do completely break that premise. So one of the reason why I really love this kind, kind like this concept of like the mission, is because whenever you do pre-execution interception, you then can read to a machine-readable primitive that has a stated mission, which is, "I am trying to make a copy change. I am trying to delete a database." Right now, if you try to infer the mission from the agent, it is just text And that, the fact that that item, which is so important, is not computed, but is generated by an LLM at runtime based on what you see, I think that creates a huge risk, and that's why there's 80 companies that are trying to solve agentic runtime security at ARM, and really love to see, like, a little bit of synergy on that front.

Allie Howe: Yeah, and you've got that concept of semantic distance tracking in ARM. Is this, like, kind of the same thing? Similar?

Herman Errico: Yeah, very similar. So, semantic distance tracking or what we're kind of like changing the name to, like, behavioral analytics for agent, is really once you can statistically plot what was a particular action direction, then you can see If a similar action, let's say I have a copy change that looked like this, then there's another copy change that's goes in a different tangent, that you can measure the distance between those two actions and then infer if that action needs to be looked at or even blocked, or you need to do human in the loop. Always use, use like share the example of like me using Claude to make a simple copy change, then something went wrong, and it did change 241 files, and it created 10,000 lines of code because of like a simple sync error.

And, that you can really measure with stuff like semantic distance tracking.

Karl McGuinness: So from an enterprise perspective, we... I was doing a lot of thinking and just about from an enterprise perspective about agentic outcomes, and Mission is sort of where I was pushing a lot on the boundary of there's not really a clear owner today in the enterprise for where that lives, right? And so we have an IDP, you have an IGA system, you have your NHI or PAM system. They all service the credential, the life cycle, the session of the user. There-- But when we talked a lot about these open world challenges, there wasn't a clear governance layer for like, well, what is, where does this exist in the enterprise?

This is gonna need to be something that effectively becomes a first-class object that then has references across the runtimes, the audit trails, everything you're doing. So it's a pretty big shift for the entire stack to go from a token-based model with an IDP to a mission-based model-. -where everything goes from the mission. And so when I was looking where Dick was building the substrate, which was picking up on a lot of the gaps around OAuth from just, you know, like I said, from shifting to headers, public keys, interaction models, he had the substrate right. But we were looking, I was just saying, "Oh, well, we need this layer that is going to describe the, the long-term outcome so we can have a primary object that then we can reference.

We need a name for it, we need an ID for it," and that alone gives us a lot to start hanging objects off of. And so my anticipation is that we're gonna need to have a new role in our enterprise identity architectures. And this is, I'm an enterprise guy, so obviously there's a personal view to this at all, and I'm sure you guys can argue the personal sides, but coming from the enterprise stack like that to me is like we, we have workload identity, we have agent identity, we have the identity pieces and lots of puzzles to it, but we didn't really talk about the, the thing that's gonna unify the, the outcome and allow us to start building the runtime layers, start building the audit layers, start building some of the, the approval layers around it.

And so Mission was sort of the, the framing of that, and I was happy to partner with Dick to be able to see it come out live in, in OAuth 'cause now you can actually see it Are we- See- seeing it live is very different than, like, getting on a bunch of whiteboards and a bunch of presentations saying, "Hey, we need this governance object." Everyone hates the word governance. They love to see it work. We're like, "Oh, yeah, that is what we need." And so I'm excited to see folks touch, feel AOS because you can actually see the power of, of having that layer at the person server.

Allie Howe: D- do you think there's gonna be like a mission manager role at companies?

Karl McGuinness: Yeah. I mean, mission control, baby. Mission control. Mission control. Yeah

Ian Livingstone: Yeah, I think like one of the, the, the hardest problem we have to figure out is like, how do you ensure the agent's aligned with the user intent? Yeah. Or a company intent, or builder intent, or like resource owner c- intent, right? Like we all have these different versions of it. Like, I think I've spent e- enough time trying to explain these things, and I think w- there's a couple things that I'm really excited about here. One is we actually have like a word for this. Like there's intent-based auth, but like what is the thing that int- contains the container for that content? How do I query it?

How does that federate across all these different systems, right? 'Cause if you just have... Look, this doesn't work, like internet doesn't work if I have to go through a centralized proxy, right? It doesn't work if we need like a protocol, and one of the biggest challenges we have is like, well, what's that protocol gonna be? What's it gonna look like? And how all these pieces fit together in a way both between companies, within a company, and across companies, and across technology stacks. And this kind of gives the, a building block that lets us now start to reason about, okay, how do these different pieces of system then get aligned around, you know, intent and what, and then have a mechanism for measuring some different authorization components, a mechanism for measuring whether this thing that's occurring is actually aligned with what this person was trying to achieve.

And I'm super excited about it, 'cause it actually is like the most important building block outside of like actually being able to do iden- identity and the delegation components as well.

Dick Hardt: Now, for me, the mis- the mission concept really, you know, is sort, sort of more at the top level of the stack of things. And earlier versions of the protocol that I'd circulated with people, Carl gave a ton of feedback on that, and I knew there was like something missing, and Carl's being a little modest. Like the whole concept, like the concept and the term a mission was driven by Carl, right? He wrote some great blog posts about it, and he pointed me at it, and I looked and it's like, yeah, that's it. That's, that's the thing that I've been thinking is kind of missing as to how do we tie all these different interactions together in one concept that is the running thread.

You know, you don't want just a trace, you don't just want some identifier that's common, and, you know, the session just didn't really capture it. And so, you know, that drove the idea that, like, let's bind everything to the mission. And so each of the components ha- track, excuse me, in A Auth, each of them has the identifier of the mission, so you can correlate with all the different pieces, but the mission always comes back to the person server as sort of the broader context of what are all the things you're trying to do, so that when you're evaluating one particular authorization, it isn't by itself, it's in the context of the mission and in the context of all the previous authorizations you had before.

So in the example of the sushi restaurant, you know, if the agent's trying to book like a second sushi dinner, it's like, "No, we've already got a sushi dinner that we've already booked." But you wouldn't know that if you're just looking at just the sushi dinner being booked. You need to understand the context of what's happening and everything else that's happened before it, and the mission ties that all together.

Allie Howe: Yeah, I think some of the best security advancements and the ones that get adopted quickly are the ones that are wins not just for security teams and the governance teams, but also for developers. And what I really liked about Jared's demo was it showed how the concept of the mission can reduce consent fatigue for actual users and developers of these applications. And also, if you're governing the mission, obviously, that's a huge win for security teams as well. Which kind of brings me to my next question. If this is a win for both developers and also for security teams, what's their adoption timeline for AF look like?

Dick Hardt: Well, as you can see by tonight, we're an army of what? 200. Next A Auth night we'll be an army of 2,000 and then 20,000. So the, the journey has started.

Karl McGuinness: I think as more and more folks are gonna see is that I'm spending a lot of time doing cost-benefit analysis of what it's gonna take to get OAuth to the promised land, why that's not the right bet, and why we need to start seriously considering A Auth. And that, that's gonna be a conversation that folks and developers, and use cases, and wins of just getting the stuff out there and using it, and seeing it, and feeling it, that it like actually our fastest... We're moving at Asian speed. We're not moving at let's get 17 vendors to all agree on 17 extensions, all deployed at the exact same time across the whole thing, and if all that's in place, then a developer can get time to value.

I think we gotta go back to like, well, how do we quickly get time to value back to the developer, and A Auth just is a great substrate to build on. There's so... Let's be very clear, it's early. Very early. How A Auth integrates with the orchestrator, there's gonna be issues at the substrate level, at the a- like how we think through some of these problems. But the core primitives I think are, are, are pretty spot on. Experts in the room, Jared was just here, he's been building this stuff with me for, for over 10, 20 years. Everyone's kind of looking at it being like, it's kinda right from a substrate perspective.

Getting it out there is gonna take a, a bootstrap challenge of time to value, customer value, pain point for the security team, deployed infrastructure. But My take is gonna be is that we don't need to, and Dick will probably have a very similar point, which is we don't need to burn down the OAuth stacks. We don't need to tell everyone OAuth's over. It's kinda this challenge of how do we build an agent native layer at the core, and then how do we sorta NAT our way out to sort of OAuth. So I view NAT as like the analogy in my mind is that, like, IP4 never went away.

Everyone talked about the future is everything, and we're just gonna NAT our way out of this problem, where we build the core, we get time to value, and then we're gonna have the, the escape route to, well, how do you get all this rest of this ecosystem integrated without rewriting it all? I think we're gonna have that unlock is my hypothesis. I can't give you a, a precise month by month, but I just think getting this back into d- dev's hands, folks are gonna realize that it's actually... It's got the... I mean, the hardest part of protocol design is, is complexity, and so we- we're looking at an artist here of, of protocol design.

And so it's not, not easy.

Allie Howe: Yes, for sure. And it takes so many people around that movement to really get it going. Yeah. But like you said, I mean, agents are now, so- Yeah... Hopefully it won't take very long. But no, I, I liked what you brought up about OAuth, because OAuth's not going away, and while we're very focused here on the future and what's coming and the future of Agent Auth, like, I also wanna communicate, like, what are the best practices for what we have today and how can we make what we have today better while we're transitioning over to A Auth. And then Carl was involved in ID Jack and creating that, which is a new grant that is actually the backbone for Cloud Enterprise Manage Auth- Yep... which came out recently.

Which is also another win for security and also developers. And it's responsible for making it so you could just log into your IDP one time, and then you don't have to go auth into every single MCP server. That's just all done for you now. And also, now your security team can also revoke that access at any time, and it's got visibility into that versus what existed before, which was an OAuth island. And Carl, can you tell us more about- Yeah... what an OAuth island is?

Karl McGuinness: Going back to the original opening part of the, of the, of the event, which is OAuth was built for one server getting a credential for another server in a known single trust domain. And we optimized at that time with the protocol and the technology stack, and we scaled that with a bunch of extensions around a bunch of edge cases around that to, to make it useful. The multi-authorization server problem is something that that stack was not native for. So when I say multi-authorization servers, every API I interact with is a resource. It has its server that it issues tokens for its resource domain. There's not one universal authorization server for the entire internet.

There's a lot of reasons why people run their own authorization servers. We have an ontology problem of understanding your resource domain. There's a bunch of engineering metrics about like performance and caching and where you put complexity and, and the side of it all. And so when the agents and modern architecture start thinking about, "Well, I need to go cross multi-authorization servers," we needed to solve this challenge. And we looked at what's available, where can we push on this problem, and what we said, "Well, why are we requiring interactive consent for an end user in a enterprise deployment model where the end user really isn't technically the end accountable resource owner?"

It's the organization, right? It, it's their data. You're a employee under HR policy for an organization accessing an employee resource through an OAuth consent dialogue. So it's like, well, are they actually able to make an informed consent decision about what's happening here? And then how can we scale that across multi-authorization servers if we already have the ability to, to broker trust? And so we found a clever way to kind of push that forward to align the value props of multi-authorization server, end user win, security win on revocation. And I think going to touch back to A Auth is like the win's gonna be the mission layer going to the next jump, which is like, that's cute.

It solves a set of challenges, but it's still glossing over, well, how do you know what scopes to ask? How do you know what resource servers to trust? You've pre-configured the federation from a SAML perspective for every one of your SaaS partners, and you've pre-configured the authorization world in a way that I know you go back to the like, well, unlocking agents with intent, how does that really gonna win it at the end? And we-- it's not gonna be sufficient. It's a building block, but it's not gonna solve the, I wanna empower my organization to use and consume agents with broad scope of goals and intents where I haven't predefined the entire authorization graph.

I don't know all the different things it's gonna connect to do it. We're gonna need a mission layer. And so the, the opportunity there, I think, is to, to look at Auth as a, as a layer that could help provide that.

Allie Howe: Absolutely. So what I'm hearing is, you know, Auth is the, is the future, but there's things we're doing right now with OAuth that are making OAuth better today, such as ID Jack.

Karl McGuinness: There's a lot. There's a lot. ID Jack is a huge, huge win. I mean, just why is everybody having to have every user run a consent flow-... vault a refresh token, have a long live secret that lives outside of any governance that every... And then, like, this just-- It's, it's a nightmare. Like, the fact that we've been doing this for 10, 20 years at the scale of SaaS, 'cause every SaaS integrates to every other SaaS. The network of applications, the constellation, whatever term is, is your favorite, is how organizations use today. They don't use an app in isolation. They use it in integration with all their other tech stack.

And so forcing that on a per user decision every time they onboard, every time I log into a Slack channel, every time I look at a new wiki, consent, consent, authorize, authorize, authorize, authorize, authorize. Like, and then storing all those tokens, all those governance and security risk issues. Like, we've had this breach issue for, for 10 plus years. What we haven't had was like, what's gonna drive change? Why do people care? Why now? And a lot of adoption issues come down to timing, and so we're lucky to, to align the value now with agents that just make it pretty much a non-starter because we can't just push that problem down to, to an end user consent problem.

And so there's lessons learned there in adoption. I haven't quite cracked yet how we're gonna do that yet with Auth, but I'm hoping that we'll figure it out.

Dick Hardt: So going back on that, I thought we were gonna go down on- Yeah. I, I started with Carl around adoption story.

Allie Howe: I always have more questions for Carl. You go, yes.

Dick Hardt: Okay. Yeah. So one of them is how do we get rid of API keys, right? So a powerful part of OAuth is enables dynamic aspects and, you know, we saw mail channels. There's a number, you know, outgoing.world has turned up OAuth that, you know, if we can get some aspects of some OAuth clients, an OAuth client can talk to any OAuth resource. And in the world of agents where you want an agent to be able to start to interact with a resource right away, right? I think that's one of the great things around mail channels. Like, "Oh, I could go and send mail. I can go...

The agent could start to talk to it right away," as opposed to, "Oh, well, if you wanna use this resource, go over to the console, log in, create an account, find an API key, copy it over, paste it into here," right? You know, the friction, the security issues around that are huge. And so I'm hopeful that some people just building resources are gonna, like, dive into OAuth just for that first layer. Knowing we wanna work with the rest of the world as opposed to, you know, everyone's gonna just use OAuth and gonna migrate off of everything. That's not gonna happen. And so in OAuth, the, the next level up is that we've made it so that built into the protocol is ability to move an opaque token, which could represent or, well, essentially wrap up an OAuth token.

And so a number of vendors are looking at building gateways that would sit in front of existing OAuth 2 APIs and present them as OAuth resources. And then you get all the power of OAuth, of the discoverability, of the ability of being able to enable the agent to do super sensitive concerned API calls that you don't wanna let the agent call an OAuth 'cause those ones can flow back up to the person server for authorization. And so that can unlock existing... Like, people don't have to rewrite their stuff to have it also exposed as an OAuth resource. And so those are just two base levels without anybody having to start to integrate into a person server or anything else, but they start to enable OAuth clients.

And on the OAuth client I didn't get it baked enough to demo it, but I was hoping to, but I've got a general purpose MCP server that just talks OAuth. And so you install that, and then you just talk to any OAuth client right away. But it's really gonna be the pe-peop- you know, people like the people here in this community. I've been amazed at the people that have shown up and says, "Hey, I would like to write a Go library. I wanna write a.NET library. I wanna write a Rust library." And people are coming in and building on top of OAuth, learning things. People are writing stuff.

I mean- OAuth was probably one of the first potentially popular protocols that was written heavily by agents. And so I write stuff, I go and I give Carl a draft. Carl takes a draft, he dumps it into his agent in his context. He goes and sends me back what the agent says, and he says, "Oh, here's what my agent said. I haven't read it yet." And I'm like, "Well, if you haven't read it, I'm not gonna read it." And so I just give it to my agent and say, "Hey, what, what, what does Carl's agent say about this that maybe we should put in the draft?"

And it goes and gives me a number of like suggested changes, and I look at it and it's like, well, some of those make sense, and I tweak it and like a new version pops out. And then a guy that was doing the Go Library, like as he was having it build out, he's like, "Oh, well, you know, my agent wasn't really sure what should happen here." And I realized, oh, well, that's a hole in the spec. We weren't clear enough. And like, his agent gave me a bunch of feedback. I gave it to my agent, turned it up. If you look at the version control of OAuth over the last- Yeah... two months, like there's like five versions as people gave feedback and me- a lot of that feedback is just tuning up and improving the spec and driving it more.

I mean, it's a super exciting time to be writing software. And so people are just, you know, pointing their agent at the spec and say, "Write me something," and like code comes out that works. It's pretty exciting. And so the people in this room, you know, go to OAuth.dev, you know, check out the demo, jump into the community. We've got a Slack workspace. Super keen to get involved with everybody, 'cause it's everybody's feedback. Now is the time when we can go and make this work well. Who is it? I was talking to somebody about, you know, how as we start to have more and more resources out there, how do we start to lay the right rails for reputation of these open resources?

So as opposed to, oh, that's a problem three years later, and we start to do it. So what are the things we can start to think about doing now to start to build up that signal so w- we can have reputational signals around is this a trustworthy resource, as opposed to like later on when the world's burning, be like, "Oh, maybe we should think about whether those are good resources or not."

Karl McGuinness: There's a lot of lessons learned from open world, like just today with Chrome and everything. We, we had this issue with TLS, everything. So that whole shift to open world is like we've had lessons learned from the human version of open world. We know those are huge fraud risk issue signals. There's a substrate here. How do we start pulling some of that early thinking in now? And so that, that's to me an exciting, an exciting piece. One of the things I wanna come back to was It's kind of gotta parse between the lines to really grok it, is that OAuth is, I think, more native to HTTP.

It's more closer to the, to the network layer. And so what that gives you, too, is a little bit of more possibility of understanding because it's resource-based, you make an HTTP call, it then says... That resource server says, "Well, here's the shape of what this means in context of me." this is an extension called R3, but the-- just for the purpose of this talk, it's all OAuth.

Dick Hardt: Rich Resource Request- Yeah, yeah... R3. Yeah. I thought it was a cute name.

Karl McGuinness: This, this is, this is pretty-- It's actually pretty interesting because we've always had this ontology problem of I wanna centralize, but then how does my central authority know all the context and in the intricate parts of the domain of the resource? Or do I put it all in the resource and have to implement policy there and lose all the centralization capabilities? And we've lacked a clear way at the protocol level with our auth protocols for you to start at a resource saying, "Well, I just made this get or delete call with slash customer param. Here's a shape of an API re-request." It's at, you know, a GraphQL call.

It's a SQL call. It's an SSH, r- you know, doesn't matter what stack you're at. Again, we're operating at a closer to network level, where now the resource server can say, "Well, here's me turning that into a context that's specific to me," passing that through all the way to that person server, where now the human on the other side of the person server has an ability of seeing, well, what is it actually trying to achieve? Is that actually what I thought it was gonna achieve? How do I prove it? Like, that's a pretty powerful loop that just doesn't really exist today, and this is why we run into all these scope challenges.

We run into all these protocol issues of trying to map where are we gonna put the policy layer? How is that policy layer gonna understand the semantics? Where are we gonna put the ontology? And then how the hell at the admin level does the owner of that system manage this? And this is always this internal debate of like, well, my identity administrators, they're horizontal. They don't understand anything about Salesforce. They don't know anything about a sales lead. They don't know anything about a customer record. How are they gonna build policy to grant who has access to what record? And the Salesforce admin deep in their stack is like, "Well, I just own my little tool.

I can build my own policy, but I can't actually pull that into a agent-based access request model." And so bringing these folks together at the protocol level of putting some of those pieces into it, it's very early, but that's to me some of the exciting pieces because I've seen the role separation inside organizations, how they specialize, who wants to own what part of policy, and we've been able to dis- undissambiguate that because we haven't had the separation of concerns, I think, at some of the protocol layer that some of the OAuth pieces have. And so I just wanna say that your layer three, you mentioned the sort of layer one, layer two, to me, the layer three is this R3 layer that I think is pretty, pretty fascinating.

Ian Livingstone: One of, one of the things I wanna point out is, like, we spend I spend a lot of time talking to people with bad OAuth implementations. And the number of like... The biggest issue with OAuth is it's evolved slowly and through committee, right? And also people have implemented it in many different ways 'cause it's underspecified. And as a result of that, it means that from an integration complexity, so many of you have probably built OAuth or used it, they all look, feel, and do different things. And so when it comes to, like, interoperability, especially in the age of agents, this is a fucking clusterfuck. Like, it's really difficult to do.

And I don't know how many of you have gone to-

Allie Howe: How, how do you really feel about it, though?

Ian Livingstone: I'm, I'm just being honest. If you go and, like, use all these, if you try to use these different MCPs with the different OAuth implementations, you quickly realize that none of them actually operate very well together. And so from that perspective, the, the greatest component here is that Trying to support the broad, bloated world of OAuth for which underserves the actual use case of agents. We're in a moment where everyone's sitting around being like, "How are we gonna make this work?" We have a n- we have a new potential answer. That answer is much simpler to understand and is much more specified. And as a result of that, I think what has always happened in these moments is there's always a shift in each platform, shift in how security models work, and how the protocols work, and what the new model requires.

The most important thing, I, I look at this and say, we need like a very simple answer for how we solve a lot of these interoperability problems, and A Auth actually gives a very specified answer that it, in the age of agents, is also very easy to build.

Dick Hardt: I'm gl- I'm glad you- That's the, yeah... I'm, I'm glad you brought that up 'cause I, I, it's a point that I hadn't mentioned. Carl and I are both working on a s- a whole working group- Yeah.... called IPSE around-

Allie Howe: Who's got McDonald's?

Dick Hardt: Oh, it's me. It's me. Thank you. I get McDonald's.

Allie Howe: Okay. It's the best part. Now is your, is your glucose a little low right now and

Dick Hardt: Well, I, I every, all of you ate all of the food before I got to eat the food, so- Yeah that's what happened there. Yeah. So, so Carl and I are in this o- I have some fries. Thanks, Jeff.

Allie Howe: That's Jeff Huntley, by the way, who we're debating tomorrow on stage about loops at AIE. So if you're at AIE and you wanna debate loop engineering, Jeff and I are going up against Dax Rosworthy and Greg from Sentry on stage. So anyways, sorry, I just had to point that out. Okay. I have to promote my, my next talking engagement.

Dick Hardt: Are there side bets- I'm in this debate... on who's gonna win? Is that like in one of the betting platforms?

Allie Howe: Loops are here to stay. Okay. That's anyways. Okay.

Dick Hardt: So there's this working group in OpenID Connect that Carl and I are involved in around profiling OpenID Connect, profiling SAML, profiling SCIM, because they're underspecified. Yeah. And so profiling is saying, you know, there's different levels, here's all the things you do so you know it's secure and you know that it works. And a lot of that is because a number of these, you know, SAML's a framework, OAuth is a framework, because people had different ideas. Intentionally with A Auth, it's a protocol so that there's conformance right out of the gate. You know, if you're writing an- Yeah... A Auth client, it does all of these things.

It has to do all of these things so that everything just works right away, which inherently you have to have if you're dynamically connecting to something. Yeah. Right? You didn't say, "Oh, here's my thing. I'm gonna connect to your thing. Let's make sure it all works." Right? I've, I've connected to all the major OpenID Connect providers several times, right? And I just write it by hand now. But every one is its own special snowflake about how it works. And so from that pain- A Auth isn't gonna work like that. It's gonna just work out of the box.

Allie Howe: Amazing. Yeah, that's really cool. What's it like building a framework, building a product in an ever-evolving space where we're- we've got these advancements for OAuth coming out to make it better, but we also have A Auth coming down the pipeline. How do you build for now and also anticipate the future?

Ian Livingstone: That's a Herman question. He, he, he's spent... He's talked to so many vendors, like you must and, and, and customers. That's definitely a you question. Wait. Yeah. Her- is Herman the agent? Oh. Mr. Arm the agent. Arm the agent? Yeah, there's probably an Arm in agent somewhere.

Herman Errico: I think the key is to not build for what is in front of you, but to make assumption for things that will be true in five to 10 years. ERM is autonomous action runtime management. The idea is that for the next five to 10 years, we're gonna have autonomous action Maybe it's gonna be agents, maybe it's gonna be something else, maybe it's gonna be lo- I don't know, loop machines or loop factories. There's gonna be another terms in a, in a, in a couple of months. So I think really is establishing those foundation, but then adoption is really key. And adoption really comes by connecting the supplier and buyer side of the equation.

In this case if I think about, about AI, it's about making sure that developers do use the system, but also that users find it useful and frictionless. In, in relation to ERM is really making sure that both builders understand the specification and they have a perspective like, "Okay, I do align with some of the primitives that you have defined." Pre-execution interception, the policy evaluation, the authorization decision, the gener- logging, semantic distance tracking, all those like primitives. And people really need to align with what you built because obviously developers are sa-- they start saying, "Well I wanna do just three and I wanna skip the other two," then it, it, it creates like some fragmentation, which then leads to a clusterfuck of a bunch of things.

And, we definitely don't wanted that. And, but on the other end, you still want buyers, which is practitioners, to recognize this is a problem. Agentic runtime security is a huge problem because like you can solve the identity piece, but still like hallucination is there. Agents do make mistakes. There's relevant threats that exist today. Prompt injection is one. You can solve it in some ways, but obviously runtime is super critical. And once it's really about adoption at some point people need to adopt it. Are you gonna hit a tipping point where it's the de facto standard? And that's essentially the perspective that I have.

Allie Howe: Yeah, I certainly feel like there's a big appetite for adoption. I know one of the big themes at AI engineer was software factories. I feel like all the raw materials for software factories have arrived. We've got model vision capabilities that allow models to verify work they haven't before. Context windows and memory has improved, so now p- models can see what work has been done before when they're in a loop. So all these raw materials are here, but it's like, how do we actually harness this power and unlock the productivity gains of a software factory? I think Auth, Auth runtime, security, all of this plays a big part in being able to use a software factory effectively, build loops that don't actually produce slop.

We're gonna get into this more into the debate tomorrow, so I hope you come out for that, it'll be fun. But for all of my people on this panel here one of the things we're trying to do at Entourage is build this community around agent security and agent Auth, and it takes a really big tent to make waves and changes in the industry. So of course, like Auth is wonderful, but is it the full solution? What other parts do we need? What does agent identity and agent security look like in like the next year? And how is Auth maybe just like one part of that solution?

What else is needed, and what do you think the end state actually looks like?

Dick Hardt: I mean, it's so early, right? I mean, you know, anyone writing code, like how, how I write code now is very different than I wrote code eight months ago, and I know in eight months how I write code's gonna be different again. And what are the requirements in this like ever-evolving world? I don't know, right? I f- I'm trying to look to see what do we need to do around Auth, but predicting what else we're gonna do I just know it's gonna be different than what it is now.

Allie Howe: What's one thing that if it existed would make AOS work even better?

Dick Hardt: I think, you know, the, you know, one thing that comes to mind is how do we have a reputation system so that we ha- we can have some reputational way to know about a resource because, you know, that's always been a problem on the open web is like, can I trust this website? You know, so how do we get-- How, how do we solve it? It's kind of an unsolved problem on the open web. I don't know that we're gonna solve it well. You know, I'm, you know, Ken's been working on stuff like this in mail for a long time, right? So hopefully we can pull some lessons out of there, and maybe we can start to go and pull signals from mail, from a number of other places, 'cause there's quite a few signals on web and things like that, that we could pull together.

But I think that's sup- a super interesting area, and agents might be the thing that drives us, driving a lot more reputation around entities that we're interacting, whether that's mail, whether it's an AOS res-resource, whether it's a website for humans.

Ian Livingstone: Well, first and foremost, I think, like, the only way that, like, we're gonna get through this is, like, a group of people, screw the vendor thing for a second, is, is just by, like, let's talk about the problems. Let's get aligned on what the actual problem state is and can we, like... Second, can we remove, like, the random bad ma-marketing messaging that comes out of, like, you know, big tent vendors trying to retain their market share or whatever it is, and can actually, like, get really concrete about, like, what is the net new problem? What is the delta between what we have as, like, an industry conceptually solve versus what we need to solve?

And then third is, okay, now that I kinda can understand that, what are those solutions we're working-- One of the reasons that I love what Herman's working on with Arm is, like, it really doesn't get into the specifics of, hey, I don't know what the solution is, but we actually know what the problems are defined and what those requirements are to think about it from a security perspective. And so, you know, first, the, the most important thing is can we, can we actually a-agree what the problems are? And I think we're starting to get pretty well aligned on what the high levels are of the problem statements.

And then second is, okay, now I, who, you know, whether independent of what you're building, now we're starting to get aligned on, okay, what is, what are the ways that I can think about solving that, right? Like, what are the protocols and what are the different pieces and how do we start pulling that together? We're just starting to, I think, crack the tip of that iceberg in terms of how we do that and then how we, how we, you know, tra-terraform our-- the world of computing to, to fit the new world that we're actually entering, which is very what I often call, like, agent native versus human-driven or agent-driven versus human-driven.

But it's a very different set of interaction patterns and very different set of technologies that are now gonna be the primary interface to what used to be, you know, humans pointing, clicking, and pressing buttons.

Herman Errico: Okay. So thinking about predictions, the honest answer is I have no clue. In six months' time, I could be jobless and being a farmer, maybe. We'll see.

Allie Howe: There's nothing wrong with that. I think it's a great outlook.

Herman Errico: But if I were to, like, try to identify some patterns the operating system is still gonna be there. Processes are still gonna be there. We're gonna have, like, tool calls, these components, APIs or, like, real primitives will be there, which probably makes me think that we're gonna see, like, an increase in, like approving human-in-the-loop actions even outside of, like your normal agent running and that's probably as far as I go. But, going back to Ian's thing about this requires really the people in this room, outside of this room aligning on a problem, and then really wish for, like, less fragmentation of, like, million things coming up with, "Hey, this is the leading, cutting edge enterprise detection thing" that a particular vendor tries to drive, and really love these, like more shared initiatives where here's a protocol, we compete on execution rather than we've created a secret sauce which at times doesn't work Over to you.

Karl McGuinness: Yeah, I come back to incentives. So trace the incentives. So there's a cost problem, there's a productivity problem, and there's a risk problem. And so I think when I trace those, that's kind of how I, I look at some of just how I looked at the last wave of productivity with SaaS and cloud and everything happened. We have a BYOD problem of like, well, how do I empower the people to choose their tools? It then has a data problem where now my data's everywhere, but then there's a cost problem of like, how do I manage this? And so in the, this model here, like, well, I don't wanna put all my tokens in one model provider.

I wanna have ability to optimize my cost structure. Not everything needs the same level of intelligence. At the same time, I wanna be able to have my employees adopt and be transformative, and I, I have wins. I get promoted by how much I can transform my organization and jump between organizations, and the more wins I get, the more momentum I get and build momentum around it. And then at the, the risk side of it all is like, well, they're, you know, back to the whole point of the mission and undetermined, you know, this is an un- a non-deterministic outcome, and so how do I manage the risk of non-determinism?

So those all kind of like play to me off different aspects, and it's who starts creating repeatability where they can build momentum, build the reference architectures, start figuring out how to manage the incentives to get the wins, to get promoted cut through the vendor noise. Like that's just how I've saw it work in the last generation, and I don't think the macro of that changes. I just think we're lost in the... or early in this sort of bombardment of everything's too new. We're operating at AI speed. Nobody has the time to dig deep in all this. So it's just how do we move fast and then understand the incentives, map that back to how are we going to empower the organization, get our wins, manage the risk, manage the cost, and that's where best practices, that's where...

That only comes with lessons learned and time spent. And if we keep rewriting the fabric overnight and keep rewriting the rules overnight, like it's hard to build on top of anything. And so we have to get some stable pieces that are okay, through enough trials and tribulations, we agree these pieces of the plumbing are gonna stay, and we're gonna build a layer of abstraction. And so the timelines for these, I can't tell you, but what I can say is that like we need to get some of those pieces of the architecture in place so we can start evaluating all three of those outcomes and figuring out what trade-offs we need to make.

And the folks that get the wins are gonna be the ones that drive the, the CIO and CISO and the board and those types of conversations that get the funding to make the investments that end up becoming all the customers that we all wanna interact with.

Allie Howe: Amazing. Thank you so much for being a part of our panel. Really appreciate it, and thank you all for being a part of AOF night. That's it for us. We'll stick around and network. If you wanna check out AOF, aof.dev, and if you wanna hear more about, from these folks, you can also check out insecureagents.com. I've done an in-depth podcast with every single person on this stage. So yeah, looking forward to networking with you later. Thank you. Cool.