Your UI is hiding security holes

Allie: An Instinct agent made 200 API requests per hour and actually got the user's Resy account banned.

Shane: UI does obscure a lot of security issues. Agents will find things that a human probably never would.

Abhi: Now an agent can crawl every API endpoint and try a bunch of different shit out, and then if you don't put tool approvals or if you don't put any approvals on your agent, then you know you got these anonymous hits to your API and now you're screwed.

Shane: Alright, we have Allie Howe here on the show for the first time in probably like six months, it feels like. We, you know, have occasionally done Security Corners where we bring up interesting security topics. Technology is changing. Writing code is changing, building applications is changing, and security is at the forefront of a lot of it.

Abhi: And Allie is the founder of Security Corner for the show. What have you been up to, Allie? It's been a while.

Allie: Yeah, it's been a while. I've been busy. I do a lot of events these days and I still run the Insecure Agents podcast. It's powered by Keycard. I also work for Keycard. I'm a member of technical staff there. We do runtime auth for agents. So I help out with a lot of like DevRel stuff with like workshops and the podcast and lots of events we're doing.

Abhi: How's the Keycard life?

Allie: It's good. I'm super excited about like the problem we're solving. It's really interesting because like once you start talking to the enterprise folks, they have agents that are making delegation hop between multiple different agents, different clouds, different environments. So like if in a large enterprise like if someone's like talking to Claude Code and they're like, oh Claude, like, you know, like what meetings do I have for the day for example, or you're gonna talk to like the Google MCP server or something, and maybe also just like a legacy app that helps like manage like events or something internally. Those two applications could be hosted on two different like clouds or different environments and that legacy system, who knows what that runs on. And so navigating and having a stable agent identity across all of those different delegation hops and being able to enforce policy at every single step is something that like enterprises need to be able to roll out something like a software factory or a highly agentic workflow. And so we have this amazing like all these amazing like model advancements and some people are like, oh my gosh, we have like AGI. Well it's like that's great, but without security, without that like identity layer, it's really hard to harness the potential and the capability and the autonomy that these agents did have so it's been really rewarding to bring that to folks that thought they couldn't have it.

Abhi: Dude without security we're all dead in ten years. So I mean it's like really what we.

Allie: I mean, if you follow the p(doom) narrative, yeah. What are your thoughts on p(doom)? Curious.

Abhi: Yeah, we've got to do that.

Shane: Yeah, we've talked about it on the show. I mean I think we're gonna be okay. You know. I'm not at the labs, I'm not on the you know, I don't see what they see, but it feels like maybe if that's the immediate risk we should just not do that. I think the only ones we really have to worry about are the people with all the compute. As long as they control themselves, we should be all right. I think it's a little overblown. Is my hot take.

Abhi: Yeah, but I think a lot of enterprises are especially we talk to a bunch. There's just three big topics that I'm seeing out in the world right now with regards to security. One is agent identity, which you just mentioned that your, you know, Keycard does. Then there's this whole concept of agent access, like are they accessing as you? Is the is this identity part of your identity? Do they have their own service account? That type of stuff? And then lastly, is there like a vault, like a one, 1Password for agents? And I think with all those three things together, you maybe that's what you need. But you know, no one's agreed yet so far.

Allie: Yeah, there's a lot of situations where you want like sort of the intersection between the two permissions between the agent and the user. And it's really interesting when you start thinking about like intent-based auth. Where like your agent should have a design. We have this like reference architecture called like Agent Baseline. It's got six outcomes teams should work towards and one of the first ones is like discover. It talks about like designing your agent and thinking through like what permissions like what's the goal of like what's the purpose of it and so like if a user has an intent to do something completely different than was the intention of how the agent was designed or what purpose it's trying to solve, then like that even it that agent shouldn't follow that user's intent. So it should be some sort of like a union between the two permission set, which is something that's possible if you're able to give your agent its own identity and not use like the user's identity.

Shane: Yeah. And I think that's where a lot of people are struggling. Right now is should it just be identified as me? It's working on my behalf. It should get my permissions or you know, it should if it makes a wrong decision, it should fall back to me. Or is this agent, and this is becoming more so the case, running relatively autonomously? It's not necessarily tied to any one user on your team. You know, we have a number of agents in our Slack that, you know, I might have built it or Abhi might have built it, but everyone uses it and sometimes it works autonomously when triggers come in. You know, whose permissions should it be using and why? And how do you validate, you know, just like you would with any new, you know, team member I might want to give this, you know, that team member permission, but certain things I would want them to like run by me before they actually did, right? Or before they had access to. So I think there's like the real time, like do you want to allow access and how long? Should it just be right now, give them access to run this one command and then lock it down again and they have to request every time? Or do you want to give them ongoing access to certain resources? So I think there's a lot of things that people are still trying to figure out, especially in the enterprise space where there's a lot of systems, a lot of different permission levels that you have to figure out.

Allie: 100%. And yeah, it's like those two different modes you talked about where it's like is it working on behalf of a user or is it if it's like doing a cron job in the background responding to an asynchronous event, like it should be working as its own identity and itself would have a different set of permissions.

Abhi: I have a good segue into you know, Allie, you have a something you wanted to talk about today. I have a really good segue to that. I was noticing from our homies at WorkOS, our homies at Resend where the UI like most things are going headless and even most initialization of products are your agent is signing up for you, you're redeeming credits, whatever. But I don't know if anyone's really like putting the security in the corner, let's say. Why don't you give us your opinions there and you know, let's take this conversation that way.

Allie: Yeah, it's really cool that like most things seem to be coming headless, but then once things become headless, it seems like chat becomes like the primary interface which I don't know if that's like the best interface for all apps, which is like a whole nother like thing that's up for debate. But when things become headless you're losing the UI being sort of like part of like the security layer and now you're relying on the security of like MCP and agent identity, authorization, policy, provenance and approvals that effectively become like the new interface. So having your agent security posture, I'm thinking that through as like headless replaces some of these legacy applications and front ends becomes like critically important and making sure like the security is in place but also just like from the usability standpoint like people want to use it like I don't know that I'm always gonna want to chat with my agent, for example. So like what does the future look like and how do we make sure that yeah security is in the corner like you mentioned.

Shane: If you think of everything as headless, right? Ultimately you should have had the right security on your APIs the whole time. You should have had all this posture in place. But so often, especially when you're building apps, you just rely on the fact that you know, a user has to click this button to perform this action. And yes, it could be scripted, and yes, you might have some like rate limits, but ultimately UI does obscure a lot of security issues, I think. For most people, 'cause a lot of security is just, you know, a bit of obscurity, right? And I think that's been a lot of people's posture for a long time. But now agents will find things that a human probably never would. Even an attacking human, right? That was trying to do bad actions on your site. So I do think that it's going to push people to think about you have to secure every aspect because you don't know what an agent might try to do. And it's gonna try to do it in ways that a human probably wouldn't unless they were being, you know, a bad actor. And oftentimes these agents are just trying to accomplish a task. They're not trying to be a bad actor. They just see that, oh, this API is available. I if it's a browser agent, I can actually just hit this API directly and get what I want done. So I'm gonna do that rather than go click this button. And so I think you have to think about things from a different perspective and you have to bake security in a bit more than you even not that you shouldn't have before, but I think people could get away with not doing it as much. And now it's harder. It's gonna be harder for people to do that.

Abhi: Well dude, people publish OpenAPI specs now because they want agents to read it to then access their API. But before you would probably not release those types of things because your surface area was just your app using it. Or the end user. Maybe you had a CLI or whatever. But like now an agent can then crawl every API endpoint and try a bunch of different shit out and then see what happens. You know, like it's not out of the threat vector has now increased. And then if you don't put tool approvals or if you don't put any approvals on your agent, then you know, you have these anonymous hits to your API and you're now you're screwed.

Allie: Yes, because it's like when you open everything up to be headless versus having a UI. And in the past, like you assumed the people that were accessing your UI were humans, but now the people that are accessing the APIs are the agents and the humans. So what does that like look like in terms of like the permissions, the rate limiting? I know we just had like the Resy incident recently where an Instinct agent made 200 API requests per hour and actually got the user's Resy account banned. So how do we make sure our APIs are prepared for that. We might not have to jump down that before. But also how do we make sure that agents are gonna be good, thoughtful consumers of those downstream APIs? And like there's a whole other problem here of like, oh the web just wasn't made for agents so those issues would have to get fixed as well.

Shane: I mean this kind of brings up the question, are websites and people who are building apps and APIs, are they gonna have to enforce way more strict limits as far as just rate limits to prevent these you know, and a human's probably not gonna do that. Of course you could script it, but that's kinda hard to do. But now imagine every human on the planet could write any script to do this to any website. It could it can script it itself and so I'm thinking like at minimum, like everyone's gonna have to have strict rate limits on their APIs. Where before that maybe wasn't a problem or as much of a problem.

Abhi: Dude, websites are even at risk. If you expose WebMCP, right, on your website and it's actually a prompt injection. So now like your agent isn't trying to do something benign. It's crawling web pages and then activates WebMCP. And then you start screwing around. Like that's another threat vector that has been opened up as well. So even websites, not just APIs anymore, it could be like the MCP server that's exposed or the Web MCP that's exposed on the website which I think honestly doesn't it all come back down to permissions and actions and stuff?

Allie: A hundred percent, yes, it does. And thinking through what permissions each agent or user should have and then potentially having like an escalation like pattern where you said like having that approval in place like maybe you should have like more permissions or at least like we should know who the caller is so we can assign a certain like subset of permissions to them.

Abhi: But then that also makes me think like when you have no if you're only headless product, let's say, and you do need to do an approval, where does that approval go? Is that like an email or a text message? Is that a MFA like Google auth authenticator thing like you kinda like cut out the UI that was supposed to grant these things. I'm curious how people do it or will do it in the future.

Allie: Yeah it's a good point. And it's like also with approvals. I guess a set few is okay, but of course you get that consent fatigue as a human pretty quickly. So how do we use security such that like we're not relying on the approvals in the loop to be like our primary like source of security. I think like part of that too is having the right evals and like audit log in place as well where you're able to see over time like exactly like what actions an agent took. So if you're going to do an investigation and see like maybe, you know, I want to tweak my policies or make changes, maybe it's super permissive, maybe it's not like productive enough, like you can actually do that and start to understand like some of these use cases as you gradually like work up that like autonomy curve, you might not you know wanna open everything up like right away. So.

Abhi: Maybe the suggestion is to not do things through APIs.

Allie: True. So like MCP would be better.

Shane: I want to go back to kind of something you said at the beginning though is you know, I feel like if you move to MCP then you're moving to okay what's the interface to access it? Is it just a chat window is that a shitty UI or is that the right UI? How do you think because UI is still important for humans to understand. I need to understand what my agent is doing. What is the best way to actually understand that? Is that some kind of MCP app? Is that some kind of generative UI system? Where it can generate the the application I'm using can generate the UI as my agent is interacting with it. I know this is not necessarily 100% security, but it is security adjacent. What is that going to look like? In your opinion?

Allie: Yeah, the MCP apps one is kinda interesting, but that's just like one part of like the ecosystem like you might you know, an MCP app might be good, but I also have seen people like on Twitter online be like, oh I'm just gonna render like HTML dynamically wherever my users are and like generate the UI like on the fly. And I think we're just also in this age of like customizable software that everyone's like really excited about so having your UI be unique to you or somehow like serving the user in that way, I think that's where it could be going. And I think like letting people have that customization, letting them be able to do what they want goes back to that permissions problem as well. As long as you trust the person's like or the agent's level of access. And you also are able to like authorize it just in time. You're also able to have like a tamper-proof audit log that's outside of the agent's hands. We saw like in the Hugging Face incident, they tampered with their transcripts of their chain of thought. And when you have all of that in place, it gets you more prepared to be able to go and experiment with whatever the right UI is, whatever the right consumption pattern is. You're able to trust that because those security foundations are in place you're ready for whatever that future looks like. And I don't know what it looks like, but I'm really interested to see where this like where this heads.

Abhi: I think the benefit of using abstraction like MCP is like there's observability baked in. And then you can add more primitives on top because it is like a standard for agents, as opposed to a REST API existed before agents and now it's existed after agents. So then like like the quality of or the standards of that API surface area is not necessarily all agentified or not, which could be such a good use case for just putting everything through MCP because that will evolve with agent standards as opposed to like open API specs have existed for 20 years and we'll see if they will change and people will have to change but like when you do an MCP, you are making a like an action towards an agent future. I think that's probably the move.

Allie: Yes, I agree with that. And MCP also creates like a policy enforcement point if you're using a gateway, for example. Between you and the MCP be able and that helps you like filter down like the tools that are allowed and also be able to see exactly like what traffic's coming in and out.

Shane: Yeah, absolutely. I think some of the recent additions to the spec make it more palatable for everyone. You know, everyone for everyone that has an API should probably have an MCP if they want agents to interact. I think before when it had to be stateful or felt like it had to be more stateful. It kinda turned some people off, but it it feels like today everything's going to be I think agents probably drive more traffic than users to most sites and apps now. Or it very likely will if they aren't already. So having a more well-defined MCP if you have an API seems like the right decision to make.

Allie: Yes. And we also have ID-JAG, which is a new protocol that enables cross-app access, which is what Enterprise Managed Auth by Claude provides. And essentially allows you to log into an MCP server once and then you've got access to all of the other ones you're supposed to log into. So you don't have to like log into every single one. So it creates a better user experience, but also lets your IT and governance people at your company be able to revoke your access like all at once to everything versus like before you used to have these like OAuth islands where you'd have like an OAuth token for every single service you would be authing into and then your IT governance folks would have absolutely no visibility or ability to revoke. And so if those were stolen, that would create a whole like bunch of problems and incidents there. So yeah, ID-JAG is a huge improvement for MCP, just like for security and for usability.

Shane: Yeah, how do folks learn about ID-JAG? I'm asking for a friend. You know?

Allie: Yeah, I'm surprised it didn't get more coverage. There's like a podcast I did over the summer with Karl McGuinness, who's an identity expert, used to be like chief identity principal or something like that at Okta. But he's had an amazing, super long, impressive identity career He helped author ID-JAG. So if you go to insecureagents.com, there if you scroll down long enough, you'll find one with Karl McGuinness. And we did a podcast on that. But you can also Google Enterprise Managed Auth Claude and you can see that there and learn more about how it gets applied. But yeah, it's episode 41 of Insecure Agents.

Shane: Oh yeah. I've also seen other types of MCP solutions, like MCP governance solutions. I think it's not finished. There's a lot of innovation that's gonna happen here. There's gonna be some winners. And I think that's an important thing for enterprises is to try to figure out how do they manage all these different connections that they're not that their humans are just gonna access, but their agents are gonna access as well. All right, Allie, we appreciate you coming on and doing Security Corner for the first time in a while. We'll definitely have you back on when there's more, yeah, secur there's always gonna be security things to talk about. How do people follow you, Allie? What's the best way?

Allie: I am on Twitter and my handle is @vtahowe. Well, yeah, @vtahowe, and then insecureagents.com is the podcast. That's a great way to follow. And then if you're looking for our events, luma.com/keycard, find all the events I help out with. But yes, that's the handle. So that's probably the best way. You'll see everything there.

Shane: Yeah. So follow Allie on X, Twitter. Whatever we call it these days. And yeah, we'll see you next time, Allie. Thanks for coming on the show.

Allie: Awesome. Thank you very much. Bye.

Shane: Like, share, and subscribe. And follow us on X.

Abhi: And tell your friends.

Shane: And their friends.

Abhi: I mean, we're not begging.

Shane: Well, maybe a little bit. Subscribe to Agents Hour.

Abhi: Every Monday, noon Pacific.