Build or Buy AI Pentesting: 5 Tests Before You Go to Production

00:05 Hi, everyone. My name is Mark Kuhr, co-founder and CTO here at Synack. There's been a lot of talk lately about whether organizations can build their own AI pentesters, and we're here to talk about that today. And not only build them, but then how do they know that it's ready to go to production and actually perform penetration testing for their business? So that's what we're going to dig into today. At a high level, this is what we're going to cover. We're going to talk through the easy prototype. Anybody can get started with a proof of concept,

00:35 and you can vibe that up and really be off to the races running what looks like a pentest. Then we'll talk about what it looks like to take that to production. And then we'll talk a bit about the agent harness and some readiness tests that you can take on your own implementation and see if you're actually ready to make the leap into production testing. Lastly, we'll talk a bit about build versus buy. This is the conversation that everybody's having. Do you build it yourself and cut the license costs, or do you buy it from a vendor that specializes in that?

01:07 We're going to openly talk about the tension in that decision. Next slide. I'd love to talk through the deceptively easy PoC. Why can't we just connect the frontier model to our security tools? Why can't we just come up with a great prompt and say, “Hey, Opus, go ahead and hack this target and run a thorough pentest”? The reality is, you can. You can take a frontier model. It's very good at reasoning about vulnerabilities. It's good at coming up with the checklist for penetration tests

01:39 across various compliance regimes. And you can wire it up to some open-source scanners or even probably your commercial scanners. It's a fairly straightforward approach with the tools available. Vibe coding has made this really easy for anyone, but it's not necessarily a replacement for what you have from vendors today. Keep in mind, you're creating this tool that you're going to have to maintain yourself. You're creating this tool that will

02:09 seemingly find vulnerabilities, but may not find the things that you're missing. The false negatives—the things you're missing in the discovery process—are more concerning than anything else. So you can do this demo. I think we're going to see that a lot of people will attempt this, and I think it's great to talk through the details here. When you look at lab performance, the first thing you're going to do with a PoC is take it out for a spin on some labs. There are a lot of challenges out on the internet, on GitHub. You can take your harness and your model and say, “Hey,

02:41 point it at a couple of labs,” and you're going to get great results. But at this point in time, a lot of these harnesses are really good at solving labs, and a lot of the models have been trained on the labs. So you're going to get great results in the labs and any of the CTF challenges. That's because all that training information has been included in the latest versions of the models. The real gap is taking it to production, where you've got to authenticate to apps and follow custom business logic in the application.

03:11 Similar to a complex quality assurance suite, you're going to need to walk through all the business process flows. I think that a lot of the home-built solutions, the PoCs you've built, will struggle with that type of thing. There's also a lot of attack surface across your business that you're going to need to send in scope updates constantly. This gap is a real one, where you're starting to see that it's very difficult to scale this up into a real testing program. That's not uncommon with PoCs.

03:42 Take them out for a spin in the lab, and they work great. When you go to production, they run into scale issues and limitations, and then you end up with a large backlog of work to add a bunch of features to that. But really, the model is only one component. Where you're going to spend a lot of your time is on the harness. The agent harness is where you're going to spend a lot of development hours figuring out how you do the task planning, how you do the scheduling, how you do tool selection—what tool to run in certain contexts.

04:15 How do you keep track of context? If you're running the same scan twice in a row, are you just repeating everything completely, or are you actually looking at deltas across the runs? And then, if you have failures, if you have guardrail issues, these are things that are going to weigh on your effectiveness in finding vulnerabilities. The bigger one that I see companies struggle with of late is exploit verification. If you have false positives coming out of the detection, how do you know they're false positives?

04:45 Some human has to look at that and verify. Then you end up in this improvement loop where you're trying to go back and fix your harness so it doesn't reintroduce the same false positives in the future. The summary really is that the model is swappable. The harness is where you're going to spend most of your time. This is where a lot of teams start to realize this becomes an engineering project, not just a security team project where we're building our own agentic copilot. It becomes a very interesting backlog of features,

05:16 and it never ends. There's always going to be more stuff to test. Model routing and replacement is another interesting problem. As each model changes, you're going to have to go in and test for the variances between the models and the behaviors that may have changed in the different model versions. That could require prompt adjustments. That could require tool call adjustments. There are a lot of things that fan out in terms of the backlog of work when you start to maintain your own agent harness.

05:46 That said, I think this is a worthy experiment for a lot of people to go into and start to understand how the technology works. We have a couple of things to look at for production readiness. If you're at that stage where you're like, “Hey, this is working pretty well in the lab. I want to go see if I can get it out there in a real testing program,” reliability is usually the first thing people hit. You've got to take a look at whether you can orchestrate the test and recover when things fail. You're going to run into reachability issues,

06:18 credential issues, and runtime issues from the harness itself. Do you have enough tokens and token throughput? Do you have enough memory and compute on the machine? This becomes a bit of an infrastructure battle, but it's also complicated by the various ins and outs of your harness. And then verification: can we prove it's exploitable? The vulnerabilities that it produces a lot of times will look valid. However, you have to add verification to ensure that they're actually

06:48 valid, not to mention the false negatives. What are we missing? Having a couple of good human pentests alongside will help you verify that your agent, model, and harness combination is working really well. Lastly, safety: can it operate without going out of bounds? There may be aspects of your application, if you're doing an agentic web pentest, that you don't want to touch. You don't want to do a checkout flow in production. You don't want to do certain types of attacks. Those types of guardrails have to be tested

07:18 and implemented, and really, it's figuring out the way to intercept the calls before they get executed. I think a lot of people forget this, and it gets caught later when a problem happens. We want to catch it ahead of that, right? Lastly, adaptability and operability. Really, can you govern it? Can you absorb changes? Can you keep up with the pace of change? This is a space that has a lot of changes happening any given week, and it's almost a full-time job to keep track of them all. You've got to ask yourself,

07:48 if you're going to take this project on, do you want to be the one monitoring for those changes and on the hook for making the code changes necessary, or do you want to outsource that to a vendor? It's really a build versus buy decision at the end of the day. Some teams will be equipped to build it, and you can probably get pretty far with a PoC. But buying it gives you a repeatable, production-ready harness, independent verification from the vendor, and, more importantly, you can push the risk of any runtime issues to the vendor.

08:18 So you're not sitting there at 2 a.m. trying to fix your harness because you've got a pentest to do tomorrow. All of this is coming together in what probably looks like a hybrid model for some companies, where they have some stuff running internally and then pair that with an external provider solution. This allows you to really understand what your needs are for agentic testing. But buying a solution that is robust and meets all the needs is just totally turnkey. It allows you to push the risk to the vendor,

08:49 reduce your internal workloads, and get attestation on any kind of results that are coming out of those pentests. For a vendor like Synack, we're really focused on comparing agentic pentests to human performance. Part of that is to discover where the false negatives are. Part of that is to also fill the gaps in what the agents are capable of finding. But production readiness in practice looks like point-in-time tests, for sure, but moving towards a continuous

09:21 testing program over time. Continuous testing is the only way to keep up with all of the changes that are happening in your attack surface. And it's the only way to keep up with the adversary that's constantly innovating and mixing in new approaches for attacks. Evaluating what you need in production is really a decision for your business. But at the end of the day, you've got to move towards a continuous model and ask yourself if you want to be maintaining that stack or you want to outsource that to a vendor.

09:52 You have to evaluate the whole system, not just the model. The model can demonstrate capability, but the harness makes it repeatable. The harness makes it reliable and trustworthy. These things together will form a system that you can turn into a continuous testing pipeline for your business across all assets, whether host infrastructure or applications. We have to start moving to this model because adversaries are constantly innovating. They're looking for ways in at all times, and the software under the hood is changing more rapidly than

10:24 it ever has before with the introduction of these coding agents as well. We're in a unique space and time where we're all trying to keep up with the pace of change. Point-in-time testing is not going to meet the need for protection against these agentic-enabled adversaries. I would encourage you to run the five tests against your own plan. It's up to you to decide what's right for your business, of course. But take a look at whether you're ready to keep pace with the reliability and verification, safety, and operational support of this whole program.

10:56 I think it's great to get out there and use the tech, understand it, and learn it. That's how you're going to stay fresh and relevant in the space. But when it comes time to do a continuous pentest program at high scale, you might want to consider outsourcing that to somebody that's specialized in it, like Synack. Thank you for your time today.

No lines match that search.