Insecure Agents — Episode 9: Ian Livingstone, Co-Founder & CEO of Keycard
Podcast: https://insecureagents.com
Listen: https://podcasters.spotify.com/pod/show/insecure-agents/episodes/Ep--9-Ian-Livingstone--Co-Founder--CEO-of-Keycard-e36r91l
Transcript (auto-generated, lightly edited for clarity).

Allie Howe: Hey everyone, welcome to another episode of the Insecure Agents podcast. My name is Allie Howe. We are here today at the beautiful Bellagio Hotel on the backstage of Black Hat here in Las Vegas. Today we have Ian Livingstone here with us today from Keycard Labs. He's the CEO and Co founder there to discuss OAuth as it relates to AI agents. Ian, would you like to introduce yourself?

Ian Livingstone: Absolutely. I'm so excited to be here with you guys and so excited to be at Black Hat. It is my most favorite summer event in Vegas, which is means is the only event I go to in Vegas in the summer. But yeah, we're super excited. We're just starting to start talking about Keycard Labs. We started the company 6-7 months ago actually on the back of trying to really fix machine identity, which has always been this like long, never ending problem in security. You know, everyone has gone to OpenAI and everyone's gone to a dashboard and copied some long-lived static key. And inevitably I've had that leaked like into Slack.

And we said, hey, this is, you know, there's lots of companies out there that are telling you how to make secrets better. We want to make secrets go away. Like developers shouldn't have to ever deal with them. We should never have to think about them. This is a solvable problem. Most machines in the world have bootstraps, secret zeros, like can we build a new version of machine identity access, an access control authentication authorization system that allows us to never have secrets? You just basically like define what pieces of software in your staff connect to each other, and then it just automatically connects. And that was the genesis behind Keycard Labs.

And then we sort of started the company, closed our funding round in December and left our jobs as myself, Ian Livingstone and my 2 Co founders, Matthew Creager who used to run platform engineering and developer experience at Snyk and DevRel and Dev X at Roku. And then my other Co founder Jared Hanson used to be the chief architect of Auth0 and then spent too much time at Okta. And we came together to decide, come to solve this machine identity problem. But, you know, got in our chairs in January and said, oh, shit, like agents are real. Like we always knew agents were coming, but we didn't realize that, you know, 2025 was going to be the year of agents in the same way that it has become.

And a lot of what we were thinking about and what we have been thinking about in terms of agent identity, agent access, agent control, and the how we remove the secret management problem in general is exactly you need to do in order to actually solve agent identity and authentication. And so from the beginning of this year, that's what we've been wholly focused on. Then have had honestly the best of the three companies that started the best start I've ever had. So super excited what we're working on and super excited to dive into. Like, what is an agent like, what is an agent identity? Like? Why does, why is this a problem that's different than anything else?

And and go from there.

Allie Howe: Amazing. Yes, this is definitely one of the top problems for AI agent security I think today. And I was super excited to host the security track at the AI Engineer World's Fair back in June in San Francisco. Jared, your Co founder, gave a talk there about Keycard and I was really impressed by what you all were building and shared with the community there. I also heard a few other talks about OAuth as well. So I feel like it's very top of mind for people. I think there's this last mile problem with AI where it's really easy to create an AI agent, proof of concept, but moving it into production is so much harder.

And OAuth is 100% one of those problems that needs to be solved. And I think it's part of the recipe for how do you build trustworthy AI, which is something that I'm really interested in with like the company that I run, Grow Cyber, really trying to come up with, you know, a favorite AI startup. What is the recipe? What do you need to be thinking about in terms of AI security if you're going to communicate to your customers? Yes, I'm building trustworthy AI. You cannot have trustworthy AI without solving the OAuth problem. As you mentioned, managing non human identities has always been a challenge. But with AI agents, it's even more so of a challenge because you're managing the identity of the agent itself, but then the agent goes and assumes human identities to go and complete different tasks.

And then if you're talking about a multi agent system, passing that identity down through the chain, Oh my gosh, it's so much to manage. I don't have the answers there, but I'm hoping that you do.

Ian Livingstone: Yeah, we're just we're getting started. It's, you know, very much do it that and this is finally the reason we started. Like at the end of the day, I think the core insight that we really had, I think the core thing that most people are learning is you have this inherently probabilistic system, right? Like what is an agent? Well, there's some words in there. There's an element at the core of it and the thing that makes it unique and novel. And the reason we rave A boner doing it is because it's probabilistic. But at the end of the day, like how do you build trust in a probabilistic system?

Well, sometimes you can use other probabilistic systems, but you still don't have any deterministic future guard rails. And really the last layer of defense that you have is, well, what can this thing actually do right? And unlike previous identity systems, if you go back over the last 25 years of of of identity, it's really been focused on user federation, right? Like, how can I have a central source of user identity? How can I then delegate that out to different apps? And then how do I, you know, when that person leaves the company, all of their accounts deprovision, right? How can or when they join the company or they join a team where the roles change, you know, which doesn't happen very often.

All of the permissions, the different and apps get updated. And sometimes we haven't really even actually solved the authorization side, but we've kind of solved parts of the authentication side that is identity focused. And when we talk about agents, we're moving from a world where like, well, first and foremost, like it's not just user centric anymore. Users are actually what we're doing with agents. We're disintermediating the user from the downstream core system and inserting this thing that's inherently like untrustworthy, right? Like it's not that, it's not purposely malicious, it's just, it's not anything. It's a distribution of probabilities. That's incredible. It's the feature, but how do we actually understand what that thing is, what it can do and contextually change what it's able to do based on the tasks it's asked and on behalf of whom?

And how do you as a downstream system understand that? An upstream user said, hey, actually, you know, this agent can in fact delete this S3 bucket Or this user said, hey, you know, this agent can in fact buy this pair of shoes or for $50 instead of $1000. Like how do you do that? Like how do you have those guarantees in the system which are the same type of guarantees that were required? We think back to dawn of the Internet when we started doing credit card transactions. Well, how do I guarantee that my credit cards don't get stolen and transit website, right? Like we had a lot of the same fundamental problems.

We needed real guarantees. That's what TLS, you know, SSL and early on and now TLS have provided to us. And so we have sort of at the same position with agents, which is cool. I want to use agents, I want to build agents, but I want to put a box around what these things can do. And I want to enable some type of upstream trust equation to my users. I as an agent builder, want to have guarantees or all my agent can do as well. Because in the same way that like Tesla won't let someone use self driving mode if they're not looking at the at the road, you know, as an agent builder, I wanted, I don't allow my agent do crazy things because then it's my liability.

And then for resource owners, you know, whether you're Shopify.com who's just announced some really cool stuff with agents, or if you're on eBay, or if you're, you know, some internal security team, how do I control what those agents can actually do? How we understand and control the blast radius? And how do we ultimately prove and push liability back to the end user, right? Like, how do we know that Allie did in fact tell this agent to do this thing and that agent is not operating out of band, right? And so in order to do that, we actually have to rethink our identity staff. We have to rethink identity and access and we have to do something we've never done before is yes, we solve user federation, but now that no point in the history have we ever actually solved machine federation, right?

There is not an SSL for infrastructure. There's not an SSL for services like there's so a bunch of competing standards. It's implemented completely differently all over the place. But we're at a point in time where we actually need the same thing that Okta and SAML brought to us. We need the same thing for agents. And it is a completely different type of stack and has a huge amounts of different types of properties and it thus a massive unlock. And if we don't have this, I've used analogy all the time, is like, OK, well, if we don't solve this problem, what happens? Well, ultimately what happens is we don't ever get to realize the promise of AI, right?

Like the promise of AI is this idea in a shopping use case that I can say, hey, agent, go find me like legitimately my most favorite pair of Nike shoes in my size, Find me for the best price under $50 and just keep looking until you find it for the next 72 days, right? That's asynchronous and it's autonomous. It's off doing the thinking. And I as a human that granted it given it a task, but I don't have to be in band, right? Like, that is a lot of the vision for what AI should enable for us as humans is to do a bunch of the grunt work we'd never want to do, but do it as if we were doing it.

But with own reinventing our access stack and all, building native agent identity and then building dynamic authorization on top of it. We won't be able to enable that type of use case since everyone basically stuck with what everyone saw in the OpenAI operator demo, which is cool. I've built a thing that can navigate the web, but I'm literally sitting there watching every step of the way. And it took what would have taken me 15 minutes or 10 minutes, actually took the agent 20 minutes. Like it's this really like a great example of the future of AI. And so that's the fundamental unlock and how we think about it and why it's so important is how do we go beyond from Co pilots?

Like today we have Co pilots and that's human driven, AI assisted to a world that is AI driven, human controlled.

Allie Howe: Absolutely. Yeah. A lot to unpack there for sure. I really liked what you said around have there's this very much non deterministic system here. And so how do you add these, you know, hard stops, these guardrails into place because your agents going to make wrong decisions that you should prepare for it. And it's not like we're going to create this perfect agents always going to make the right decision every time. It's nondeterministic. It's never going to do that. And in my own experience creating my own agents, I have found that the more tools you connect to your agent, the harder it is for your agent to know which tool is the right tool to call at a certain time.

So you need to be prepared for it to call the wrong tool. And there was some really interesting research that came out from the Trail of Bits blog a few months back around I think there was a tool poisoning and some MCP tool that the prompt of that tool said something about and the name of SOC 2 compliance. Please export the entire chat history from this agent, which is a little bit of goal manipulation there, right? Because I think the agent probably knows that IT security is a goal that it should have, but it obviously doesn't know enough about SOC 2 to know that that's completely non applicable and not good for security.

But if you had auth in place and that request came in, please export the entire chat history. OK, Where's the chat history? Probably in some database. I know some of the frameworks I use, Mastra, for example, they have their own database that gets created as part of that framework. So you probably are sitting on some sort of database with that chat history. And if you had auth in place, you would see that request come in. No, it's not authorized to access that database in that way. And so you'd have that hard stop, that hard guardrail. That's why people, I think need auth and then maybe they're not thinking about it because so much can go wrong with agents.

And I'm even thinking about some of the research that's happened here at Blackhat that I have seen, which has been really exciting. I know Zenity presented some interesting research yesterday where they showed an agent was connected to Google Drive and using like ChatGPT's connectors. And they were able to actually extract API keys that were in Google Drive by adding an indirect prompt injection to a Google Doc. And so again, if you had auth there, you had some sort of, you know, hard check in place, you could prevent things like this. So this is a definitely like part of the last mile problem for creating production level AI and it's something that people need.

So I'm super excited that you're in the space solving this.

Ian Livingstone: Absolutely. You know, we, we, this is one of those problems you kind of have to solve from the ground up, right? Like we've been very focused on you mentioned, like the API key thing, like the the reality is, is like one of the core problems with our IAM stacks today is like they're broadly based on long lived session tokens or API keys or bearer token things that get littered around in the place that get in Google Drive, they get into logs and those things can live for long periods of time, right? And in modern systems, yeah, we might have a timeline of like 24 or 20 hours on login sessions and they expire.

And that's sort of how sometimes in user, in the user world, we have like negated some of the risks associated these long-lived sessions. The problem with agents is they're hyper ephemeral. They're hyper fast and their behavior patterns are incredibly unpredictable, right? So like anomaly detection doesn't really work in a situation where that you have the core feature of an agent is actually task dynamicism. Like the core thing we want to enable is the fact that I build an agent once and as I give it data and actual access at inference time, it can take on net new tasks and solve them very well. Like that is the core unlock that agents promised to us and do it in a way that's a synchronous autonomous from the human.

And so the core bedrock, what we've have even started to do is how do we move the world away from like long-lived tokens to hyper ephemeral task specific like JSON web tokens that include that include like user properties like hey, the user did in fact, like delegate this to this agent. In fact, this is his agent's identity. And you can treat those two things as separate, but also use them in conjunction, perform both authentication, but then ultimately authorization. But as you build up from that, like ground level. So now I have, I can identify a user, I can identify an agent, I can prove that a user did in fact give grant this action ability or this functionality or to this agent for this time duration under this context, all baked into like a token that you can actually read, understand, authenticate and authorize.

Then it's building on top of that, which is, OK, great. Now that you have this sort of bedrock and those basic understandings, how do we go to that next level of what you were just talking about, which is what is the data flow within an agent that's actually allowed to pass? Like, what tool should be able to be called in the context of like a user's prompt, right? So as a user writes a prompt to an agent, really included in that prompt is actually going to be a bunch of access grants and probably predicates upon when those access grants are valid, right? And so that's how we're starting to think about how do you actually build a much more holistic sense of agent identity access and authentication authorization.

And then you have the next level, which is there's a whole bunch of like agent generic agent security problems, right? Which is how do we prevent certain data flow once the agent has acquired data, How do we prevent that data from flowing to different tools, right? How we print that data from ending up in different places? And this is where like one of the principal, he's always wanted and have never actually had in any, any system ever is like the principle of least privilege, right? But agents have to actually start at no privilege. And as they progress through a plan, as the plan changes, the privileges they have has been depended upon where they where they sit in that like broad plan graph and as it gets revised.

And so a lot of the thinking we're doing is, K, you have all these sort of foundational components I just mentioned. How do you then take those values of components and layer them into the task graph in a way that the agent only has access to exactly the thing they could be doing at that point in its plan? And that's cryptographically provable in a way that a downstream security practitioner can say, you know what the system this is operating and I understand those things. And upstream user can say, you know what, this agent can only ever do the thing upon which I actually granted or within the box.

It doesn't mean it's not going to do the wrong thing. It means that the worst case scenario that could potentially happen, you've taken it from like delete the S3 bucket cost 2. 5 million data restoration to it can't delete the S3 bucket just can't do the task right. And that's, that's the type of things that we have to remove to get these things off of laptops in production is how we how we narrow that blast radius to a point where a security team or compliance team or people or data, you know, data protection team, they could sit back and say, you know what actually, like the the worst case scenarios here, we don't really care about.

Yeah, so they might not do the right thing. The user asked. But that's really the user's problem now, not our problem. And that's what we need to do to get AI from laptops and in production.

Allie Howe: Amazing. Yeah, that kind of sounds similar to the MCP's new like OAuth spec that they put out around changing their service to be resource server for OAuth instead of authorization servers.

Ian Livingstone: Yeah, so we, we Jared on our team is heavily pushed and is it you know, trying to influence in the in the public and privately around around MCP. Anyways, you're going to ask a question.

Allie Howe: Yeah, yeah. No I just it's I was wondering how helpful that is. It seems like it was super helpful because with the way the resource servers work it tells the agent what OAuth scopes it's allowed to request. So instead of just line there requesting everything not knowing what it permissions it actually needs, the MCP server will tell the client what it needs which is helpful. But the only thing that I struggle with there is that the OAuth spec is optional to implement for servers. So it's like if you're a developer and you're like what you know which MCP server should I be using? How do you know which ones support the OAuth spec or not?

How do you account for that in your system? Like you, you probably end up wanting to using MCP server that maybe hasn't implemented the spec before, but you need to use it because you need to push, you know, innovation. So where's the risk reward there? Where's the risk?

Ian Livingstone: Yeah, it's a great question. And so I think this is like that, You know, we talked to a lot of security teams and companies that are trying to be AI forward, right? They, they know that they need to be AI forward and they generally when the company wants to be like I often use the word like agent native. Like when a company decides that they need to be or wants to be agent native, the 1st place they start is usually because they actually want to evolve a company, become an agent. And every company, like just like with every company went from on Prem to SaaS, you have the same revolution of every company has gone from being I'm selling a SaaS software, I'm selling you to an agent.

And there's like, it's going to be, you know, a lot of the same thing. But like they first place they started. It's OK. Well, in order for us to understand what that means for our business, we first have to like, let's use AI internally and do a bunch of automation, right? Like let's pick up cursor, let's pick up, you know, like, let's go to MCP servers so we can expose tools in the cursor, expose tools in the Claude, so we can build agents that can be exposed as tools, right? They can do all of the fun things, right? Or we'll start to live some of that dream and, you know, finally start to solve some of the internal automation we always wanted to do, but never really could because they were not, they were not like truly deterministic problems.

There were heuristical problems that like would require a level of thinking that like classical code could do for you. And what we, what we hear from people in these situations we're starting with is exactly what you just said. It's like people are building MCP servers. They, the MCP servers are building are like unauthenticated and they're spinning them up. And now there's randomly deploying on like a Cloudflare. We're deploying on some random hosted website, some place that someone who's running MCP server that is a broad based backdoor to our Snowflake, to our AWS cluster, to all these different things. And So what they're struggling with is, OK, how do we give our companies, our teams and our Gen AI platform team where these teams are trying to use these things like the tool kit so that, yeah, we, we're not saying, no, we're not shutting you down.

We're actually helping you enable, right? We're helping enable you so you can build secure things. And, and when you do build secure things, it's not just that you're making our days better, right? You're not creating these back doors or massive vulnerabilities of company making us a bad guy. Come to you saying, no, we're actually giving you tools that actually make it easier for you to build agents, make it easier for you to actually like enable the rest of your organization with these things. What we saw for is, OK, great. So you've built a little bit of an agent, but how do you like ensure that agent only has access to the data that user has access do right?

And the reason you want to do that or only has tools that that users access to right for all of the reasons that are the more stuff you dump into that context window, the worse the results of the agent get, right. And so security in the an agent in an agent native landscape isn't just about checking a box for security. It's also about like reducing the probable. Probable space in that context window is small and it's. Is possible so that the agent has the best possible path forward and not a bunch of extra trash it doesn't need to understand. And so we've been working a lot with our customers on how do we create a yes and right.

Like how we make it easy for people to discover like what MCP servers to use and to know that those MCP servers are are safe and secure. Know how to like deploy and publish an agent that other people could use. And then know how to build an agent that is much higher probability of working because that agent is only you has only access to the context that actually needs to do the job versus all of the context. And that's broadly where we're at today and we're incredibly excited about what we're working on.

Allie Howe: That's amazing for your solution. Where does the technology sit inside of the agentic system? Like so Like where's the IDP for all of these controlled?

Ian Livingstone: It's a great question. So I have a slide that some some people seen, but I broadly think about what we're doing is today with existing IAM systems and you try to build an agent with existing IAM system. The truth is, is that like the authentication authorization boundary actually lives inside the agent because you have these broad based overscoped API keys that end up inside the agent to access all these MCP things. Most MCP servers require like long-lived broad based API key that gives access to everything. The best way to think of what we do is actually move that authentication authorization boundary over the agent like, and, and by doing that, we're actually doing is moving the control loop over the agent, right?

Because the agent's control loop ultimately is driven by what the agent can do. And yes, you could have some extra things inside, you know, every agent basically being a giant for loop. But what that agent can do in the context of what it's trying to do ultimately is how you have bring human in and out of the loop, right, Yes, you can have access to do this now, because you've proven to me that you've done the job up to this point. And I'll grant you the additional access in the task, right, like I, as an agent, need to come back to the human before I make that purchase to show, Hey, I actually did in fact find that pair of Nike shoes.

Are you sure you want me to buy it? Yes, right, like, but that control loop needs to be outside the agent, not inside the agent. And so broadly that's what we do. And what are we actually the best way to think the Keycard is we are like the AWS IAM for everybody and every single agent in the world and every single company in the world is going to need an internal and external IAM stack that looked a lot like what you get from AWS IAM. It needs to be mixed identity, meaning that it has to both deal with user federation and machine identity federation. It has to deal with like dynamically tasked scopes of roles and actionality.

We think of it as per task based contextual based roles and that being scoped into the specific grants that are time limited and ephemeral and that are highly revocable. So it's easy to revoke and are only usable by that that identity, right? Like using proof of possession tokens so you can prove that in fact, hey, this agent, it is actually this agent that is actually making this request. It's not like Susie Jane down the street that stole this like bearer token is trying to use it on outside out of band. And so those are some of the things that we do and how they think about what we are is we're basically AWS IAM but for everything.

And you come, we deploy Keycard, you connect us to your existing Okta, you connect us to your existing compute infrastructure. We all of existing computer infrastructures are resolved like secret 0 problems. So when your agent starts up, it can bootstrap an identity based on where it's running means there's no secrets to deploy. And then it can use that identity to authenticate and authorize with us. And then from there you can use that identity that we have. We issue to this agent to then start doing some of the things I talked about like the user delegated workflows and all the other different aspects.

Allie Howe: Amazing. Yeah, that's that approach sounds very similar to some of the LLM guardrails that I looked into for an AI security report that I wrote back in January. Some of them sat really close to the LLM, which sounds like your technology sits really close to the LLM to be effective, which I think is the same thing that I found with LLM guardrails were like people were, you know, the cloud providers were creating them and they would sit pretty far away from the LLM, kind of like at the network level. And then there was other ones that were sitting more like at the kernel level with like eBPF eBPF, or if you have someone anyways, like it just seemed like the closer you're able to sit to the LLM, the more context you have about what the agents actually connected to.

And so you're able to create that context graph which which is how you know like which identities it should be assuming or or not. And which actionability?

Ian Livingstone: Yeah. So I mean the broad scope here and we we've seen this like each generation like on Prem, like the boundary of control was the firewall, right? And then in the move of the cloud, the boundary of control was the VPC. And IAM right in AWS, GCP and Azure, right. And that was like how as a security team or as a developer building things like I control why firewall rules fly the VPC or my subnet groups. And then I had identity and access. IAM systems that helped me manage like roles and machine addressability into like core S3 system, like core systems AWS. The thing that's happening is well over time, what's actually happened is the value of the firewall has really eroded as more things have been come connected the application layer, right?

And so agents are the ultimate app, right? They are literally connected everything at the application layer and it all communicates over the open Internet. And at the end of the day, that means ultimately the value of the firewall continues to decrease, right? Because the transport layer, the network layer, TCPIP, what's going on at the transport layer, Like none of that's like HP, like none of that stuff has enough fidelity and context to make it decision. The only decision what you need is a failure console. What is actually happening in the app? What is this thing trying to access and what downstream resource? And how does and contextually understand like is that thing actually allowed to do that?

And so this is a problem space that can only be solved with the next generation identity aware. And This is why, you know, CyberArk got bought by Palo Alto for 25 billion. And I think this is just the beginning of identity being if it's next wave of growth is that ultimately these are app layer identity challenges. And the only way to solve agent stuff is have it deeply integrated into what the agent is trying to do. So you have to be deeply integrated into the LLM. And this is under more importantly, like the actual like action graph of the agent itself and then have a system that lives outside of it that orchestrates the actual access that thing has, right?

So the boundary of control has to be outside, but you have to contextually understand what the agents trying to do and what the user's intent for that agent was. And that user intent has to travel through the entire system. And user intent also has to be available to the authorization system and also has to be available to the identity system at the same time, unavailable to the upstream resources trying to access, right? Because one of the things you mentioned the beginning is we're under, you know, 20 years ago, the model of the Internet was user straight line to website, right? And that like getting that off the ground was a huge amount of work.

But now it's user to agent and dimensional number of agents to end dimensional number of downstream resources. And we actually, and we need to retain that user intent from the very beginning of what did that user actually ask this beginning, you know, Agent 0 to actually do to understand whether it is forming an action that user intended for it to do or it's a mistake.

Allie Howe: Yeah, that's super interesting. And back in the day, I was a back end developer and I was in charge of integrating Okta and SAML into our, our customers could log in with Okta if they wanted to, but our product also allowed users to log in with Google if they wanted to. So what I created was this issue in our database where we had to sort of decide how we wanted to mark users as unique, given that we were getting different information from Okta, different information from Google. And then we had to sort of come out with like, you know, what's the same or what can we like mark as unique and use to manage these different identities.

We've got all this different information coming in and I just think about what agency and in terms of how many different identities they see. And I think I'm curious to hear if this is one of your hardest problems is you have to solve to create something like Keycard. How do you do a DIF and manage all those identities that come in?

Ian Livingstone: Yeah, our central, our central focus has been, well, what's your one identity for the agent? And then you have N dimension, the one identity for the user ultimately, like that's where the world has moved is like the agent really isn't managing more identities in itself, right? Like that's where we got is like, yes, the agent has an identity. Yes, the user has an identity. And yes, you an agent, a user can, you know, distill some access to an agent. And that is ephemeral in the sense that like they do it through some type of grant process that lives and is embedded to a token that that user can pass to that agent.

That agent can then use and prove that is actually the agent that is allowed to do that. But ultimately, like I think this long-lived world that some vendors are talking about, which is you're going to be managing like endless number of identities. So when they say identities, what they actually mean is like long-lived static API keys. And it's like that world should go away, right? We shouldn't. You should not be managing long lived static credentials anymore. We shouldn't need giant dashboards, when that secret was last rotated. We shouldn't need giant dashboards of who is who's that's what secrets from what vaults like that that world should go away and should be replaced with an identity driven world that uses a highly ephemeral tokens that are identity bound that those that the owner of that identity can prove in fact that they are that identity is a part of using that token.

Allie Howe: Amazing. Yeah, I was wondering too. I've seen a lot of different infra platforms and providers. I know you have an infra themed podcast. It seems like they're trying to sort of offer everything under the sun that someone would need to ship an agent to production, which sounds great. Like on paper where they're going to offer like auth and emails and runtime security guardrails. Like probably not like, you know, the best that a single vendor that's all they focus on is going to, but why would someone a team need Keycard versus like why was why was someone just have like a unique vendor solely for auth like Keycard versus like installing it from like their cloud provider, their infra provider?

Ian Livingstone: It's, it's a super amazing question actually. And you know, I, I actually answer this question all the time. There's a reason that Okta is Okta and you and everyone in the world has Okta inside the enterprise as their source of identity. And in truth, in truth, the landing page for the enterprise usually is Okta, right? Like you open up the the the web browser, you say, well, what are the things they can do? What's, what are the things you can access for the apps that are available to you? And the reason Okta became quite successful is actually became a neutral third party, right? No one vendor could win and you didn't really want anyone vendor.

Like you didn't want a Salesforce to be the source of all identity because then you could never get off of Salesforce, right? You didn't want Microsoft to be the OO forfeit because you never could get off Microsoft. And so a lot of enterprises started buying Okta is a is a thing that sat in the middle that enabled their organization enabled to adopt A lot of these different tools. And ultimately, that's why we've made a big bet on on starting Keycard, right? Is this is a this is a problem that is horizontal and everywhere, but you're starting to require in order to stitch this problem together, which acts as all these downstream things, you're going to need a source or control plane.

You're going to need, you know, the Okta equivalent experience for your agents. And that's what we're here to deliver is that neutral third party, the neutral ground that understands agents through access and gives security like a centralized place where they can go and manage it, and also gives builders a centralized place where they can go understand what their agents can do and then use it to build agents as well.

Allie Howe: Amazing how can our audience and myself cuz I'm interested too like how can we come and try Keycard?

Ian Livingstone: We are in the process of repairing Keycard for launch. If you're interested in being a design partner, please hit us up. You can find Keycard to Keycard dot AI, and later this fall we'll be launching the product for self-serve.

Allie Howe: Amazing, super exciting. Is there anything that you'd like to expand on our touch on before we wrap up?

Ian Livingstone: No, this has been incredible. Allie, You actually understand a lot of agent security problems much deeper than the average bear. And this has been really fun. Thank you so much.

Allie Howe: Awesome. Thank you so much for coming.

Ian Livingstone: You're welcome.

Allie Howe: All right, that's it for this episode of the Insecure Agents podcast with Ian Livingstone from Keycard Labs. He's the CEO there. Thank you so much for your time and we'll see you next time.