Reducing Attack Surface & Evaluating Efficiency in Agents - Itamar Apelblat, David Goldschlag - ASW #389

Speaker A: Hello, packages, parsers and programs. An org once let their coding agents run loose and wanted more features for them to produce. They said with a thrill we'll download a skill. And now they are fighting supply chain abuse. And so this week we covered the latest AppSec news with Tyler Shields and run some interviews from Identiverse. Mark up your markdown and stay tuned for Application Security Weekly. It's the show to learn the latest tools and techniques to understand DevOps applications and the cloud, your trusted source. For the latest AppSec news, it's time for Application Security Weekly. This is episode 389, recorded June 29, 2026. I'm your host, Mike Shima and as predicted, I'm here with Tyler Shields. Hey, Tyler.

Speaker B: Hey, Mike. Always a pleasure. Thanks for having me on.

Speaker A: Today we've got some fun news to go through, but first we have an announcement. Tyler and AppSec teams, your backlog is growing faster than you can fix it. Tools are flooding you with findings. Developers are pushing back and prioritizing. What matters in code is getting harder, basically all we talk about on this show. So how do you reduce risk without slowing releases? Join the Vulnerability Management Virtual Cybersecurity Summit to learn how teams are dealing with tongue twisters as well as prevention, prioritizing real exploitable issues, reducing noise and integrating remediation into modern development workflows. Security Weekly listeners can register for free@securityweekly.com vulnmanagement with the code CSS26SW. So hopefully during that, um, bit of preamble, you've signed up for the summit there, Tyler.

Speaker B: I 100%. Did I click the button as soon as you said it?

Speaker C: That's good.

Speaker A: Well, it's time to click some other buttons that open up some news articles. And I have once again a mix. And I'm going to preface my thinking with these. We have a vuln but then we have decidedly, uh, some non volume, some more of thinking or how to, how to. What is the practice of AppSec? Um, types of news articles. And so with that in mind, let's start with the easy one, the vuln. This is from caliph.IO. uh, we've covered a couple of these, I think about once a month at least. Basically the team over there is having fun with their LLMs to find volumes. This one is squid Bleed. Um, as they say in their their subtitle, Heartbleed's ancient cousin hiding in squids since 1997. And yes indeed it is always, especially for me, I always love finding or the scene, I should say the discovery of these vulns that have lasted decades through code refactoring, through human eyes, through SAS, through DAST, through fuzzers, through compiler options, etc. Here is a vulnerability that survived all that time and was found through some humans with a lot of help from LLMs. And I'm going to kind of, I'm going to jump over the technical parts because there's a more interesting aspect to this. I think, uh, the technical part, roughly speaking, is that SQUID proxy, which I think we've all used in the past, or we've probably come across through a captive portal on an airplane or in a hotel or something like that with the browser, we're probably using it with HTTP or HTTPs. What this vuln founds is FTP. And the way FTP, because it's an ancient protocol, doesn't have a standardized format for reading listings of file structures. It has some homegrown parsing or some unpredictable parsing or other types of alliteration I can't think of at the moment. But basically skuid supports FTP. You can basically omit the, what is it? Omit the file name in a directory listing of an FTP and that omission leads to reading off some nulls and going past some nulls and going to the end of a string. And this is C based code and I think we can all see what's going on there. So that's my long winded way of setting this up. And I have some more interesting things that I think this is a broader lesson to teach us regardless of whether you have FTP or squid. But before I get on to what I thought was interesting, let me stop talking and throw it over to Tyler. Was there something in particular that stood out for you on this one?

Speaker B: Yeah, what I was trying to figure out was what was going to be interesting for you, Mike, to be honest with you, when I read this, because I've read through it in detail and I saw the double null, um, the stir n copy, uh, volume. It's a very typical heap overflow, um, or overread. Not overflow, but overread with double nulls when you leave, um, a particular chunk of the data out. And so I was like, I don't know where Mike is going to push this one for nuance and uniqueness because it felt kind of straightforward and standard. Uh, I do like. And I did find it interesting that it was FTP related. Right. Which is a bit of a dying or even dead art. Right. Um, so I think there's some interesting Things that we could talk about maybe replacing FTP altogether getting rid of that at a broader level from a design theory vantage point. But the exploit itself was fairly rudimentary yet somehow survived since it was introduced in 1997 which is wild to me. We're seeing that consistently every time I get happen to be on this show on a Monday we've got something dating back to 1990, something that was uh, you know that DJB is involved. Right. Um, so you know there's always seems to be something of this scale.

Speaker D: That's right.

Speaker A: ASW still trying to make fetch happen. But you. The. The FTP was the. It's not this FTP itself or this was just a STR care misuse and a um, you know, read past the null. It's specifically what you said that. How did you phrase that? Dying protocol. Let's just say dead protocol of FTP. And even the write up says near the end, you know the chromium. All the chromium based browsers removed support for FTP a while ago. So A while ago meaning several years ago. So even if you have, if you're using SQUID for browser capture you didn't even need FTP support because browsers aren't even going to use that. And that's why I wanted to set up in that aspect of getting rid of code is a wonderful way to reduce attack surface because your users likely aren't using FTP. And the other thing that SQUID could do even if they didn't want to get rid of the code because there will be those edge cases or those poor who knows what those orgs out there uh, are but still need FTP for some reason don't turn it on by default because it is such an uncommon unused protocol by now that it's just either getting rid of the code, getting rid of disabling by default will be two ways of just reducing that attack surface. And I think that is the part that I'm pretty sure any enterprise out there has some services or is consuming some services or even some third party code where they could say you know what, what if we just disable all the parts we're not using or what if we actually did just delete this code because we're not using it. But I don't know how that's how to sell that story very well.

Speaker B: Yeah, you know it's super interesting you bring that up because. And you may have already in your uh, preparation for today's show made the connective tissue between this and a second story with str and copy. Right. Um, which we will get to. I'll kind of punt that off a little bit. But suffice it to say that if, you know, we're looking to get rid of that, if we're looking to get rid of something like string and copy in general, and we can even supersede that by just either default turning something off or not even having that call happen. Like, let's just limit ATT and ck, right? Limit, um, the capability in a general sense. I think that's, it's an interesting way of saying we can bury a lot of vulnerabilities and hide them in the sense of just not making them accessible anymore. And it doesn't solve the problem. Right. The vuln still. If a tree falls in the wood and nobody there to hear it kind of problem, does it cease to exist? No, it's still found in the woods and there's still vulnerability that exists. It just becomes unexploitable. Right. So, you know, finding ways to limit, uh, threat landscape should be a default preparation in how we do these things. But as you'll get to with the other article, it can take many, many years and years of effort to politically get something removed or default turned off, depending on the size of the project. So, um, you know, it's not as easy as just turn it off because of all the politics that comes in in with it.

Speaker A: Generative AI is powerful, but it comes with real risks. From prompt injection to data leakage, misuse and agentic AI. The OWASP Gen AI Security project unites a global community of expert practitioners who tackle these challenges every day. Together they've built practical playbooks, adoption guides, and the OWASP top 10 for LLMs resources any team can apply right now to strengthen AI security. And it doesn't stop there. This is open source, built by practitioners. For practitioners working together to secure generative AI. Visit securityweekly.com OWASP to use the playbooks and join the effort to protect tomorrow's intelligence today. Yeah, and it definitely requires a lot of discipline too. And this is one of the weeks that I didn't pull in one of the blog posts from Daniel, uh, Stemberg over at Curl you. Even though I notoriously do like a lot of these Caliph IO but the reason I bring that up is to echo what you're saying in the sense of it takes a lot of discipline to say we're not going to use these functions anymore that are known bad or that are easily misused. But it takes time to have the discipline, uh, to commit to that and to stick with that as well as to migrate off. And that's I think the same story with it's uh, similar discipline just to say nobody's touched this code in a long time, nobody's really using this code. So maybe we're too, we don't have enough test cases or feedback loops from our customers to know exactly how many of them are still using it. But if we turn it off by default, maybe that's at least a way to get some of that noise and discover.

Speaker B: Yeah, I think it also makes a very interesting argument for instrumentation, uh, especially in situations where like ah, an application or a section of code is used, um, in like a SaaS model where you have kind of like a centralized approach, right? And you can say, hey, we've instrumented all these functions and we can see which functions are used and which functions are not used and we can demand or dictate, hey, this is a piece of dead code. And you know, it may be called, it may be callable, but it isn't being used in production. Right. So let's, let's figure out a way to, even if there are zero vulnerabilities in it, limit our threat landscape for vulnerabilities popping up in different sections at a later time. So you know, it's easier in a, in a sassy, you know, approach and a SaaS model to do the instrumentation. But you know, when we talk about the second, second story here, um, you know, we can instrument that in the kernel layer for the second story and say, hey, this hasn't been called in 10 years. Kill the code, stop it. You know, and so I think it's, it's a similar story here in the sense of, look, you know, 90% of our people, if we can instrument it somehow and determine that 90% of the users do not use FTP, that's enough of an argument to at least place it in a default off state. As you were, as you were bringing it.

Speaker A: Yeah, and let's pull in that other article that you're alluding to. This is from uh, Pharonix.com, linux finally eliminates the STRN copy API after six years of work and 362 patches. And as you said, they got rid of this one C function. So we've got the surprising nature of the STR care function in the SQUID bleed example. And here is STRN copy, which is the N is the, what supposedly more secure version of STR copy because you can at least put in how many bytes you're copying. But there's obviously if you miscalculate those bytes, things can go wrong. One of the other things that this points out is that there's also a performance benefit here because in this case the STRN copy was the Linux kernel was always zero filling the destination. Which the zero fill has some security uh, benefits to it as well in terms of if you do uh, you're under filling the buffer or again you're, if you're miscounting for an undercount of what you're trying to fill with that copy. What was really cool here is more of like what you're pointing out. It's a six year journey to do this. Um, and of those 362 commits over the years, one contributor however did about 200 of them. So two thirds of those commits were one contributor and then there were only 1, 2, 3, 4 others that were in the 10 to 20 commits. And then this massively long tail of just one commit here and there by other contributors. So it's a long amount of time, but it's not necessarily a huge amount of people that it's getting into. And the reason I bring that up is just that idea of how do we sell this politically? How do you say this is what we want to do, this is the effort it's going to take. And that effort is a lot of time and people. Um, so those aspects just, I guess I'm not necessarily sure. Help me out with maybe where to go from this. I've talked myself into a corner, but

Speaker B: yeah, no, it's, you know, like I said, you know, replacing the, replacing a vulnerable function with a less vulnerable function if uh, you know, the outcome of operation is identical is a logical step. Right. The real question is why did it take six years?

Speaker C: Right.

Speaker B: And you mentioned, you know, that the bulk of the patches came from one person. I did not do that research to get to where you're at with that conversation. And my immediate question is, is the bulk of discovery also one person, which is likely a researcher who was like, you know, I know STR N copy is garbage, therefore I'm going to literally look for every STR N copy and just beat the hell out of it for six years. And because I like finding zero days and I like getting the buzz from it. Right. Or whatever, whatever his or her potential output was. Right, Yep.

Speaker A: So that's a good question because it's not. I think finding all these examples is pretty much just, let's grep for SDR and copy. Okay, done. The Discovery is pretty easy. I think what m took the longest amount of time and honestly where the smart software engineering comes in is they didn't just say here's the, here's the old version of STRN copy, here's the new version, you know, just a one to one swap. What they did was go through and figure out how are these being used and how, and how was the API. What, what is a better API or basically what is a better function call for this particular use case. And that's why the replacement as I mentioned, isn't one to one. It has, let's see, 1, 2, 3, 4, 5, 6. About six or seven replacements that are basically, here's a normal copy when you just need the destination be null terminated. Here is it 0 padded and null terminated. Here is some other, here are some other situations that don't need the null termination and, or don't need null termination, but do need zero padding. And that to me is pretty cool to see because I think it is going through and realizing, ah, uh, this is what the developer originally needed and they just had to push that to be a little bit cliche, push that square peg into the round hole of SDRN copy into their use case. But now with 362 commits later, there are some better versions of that function that fit that use case, both for security, but probably more importantly for, for semantics and understanding and performance. And I think that's a better story for developers.

Speaker B: Yeah, I wonder if these six whatever it was alternatives, um, existed before STR and copy. Probably not. Meaning, um, before the stern copy calls were introduced to the kernel. Right, because obviously stir and copy was one of the early, early functions. Right? But when they were introduced into the kernel, were there the better options that existed and was it a developer error to stick with steering copy? Right. In which case that opens up a bit of a different problem or a bit of a different discussion because now we're talking about code review and best practices in the development side. My gut tells me that the bulk of these existed prior to the alternatives existing. Right. And we're retrofitting essentially foundational patches into play. Um, and then going forward we just ban the bad function. Right? This function should never exist because there's superseding better versions of it that have nuance and intention amongst six different alternatives. Um, it's kind of a cool story that uh, you know, I mean, I guess nobody really, I shouldn't say nobody really codes in C anymore because people still code in C obviously. But um, you know, is it even A problem that we should worry about going forward. Just trying to ban strang copy as a broad recommendation in all of C given given the superseding versions of functions that exist.

Speaker C: Yeah, and I think there, I didn't

Speaker A: think of that aspect in terms of just the C based code. I think it's still a really good question. Or say if you're writing the C, do you start banning or saying here, here is our coding style and we ban these functions. We prefer these functions. I would also, in the spirit of generalizing and saying, even if you aren't writing in C, I'm pretty sure there are some functions in your language of choice that are easily misused or that you would prefer users to avoid or not use. And those could be around parsing JOTs. For example, here's your JWT, here's handling an oauth, uh, flow and a different type of authentication flow. Some of those business logic types of areas that aren't so specific to memory handling. And I wanted to be very clear about that because as you said, it gets sort of that idea of what is our code review stance, what is our are linting for that matter on just these are the functions we want to see, these are the patterns we would like to see and if we don't, then we want to go either talk to the human developer or update that. You know that LLM skill that is ah, that agent that's writing that code.

Speaker B: Yeah, I was going to say like the output is likely highly discoverable by LLMs when we start to really put in stricter rules there. Right. We just won't use it. And if we are, it needs to. If you're going to do, you need to do that type of capability. Here's your six options based on the nuance of each option. An LLM should be smart enough to at least make a recommendation there and code it properly if they're taught to. Right. Which presumably some of the more modern frontier models are taught to. Fingers crossed. We're not sure. Um, but yeah, hopefully we can maybe see the uh, elimination of stirring copy and SEO going forward and the equivalent of classes of issues. Right, classes of issues.

Speaker A: Cross language pull out. Thank you.

Speaker B: Yeah.

Speaker A: So in the spirit of that we're almost. This conversation is almost like we're imagining what if there was some sort of security verification standard for writing code like uh, an OWASP application security verification standard or for this week a relatively new AI Artificial Intelligence security verification standard. And this is once again from owasp and it is very explicitly and Deliberately modeled on the original ASVs. As an aside, we covered the secure, uh, pipeline, the SP SVs, a couple weeks ago. So there's a lot of these security verification standards coming out of owasp. What's funny to me is that on uh, the one hand, very superficially, I just have to get this off my chest for living in an era where AppSec is talking about don't be the department of no, let's get away from checklist security. We still have top 10 lists and the ASVs, I mean in all practical purposes is still a checklist. Not necessarily a bad checklist though. That doesn't have to be a pejorative, but it is a checklist nonetheless. The first question I want to throw over to you, Tyler, and I think this is here, here's a seed for our conversation is why AI SVs rather than application, you know, is there. What did you see something in here that feels like, oh, this really should be a new SVS first dedicated to AI. Or we could have just had one original one for applications that covers everything.

Speaker B: No, I definitely. So I struggled with this article because I'm very practical and grounded in output and fixing things as opposed to kind of this pie in the sky, thou shell and thou should and nobody does it because everybody ignores it unless it's practically applied. Right? And so that, that's my struggle with this and all of the comparatives of, of similar things you brought up. Right. Is like, yeah, great, thou shalt never park in a bad parking spot for fear of getting your car keyed. Yet it's 10 yards closer. Therefore I have to. Right, like, you know, what people do and what people should do are miles apart until it's automated. And so that's where I think rubber, uh, needs to hit the road. Now to directly answer your question of whether this should have been created, um, or whether we could have just used foundational other ones and said, hey, just apply it to the model. I definitely think it has to be created. There is enough nuance in the delta between traditional code generation and non deterministic AI driven code. Right. And again, I'm going to go right into the next article without going fully into the next article, uh, the definitions article, which you'll get to, uh, soon. I've been living and breathing AI since it came out and I loved the article we're about to go into after this one because it really breaks down the nuance of every single, um, technology term within AI. And why that's important to this article is that most people, if you have to break down to the foundational terms. Then the application of the traditional models isn't going to make sense. Right. If people don't even understand the high level terms. So I think it's very important to have this and at the same time I look at it and go it's not going to have any impact whatsoever. So that's my kind of contrarian problem with it. I think it's mandatory. I'm glad we wrote it. I love it. I think it's really useful and powerful. I don't think it actually gets applied anywhere.

Speaker A: Yeah, and I think uh, my reaction is similar and I definitely want to preface this. This is not an intention to say compliance is not equal security because I think that's just too dismissive and that misunderstands both compliance and security for me. What's missing here echoes a bit of what you said in the sense of okay, we have a, basically we have a checklist that has been modified to be specific and contextual to be a little bit of a pun with LLMs and agents. But I would love to see, here's the linter that enforces that or here is how it is enforced at the CICD layer or something with a git commit hook, something like that rather than just hey, by the way, whether you are a human or a code review agent, remember to think about this and think about this and think about this. Because those just feel as reminders that they're not getting us anywhere. They haven't gotten us out of 20 years of cross site scripting. I don't think they'll get us out of another 20 years of AI mistakes.

Speaker B: And the extra hard part about this particular one is the breadth of what they cover. Right. So you're, I mean it covers from hardware security all the way up through um, you know, infrastructure layer, supply chain orchestration, agentic modeling, mcp. It is so freaking broad that I just don't see the application of it being used in a grounded way very often. Now you know where it would be amazing is certifications, education, training and learning like very powerful people for people to read this, learn it, um, maybe have training modules around it so they can understand the impacts of it. I find significant value from it, but not in a hey, we've decreased risk directly kind of way.

Speaker A: Yeah, and that's where the breadth is. Another comment I did want to make on this because if we look at some of diving into some of the requirement chapters of it, there are a dozen. So hey, good number. We've gone beyond 10, but uh, C7. So this is model behavior, output control and safety assurance. And just quote briefly, that's about constraining, validating and monitoring model outputs so that unsafe malformed or high risk responses cannot reach users or downstream systems. The reason I pulled that out is that I suspect that safety is an analysis that is going to figure out who's responsible for that. Is that an AppSec team? Because this isn't very m. This is not like a regex that's going to help you. There's. This isn't necessarily a very specific deterministic output that you can specifically test for. Uh, reliably it needs to be testable. But there's definitely some trust and safety team in the org that might be responsible there. There is the developers of course themselves or just understanding what model you're using. So I'm highlighting that in that sense of it's much more than an AppSec problem here, which I don't think is a bad thing to call out. And it's important to have this to be considered. But by the same token I think that uh, it's testing this and reviewing this is a much more in depth effort than two or three checklists.

Speaker B: Yeah, Output safety is an interesting one. Right. So the way this model is created is they have three different levels. Right. And the level two and level three is a little bit more grounded. Verify that output filters detect and block responses that disclose system prompts. Um, you know, prevent from triggering outbound requests. Like those are pretty like um, a little bit more deterministic and syntactical from a detection vantage point. But level one, verify the automated classifier. Scan every response and block content that matches defined harmful content categories. What does that even mean? What's harmful to me may not be harmful to Mike and may not be harmful to someone else. And so you start to get into a lot of gray areas and that's where some of the safety concerns. And that's why again I struggle with the grounding of these. I love them, I think they should always be created, they help people learn and get better. But each one of these needs to be assessed and grounded individually the best way that they can be. And that's a massive, massive undertaking.

Speaker A: Yeah. And especially if we're talking about any type of moderation aspects in terms of that safety, doing moderation at scale is easily going to run into trade offs, challenges, competing requirements that honestly cannot be resolved. You're going to be continuously trading off. Well in this situation we'll do this. This other situation we won't and that's much more than you can write into code. There's some policy discussion that has to be part of this. Uh, but in the interest of time because you love peeking ahead and so let's make sure to keep Tyler happy. There's another article here that I think

Speaker C: was getting your attention to.

Speaker A: This is from Security Research Labs titled Beyond Fable. Can a local LLM replace cloud AI with for security code reviews? And this is the type of article that falls into two categories. On the one category there's so many of these LLM type of articles that are admittedly marketing that I fall for. We covered the Caliph IO1 covered a bunch of others. Uh, I'll admit that up front. But the other aspect is how do we know how helpful, how useful models are and which models are are more helpful than not and how much, how much should we be spending on tokens? Either one of these so called frontier models, which is just another word for very expensive or a local model. So I appreciate this article for giving additional view of some data on this and what it's highlighting are probably two important things. One is that right at the top I appreciate this. The quote finding count parity is not capability parody. So if we're just playing a numbers game, how many volumes, how many CVEs, that feels like a losing game anyway within AppSec regardless of whether we're using LLMs M. But the other part is that it digs into that we could talk about perhaps a bit more as well is just using this. You know, Claude is good, as they say, architectural reasoning, whereas Quinn 36 had a very good breadth of coverage and very good calibrating the severity of the findings that it was, it was producing. So it's interesting to see that there's no, well how am I trying to say this? There's no easy benchmarking that says this one good, this one bad.

Speaker B: Yeah, it can't be simplified that easily. Right. Because it's not like it's, you know, you put one thing into the engine and its consistent engine across the board because harnesses are different, prompts are different, you know, overall workflows are different. Um, now that all being said, I personally am of the belief in my reading and research lately that um, that some of the open weight models are really going to or are already on par with the frontier models or close to the frontier models maybe one level back in pretty much everything they're doing right. And if you look at it that way then where does the nuance and the difference come in beyond that. Right. It comes into, and we've seen this with previous uh, previous articles that we've discussed on the show before where if you harness it right and you use contextual um, focusing and prompting techniques that keep things focused to what you're specifically in need of and kind of do like more micro prompting that are orchestrated together and harnessed together, you can increase your efficacy using much cheaper and um, less good or not as accurate models. Right. And that just tells you that if we think that and believe that the open weight models will or are close to par with some of the frontier models and we also have shown um, with experiments and with data that harness and prompt matters as much as the model. I don't see a world in which we continue to spew to the fables of the world and just throw away tokens for throwing away the case of tokens. We're going to solve the problem in efficient way way at some point.

Speaker A: Ah, thank uh, you for saying efficiency. That's. I mean that's the world of SREs. That's world of. Honestly, I think a lot of software engineering is about business and business it's

Speaker B: also right a business is all about being efficient in how you spend and return value. And all of this is as cool as we're talking here. From the, the bits and bytes in the tech, it's all in support of a business of some point. Whether it's the business of finding Vs, the business of reducing risk, uh, the business of just creating an AI something or other. Right? Efficiency is what matters.

Speaker A: AI is accelerating how software gets built and how it gets attacked. Most teams still rely on periodic pen tests which leaves gaps in coverage and means. Findings remain theoretical rather than proven. Expo is an autonomous penetration testing platform that mirrors real world attacks attacks and proves which vulnerabilities are actually exploitable. Tests run in hours to quickly produce clear evidence your team can reproduce and fix. Go to securityweekly.com expo to see how it works. And part of that I'll build too. Near the end of this article there's a quote. Each model found vulnerabilities the others missed entirely. And one of my questions, somewhat rhetorically, is why? Why was that? And uh, I'll just offer up briefly. They mentioned too when they were running the local tools and the local, the local models, for example, they were also running those models with access to things like semgrep, Breakman checking out that Ruby NPM audit, you know, they were running these old SAS tools or similar types of security tools that have been around for a long time. So it's very interesting to see is that LLM, as I think to reinforce what you're saying, is the LLM on its own? Is it an LLM plus a fuzzer plus security tools, or do we just have to run this LLM 3 times and 1 time out of 3 it finds the vuln 3 times out of 10 spend more tokens to make sure you found that vuln. So spend more.

Speaker B: Tom. I definitely don't believe in the latter of that. I don't believe in the token maxing approach there of just run everything and find everything. I think it's more about the combination of focusing the laser beam of what you're looking for where determinism is needed, use determinism, where non determinism is appropriate and provides the broadest value, use that as well. Um, and I just think that over time we're going to find efficiencies. I think we're going to find that the models approach commoditization faster than we ever thought they would. Uh, probably in the next 18 months. Right, where we're just not going to see leaps in frontier model expertise. Um, I could be wrong on that, but who knows, right? So I think you're just going to see it continue to get more and more efficient over time and we're going to design the approach to use it where it's best to use it.

Speaker A: And yeah, I think the struggle is going to continuously be how are we measuring the best to use it? Uh, because that if there's with the compiler in our C code, just to go back to that very briefly, we could look at, oh, this is either the size of the machine code that's been generated or uh, this is the number of CPU cycles now that it's burning to execute this particular function. As the human readable code gets compiled down into what the CPU executes with LLMs, it's sort of, ah, well, this is how I prompt engineered this and I put this in all capitals and that helped better. And here I said please, but this over here I didn't say please. And here I said you're a senior security code reviewer. And here I said you're an expert security code reviewer. And who knows if any of those make any difference. So that's me soapboxing briefly. But uh, there's two quick things I wanted to get as we're coming to the end of our time together here, Tyler. One is just a quick reference to thingst. They've been around forever with tokens that have Basically their, uh, deception is the name of their game. I've loved things for quite a while. They, they have a great resume of research as well. And mostly I just wanted to point out that they now have tokens for MCP servers. So I think that just legitimizes that uh, MCP servers are definitely part of expected, part of enterprises. That deception is one of those new ways to figure out is it being abused or who is abusing.

Speaker E: Yes.

Speaker B: And I think this is going to become more and more, uh, imperative and important to put into play. Um, especially because I was just reading an article today about pricing pages for many products and companies are starting to include AI agent pricing. And there's. So there's a link that literally says if you're an agent, click here for pricing and it presents it to them in a, in a, in a model that or a way that's consumable easily by an agent to then make their decision about where they want to execute something. Right. And why does that equate to this MCP thing? Because we're just going to see more and more MCPs and automated agentic approaches to execution on the back of again, efficiency, where the agent's going to go, hey, this one's cheapest and this one's most secure. Oh, look, this one has uh, an mcp. Let me get in there and test and see if it works. You're just going to see the MCP become the de facto communications pattern because of the agentic approach. Um, and this is just a really interesting way of detecting unauthorized activity around mcp.

Speaker A: Yeah, I think next week we'll have to chat more about, uh, MCP versus skills. Just where is the developer mindset going? Uh, as well as there's a new version of MCP that's coming out that is bringing I think some more enterprise, uh, level of security and design around it rather than the very early version that we all saw and love. But before we go, Tyler, I think you've been chomping at the bit to be able to chat about this one last article I grabbed from hugging face. And honestly it's more of just kind of a, in my FYI category, sort of the, A reference for listeners. It's the harness scaffold and the AI agent terms worth getting right. And it's literally just uh, a short list of common terms within this domain.

Speaker C: And I don't have much to add

Speaker A: for it other than to ask you what was your favorite term here that you would pull off the list?

Speaker B: Yeah, so I've been Obviously neck deep in AI, specifically around building agents and agentic approaches. The whole time AI has been growing and I learned something from this article. Right. And when I can say that, that's when I go, hey, I think everybody should read it. I don't care how long you've been using AI, you 100% should at least give this a skim. Are people hugging face in this particular case actually defining things the same way that I use them? And where can I get more specific in my terminology? Um, one thing that jumped out to me was the skill versus MCP discussion, which I think is worthy of a blog post to help the nuance of people kind of interchanging that a little bit. Um, and then the other thing is harness versus scaffolding. Right? What's the difference between harness and the scaffolding? And I found the nuance of that in this article to be very, very useful for me personally.

Speaker A: Yeah, uh, plus one for that. It was the harness versus scaffold nuance in the way. They've also got a nice uh, image, uh, in there, a diagram. That's the word I'm looking for. So it's worth reading. Pictures, speak a thousand words. I think that's probably a good one or two thousand words right there. Just some, some helpful nuances and it's helpful to have definitions like this. They don't have to be extremely pedantic or super accurate, but it helps with how are we talking about this area. Much like the OAS top 10, to give it some credit helped us talk about. This is cross site scripting and this is what we means with, with xss, with csrf, with open redirects, things like that. So there is a, there is value in human language and definitions and terms because we're humans talking to other humans. But uh, unfortunately we also have to stop talking to humans when we run out of, run out of time for these segments. Tyler, any last words you want to send to our listeners?

Speaker B: I think at some point we're going to do AI to AI podcast. How about that? We'll see where it takes us.

Speaker A: Um, good luck with that. I'm going to stick with the human to human and uh, let the AIs, let's talk to the AIs. But while everybody's thinking their own thoughts on those subjects. Thank you for joining us. We're going to take a quick break and then return with two interviews from the I think it was two weeks ago for my Dentaverse 2026. First up is Tamar Appleblot from Token security. He talks about the nuances of identity controls for agents. Then David Goldschlock from Ambit talks explains how the history of identity security sets the foundation for what agents need today. So if you're still interested in agents and LLMs like we've been talking for the last 30 minutes in identity and securing them, um, stick around to check those out as well as please do subscribe. Check out the show notes, share us on the socials. And speaking of alliteration, check out 01 by Dan Terminus. We'll see you next time on Application Security Weekly. When it comes to mobile application security, good enough is a risk. A recent Survey shows that 72% of organizations reported at least one mobile application security incident last year and 92% of responders reported threat levels have increased in the past two years. Guard Square delivers the highest level of security for your mobile apps without compromising performance time to market or user experience. Discover how Guard Square provides industry leading security for your Android and iOS apps at, uh, securityweekly.com guardsquare.

Speaker C: Welcome to Identiverse 2026. I'm Mike Shima. Joining me today is David Goldschlag, CEO and co founder at Ambit. David, thanks for being here.

Speaker D: Great to be here. Thank you.

Speaker C: So one of the things you're helping me wind down a day, one day of Identiverse, it's pretty exciting. And um, this is Las Vegas. I feel like we should do a mentalist bit or something like guess what's on my mind. But I'm pretty sure you're just going to say agent or agentic or AI.

Speaker D: That's it's all about AI.

Speaker C: It's all about AI. It absolutely is. And one of the things I've been slowly learning and discovering is that there's still some nuances, important things in AI because there's humans, there's call them machine accounts, service accounts. We've had those for at least the last decade with the cloud, for example. And then there's whatever agents are and they're not just a synonym for machine accounts. Tell us a little bit about why that is. Why do we care about AI agents?

Speaker D: So you're right, at one level there's people who do stuff and at another level there's agents that do stuff. And those agents are just pieces of software. But we've had software applications for 50 years, so why? What's really interesting is software that we've had so far far basically does the same thing over and over. Okay. And agents seem to have people call it non determinism but there's some flexibility in what they do, and they sort of decide a little bit what to do next based on the information that they get. Okay. And that's intelligence. Okay. Now, you could debate how intelligent is it, but it creates a different way that these things operate. Okay. And you were asking, though, about, you know, what are the differences between giving an identity for people. Right. Or an identity for software or an identity for agents. Okay. And I think one thing we should start with is you need an identity for each of those. Okay? So if you're a person and you're doing something, you need an identity because that identity gives you rights to do some access. And the logs and the audits should show that you did that access. The same thing happens if you have your Google Calendar logging into some service. It should authenticate and it should know what was happening. But an agent should be exactly the same thing. You should have an agent, and it's trying to go to your database. It should have an identity, and you should be able to track that, uh, that agent did the work. Now, the most common version of agents, though, are agents that do work for users. And that becomes sort of this combined hybrid problem. Right. Like you have your agent going to operate on your calendar. Uh, it should have your rights. Should it have your rights forever? Should it have all of your rights? I don't know.

Speaker E: Okay.

Speaker D: But we should make a decision. Right? So it should have some of your rights. And what we're hearing from customers is if it can impersonate you, that's too much rights for too long.

Speaker E: Yeah.

Speaker C: And as you're setting up that hypothetical, I wasn't answering because I was getting

Speaker A: a little bit worried.

Speaker C: I'm like, no, I don't want it to do all those things. But the reason for that is that's where the risk lies. And I think, uh, I'd love to hear some more about what are the risky workflows or why you sort of answered this already in the sense of, we want to know who did what or what did what, but tell us a little bit more about how that risk manifests or are organizations appreciating the risk that comes from these agents?

Speaker E: Yeah.

Speaker D: So we've had delegation for a long time, right? Sure. Okay. So an exec. I'll have an admin who will do things for the exec. Okay. But there. The delegation is. There's process around that where there's a person, right. Who's the delegator and the person who's being delegated to. And there's a sense of responsibility and a code that's related to your job. Okay. If you have a piece of software and you give it your rights, you don't know what it's doing, okay. And how do you know that it'll keep doing only the things you intended it to do? Okay. And when it goes bad, who's responsible for it? Right? And we. You got to think about both of these things. You got to think about the happy path, right? Where it's doing what you're intended. And you also got to think about the pace where it goes to these dark corners. And then how do you know? Right? Shut it down. How do you know what it actually did?

Speaker C: Yeah. Now, one of the things you weren't here this morning, but this morning I was introducing the day and I was talking about one of the things I'd love to see is practical advice. You've already given us a couple teasers of that already. Some examples as well as real world examples. I think you've got a really good real world example of deploying agents, securing agents. Can you walk us through that?

Speaker D: Yeah. So we have a customer. They're a, ah, large investment company, okay. And um, they've decided to give all of their employees access to Claude, either Claude Webb or Claude Desktop. Okay. And Claude then can access all of the corporate information. Okay. And the corporate Information could be Microsoft 365, or it could be various SaaS, applications, financial apps. Right? Different things that help different functions do their jobs. And how do you make this all the plumbing glue together. You put MCP servers in front of all the data sources, all the applications, and then you have the user sitting with Claude. And now Claude magically can access all of those data sets, search them intelligently, do operations on them. A lot of things. You might call this a, uh, digital assistant type scenario. I heard that it's sort of somebody, uh, another customer. We have called it kind of a next gen search. It's what you always wanted search to do, the intelligent search. And not only is it search, it can act on the data and process it and do things. Okay, so that's the glue, right? User, laptop, Claude, MCP servers in front of all of the applications and data. And it should all work. What's missing, the missing is access control. How do you get Claude the right amount of writes for the right amount of time to do what the user is asking Claude to do. So the obvious answer would be, give Claude your rights.

Speaker C: Here are my credentials, here's my password.

Speaker D: After all, it's your Digital assistant. Uh, right. The problem is now cloud can do everything you can do.

Speaker E: Okay.

Speaker D: For forever. Okay. Uh, and changing your password is not a way of limiting the forever. It's too blunt. Yes. Okay. So what we're hearing from customers is they want to give Claude the appropriate rights, but just for a certain amount of time. Okay. And they want all this to be centrally managed. You don't want every user doing this delegation themselves. Okay. And so what we do is we're able to give Claude what we call a blended identity. And the blended identity is your. The user's identity and Claude. And then we can make an access decision not based on what you are entitled to do, but what Claude should be entitled to do when it's doing work for you. And a nice example of that would be it's going to Microsoft 365. Maybe you have rights to read and write all that data and delete stuff, but you don't want Claude to delete anything. Okay. And that might be because you're not ready to give Claude those rights. Like, in a year you'll be ready to. But it might also be that, you know, you're just. You're making these decisions that this sort of operation should not be permitted. And so we can give the blended identity the write rights, and we can give it for a short amount of time so you can seamlessly reauthorize and Claude can only get access while it's entitled to. Now, from the bad side, we can audit, so we can do something called attribution. When Claude is doing work for you, we know that it's the blended identity, we know it's Claude doing work for. For you, which can be differentiated from you doing the work. And that's really important, right, that we can tell what entity, the agent or the person did that work. Or if Claude was trying to do something on its own, then of course it wouldn't have those rights at all.

Speaker C: And that's a key part because it goes back to what I was going to ask about or make the comment that Claude did. This hybrid identity could be a malicious intelligence insider, even though their intent was just Claude to go search and take some actions. Now, obviously, a human could have been a malicious insider. We've seen that already with, you know, nation states trying to get employees hired in things like that or just what have you. But an agent is just, oops, it made a mistake, or, oops, it took some action that it was given permission to do, but nobody intended it to take that action. And it sounds like this is the way to both constrain that as well as to say wait, why is this action happening in the first place? We want to revoke that basically.

Speaker D: That's right. And so you want to know what the starting rights are and then you want to limit those rights both in scope and in time and duration so that way things can happen outside of scope and things can't happen for too long.

Speaker C: And part of that because in my mind I've seen a lot of organizations also be like we're going to have a great R back story. We have super granular access control. And this is just in the human world. And it's so granular that it boils down to this new hire. Just, just give them basically the equivalent of star access because it's so much easier. I imagine that's got to be the same thing with agents, low maturity organizations, either on this deployment you were talking talking about or just what you've seen other ways. How has that granular access control actually stayed granular without becoming just give them everything.

Speaker D: Right. So you run into um, either too much access because that was the simple way of doing it right, or it's too hard to manage and finding that sweet spot is actually complicated. Okay. And tools like Ambits are trying to work to a place to make life manageable for the administrator and also no extra work for the end user. Okay. Because the end user doesn't want to be thinking about all this. They should be doing what he normally does in order to do his job. Okay. So one of the things that we're able to do here is we're able to capture most of the rights of the user from the identity systems that the company already uses. You may use Okta or Entrepreneur and you already know what that user's entitled to. And then you can have centralized rules that say okay, when you're accessing Microsoft 365 we'll change read write to only read permission if that's the company's. So sort of these fusing of policies give you a way to make it simple and not repeating and duplicating the policies that you already have.

Speaker C: And I imagine that kind of fan out of that central policy policy to a multitude of agents I hope is probably easier for humans to reason through and say this is what makes sense, this is how we can audit it rather than just we have a million agents and we also have a million policy expressions.

Speaker D: So uh, this comes down to sort of a how do you count the agents you have? Right. So if you think about it, you have all these users. Right. And they roll up into groups and they have rights. And now you have this instance of claude, and every user is using claude. And now you can create a policy, perhaps group based, that this group of users gets to use CLAUDE in this way. And that scales. Because that's how we manage things to scale today.

Speaker B: Yeah.

Speaker C: So in this deployment, for example, how much have you seen this type of granular access control, being able to revoke or being ephemeral grants, how much of that has been, I want to say, preventative rather than just, oh, uh, there was a mistake and now we need to react and then refine.

Speaker D: Yeah. So we're finding that the job is to get up and running quickly. Okay.

Speaker C: Yep.

Speaker D: And to do this in a way that gives enough power to the users to do what they do. And then you can tweak stuff. Okay. Right. And you'll also. Also learn as you move through things. Right. That activities you may not have been comfortable with are those that you might want to. Want to do. Now, a lot of times you roll things out for a group of users. Okay. Right. So you start with this and then you roll out some changes and you'll do it for a group, and then you can expand it to other ones. But I do want to say that this digital assistant model. Okay. I think that every customer should be doing something like this. Right. Because your employees now have access to all of your data. Okay. Or all the data that they'd otherwise be entitled to, but in an intelligent way.

Speaker C: That they would otherwise be entitled to is a great phrase that I just want to jump on. Because me as a human, I have my handful of task lists for the day. Here's what I want to do. I could have access to all this over here, but I'm not going to just because I don't need to today. But as you're. I just want to emphasize that agent could have done that.

Speaker D: That's right.

Speaker C: And it doesn't know necessarily not to. Or doesn't know, like why it shouldn't or express why.

Speaker D: That's right.

Speaker C: That's a really good story that resonates with me.

Speaker D: Yeah.

Speaker C: And, um, I'm curious. Then I just want to squeeze in one last question as you, as you talk to the CISOs about this. What's the story then that they say, how has this helped them become not denotes. Don't deploy those agents here. We're going to enable you.

Speaker A: What's.

Speaker C: Yeah, what. What are they. How are they reacting to this?

Speaker D: Okay, so what we're seeing in organizations. Right. Is, um, let's say a company wants to deploy. We're just releasing Copilot support for Microsoft Copilot Studio. So you're having third party apps, uh, connect Intelligence. Right. Connect to your own services or to other third party services for users. And the organization's deciding I want to do AI. Okay. Right. Uh, the CISO is coming to us and saying, how do I say yes? Okay. And if I say yes by giving the AI all the rights that was your guard rights before. That's irresponsible. Okay. So how do I say yes but still stay within my guardrails? And what we're let you do is we let you say we're going to give the AI the rights with the same level of control that you've been doing for users, but we're doing it for this new combined user agent. The blended identity.

Speaker C: No, I love that. And unfortunately, we're against our own guardrails of time. But you've given us a great conversation. Thank you so much, David.

Speaker D: It's a pleasure. Thank you so much.

Speaker C: To learn more about AMBIT, uh, visit securityweekly.com ambitidv that's a e m m b I t IDV for all of of identiverse 2026 covers from Cyber Risk Alliance. Check out securityweekly.com IDV and stick around. We'll be right back after this break.

Speaker A: Zero Trust is clearly the future as threats get faster, quieter and harder to detect. But implementing it shouldn't disrupt the business. Threat Locker enforces default, deny and execution in a way that remains enterprise ready, scalable and operationally clean. Unknown software is stopped cold. Trusted apps stay contained and drift is locked down across the environment. It's Zero Trust that works in real enterprises and prepares you for the threats ahead. See why CISOs are adopting it@securityweekly.com ThreatLocker

Speaker C: welcome to Identiverse 2026. I'm Mike Shima. Joining me today, today is Itamar Appleblack, co founder and CEO at Token Security. Thanks for being here.

Speaker E: Yeah, it's great to be here.

Speaker D: Thanks.

Speaker E: And thanks for pronouncing my name exactly how it sounds.

Speaker A: So that's great.

Speaker C: Thank you. I want to make sure I get that right.

Speaker E: Awesome.

Speaker C: Uh, so one of the things I want to get exactly right. Let's see if I can get 2 for 2 is secure all my agents. How do I do that? Easy question right off the top.

Speaker E: Yeah, I mean, I think that's the main conversation of today's conference. Right.

Speaker C: That's the entire theme.

Speaker E: Everybody's happy, everybody's speaking about AI and AI security. I think that there's a program that you need to build around agent security, but it's always need to start with inventorying your AI agents, uh, treating them a bit differently than classic identities. I think that that's a, ah, fundamental change that you have to tell me

Speaker C: a little bit more about that. Because everybody's inventory their machine identities, their service identities. Yeah, but, yeah, but why, why are agents different?

Speaker E: Yeah, so agents pursue a goal. They are uh, a bit of a combination of humans and machines where humans has, they're in a small scale but are unpredictable in some ways, going off against some, you know, like against some objective. Then you have machines that are doing things in a much larger scale, but are um, super predictable. They are deterministic. Do this, this and AI agents is a mix of both. They'll pursue a goal, but in a much larger scale continuously do so. So we need to think about them a bit differently and not just try to fit them into the existing characteristics of our human programs or our machine programs.

Speaker C: And part of that then makes me the other hard part of that is what does then what does least privilege mean for an agent? Because uh, that's a classic identity challenge. But now is there hybrid like mostly least privileged? Least and most privileged. We have to pick up a term.

Speaker E: Yeah, look when we started, when we thought about this privilege, we say okay, easy, let's look at the past and try to predict the future. Let's look at what the identity were doing in the past two years, the service account, and say okay, did A, B and C. So let's restrict it by that. But it's not working anymore. So forget about that static list. Privilege will never work for AI agents. So how do you do that? You need to look at the goal of the agent and then scope the permissions based on that. And the least privileged mechanism should also be moving to more dynamic and real time. Right. So for every action we want to, to validate, hey, is this action, is this behavior is aligned with the intent of the agent, with the purpose of what we're trying to achieve with this agent. Okay, so that's uh, the transformation.

Speaker C: And so yeah, and to kind of, to translate, I'm translating in my head a little bit. That sort of means that this agent, yes, maybe it needs to push to production, but it doesn't need to always push to production. Only when a build has successful, successfully completed and only this particular type of build. It doesn't need to press everything.

Speaker E: Exactly, exactly. Even production is a very large scope. Right. So good point. What it needs to push that scope it by that. Right. Like it needs to update those three resources. All right, so let's focus on that and not like allowing them to be an admin in the production environment.

Speaker C: Yes or no? Don't be an admin and don't be one prompt injection attack away from here is uh, everything goes away.

Speaker E: That's terrible. Yes, yes that's true.

Speaker C: So we've jumped into I love how this story is going and you answered that question of the nuance. I want to roll back because you were also talking about the discovery and inventory. Okay. We've had the cloud before and we've had shadow it. Shadow cloud. I think you know where this is going. Shadow AI. Everything is a shadow these days. Yes, obviously that's a problem. So how do you. I don't know that we've solved shadow cloud even or shadow it. So how are we going to solve Shadow AI? What's the story here?

Speaker E: Yeah, I think that uh, at least the way that we think about it is that AI agents could be deployed in three different types. You have agents that are running locally in your employees computer usually for you know, for uh, personal individual efficiency and improvement. Then you have agents that are in different managed SaaS applications like Copilot, OpenAI. And then you have agents running in production. You want to think about how to discover those three types of agents and create some type of visibility for each one of those layers and also understand what's the risk model that you care about. What do you see larger deployments and focus on those uh, uh, different ecosystems.

Speaker C: Yeah, yeah, yeah. And that's got to be. I think I like how you grouped down to three different areas because I have no, I have no data on this but who cares? We're in a world where people don't need data to make decisions or broad claims. I'll say that those, those personal agents like on ah my system like ah, answering email, writing email, uh, those are probably a lot easier to be ungoverned those Shadow AI because I could get the free access to that chat or I could just pay with my own credit card. What happens? How I guess a two part question. How do you even find those and that what happens? How does the security team figure out how to control that without just say no, stop. We're shutting everything down.

Speaker E: Yeah. So by the way we did uh, a research not too long ago, two months ago and we do have data so 82% of CISOs share that they found an unsanctioned AI agent. They discovered shadow AI. Uh uh, although they have some programs to control and to inventory those agents.

Speaker A: So yes even with that, even with that still finding.

Speaker E: Wow. Yes. And that's why I think that so for local agents. So let's say that uh, I'm having plot code, it's being installed in my computer. So the only way to give visibility for that is looking into the local endpoint and monitor the processes activities and also um, EDR interactions and file system in order to map those local agents or OpenCloud cloud code code. Then what you want to do is give it a bit more of a context because an agent without access it's redundant, it's not giving any value. Right. But it's also as I give it more risk, as I give it more access, it has higher risk. Same with autonomy. So for each agency want to create this model about what access does it has which identities it's leveraging in the target applications in your environment.

Speaker C: So with that then I love that answer because I want to get in some details too. Let's say I'm going to riff a little bit on the cloud. Yeah we've got an organization has their IAM tools, their PAM tools. They figured out how to do the cloud services, the cloud identities and the cloud service providers. They want to know how to bill you for every single day spin up. So inventory is perhaps a little bit easier. The AI companies want to bill you for every token you spend. But that's a little bit different from identity. So do those tools, those cloud oriented tools, are they translating into AI uh as well or what's something that the tools are there are missing that what you're describing is really necessary?

Speaker E: I think that um most identity tools and most of the identity vendors here started from a specific problem which was human centric. So focusing on human access understandable. Uh right, because that's you know in the past 20 years was top of mind. But as identities became more decentralized so there's no one place, one uh, uh place, single uh pane of glass, one place to see all of your identities, one place of control. Then things became more complicated. I think that those solutions, the classic IGA and PAM are uh, actually didn't scale even to the explosion of identities in cloud. Uh so for sure they are not going to uh support agents explosion. So each employee has thousands or hundreds of different agents that they're leveraging. Um so yeah I don't think it's Scale, uh, at all because of the fundamental approach. Where is my source of truth? Is it in a singular place, idp, or is it being decentralized across all the different applications?

Speaker C: Yeah, and I think there's a little bit of a hand wavy math game here because I'm going to say volume, it's not, it's the complexity or the difficulty. What I'm hearing is it's not just that it's a numbers game because we used to have a thousand humans, now we have a thousand humans each with a thousand agents. It's 10,000 or whatever. It's those agents figuring out what their scope is, what their privileges is. So how does a human manage that? How does it. That that's, that's painful. Otherwise you're just going to hit the like, approve, approve, approve, approve. Why not?

Speaker E: Exactly.

Speaker C: But that's bad. There's got to be a better story. Help me with story time here.

Speaker E: Yeah, I think that you have to define uh, even before bringing vendors or trying to do things in scale, you have to define what agents should do and what an agent shouldn't do and create some type of policies around it. But then think about how to enforce those in scale. I think that the fundamental thing that is really shifting here is the scale and the decentralization. So um, we need, with such a large scale we need to have automations. We cannot do a manual, uh, reviews and access reviews and things like that. A lot of the things we need to think from uh, the beginning about how should we manage the processes, the governance and controls for um, much larger scale identities.

Speaker C: That's interesting. I'm curious especially the idea of decentralization. It makes sense to me as I hear you describe that, but I imagine that must be a tough sell. Or that's got to be bringing a CISO around from a single pane of glass, to use the cliche. Or here's the central point where I can know all of my policy comes from. How do you get that to resonate with them? That the controls still work? The mindset just needs to change a bit.

Speaker E: Yeah, I think that just asking them how agents are being deployed today in the organization makes um, them start to think about okay, wait, I cannot just look in Okta and ask, hey, show me all of my agents. Because they're managing so many different places. So I actually think that in terms of education it's not so complex. Also because every SaaS vendor in today's world is having some of AI story themselves. So they have their own agent suites. So it's it's so they just need to think about okay, I had shadow SaaS shadow it in the past 20 years and it's because of this decentralization. Right.

Speaker C: Yeah. I'm curious then too. As you see what do you often point to as a success story or let's say an indicator of success when an organization is able to follow the advice that you're giving now, what does that outcome look like?

Speaker E: Yeah, so it starts with I know about all of my agents and then I start start to have a life cycle management processes that are continuously and automatically. Right. So right now a lot of CEOs and CIOs are pushing AI. So what you see is a lot of those experiments. So how do I deactivate a dormant agent? How do I understand accountable least privilege that we talked about all those processes but in a much more continuously and automated fashion and not just like knowing about this list of endless problems that uh. I'm not going to solve by myself.

Speaker C: Yeah, I'm smiling because I'm thinking of uh, from an application security perspective often dealing with tech debt or legacy systems or old systems that who knows where the original developers were. And you're describing this life cycle of agents. Uh, have you encountered agent debt so far? Organization organizations where these agents are running. They have they. But the, the employee has left but the agent didn't get spun.

Speaker E: Yeah, yeah. Ah, agent created by off boarded employee is a ah phenomena and we see it ah quite often. Also agents are using old school um authentication mechanism using. Okay we actually saw an interesting phenomena. We saw that um. Because of the agents adoptions and a lot of them running locally in employees computer we found a lot more of secrets exposed secrets credentials that are just being stored, you know plain text in the endpoint which was something that we thought is shrinking over time because of Vault and other things is now actually expanding. So that's an interesting phenomenon.

Speaker A: Oh wow.

Speaker E: Yeah, yeah.

Speaker C: That's scary because I would have hoped that we've gone to the protecting our

Speaker E: secrets management but yeah, uh, history doesn't repeat itself but it rhymes. Right?

Speaker C: What rhymes with my password is. Yeah, trying to think of that. Well if history were to repeat let's say next year, next identiverse. Is there something that you would hope to see that most organizations have matured in some way or at least something that they're understanding about agents much better.

Speaker E: Yeah I think that a year ago um when we spoke about AI security and agent security a lot of the mindset was protecting the AI from what it says. Right. So, uh, policing the prompts, what the AI can reply, what the AI cannot say. I think that next year I hope that people will start to think more about what the AI can do and not what it says. Because we are using the Frontier Labs models, and this is their job also to improve the response of those models. So we need to focus as an identity folks, more about what the agents can do and how to, um, guard your debt.

Speaker C: Yeah, I love that. Because it's what the agents do. That's where the risk comes from. That's where the consequences come from. That's what, on the security side, we hope to avoid.

Speaker E: Yeah, exactly.

Speaker C: But I'm glad I didn't avoid this conversation very much. Thank you.

Speaker E: Tomorrow. Thank you so much.

Speaker C: If you'd like to learn more about token security, visit SecurityWeekly.com TokenIDV and for all of our Identiverse 2026 coverage from Cyber Risk alliance, check out SecurityWeekly.com IDV Stick around, please, because we'll be right back after the break.