Building security teams that combine AI speed with human judgment

A testing agent loses its session halfway through an application. Several checks never run. The report comes back clean. Did the app pass, or did the test fail?

 

That’s the question you have to answer before you put AI into a security testing program. Agents accelerate discovery and cover more of the environment. But the team still needs to know what ran, what broke and what the evidence actually proves. More testing activity doesn’t equal a reliable result.

 

Build the team around that. Give agents work they can execute inside clear boundaries. Give researchers the evidence and access to chase the hard paths. Put one person on the hook for closing the gaps. The handoff between them is part of the system, and it has to be engineered like one.

 

Start with what the agent tested

Agents do more than enumerate assets and match known patterns now. They form hypotheses, test them and use the results to decide where to go next. That expands what a testing team can attempt.

 

The environment pushes back. Credentials expire. Applications change state. An endpoint answers differently depending on the role. An agent that can’t hold that context will repeat a failed test or walk away from a path worth exploring.

 

The testing lead defines scope, permitted actions and stopping conditions before anything runs. The system records what happened inside those boundaries. Access failed? That’s a coverage gap, and it shows up as one. Incomplete evidence? The result stays inconclusive. Don’t let either collapse into "no findings."

 

That gives researchers a starting point. They investigate the missing coverage or the uncertain result instead of reverse-engineering a summary that says everything looked fine.

 

Follow the path an attacker would take

Attackers want a sequence that reaches an objective. That sequence crosses roles, workflows and systems. You can pass every individual check and still leave the path wide open.

 

Take a purchasing application. One employee creates a supplier. A second approves it. The first employee then changes the supplier’s bank details, and nothing asks for a second approval. Every step is allowed by the access controls. Chained together, they redirect an approved payment.

 

A test that only asks whether an unauthorised user can approve a supplier misses this entirely. The right question is what can change after approval and whether the original decision still holds.

 

An agent can help discover and test that sequence. A researcher brings the business context, challenges what the control was supposed to do and works out the exact conditions to abuse it. Don’t lock either one into a fixed script.

 

Researchers also need room to start their own investigations. If the job becomes reviewing the agent’s queue, the program inherits the agent’s blind spots. Protect time for business-logic testing, attack-path exploration and the questions the automation hasn’t asked yet.

 

Make evidence the handoff

A finding needs enough evidence for someone else to reproduce it. Affected asset. Account and role used. Application state. Actions taken. Observed result. For a multi-step attack, preserve the sequence. Drop one prerequisite and an engineer burns hours trying to reproduce it under the wrong conditions.

 

Evidence decides the next step. Automated checks validate repeatable outcomes where the method is reliable. Researchers take the uncertainty, the complex interactions and anything that needs judgment about operational impact. Every actionable finding gets validated. Raw agent output doesn’t become a manual review ticket by default.

 

The testing lead owns the routing rules. Researchers establish technical impact. Application owners fix. Accountable business owners decide whether to accept what’s left. Retest checks whether the fix actually closes the path.

 

Feed confirmed and rejected results back into evaluation. If an agent misreads the same response every week, fix the behavior and test the change. A researcher dismissing the same false positive every Monday is wasted capacity.

 

Measure where the system breaks

Finding counts tell you almost nothing. A high confirmation rate can hide weak coverage. An agent that only reports easy vulnerabilities looks accurate while missing the paths that matter.

 

Track five things:

1. Confirmation rate. Proportion of reviewed candidates that are confirmed, with consistent definitions and rejection reasons
2. Time from discovery to reproducible evidence. If that interval keeps growing, validation can’t keep up.
3. Coverage. Completed tests, failed tests and exclusions, all three.
4. Controlled evaluations against known vulnerabilities, including multi-step paths. These expose limits. They don’t prove production is clean.
5. Time to remediation and successful retest. A patch can kill one symptom and leave another route to the same outcome. Test the path again. 

Each metric points at a different fix. Missing credentials need better access. Repeated false positives need better validation. Proven findings sitting in a queue need remediation capacity. Those are three different failure modes. Adding more agents doesn’t solve any of them.

 

Keep responsibility attached to the result

AI makes broader, more frequent testing practical. Researchers bring independent investigation, context and judgment. Both need a system that preserves evidence and makes gaps visible.

 

For a business leader, the questions are simple. What did we test? What could an attacker actually do? What did we fix? What’s still open, and who owns it?

 

A team that can answer those has something real. It can explain the exposure, show its work and make the next call. That’s the bar I’d hold an AI-assisted security testing program to.

 

---

 

Mark Kuhr is Co-founder and CTO at Synack

 

Main image courtesy of iStockPhoto.com and tadamichi