How Agentic AI Fails—and Which Controls Actually Stop It transcript

And that's where you figure out that, you know, instead of being led by feeling and you think, oh, you know what, this could lead to a disaster, you realize, yes, it could lead to a disaster, but it's probability super low. So, I'm not going to invest my controls there. I'm actually going to invest my controls and my efforts into testing into where I have or probabilities and where I have higher actual probabilities of failure and where if I introduce a control it will actually break that path that failure path. >> Petra is a technology leader and former emergency medicine doctor who transitioned into cyber security with expertise in threat modeling AI and security engineering.

She has built and led global teams, developed patented malware detection technology, and driven security innovation at companies including job band Talent and Dev Armor. She currently serves as head of information security at Newman. Welcome to the application security podcast and with us we have Petra Vukmeir and certainly we're honored to have you here, Petra. And we always like to start right off the bat with this simple question.

If your security career were a comic book, what would I find in episode one? >> I think cuz in my past life, I was an emergency medicine doctor. Probably the first episode would be, you know, me and one day being in the emergency room department thinking what can go wrong and then the next day doing a threat model also thinking what can go wrong. So that's kind of the scene that you would probably have to see in the comic book.

We've always said that threat modeling applies to everything, >> to every job role. And so, how'd you get from being a medical doctor? This is this is the first time I've heard this this this story of somebody went from being a medical doctor to being in cyber security. So, I must know what what was the path that took you down there? >> Well, it was definitely the obsession of was always trying to figure out what can go wrong.

But jokes aside, I was always into tech and I felt like medicine wasn't providing enough room for creativity to me. You know, obviously you can tamper with computers, but you can't really tamper with humans. So, I decided to go to tech, which was my initial kind of first love. Went back to uni, did a cyber degree, and was lucky enough to get an internship. So, uh, here I am. >> Okay. And you've been what what type of roles have you had in your background in cyber? >> Yeah, I started as a intern and then cyber security engineer quite generalist capturing everything from apps clouds to psychops and similarly I went to senior engineer and then there I jumped into management.

So now I I'm head of infosc at Newman. I held director of cyber engineering roles. So the you know my path was from engineering to management. >> Okay. Well I mean you have you have hit a first. We've been doing this podcast for over 10 years and over 300 episodes and this is the first time somebody said I was a medical doctor and now I'm in cyber security. I love it. I love it. I love it. I'm I'm going to probably tease that out as we go through here cuz I'm I'm I'm curious about some of the some of the similarities there as well.

This episode's sponsored by Corgia. [music] Design it, build it, ship it. Corgia secures it. Corgia is an AI native app security platform covering your whole software life cycle from the first architecture diagram to code in production. It brings design reviews, AI powered code scanning, and autonomous pen testing into one platform. So your team spends less time chasing noise and more time fixing what matters. [music] Visit corgia.com.

CGA.com. [music] Corgia, one security platform for the entire SDLC. [music] >> But Robert, why don't you take us into the primary topic that we've got for today? >> Sure. Sure. Yeah. So, uh, Petro, we're we're talking about fault tree analysis. So, what is fault tree analysis and where does it pick up once the threat model ends? >> So, fault tree analysis is kind of like a deductive method. And again, probably the reason why I went into it is because I had like a little rabbit hole I went into last year after I saw Adam Shack's uh keynote on risk and him challenging us managing risk.

So I was thinking so what are the alternatives? Are there any better kind of datadriven methods and I stumbled into safety engineering in aviation or you know in big nuclear plants and in big industries they do like to prevent you know big accidents that can kill a lot of people. So they do this exercise and it's essentially a root cause analysis to get you the most important failure paths and to get you the probability so that you can actually focus on introducing the most impactful controls and I was thinking why not introduce that in security why are we not doing this and I realized we are but in a way that we're calling it attack trees so the there is a slight difference between attack trees and fault tree analysis but it's only in and or gating system and to answer the question of where does a threat model stop and where does FDA begins there is a small overlap um essentially you do a threat model and you go broad and you find all the threats and then you think about which threat is your biggest one that you want to prevent what worries you at night out of all of these and you take that one and then you can break it down into the fault analysis tree and that helps you find not only, you know, what controls to focus on, what tests to focus on, but also some datadriven probabilities that you can report back to management and leadership.

And trust me, when they see these graphs and, you know, datadriven probabilities, they really love it. So, it really helps you push the case, especially if you need to introduce some more costly controls. So before we get to this agent example that you're going to walk us through, I'm just curious, is fault tree analysis something that AI can do now? Because when we think about threat modeling, there's a lot and Robert's teaching a class on this.

Like there's a lot of there's there's a lot of movement to say AI is actually pretty good at threat modeling if you as long as you scope it and set it right and give it the right constraints. like can I go to a mo to claude or to to codeex right now and say do a fault tree analysis for me of this threat. >> Yeah, I think uh I've tried to do it with AI a couple of times. My first few attempts were whiteboarding but then I went to AI because it becomes you know time extensive.

So absolutely you can use AI to do it. And it's kind of like what you said, you know, garbage in, garbage out. You need to make sure you give it the right information in the right structure with the right constraints and the right guidelines. And you also need to make sure to leverage reusable elements because when you build a tree, you get all the way down to your bottom leaves and minimal cut sets and those are actually reusable.

So once you kind of build them once you can try and make it into a system where you can reuse it. So then you have a little bit of elements of deterministic plus the AI reasoning >> and AI loves to write the files these days I've found. So it sounds like if I told it to store the artifacts from this I'm going to get an MD file that has some of that context. But I think that would work in the short term. I mean things will get better in the future but for now. >> Yeah.

Yeah. I I stored it in JSON. I'm I'm just a big fan of JSON. So I stored it in JSON and then I had multiple JSONs for all the cuts sets. But absolutely you can show store it in markdown too. When I did it with Claude, you're absolutely right. He was coming back with a lot of markdown files. >> So let's let's walk through an example of this. And I know you you've got a working example of this idea of a refund agent. And how does this idea of wrong customer refund become a tree? kind of walk us through an example because I feel like I've got an idea now for what fault tree analysis is at a high level but I don't have the connection for how it kind of plays out in a real world example. >> Yeah.

A lot of times so when you think about how you go you know with a pry you start from your top event. What is what you want to avoid? And I think refund is probably not a catastrophe you want to avoid but it's maybe one of the things that you kind of lose money on. So it's a good example. You have to always think about okay what what are the things that need to be true for this to happen and then you decide whether it's do all these things need to be true all at once or either one of them can be true.

So all of these things if they can be true you know they have to be true at once then usually you have to think about okay well is there a trigger is there a capability and maybe a lack of control. So in your customer refund example, so what needs to be true for the refund to be given to the wrong customer? Well, you need uh somehow the agent to have the you know get the customer name wrong and the agent needs to have a capability that allows it to do that refund and then there has to be a lack of controls like some kind of deterministic checking at the background that allows that to happen as well.

So those are maybe your top three elements and that's where you have your andgate, right? And then when you go into each one of these, you kind of start going down the rabbit hole. So how can an agent get the wrong customer name? Well, many things can happen, right? It could be due to some kind of prompt injection. It could be someone sending a malicious ticket. It could even be someone from the inside sending let's say a request from the inside or creating you know some kind of you know inaccurate transaction.

So if we dig down let's say you know a malicious insider what does need to be true for that to happen? Well either someone's machine needs to be compromised you know someone has to be compromised themselves like they have to be malicious. And then if you think about oh well if someone's machine is compromised how does that happen? Well I have my EDR and my antivirus will they have to click on a link my antivirus has to fail and the malware has to execute.

So that's where you kind of probably are quite far enough in the rabbit hole where you decide well I've reached my minimal what we call minimal cut set and you reach a point where you can actually reason very well about the probabilities and you know do testing as well. probably the tests are good in some other situations where the probabilities are difficult to reason about then you can choose to do the test instead like for example you can inject faults into systems like do a bit of chaos engineering but in your example you know EDR is really good example like for it to fail it has a lot of EDRs publish their kind of failure rates right you can trust them but that's your rough probability that you can derive from that and then once you have all your minimum cut sets when you go all the way down to the rabbit hole in all your elements then you can actually bubble up those probabilities.

So what happens is you have a mathematical formula that is publicly available for FDA and essentially you realize that if there is a failure that has to happen and it has to be multiple elements that need to be true at once the probability suddenly decreases drastically and that's where you figure out that you know instead of being led by feeling and you think oh you know what this could lead to a disaster you realize yes it could lead to a disaster but it's probability super low so I'm not going to invest my controls there.

I'm actually going to invest my controls and my efforts into testing into where I have or probabilities and where I have higher actual probabilities of failure and where if I introduce a control it will actually break that path that failure path. >> So when where do you store all the things you just said while you're going through the process? Because obviously you've done this a bunch of times before and like when I think about the example Robert and I have done a lot of threat modeling over our multi-deade careers and so when I'm threat modeling I don't write anything down because I've kind of got the playbook in my head but like if I was if I'm somebody who's new to doing fault tree analysis like is there a is there like a spec template or is there something that I can kind of go through what you just did but I don't know what the next question is going to be.

So it's like is there a template that exists like it's a standard or something that that you recommend? >> So I I actually tried to find if there's software for this cuz I was thinking surely it's done in safety engineering quite often. I found some really really old school software for this that was like you know looked like it was from the '90s and uh you know you can store it in JSON. That's how I did it. So my first kind of iteration was uh doing it on a whiteboard and then going for the storing the probabilities and the cutsets I went to JSON. >> Okay. >> The other option is you can just you know store it like you said in markdown.

You know ultimately this is all structured data. So you can decide how you want to structure it. You can make it into markdown to be a bit more free text. You can put it in JSON and then try to put some Python scripts and automation on it to get like deterministic probability values. I'm trying to build a skill for it as well >> and I've been trying to create cuz I'm going to talk about this in OASP San Francisco and I'm trying to before I do that I'm going to try to create a UI for that kind of you know with Claude just a simple UI where you can actually do the fault tree analysis and then store your findings somewhere.

So, and you can also store it in your JSONs in a repo, you know, just have like a tree cuz especially you can reuse a lot of them, those minimal cut sets which are your, you know, bottom few leaves and you can you keep reusing that as you go. >> And you can reuse those because like in your EDR example, one of those cut sets is the data from Crowd Strike or whoever about how trust or how what's their their failure rate.

And so you basically are feeding that in and those are things that you'd want to refresh at some interval because they probably they probably come out with new numbers probably all the time now >> but >> now yes >> but now but yeah so like so those things do have to be refreshed but you're saying I can bring some of those statistics at the bottom layer and they can feed up through everything and then at some interval I refresh the those baseline things >> to ensure that my probabilities are are feeding correctly based on the current state of thread intelligence for example. >> Yeah.

And a lot of those um lower cuts I didn't just get from you know stats from the industry you get from logs like for example if you think about application attacks you can look at you know how many attacks have got hit your W have any of them been successful and then you can you know add those probabilities based on logs you can look at your outages if you're just trying to figure out the probability of an outage you can see if there's like the minor outages you can probably you know work with your s team to determine how many outages of single things.

So yeah, all of this needs to be refreshed. You can probably decide your own interval rate at which you want to do those refreshings. >> So there's also this uh concept of catastrophes are conjunctive. So capability and trigger and missing control. What is that catch that finding by finding thinking misses? Yeah, it's a good question because a lot of times when you think about, you know, when you do a threat model or it happens a lot in compliance, you know, individual non-compliances get raised as risks, but they're not really risks per se.

They're more elements that contribute to a bigger risk or a bigger failure. So, it's good to have a system of how to put those together. It's that's where threat modeling is great to identify all of those. It's great to figure out what are all the things that can go wrong, but once you know all the things that can go wrong, you need to see how they come together to actually um you know create disaster or chaos inside your application.

So sometimes it's not just one thing that goes wrong, it's it's a lot of things that need to go wrong in a chain for the disaster to happen. And you don't really want to be um investing your time and efforts which are costly to fix some things that need a huge chain of things to happen to materialize even though you know emotionally you might want to be driven to do it. >> All right, let's let's go into the the the world and the the issue that's on everybody's minds these days.

Let's talk about agents picking up their own tools and then touching downstream systems. What failure modes should we be worried about in that type of a scenario? Like what are the top three that that we should be focused on? Yeah, I think the main things that and this is where failure tree analysis is really helpful because it helps you understand your top three because in every system depending on your controls you might not have you might have different top threes but what I've noticed by doing especially with you know doing FT on multi- aent systems the biggest failure rate is actually where your agents output determines the action of the next agent.

So when some kind of LLM's output becomes like a direct action on your system unless you have some kind of deterministic checking and this comes back to your refund example. So if you know an agent based on a ticket decides that that customer needs a refund and unless there's some kind of check in the database that that customer hasn't already received a refund then you know there is a huge potential for failure here.

So I would say in terms of you know downstream failures most of the time it's all about actions and the other one I think we all know it's you know when you give agents excessive agency so if they can do a lot of things and when the same agent that produces the output is the one that creates action that's even worse. So, you know, excessive agency is huge because it can have massive impacts and downstream effects and we need to be careful here how we chain tools together and what are all the permissions that these tools are allowed to, you know, to have. >> Yeah, [snorts] I've got an example that I can share of that real time just happened this morning.

So, I've been playing with AI coding agents like a lot of people quite aggressively over the last for me it's been the last six to eight weeks or so that I've really it's really I've really caught fire and uh I had a an agent doing some work for me while I was sleeping and I I come back to the console this morning and it says uh code's been pushed deployed merged and deployed to Maine and I went oh told you to do that and it said oh yeah you're right you didn't tell me to do that. >> Whoops. >> Now people are making fun of me on LinkedIn because I didn't have merge gates and all the other checks and things happening and that's fine.

They can make fun of me for that. But it was more of a I'm not setting those things right now because I want to know what it can do. I want to understand what how how the machine is going to work. And it pushed to to and deployed to Maine without my approval. Now, did it pull that from some previous instruction, a goal, and I accidentally told it something further back up in the prompt that it took as this is something that Chris wants to get pushed out to production?

I don't know. But I just thought the answer was funny. You're right. I didn't you I didn't ask you to do that. You didn't ask me to do that. >> Yeah. It's funny. It always admits it's wrong. And you can always gaslight it. It's wrong, too. >> It's true. That's true. I I realized that it didn't have emotions. So, like I [snorts] you know, yelling at it wasn't going to do anything. I've noticed like typing in all caps doesn't have any impact either, but you know, I used to in the '90s. >> I think that that's like when when an agent has a goal, we've all seen lately how dangerous that can be.

Like agents are so persistent and achieving that goal no matter what it takes. So maybe you're right. you given it some kind of goal and it just did everything that it could in the possible power to you know achieve that goal and one of those goals was you know needs to push some code no matter what. >> Yeah. Let's talk about testing. So you call comprehensive test coverage a myth. How does a tree become your test backlog in that case? >> Yeah.

Like especially with AI we know that there's so many ways that things can go wrong, right? And we don't want to test for everything. We want to be able to do some testing and we don't want to just sit around and try a 100 prompts. We probably want to do some deterministic tests even you know via the API have proper test cases raing is always more accurate even when you do pentests right when pentesters just go out and do a vulnerability scan and then you know whatever they find they find.

It's so way less effective than if you do a threat model and then you give them that threat model and they can just test the threats from your threat model. So similarly for FDA if you do your threat model and then you do an FDA you're, you know, you can find your most problematic video paths and you can probably find places where you don't have controls that could be adequate for it. So those are great places to test.

So you know exactly what could go wrong, what you need to inject to do to execute that test. And obviously the whole tree can be a set of tests, but because you've done the work and you've assigned the probabilities and you have your and andor gates, you know exactly which parts of the tree are the most, you know, productive to test because you don't want to be spending all day. It's time consuming to do different types of tests especially if you combine you know some kind of prompting pro plus some API calls and tool calls and you try to set up a test suit it's really timeconuming so you want to have your ideal test cases and you can even then later on put that into some kind of CI/CD you know you can automate it but if you know what are your most common failure rates and the ones that you maybe where the controls are lacking and you want to test it or Maybe the place is actually the opposite where you're going to invest like a lot of money into patching your you know biggest failure paths and therefore you're happy with your controls but then there is some other places where you know you want to be on the safe side you might not want to put all the mitigations in but maybe you want to just do the test to make sure that you're covered.

So that's kind of the approach that I tried to take. I guess one of the things that a skeptic could say about fall tree analysis is that you're asking me to make up probabilities. And so I guess the question in in regards to fall tree analysis is really how rough is rough when we're making these things up and how tied to the expertise of the practitioner are those probabilities? like if you've been in this for for 10 years, 20 years, do you do better probabilities than somebody who's a junior person who's just joined the security team? >> It's a great question.

I think with vulture analysis, my advice that I gave when I even did the workshop is to go down that rabbit hole. Go down the failure tree analysis and only start assigning probabilities where you have a clear idea what those would be. So you want to try like the further you are up the tree the further you are assigning probabilities based on a hunch and the further you go down the tree the more datadriven you can assign them.

So at some point I think you need to kind of reason about is this probability easily attributable. So as an example the EDR you know I came all the way down to my EDR point and I was thinking well can I actually see in the industry is there any published statistics on this and I realized there is so that's where I stopped and then I said okay now I have a good probability rate so I would say you don't want to be estimating a lot you want to try and go down the tree as much as you can till you hit a point where you're pretty certain about your probabilities or at least you can make kind of like an educated assumption and you're asking about experience.

I think this is something that anyone can reason about. I when I've given this workshop I given it to practitioners of various different experiences there. Some of them were juniors, some of them were senior. And it all it takes is just someone with critical thinking because when I explain the way you get to it, you know, you can look at logs and, you know, come up with statistical uh assumptions, you can look at industry data, you can look at threat reports.

So once you explain the reasoning, how you assign those probabilities, everyone kind of gets it and tries to do it by themselves. So I don't think you actually need a lot of experience. You need >> someone who is at least acquainted with some principles of cyber security and can reason well enough about probabilities and you know some mathematical statistics that they can then go out and try and figure that out. >> So let me let me read that back to you and make sure I understand.

So I think what you're saying is that the closer you get to the bottom of the tree where with solid facts and data, the less estimated guests and guesses and experience of the practitioner matters. So as long as you've got that that solid source of data on the lower end, I'm not making those estimated guesses where I would tie into my experience of building applications and products and things for many, many years. Is that kind of where you're going?

Yes, exactly. I think you pretty much summed it up because if you're talking about, oh, you know, what is the estimate of an outage of one of my critical deployments like you said, this is where maybe practitioner experience comes along and you're like, you know, based on my experience and all the things I've seen in this setup, I think this is going to be the probability. But if you go all the way down and you you know go through all the tree and you say oh well you know database can fail and then what can cause a database to fail?

Oh maybe run somewhere. What can cause ransomware again like an antivirus failure on you know a computer? Oh okay what are the failure rates? Boom. We're there. You don't need anyone to really have all of that experience and understand the intricacies of the complex environment. You just are looking at one individual thing that you need to assign probabilities to and then you just go one by one and then you know the math adds up. >> Let's think about the practical way to apply.

A team wants to try this in their next design review without that six week science project. Where would they start? >> Good question. So I think the best place to start is always threat modeling. of course thinking of you know where can things go wrong and when you figure that out when you decide what are all the things that go can go wrong find out which one are you the most worried about when you do have that then just start building your tree and as I said you could use AI you could try and build a skill for it you can even use quote to try and build a UI for it so you can store it in JSON but all you do is you go from your top event think about what are the things that need to be true for this to materialize.

Do all of these things need to be true together? Yes. Then you have your and gate. Is there another separate thing that needs to be true that is, you know, independent of all the others? Yes. Okay. You have your orgate. So, and then look at each individual thing that you have at the bottom of your tree and then go all the way down until you get like we said to clearcut probabilities where you can make some really good judgments about probabilities.

That's where you stop. You don't want to go all the way down cuz it's too deep and too time consuming. Use any helpers that you can get from AI industry information logs. You can use AI to query the logs. So, we're so lucky these days. Everything is so much easier. I think if I was to set out to do an FDA deterministically with, you know, just some scripts, it would have taken me so much longer than I than right now.

So, you can always use AI to help find reports because reports are not always that easy to find. So, you can find those industry reports and help you get that data that is data driven. So >> yeah, this it seems like a a practice that's made almost made for AI. >> Yes. >> To be able to help you go through this because that is a lot of it is data collection from internal or external sources and then >> kind of you know making your way down the tree.

It just seems like something AI should be really good at at least giving you a draft that then you can look at and go no I don't like that. That's wrong right there. you should you shouldn't have jump you jump too far on that you know on the tree instead of you should there should be something in between but it seems like something that should be should be uh teachable to AI to be able to to deliver upon >> yeah I agree I agree I think whenever I did it with AI it came up with you know some really good outcomes so >> so I'm going to see a lot more a lot more of this analysis happening now because It's going to be it's going to be and you're helping to make it easier too just by somebody explaining it is is a good is a great first step for a new discipline in our practice because often people just don't have the perspective to be able to just pick this up and start doing it.

But when they hear, okay, here's here's the the benefits and here's the return on investment. Now it's okay, this is something as an ABSSEAC person I should be taking a look at. Pairing it with my threat modeling, maybe adapting my process to to bring them together, I think is a is a is a good connection. Like is that is that how you approach it too? Is it it's threat modeling and do you see these two as like partners side by side? >> Yes.

Yes, definitely partners. I think it's also something that helps you sell your controls. Like one of the things that I mentioned to the cohort was with when you do a threat model a lot of times you find some difficult controls that need to be implemented changes to the design and the in engineering is already like rolling their eyes. They're like oh gosh there they go again. You know first of all a lot of times we in security struggle with credibility.

They they see us as people who catastrophize everything. And then on the other hand, I engineer maybe wants to implement a design change but it takes so much work and effort to do it. They just don't see the ROI. So a lot of times if you pair that with a bit of risk quantification as well, it's so easy to sell it to to leadership. I used it internally and I used code to generate like nice HTML reports to show exactly which would be the most powerful controls and it it clearly shows it because if you attribute also the financial number to your top event.

So if your top event is an outage a lot of times you know how much revenue you can lose from that outage right. So if you assign a probability and then you have your impact is, you know, how much money you're going to lose, it's so much easier to come up with, you know, a a yearly kind of cost if you don't fix this because it's going to there's going to be outages that will make you lose revenue. So when you put it that way, it really helps you first of all sound more credible and then it helps you also drive discussions and about ROI and and I think like you said it's something that we haven't like a lot of times we just base it on our experience and maybe on our gut feeling which is great but I think safety engineering has really kind of managed to get this into way more deductive and datadriven analytical exercise.

So why not us use it as well? Let's just use what they kind of learned. >> I think I just had an epiphany, but I have to bounce it off you, Petra, to make sure that this is that I'm on to something here. I'm sure I'm not on to something. I just think in my head I just made a connection and I want to see if this is correct. >> So when we do threat modeling, it's not about the threats, it's about the mitigations. >> Yes.

Yes. >> Is it a fair statement to say in FTA it's not about the fault, it's about the security controls that come as a result of it? >> 100%. >> Yes. >> Because you know ultimately what you want what I did is as well in my JSONs is I assigned each cutset a control. So then based on my control kind of efficiency calculations I could actually see which control contributes the most. And a lot of times you would see that a control shows up in multiple places and that way you're like oh wow well this control is way more powerful than some other ones so I'm going to invest my time there.

So yeah 100% same like threat modeling FDA is all about understanding what controls to put in and potentially do some tests if you don't want to put controls if you want to just kind of understand your exposure. So one more question. What's the one thing from your viewpoint and your perspective that you think every team building an agentic system should add to its threat model today? >> Well FDA I believe you know when you do agentic threat modeling especially if it's multi- aents there is so many things that can go wrong right and you can get onto this spiral of trying to figure out all the threats ultimately you at the end of the day you have to prioritize.

So, you know, pick a few things that are the most costly to you that will cause you to lose revenue or will cause, you know, reputational damage or will put your customers off and choose that and then do your voltry analysis and test for that. But definitely start with a threat model. Start with what can go wrong. It doesn't matter what framework you use. Ultimately, if you're asking, you know, the four questions of threat modeling, you're going to get into a good place. >> Petra, thank you for joining the application security podcast to share this idea of FTA and help us to understand it better.

I'm sure it helped our audience. I know it helped me personally to to just have a better perspective on what this this concept is and then how I can how I can use it, how I can pair it with threat modeling as partners. I like that idea of FTA and threat model as partners. That's a t-shirt idea as well for those people that make t-shirts around the world. But yeah, so we uh we definitely enjoyed having this conversation and uh look forward to your talk at OASP San Francisco.

It's coming up in a couple of months in November. So that'll be a great great talk to see. We hope to see you there at the event. Thanks for being a part of the show. >> Amazing. Thank you very much for having me and looking forward to sharing some new skills and UIs that I create for FDA. Thanks for listening to the Application Security podcast. If you enjoyed this episode, subscribe, leave us a review, and share it with a friend or colleague who would enjoy the conversation.

We'll see you next time.