WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=4lXks428C9o NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/4lXks428C9o.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:16.560 --> 00:00:17.600 Hi everyone. s2 00:00:17.600 --> 00:00:18.800 How are we feeling? s3 00:00:18.800 --> 00:00:21.119 Uh we're in the home stretch. s4 00:00:21.119 --> 00:00:31.519 Uh, my name is Sarah and I am a context engineer at Post Hog and I get the delight of working on our beloved wizard every single day. s5 00:00:31.519 --> 00:00:33.520 So, what's the wizard? s6 00:00:33.520 --> 00:00:36.719 Um, the wizard sets up Post Hog for you. s7 00:00:36.719 --> 00:00:41.280 It's an agentic CLI tool that reads your codebase. s8 00:00:41.280 --> 00:00:44.239 It installs the right SDK for your project. s9 00:00:44.239 --> 00:00:48.320 It instruments your events and it sets up dashboards for you. s10 00:00:48.320 --> 00:01:01.680 It takes what used to it takes what used to take about an hour or two of setup and it runs that in about five to six minutes and it's free inference on us so that you have a great time onboarding to Post Hog. s11 00:01:01.680 --> 00:01:03.199 Sounds kind of sick. s12 00:01:03.199 --> 00:01:04.960 Uh, people love it. s13 00:01:04.960 --> 00:01:14.240 But a few months ago, we dared to dream, what if this became the recommended or default way to install Post Hog on your project? s14 00:01:14.240 --> 00:01:18.080 And my security alarm bell started going off. s15 00:01:18.080 --> 00:01:25.040 Uh, I started questioning how secure is this thing because it sounds kind of malware shaped. s16 00:01:25.040 --> 00:01:29.200 Um, and in that questioning, I learned a lot. s17 00:01:29.200 --> 00:01:39.920 So today is all about the lessons I learned, the stuff that kept me up at night while I was building this thing, and the thing that I ended up building because of it. s18 00:01:40.560 --> 00:01:49.680 So before I dive into all of the boring security stuff, aka your 2pm catnap, I want to show you the wizard actually running. s19 00:01:49.680 --> 00:01:53.920 If you look up on the screen, it is running for you on a loop. s20 00:01:53.920 --> 00:02:02.000 This is the same exact experience that anyone who runs npx at post hog wizard gets uh on their terminal. s21 00:02:02.000 --> 00:02:03.200 Like I said, it's an agent. s22 00:02:03.200 --> 00:02:05.840 It figures out what SDK is right for your project. s23 00:02:05.840 --> 00:02:10.479 It installs it for you, instruments your events, builds dashboards. s24 00:02:10.479 --> 00:02:15.760 I like to call it a little mini implementation engineer in your terminal. s25 00:02:15.760 --> 00:02:18.800 And sometimes I show people this and they ask me, why an agent? s26 00:02:18.800 --> 00:02:20.959 Why don't you give users a good prompt? s27 00:02:20.959 --> 00:02:24.319 Why don't you give them a skill that they can invoke in their own tool? s28 00:02:24.319 --> 00:02:32.560 And while we do provide those things, the answer is because this developer experience and the capability of the wizard is the whole point. s29 00:02:32.560 --> 00:02:44.480 It's the whole product because we built a CLI tool that can fully take part in an agent loop and experiencing that for the first time is really powerful. s30 00:02:44.480 --> 00:02:51.680 But you can't ship something like the wizard without shipping the stuff that makes the wizard kind of suspect. s31 00:02:52.800 --> 00:02:54.080 So let's take it apart. s32 00:02:54.080 --> 00:03:02.159 Uh let's look at the anatomy of the wizard because usually threat models fall right out of the anatomy of the agent. s33 00:03:02.159 --> 00:03:07.920 So the wizard is a similar shape to what I'm sure a lot of you are building if you're building agents. s34 00:03:07.920 --> 00:03:11.680 It's got models that we've picked for specific tasks. s35 00:03:11.680 --> 00:03:21.519 It's got prompts that steer it and it's got a set of tools that we've handed it to get the job done, but it also has some pieces that are really specific to us. s36 00:03:21.519 --> 00:03:25.760 It has a context engine fully built inhouse by my team. s37 00:03:25.760 --> 00:03:31.680 It's what allows the agent to do such a good job and give us similar results on every run. s38 00:03:31.680 --> 00:03:33.599 I like to call it the wizard's brain. s39 00:03:33.599 --> 00:03:36.239 Sometimes we call it marked down in a trench coat. s40 00:03:36.239 --> 00:03:39.120 Uh but it's our in-house context engine. s41 00:03:39.120 --> 00:03:44.799 There's also a terminal uh UI that we built ourselves using ink. s42 00:03:44.799 --> 00:03:56.159 And now there's a security scanner called the Warlock, which is what I built when I started snooping around and uncovering the horrors of shipping an agent to production. s43 00:03:56.480 --> 00:04:12.319 So, if you take the anatomy of any agent that can run commands, it's basically what I like to call the malware starter pack because it's almost exactly what you would hand a piece of malware if you were feeling generous or chaotic evil. s44 00:04:12.319 --> 00:04:16.639 Luckily, this is the worst case scenario or the nightmare fuel. s45 00:04:16.639 --> 00:04:18.799 And it's uh not a confession for me. s46 00:04:18.799 --> 00:04:28.240 It's a warning for all of you because if you want to ship an agent with hands, an agent that can run commands, you need to make sure that you do not build this. s47 00:04:29.360 --> 00:04:42.080 So the V0 of the wizard was born because Josh Snder, if you know him, on our growth team was watching cursor hallucinate postfog setups in quite possibly the worst ways. s48 00:04:42.080 --> 00:04:46.880 And he thought, what if we built an agent that could do a better job? s49 00:04:46.880 --> 00:05:01.600 So my team started building on top of it as we validated that it did a much better job than cursor hallucinating and we thought what if it could onboard anyone to post hog it doesn't matter what their framework is what their stack is s50 00:05:01.600 --> 00:05:16.960 instrument all their events without them having to touch a thing and then we dared to dream what if it was the default way to install Post hog we were dreaming of thousands of developers running this a week and yesterday we just hit 8,000 people running this a week. s51 00:05:16.960 --> 00:05:18.800 So, our dream came true. s52 00:05:18.800 --> 00:05:27.759 Um, but we back in those days when we were dreaming, we had to take our security posture under a microscope and look at what was going on. s53 00:05:27.759 --> 00:05:33.280 So, I took the ownership of that and I sat down and evaluated where we stood. s54 00:05:33.280 --> 00:05:42.080 And early on, I'm talking like a year to nine months ago, we had what I call layer zero because it quite literally is not security. s55 00:05:42.080 --> 00:05:49.440 it is just prompts that suggest what the agent should do um and steer it and prompts are not security. s56 00:05:49.440 --> 00:05:51.440 So I was concerned there. s57 00:05:51.440 --> 00:05:59.919 Uh layer one uh it was an allow list and when I started digging into this allow list I started to feel a little bit better because it was pretty tightly bounded. s58 00:05:59.919 --> 00:06:06.319 Uh but I still had a lot of concerns and I started panicking because of that context engine that I told you about. s59 00:06:06.319 --> 00:06:10.319 We are feeding a lot of context into the agent at runtime. s60 00:06:10.319 --> 00:06:20.720 So, I built this really hacky reax scanner to look for um threatshaped things going into the wizard and threat shaped things coming out of the wizard. s61 00:06:20.720 --> 00:06:24.160 And I will admit that it was extremely hacky. s62 00:06:24.160 --> 00:06:34.080 But I'm telling all of you this very candidly because we are all building things that feel extremely experimental and we are all building things super fast. s63 00:06:34.080 --> 00:06:39.039 And I know not all of us uh have security in our wheelhouse. s64 00:06:39.039 --> 00:06:43.919 Um, and some of us are just learning it on the fly like I was. s65 00:06:43.919 --> 00:06:49.600 But it's something we need to be thinking about when we are building things that have this shape. s66 00:06:50.960 --> 00:06:53.600 So that was our security posture. s67 00:06:53.600 --> 00:06:56.639 Uh, but I asked the question, are we cooked? s68 00:06:56.639 --> 00:07:04.080 Uh, good news, we were less cooked than I thought because when I mentioned earlier that allow list, it was pretty tightly bound. s69 00:07:04.080 --> 00:07:06.960 We had bash as deny by default. s70 00:07:06.960 --> 00:07:10.319 It could only install trusted packages that were vetted by us. s71 00:07:10.319 --> 00:07:14.880 Um, it could build, it could type check, it could lint, and pretty much nothing else. s72 00:07:14.880 --> 00:07:17.440 It couldn't run random shell commands. s73 00:07:17.440 --> 00:07:21.199 And it didn't have access to environment variables. s74 00:07:21.199 --> 00:07:28.880 Um, the agent couldn't read your uhv file because we blocked it outright and we were rooting secrets through a vault. s75 00:07:28.880 --> 00:07:35.680 So, I took a a breath of relief and realized we were in a better place than I thought. s76 00:07:35.680 --> 00:07:39.919 But I wanted to know where the cracks were because with security there's always cracks. s77 00:07:39.919 --> 00:07:42.240 So I did the thing that we should all be doing. s78 00:07:42.240 --> 00:07:50.720 I tapped our security team and I said, "Hey, can you audit this thing for me and find those cracks for me?" s79 00:07:50.720 --> 00:07:52.160 And they found some things. s80 00:07:52.160 --> 00:07:53.759 They found some gaps. s81 00:07:53.759 --> 00:07:59.360 And the interesting part wasn't the specific gaps or bugs they found themselves, but it was the shape of them. s82 00:07:59.360 --> 00:08:02.400 Because almost none of them were obviously evil. s83 00:08:02.400 --> 00:08:10.160 They were all two very innocent, well-intentioned things that were shaking hands and opening a hole. s84 00:08:10.240 --> 00:08:27.280 So, the lesson I learned was that attacks compose code review doesn't because us developers all look at diffs uh one at a time, but attackers look at the whole system and they look for those two things that shake hands and open a door. s85 00:08:27.280 --> 00:08:30.319 But there was one more thing that was keeping me up at night. s86 00:08:30.319 --> 00:08:38.399 And going back to that context engine, uh, I realized the scariest part of the agent we had built wasn't really a command in our case. s87 00:08:38.399 --> 00:08:44.000 It was the helpful looking stuff that we were feeding its brain. s88 00:08:44.640 --> 00:08:47.519 Oh, I think I went the wrong way. s89 00:08:47.519 --> 00:08:49.440 Yes, the context mill. s90 00:08:49.440 --> 00:08:57.680 Um, so this is our context engine, aka the wizard's brain, and it's how the wizard knows anything at all and why the wizard actually does a good job. s91 00:08:57.680 --> 00:08:59.360 It pulls from our docs. s92 00:08:59.360 --> 00:09:12.560 It has handwritten prompts that are gotus and lessons that we learned along the way and real working endto-end example apps that help the agent pattern match so that it can install Post Hog in a really great way for you. s93 00:09:12.560 --> 00:09:24.000 It package packages all of that into skill bundles that get shipped to the wizard over our MCP server and loaded straight into the agents context at runtime. s94 00:09:24.000 --> 00:09:25.519 So sit with that for a second. s95 00:09:25.519 --> 00:09:32.880 It's a machine whose whole job is to take content and inject it into an agent that can run commands. s96 00:09:32.880 --> 00:09:37.440 Now if you were an attacker, you might say, "Well, what if I just poison the content? s97 00:09:37.440 --> 00:09:42.480 not the user's codebase, not the agent itself, but the actual content. s98 00:09:42.480 --> 00:09:53.120 Say someone opens a pull request on one of our open source repos because at Post Hog we build everything in the open and they inject something in a markdown file s99 00:09:53.120 --> 00:10:04.880 or a seemingly harmless code comment and we have some sort of like LLM powered code review going through that and it says looks good to me and ignores it. s100 00:10:04.880 --> 00:10:15.440 We may have just shipped a prompt injection payload signed by us into an agent that is running on thousands of developers machines in a sandbox, but still. s101 00:10:15.440 --> 00:10:26.399 Um, so that was the threat that reshaped how I think about security and the wizard because the dangerous input for us really could come from our own supply chain. s102 00:10:26.399 --> 00:10:31.519 So what I ended up doing is I started scanning content at both ends of this pipe. s103 00:10:31.519 --> 00:10:38.000 Once when a skill gets built and released and again when the wizard actually uses it. s104 00:10:38.000 --> 00:10:45.680 My methodology is catch it at the source, assume the source failed and catch it again at the point of use. s105 00:10:46.720 --> 00:10:50.079 So now I get to introduce the warlock to you. s106 00:10:50.079 --> 00:10:53.440 Building the warlock was not necessarily damage control. s107 00:10:53.440 --> 00:11:02.079 Like I said, we had defense in other ways, but I built the Warlock because I didn't like telling people, well, this thing is like pretty locked down. s108 00:11:02.079 --> 00:11:03.279 That doesn't scale. s109 00:11:03.279 --> 00:11:05.440 That's not something you want to ship to production. s110 00:11:05.440 --> 00:11:19.920 That's not something that you want thousands of developers running every single day because when you ship something to that scale, you have way more surface, way more users, way more content flowing in as you expand the capability of the wizard. s111 00:11:19.920 --> 00:11:24.160 and we're probably fine just stops being good enough. s112 00:11:24.160 --> 00:11:31.120 So, I pulled that hacky little reax scanner that I threw in there, pulled it out of the wizard, and I made a standalone thing. s113 00:11:31.120 --> 00:11:36.399 I called it the warlock because everything wizard shape needs a bodyguard. s114 00:11:36.399 --> 00:11:39.120 And it does exactly one job. s115 00:11:39.120 --> 00:11:40.640 You hand it a string. s116 00:11:40.640 --> 00:11:42.720 It hands you back a list of findings. s117 00:11:42.720 --> 00:11:47.519 Each of those findings has a category, a severity, and a recommended action. s118 00:11:47.519 --> 00:11:49.519 And then it stops. s119 00:11:49.519 --> 00:11:55.040 I want you to focus on recommended here because the warlock detects it does not act. s120 00:11:55.040 --> 00:11:58.079 It'll tell you, hey, this looks like exfiltration. s121 00:11:58.079 --> 00:11:58.800 It's critical. s122 00:11:58.800 --> 00:12:00.160 I would block it. s123 00:12:00.160 --> 00:12:05.040 But what you actually do with that finding is completely up to you. s124 00:12:05.040 --> 00:12:10.639 Because detecting a problem is one job and deciding what to do about that problem is a totally different job. s125 00:12:10.639 --> 00:12:16.399 And the only thing that keeps all of this understandable is keeping those two things separate. s126 00:12:16.399 --> 00:12:28.320 So underneath the hood of the warlock, instead of my hand rolled reaxes, the rules run on Yara, which is the pattern that engine malware researchers have been using for like 15 plus years. s127 00:12:28.320 --> 00:12:29.680 It's fully deterministic. s128 00:12:29.680 --> 00:12:32.399 It's the same input, same output every single time. s129 00:12:32.399 --> 00:12:34.399 It's boring on purpose. s130 00:12:34.399 --> 00:12:38.480 And in security, boring is a feature. s131 00:12:39.519 --> 00:12:44.000 So what does the warlock actually catch in the wild today? s132 00:12:44.000 --> 00:12:49.440 um a bunch of different stuff, but two of these are an absolute like nuisance to my soul. s133 00:12:49.440 --> 00:12:53.519 Uh the first thing is actually not a rule-shaped thing. s134 00:12:53.519 --> 00:12:56.560 It was something the uh that the warlock flagged. s135 00:12:56.560 --> 00:13:04.079 That was actually a sub aent behavior that exposed a vulnerability to us um based off of what sub agents were doing. s136 00:13:04.079 --> 00:13:07.680 Uh so basically we were spinning up agents to do large tasks. s137 00:13:07.680 --> 00:13:17.200 They were spawning sub aents and those sub aents were trying to get around the guardrails that we had implemented in the wizard and they were trying to invent secrets. s138 00:13:17.200 --> 00:13:22.000 They were trying to pull secrets from quite literally anywhere in the codebase and we shut it down. s139 00:13:22.000 --> 00:13:28.079 We said no more sub agents and because of the warlock we caught that. s140 00:13:28.079 --> 00:13:29.680 And I'll empathize with the robot. s141 00:13:29.680 --> 00:13:33.920 The robot had a task to do and it was trying to optimize and please us. s142 00:13:33.920 --> 00:13:36.880 But we can't have that. s143 00:13:36.880 --> 00:13:40.160 And something else at Post Hog that really matters to us is PII. s144 00:13:40.160 --> 00:13:46.959 Uh agents genuinely do not care about uh exposing data unless you make explicit rules. s145 00:13:46.959 --> 00:13:52.320 Uh left alone, we watched it dump emails, phone numbers straight into events. s146 00:13:52.320 --> 00:13:58.160 And to an agent, that looks like a totally normal thing to capture. s147 00:13:58.320 --> 00:14:03.920 And luckily for prompt injection specifically, I'm going to knock on wood here. s148 00:14:03.920 --> 00:14:12.560 Uh we have basically never caught an actual malicious prompt injection in the wild, but we do catch a ton of false positives. s149 00:14:12.560 --> 00:14:18.000 Things like our demo login screens, copy on our example apps, things in our docs. s150 00:14:18.000 --> 00:14:27.440 And it's actually made me rethink how I build applications and how I write docs because I don't want to ship anything that looks threatshaped. s151 00:14:28.160 --> 00:14:37.120 But the false positives are honestly the perfect setup for the messiest, most interesting part of this whole thing. s152 00:14:37.440 --> 00:14:39.839 So this is the part that I wrestled with. s153 00:14:39.839 --> 00:14:43.920 I spent this whole talk preaching deterministic to all of you. s154 00:14:43.920 --> 00:14:50.880 And then I went and I added an LLM layer to help sort my false positives and silence some of the noise. s155 00:14:50.880 --> 00:14:53.519 And I call it triage. s156 00:14:53.600 --> 00:14:57.199 When I was building this triage layer, I had to make a choice. s157 00:14:57.199 --> 00:15:02.000 Should the layer be a bouncer or should the layer be an adviser? s158 00:15:02.000 --> 00:15:06.880 And the easiest choice probably could have been make the LLM the bouncer. s159 00:15:06.880 --> 00:15:14.160 Show it the command, ask it is this an attack block allow and just do whatever it says. s160 00:15:14.160 --> 00:15:27.839 And while that's tempting because it seems easier, I can't uh bet my security model on a coin flip because my model's having a bad day or something happened and it's acting different today than it did yesterday. s161 00:15:27.839 --> 00:15:33.120 So instead of the bouncer, I crafted the model to be the adviser. s162 00:15:33.120 --> 00:15:39.600 And this was the clean line that I found and a line that I'm still exploring, but I want to leave all of you with. s163 00:15:39.600 --> 00:15:44.399 Uh for us, detection and enforcement stay deterministic and mechanical. s164 00:15:44.399 --> 00:15:50.560 If a rule matches, the gate locks, the session ends, and there is no model anywhere on that path. s165 00:15:50.560 --> 00:15:55.199 The block happens before we even ask the LLM's opinion. s166 00:15:55.199 --> 00:15:59.199 The LLM only gets to weigh in afterwards if we have not blocked something. s167 00:15:59.199 --> 00:16:01.519 It's designed to remove noise. s168 00:16:01.519 --> 00:16:04.720 It is not designed to let things through. s169 00:16:04.720 --> 00:16:07.279 And if it fails clos and it fails closed. s170 00:16:07.279 --> 00:16:11.920 So if the model is having a bad day, all wizard runs are killed. s171 00:16:11.920 --> 00:16:15.199 Sorry, but we're just protecting you. s172 00:16:15.360 --> 00:16:18.880 Enforcement is the part that you bet the house on. s173 00:16:18.880 --> 00:16:24.000 So it has to be deterministic, but judgment is the part that adds nuance. s174 00:16:24.000 --> 00:16:29.440 So that's really the only place that you can put anything probabilistic in there. s175 00:16:30.880 --> 00:16:35.440 So, how do we ship real rules for agents? s176 00:16:35.440 --> 00:16:39.120 This is the anatomy of one of our warlock rules. s177 00:16:39.120 --> 00:16:42.000 And every warlock rule has four parts. s178 00:16:42.000 --> 00:16:43.759 Part one is the metadata. s179 00:16:43.759 --> 00:16:50.880 It's plain English description, uh, severity, category, action, uh, direction. s180 00:16:50.880 --> 00:16:52.560 Is this flowing into the agent? s181 00:16:52.560 --> 00:16:55.759 Is this something the agent is writing? s182 00:16:55.920 --> 00:17:00.160 Uh then we have the strings. s183 00:17:00.160 --> 00:17:03.680 So these are the actual patterns that you're looking for. s184 00:17:03.680 --> 00:17:06.240 And part three is the condition. s185 00:17:06.240 --> 00:17:11.039 So this is where the rule is actually allowed to fire. s186 00:17:11.120 --> 00:17:15.839 I'll walk through this example for you and we can pretend like we're writing it in our head. s187 00:17:15.839 --> 00:17:20.959 Prompt injection being like the classic ignore all previous instructions. s188 00:17:20.959 --> 00:17:32.000 Your first instinct here is probably to block uh the word ignore, but agents read code all day and ignore can show up in code comments or examples all the time. s189 00:17:32.000 --> 00:17:34.240 So you don't want to match the verb alone. s190 00:17:34.240 --> 00:17:39.039 You match the verb plus an instruction flavored noun. s191 00:17:39.039 --> 00:17:43.200 In the condition, you say fire if any of any of those patterns hit. s192 00:17:43.200 --> 00:17:48.000 And in the metadata, you determine is this critical? s193 00:17:48.000 --> 00:17:57.440 uh what the category is, what the action is, in this case block, and the direction in this case being input flowing into the agent. s194 00:17:57.440 --> 00:18:02.720 But to write good rules that reduce noise, you have to ship tests with them. s195 00:18:02.720 --> 00:18:06.799 So you have to write tests that say this are these are patterns that match. s196 00:18:06.799 --> 00:18:08.880 These are ones that should not. s197 00:18:08.880 --> 00:18:14.080 And that negative test is the first line of defense against false positives. s198 00:18:14.080 --> 00:18:25.280 But you also want to make sure when you're deciding the severity of that uh rule that you track real world impact, not how scary it looks. s199 00:18:25.280 --> 00:18:32.240 RM-rf is scary, but it's also how we all delete note modules like 40 times a day. s200 00:18:32.240 --> 00:18:48.160 You decide the real world impact for the agent that you're building because a security tool that crashes every time it tries to clean a build folder is a tool that gets turned off and one that catches absolutely nothing. s201 00:18:48.799 --> 00:18:51.760 So I'm proud to say this is our security posture now. s202 00:18:51.760 --> 00:18:55.679 I can finally come up here and say we have true defense and depth. s203 00:18:55.679 --> 00:19:00.880 Um all my learnings have assembled into this. s204 00:19:00.880 --> 00:19:04.960 Uh, it's still layered, but every layer is doing a job that it's good at. s205 00:19:04.960 --> 00:19:08.559 Now, we still have prompts, but we only use them for steering. s206 00:19:08.559 --> 00:19:10.559 Everything runs in a sandbox. s207 00:19:10.559 --> 00:19:12.559 We deny by default. s208 00:19:12.559 --> 00:19:15.600 We have a vault, so secrets never hit the model. s209 00:19:15.600 --> 00:19:21.760 We have the warlock to scan content coming in and to scan output being written by the agent. s210 00:19:21.760 --> 00:19:24.240 We also have triage to reduce the noise. s211 00:19:24.240 --> 00:19:29.600 And we have telemetry embedded in the entire process so that we see everything. s212 00:19:29.600 --> 00:19:32.160 None of these layers stands on its own. s213 00:19:32.160 --> 00:19:34.799 Not a single thing here is going to save you. s214 00:19:34.799 --> 00:19:37.840 But it's just boring, honest layers. s215 00:19:37.840 --> 00:19:42.880 Each of them doing uh one job that it's good at. s216 00:19:43.520 --> 00:19:48.160 So if you're building an agent with hands, this is the whole talk in three lines. s217 00:19:48.160 --> 00:19:53.039 One, if it isn't enforced uh deterministically, it is not enforced. s218 00:19:53.039 --> 00:19:55.520 Prompts are not security rules. s219 00:19:55.520 --> 00:19:58.080 Don't act like they are. s220 00:19:58.080 --> 00:20:03.280 Uh two, the dangerous input uh isn't just what your user types. s221 00:20:03.280 --> 00:20:05.840 It isn't just the commands that you allow it to run. s222 00:20:05.840 --> 00:20:10.240 It's everything flowing into the model, including the content that you write yourself. s223 00:20:10.240 --> 00:20:16.640 So scan your own supply chain at the source and when the agent invokes it. s224 00:20:16.640 --> 00:20:18.799 Three, attacks compose. s225 00:20:18.799 --> 00:20:20.240 Code review doesn't. s226 00:20:20.240 --> 00:20:27.039 Most of our gaps during our audit were two innocent things shaking hands and opening a door. s227 00:20:27.039 --> 00:20:31.520 The wizard, the warlock, and the context mill are all open source. s228 00:20:31.520 --> 00:20:33.280 So, come find me downstairs. s229 00:20:33.280 --> 00:20:42.480 I'm in the expo hall at our booth, and I'll show you around uh show you what we built, and I want to hear how you guys are securing your agents. s230 00:20:42.480 --> 00:20:44.720 Thank you.