Dan Guido - 200 Bugs/Week/Engineer: How We Rebuilt Trail of Bits Around AI | [un]prompted 2026

0:05 What's up? I hounded Dan for quite some time. How long How many times did I hound you? Like 10. Yeah, about about 10. 10 times on signal and on email and in public groups. Dan, are you coming to do a presentation at Trail of Bits? And he was like, "I don't know. I don't I'm not sure I have enough to say." But the thing is, I actually prompted him, well, they're very sensitive to this, to come and do a vendor pitch. What? I I know you're not doing a vendor pitch, it's fine. But I hounded him, "Come and talk about your company." And everybody [clears throat] was, "What are you doing, Gadi?" And then I went to the committee and I said I want to do this because what Dan has done I did not mean that pun, but it works. What Dan has done is essentially

0:50 create a company in this space that is not just so-called AI native, but is so ahead of its time, they literally emptied the Apple shops Apple stores down because they bought laptops that will be strong enough for the people stealing your content. And yet everybody started using I think load code right and skills, and they keep releasing their stuff in open source, and they invested millions in getting to the DARPA AI CC competition, and they have just made themselves the leaders in many cases of AI security just because he took a bet that the world is going to change. He was did not want to be left behind. He wanted to actually help make themselves relevant in the future because many of us will not be. And that transformation was so critical for me. I asked him, "Please come do a vendor pitch. Tell us your journey, your your

1:36 transformation of how you see the world working right now because there is nobody else out there right now that I know that can do this both technically with the right ethos and also be careful about not pitching us too hard." So with that, Dan, please. Thank you. Thank you, Gadi. Uh set this up over here. If I can see that. Woohoo. All right, great. Uh so again, thank you for the introduction. I am Dan Guido. I'm the CEO and co-founder of Trail of Bits. Uh and I'm here to talk about how we made Trail of Bits AI native so far. It's a journey. We're not there yet. Um so just to start out, uh this article came out about 2 weeks ago. There were

2:22 thousands of CEOs surveyed, and the result was that AI had no measurable impact on employment or productivity for them. Uh economists are starting to call this the Solo Paradox, which is a uh phrase that was coined in the '80s saying this this economist called uh Robert Solo that said, "You can see the computer age everywhere, but in the productivity statistics." Uh so the same thing is sort of happening with AI right now that a lot of people think they're using it, and they find out that it doesn't work, and the projects get dropped. Um so obviously, I don't think AI doesn't work. Uh I just think most companies are doing it wrong. Uh they give people tools without changing the system. So everyone gets a chat GPT license, and then leadership waits for the productivity numbers to move, and they don't. So that's the gap between AI-assisted and AI-native. One is a tool, the other

3:09 is an operating system. And the rest of this talk is about how I'm building the operating system at Trail of Bits. Uh so before I go on, um I want to define what we're even aiming for. So AI native gets thrown around a lot. It means a lot of different things to different people, and the way I think about it is that there are basically three levels. Most companies are at level one. AI-assisted is where everyone starts. You give people chat GPT, they draft emails, generate boilerplate, you know, the organization doesn't change, the workflows don't change. You just do the same things a little faster. Um AI-augmented is where things start to get interesting. That's where you start slowly, incrementally redesigning workflows. You're not just using AI as a tool, but you're putting agents in the loop. You're changing how work actually flows. And maybe the AI does the first pass on

3:54 your code review, and then the human does the second. Uh so the process is slightly different. And then finally, AI-native is where you get to a structural shift. This is where you've designed the organization from the ground up assuming AI is a co-participant in the work. It's not a tool, it's a teammate. And that's your knowledge management, your delivery model, your expertise, all of them have to be designed to be consumed and amplified by agents. So at Trail of Bits, what this means is that our security expertise should compound with code. Every engagement we do, all the skills, all the workflows we build make the next engagement faster. Every engineer operates with an arsenal of specialized agents built from our 14 years of audit knowledge. That's not we use AI, that's AI is on the team.

4:41 >> [snorts] >> Uh so candidly, I had a lot of trouble getting here. Uh when I first launched this initiative inside Trail of Bits, there was an incredible amount of pushback. Uh like you would not believe. I think that I had about 5% of the company with me, about 95 against. Um at least 50% were passively resisting. There were probably a good quarter that were actively resisting. Um I'm sure people thought about quitting. Just totally like cards on the table here. Um and this isn't really an uncommon issue. Whenever new technology comes around, people resist adopting it. And it can be the most senior, most expert people that resist the most. So I had to work through a couple of common psychological barriers that are well documented in research and build systems that worked within those psychological conditions to get to success.

5:28 The the core insight here is the problem's not the technology, it's the people. So um these are four uh psychological barriers that um that are I think key among all the other ones in getting people to adopt new technology inside of a company like Trail of Bits. First was self-enhancing bias. This is the tendency to perceive oneself in an overly favorable manner. Uh so you obviously want to maintain your own self-esteem, and this bias means that you take credit for your success, and you blame external factors on failures. Um now there are some funny interactions with this. Like in in some research by uh Paul Meehl and Robin Dawes, you can take the variables an expert says they use and build a crude linear model, and the model outperforms the expert.

6:13 Almost always. And it's not because the model is smarter, it's because it's consistent. Humans don't operate the same every day. Some of you are very hungover right now, and I'm sure you could agree with me on this. Um and this gets worse with seniority. The the more that you are an expert, the more that you believe that your intuition is what got you there. Uh there's also an identity threat. This really attacks the core of who we are that like I spent 20 years doing this. A machine can't can't do 20 years of experience and like get to be me. Um And this shows up in in things like uh there there was Stanford ran a cooking study. They they they used this device, some cooking system, and they advertised it two different ways. One way is it does the cooking for you. The other way is it helps you cook better. And uh it's the same device.

7:00 But for people who identify as cooks, they reject the device if it's advertised the first way. There's another dimension to this as well based on the the symbolism of what the activity represents. So for instance, if you had a tattoo robot, people do not want tattoo do do not want robots to give them tattoos because it's symbolic. There's a human craft to it. But they're fine with a tattoo removing one because that's an instrumental process. There's no symbolism there. So for us, security auditing is deeply symbolic work. And it's important to frame the AI as making you a more dangerous auditor, not something that does the audit. Uh there's also challenges in opacity. Uh so in this case, the subjective understanding of human judgment is high,

7:46 and AI judgment is low, but objectively, you actually understand neither. Um like when a doctor tries to communicate to you that you might have some medical condition or cancer or something, you might think you understand the words that are coming out of their mouth, but you absolutely do not. Um But the level of trust you have in the doctor is way higher than if a machine just prints out a receipt and says, "Here's what you got." So the way you typically fix this is uh you could modify the same AI to show you uh well, why is this not a benign uh skin condition? Uh and if you give a visual comparison to a benign mole, then trust starts to equalize. So we had to think about how to build this into our process as well. And then finally, humans have an intolerance for imperfection. Uh so again, well-known

8:33 academic study, participants watch an algorithm outperform a human forecaster. The algorithm is better, but the second that the algorithm makes a single error, humans switch back to preferring the human. Um the fix in this case is generally to let people modify the algorithm. If they have the perception of control, then they start to trust the process again. So what did we do? Uh so for the self-enhancing bias, uh we built a maturity matrix. Uh this was controversial internally. Nobody likes being told they're at level one, but that's the point. You can't argue with something that you're You can't argue that you're good enough when there's a visible ladder. And it also makes the conversation concrete instead of I don't think AI is useful. Uh it also creates social proof. When you see your peers escalating up the

9:19 ladder, the passive 50% of the company starts to move with them. Uh the identity threat was extremely difficult. You had to get people to accept skill-allowing automations and reject skill-replacing automations. Same tool, different framing. So we never really asked anyone Well, we not never really. We didn't ever ask anyone to stop being a security expert, but we gave them a different way to express that identity. So the skills repos that I hope you all are familiar with are the clearest example of that. When we have a senior consultant on the team write a constant time analysis skill, they're not being replaced, they're becoming permanent inside the company. And that means their expertise is encoded and reusable by the whole team. That's an identity upgrade, not a

10:05 threat. So, the maturity matrix reinforces this. Level three isn't who uses AI the most, it's who invents new ways and builds new tools. So, the identity shifts from I don't need AI to I'm the one who makes AI dangerous. Uh we also did hackathons instead of mandates. I never forced anyone to adopt these tools, but we created a space where people could experiment on their own terms. Uh oh, I'm not doing that. There we go. >> [snorts] >> Um for the intolerance for imperfection, uh everyone if if if somebody's first experience with AI is bad, you've lost them for months. Uh so, one error and people just abandon the system. So, we invested a lot in ways to reduce the ways that AI can fail embarrassingly. We curated a marketplace so that people weren't getting random

10:51 plugins. We created sandboxing tools so Claude Code didn't accidentally delete your work. Uh we put guardrails and foot gun reduction systems in place so that there were a lot less of like, you know, AI did something stupid stories circulating in Slack. Uh for opacity, we clearly articulated what tools were allowed and which ones were not and under what conditions. We described those conditions and why we why we decided to uh adopt those risk levels. And then we made adoption fast and visible. So, this really underpins everything else. If the setup takes an hour and the first result is mediocre, then you've confirmed everyone's priors. So, we have copy-pastable configurations, one command setup. We have a standardized tool chain, and the

11:36 first experience is fast and good. And then I think finally, I matter to this more than most people think. Uh the passive 50% of the company is going to watch what leadership actually does, not what it says. So, if I'm using these tools visibly every single day, it signals that it's not a fad. We're actually all in. So, that's the problem and the approach. Uh here's the actual system we built. So, five parts, each one addresses barriers we just talked about. I'm going to walk through each of these in detail with screenshots and examples, uh but this is the overview. You can think of it like a checklist, uh but you need all five for it to compound. And um importantly, this isn't like some strategy deck that like I'm presenting here. This is everything that we built

12:22 ourselves, and most of it has been open source so that all of you can use it right now. Uh this is what I use for a 140-person company doing real client work. So, let's go through each one. Uh first one, super boring. We had to standardize. Uh we got everybody on Claude Code, and we treat it like any other enterprise tool. We have supported configs, no good defaults, and a clear path to this is how we do it here. If you skip this step, you can't build anything else because you end up with 40 different workflows and zero leverage on it. So, for better or for worse, we settled on Claude Code. I think it was for better. Uh next thing, we wrote an AI handbook, and this wasn't to teach people how to prompt, but it was to remove ambiguity. What tools are approved and what isn't, especially for sensitive data where we

13:08 have a lot of that. So, we explicitly call things out like where a tool can't be used on client code, where meeting recorders are disallowed depending on engagement type, where we want people to use a specific alternative. And that stops the endless Slack debates. It gives project managers and engineers a shared answer, and it makes client conversations consistent. When we have highly sensitive clients ask us questions about, "Hey, what are you using on the code that you I I've given you?" I can give them a clear answer that everybody knows. So, once you have a policy, you can push harder on adoption. Then, I will I will post this on Twitter because no one can read it. Uh but we built an AI maturity matrix. Um this makes AI a first-class professional

13:54 capability. It's just the same as you can use Git, or you can write tests, or you can audit C. It's not a vibe, it's a ladder. So, there are clear levels, there are expectations for getting one for for uh escalating, uh and there are consequences for staying stuck. It starts at level zero, and if you're stuck at level zero and you're not engaged in this process, then there may be a transition out of the company. Um and this is how you avoid two different failure modes. You don't want leadership to like wish adoption into existence, and you don't want the organization splitting into AI people versus everybody else. This is a whole company need. Everybody needs to be on board. So, this turns it into a normal part of performance, growth, resource allocation,

14:40 uh and and bonuses. Um now, the fun part. So, hackathons. Hackathons became a management system for us. We run short, focused sprints, two to three days with a specific objective, one objective. And that's how we keep pace when the ecosystem changes every single week. So, here's one of the kickoffs for one of them. Uh we did this one or actually, well, these are both These are the last two, I think. Uh which one? I think the one on the right is um our autonomy-focused one. Uh the most important thing is that we put a constraint on the hackathon. You had to run Claude Code in bypass permissions mode. This was to break the barrier on people's hesitance to giving them full control over the tools and

15:26 build systems that allow it to work under those constraints. So, that was intentional. It forces everyone to learn how to use sandboxing, guardrails, and how to structure their work so that the agents can succeed on their own. Um other design choices that we made, we focus on public repositories so that we can move fast and show real outcomes. Um we measured success on activity. I wanted people to put in the reps. So, we're talking about issues fixed and filed, PRs reviewed and merged, branches created and deleted. Uh we're not so worried about like the meaning behind all that code. I just want activities that they put in the reps. Uh and then we had people work in pairs. Every change gets reviewed by a buddy. Uh so, even with the move fast

16:11 uh sort of sprint-style work, we had some quality control built in. So, the hackathons create motion, but the motion doesn't compound unless you capture it. And that's where we started collecting these artifacts as skills. Uh so, a skill, most of you know, is a reusable structured workflow, uh usually with examples, constraints, and a way to verify the output. So, we maintained three separate skills repos, uh two of which you all have access to. Uh we have an internal one that has a lot of company-specific workflows and a lot of our most sensitive vulnerability research-related skills. But we also have an external one so that the broader community can validate and improve on the work that we're doing. Uh the third one is we have a curated

16:57 marketplace, which I think I'm talking about next. Yeah. So, for a firm like ours, um I appreciate the external validation. It keeps us honest, and it forces us to write things that other people can actually use. That's a core value of Trail of Bits. I don't want to just release a Black Hat talk that gets me a Wired article or whatever and disappear the next day. We measure success based on uh downloads of a specific tool or stars of a specific tool. I want continued usage. Um and uh and enhancement. So, then we have another problem. You know, you tell people to go use skills and plugins, and they go use skills and plugins, and they get a whole bunch of random stuff that's like AI slop filled with emojis and uh you know, steals your cryptocurrency.

17:43 Um so, we created a curated marketplace. This is just standard, you know, enterprise stuff, right? We made a known good place for third-party skills. You want a third-party skill? There's a command built into the curated marketplace that goes out and grabs it from somewhere else, filters it, and then puts it into ours. Uh so, if you want adoption, you need a safe supply chain. Basic enterprise thinking. Uh then we made the defaults dead simple. So, after we went through a couple of rounds of this, we started to get to uh really like known good um Trail of Bits style Claude Code installation. So, we published a repository that has our recommended Claude Code configuration. I want to eliminate tribal knowledge. We want to have specifics around this is how we do

18:28 Claude Code at Trail of Bits. So, we put known good settings, a known good Claude.md, and anything else that we want to standardize for how people use it. We also included some usage instructions there. Um now, this is freely available, but there is a whole separate section that describes how to use it for bug hunting that we're we're we're keeping internal. So, if you're wondering where that part is, uh that's why it's missing. So, it's very developer-focused. Um then, the real constraint. Obviously, the more control that you give to these agents, you're going to want a sandbox. Uh so, we give people choices. We don't just tell people to do one thing or enforce the Claude built-in sandbox, which is quite good. Um but we give people choices, and we invested in building some of our own. We built a dev container option. We made um

19:16 uh another one that uh automatically interacts with Digital Ocean to create single-use virtual machines in the cloud. And then we documented the native Mac OS sandboxing option. So, the point wasn't that everybody uses the same sandbox, the point is that everyone has a safe sandbox to use. You know, we have a variety of different things going under one roof at Trail of Bits. We have engineering engagements, research engagements, audits. We have non-technical staff, operations staff, and they all need different solutions. I can't mandate one. Uh then, as you give people more autonomy, these agents start to go haywire in different ways. They start to pull in third-party dependencies that have security issues. So, the one step that we took that I think is is extraordinarily effective

20:02 besides the ignore scripts in NPM was implement a mandatory developer mandatory package cool down policy. So, nobody installs packages that are less than 7 days old for any package manager across the company. We have it enforced with MDM. Um that's the I think the easiest way to reduce risk and make the safe path the default path. There's more that we've done here, but this is something that I'm preparing to release. We're going to start open sourcing our entire Jamf configuration stack for how we secure some of these agents with MDM. Uh and then finally, once you have the policies, the guardrails, the sandboxes, the skills, you can connect agents to real tools. Uh so, one example that we've already wrapped inside of an MCP server is

20:47 Slither. Um and if you don't care about Slither, which is a static analyzer for Ethereum smart contracts, the point is that MCP turns your internal tools into something that agents can use reliably and that your org can govern. Uh so, this is a another way that we can inject policy into how these tools get used. Um so, now the results. So, um you know, you've seen some of our open source work, but internally I can share that we have 94 separate plugins accumulating 201 skills with 84 specialized agents and 400 reference files encoding all of our domain expertise. And that's the compounding effect. So, every single engagement, every auditor, every experiment adds to that arsenal. And what's important is the breadth,

21:34 right? We're not just talking about an auditing toolkit. I have skills for writing sales proposals, tracking project hours, onboarding new hires, prepping conference blog posts. Uh we have 20 plus plugin plugins targeting specific vulnerability classes. Um but uh you know, each the the important thing is each package um each one packages expertise that used to live in somebody's head and it turns into something that every auditor on the team can now invoke. On the delivery side, uh we have certain clients where the codebase and the scope allow it. We've gone from finding 15 bugs a week to finding 200 bugs per week. And that's not a faster human. That's an auditor running a fleet of specialized engagements that do targeted analysis across the codebase in parallel and then

22:21 validate the results. So, across most of our engagements at Trail of Bits, the number that we're about at is that 20% of all the bugs we report to our clients were initially discovered by AI. Um on the business side, we also have our sales team averaging about $8 million in revenue per representative, which is about double what the industry averages for uh for sales for sales consulting. Um so, yeah. So, AI doesn't just help our engineers, it also helps with proposal drafting, competitive positioning, conference prep, lead enrichment. Uh same system, same repositories, same compounding effect. Uh and this is maybe, you know, a year into building the system seriously.

23:06 Claude Code came out what was about a year ago. Um the models get better every month. The skills grow every week. And a year from now these numbers are going to look very different. Uh yeah. So, let me close with some of the essential starter pack. This is the minimum viable AI native org design. Uh this is what we've done so far and it's changed how fast we can ship and how quickly we adapt. If you want to copy this, you have to copy the system, not the tools. Uh we do have some open questions. You know, there's obviously some things we're still working on. Um obviously uh Gadi made an allusion to a conversation I had with him about private inference. Um you know, we don't want to always send our queries to the cloud. Sometimes we want to do them on a machine that we

23:52 control. But uh these local models, they're good, but they're not amazing. There's definitely this big model smell where you can tell the difference between, you know, Opus 46 and a Haiku 46 uh no matter what day it is. Um so, right now we're investigating a couple of paths here and I'm sort of reticent to spend money on a local server because a lot of the private inference systems are getting really good. Uh we've been evaluating tinfoil.sh, but there's a huge variety of other private inference servers that are now available where I can confidentially run my queries in somebody else's cloud. So, these are where um you know, we're we're doing some research to figure out the right solution for us. The prompt injection problem, obviously not solved. We have a real blunt instrument for solving it today, which

24:38 is for certain clients we just deny access to the web. Uh and for a lot of our internal tools, we don't allow them access to external resources. Um so, things we're playing with here are agent native shells. We're looking at things like the No No Shell, Agent.sh that are going to wrap the agent execution in something that can be protected with uh kernel level system calls instead of, you know, discretionary guidance thrown into a claw.md. Uh and then something else we don't have solved yet is policy enforcement and continuous learning. So, we push a lot of settings via MDM, but what do we get back? Because there's a huge amount of data that's accumulated on each person's device about how they're actually using AI and how they're doing their job that I would love to be able to collect and synthesize and use to enhance our

25:24 process. And we don't have a solution there yet either, but it's something we will probably soon. Uh you can take a look at things from Trail of Bits like our We Audit Visual Studio Code extension that might offer a solution there. Um you know, longer term, we also need some sort of policy architecture. You can see Stripe with their Minions paper. They have one giant MCP server that all their agents call into and that they can use to enforce policy and that might be a good long-term answer. And then finally, the business is really shifting. I think consulting today may not last that long. Uh we're looking at billing by hours today, but in a future where everybody has an arsenal of agents and some people can outperform others by 200x, I think you have to start billing by expertise and by results. So, the nature

26:11 of how Trail of Bits offers our services to the world is probably going to change in the next 6 to 12 months as well. And again, no answers there yet because we're still on this journey just like everyone else. Uh so, I wanted to offer a few links to these references. These are all the tools that I talked about during this talk. I also want to mention that yesterday, as a gift to you all, I open sourced 10 additional plugins. Uh we have one for checking false positives for bugs that your Claude might find and you want to give it the ability to check. Uh we have a fun one called Let Fate Decide that teaches your agent how to deal tarot cards um as well as a whole bunch of others that are up on my Twitter and that are up in the skills repo right now. Uh and then I I would also be remiss to mention we have a bunch of jobs open and I would love it for someone to work with

26:57 me to carry this exact process forward. If you want to help me continue to instrument Trail of Bits and make us uh further along in this journey, uh please contact me. Thanks. Thanks, Dan. All right, we got to we'll try to get back on track here. So, I'll take time for two questions. Do we have two questions in the audience? processing all of the things to do with an org. We've got one over here, Andrew. I'll run it. Thank you. Hey, thanks so much. That was amazing. I'm wondering if an additional um uh hesitance that you've seen with your employees in adopting AI is also around uh eventually like being replaced or like mass joblessness stuff like that. Yeah, so I think Trail of Bits is in a

27:43 really good spot because we're kind of um I think the term is obelisk-shaped. You know, consulting agencies, they usually have a really large base of junior employees. And uh I think as people get more enhanced by AI, it's a lot of the most senior people that benefit the most. So, I'm going to sidestep that question and just say that everybody at Trail of Bits is perfectly positioned to take advantage of this because we only have senior level and up people. Um I yeah. I'll leave it there. >> [laughter] >> Sibilance. Okay, thanks, Dan. Um I have a question in terms of like the blessed list that you're creating for

28:30 the team. How do you think about like rug pulling attacks or, you know, we've seen with some folks who are like, you know, releasing sort of safe and secure and then updating it with like some type of, you know, something malicious. As you think about, you know, these are our blessed lists, are you checking them every day or how do you think about Blessed list of what? Of >> Like your MCPs or skills that you've got or, you know, any of those. Oh, yeah. I mean, well, we're importing all of them into an allow list. Like the only plugins that you're allowed to use for Trail of Bits are the verified ones that are in our curated repo. Uh so, we don't want you to install random skills from other places. If it gets updated, it gets updated through us. And we have a bunch of automated systems that help us perform those updates with speed. So, obviously like if something comes out on Twitter, you want to use it that minute. Uh but we've enabled the organization to

29:18 uh perform those, you know, internal update steps on its own. So, our our curated skills repo is open source. Everybody at Trail of Bits has write access to it. Uh requires pull request reviews and it includes um commands that Claude Code can understand to go out and grab those resources. So, you can just give it a tweet and say, "Hey, I want this." And it goes, pulls it in, tags somebody for review, and then 5 minutes later you've got it on your machine. Very cool. Cool. Yep. Awesome. Thank you so much. >> Thank you so much.