10 Nov 2026
The past few weeks have shown how quickly the security landscape is moving. In October, there were critical flaws in PHP found, with AI assistance, after going unnoticed for more than a decade. Organisations went as far as to take websites offline as a precaution. Days later, Node2Shell, a remote code execution flaw in Node.js, was added to the CISA exploit list. And at the start of November, a CVE rated at 9.8 for a Linux kernel vulnerability was found by an AI model, potentially giving an attacker remote root access.
That’s three foundational technologies, three critical flaws, all uncovered in two weeks. And these weren’t new vulnerabilities – each had been sat there for years and had been discovered from AI aided scanning. It’s a pattern we’ve described before: AI is shortening the time between weakness appearing and being exploited, surfacing problems that have been hidden for a long time. Testing a few times a year can no longer keep pace.
The good news is that the same capability works well for defenders – and it’s something Atomic have put into practice. Recently, we ran one of our agentic security audits on a legacy enterprise estate – a large, sprawling codebase with many entry points, many services and little documentation on how it all worked. In the few days it took to set everything up and run, our audit found four critical vulnerabilities that a recent penetration test had missed.
Below, we cover the brief – how our agents and engineers divide the work, the human oversight behind every finding, and what continuous assurance looks like from here.
The client’s estate was an entirely back-end microservices solution built in Java and deployed across AWS. As with many long running systems, the documentation was minimal and fragmented – it covered isolated sections of code, but gave little insight into deployment, release patterns, or how the services behaved.
WIth solutions this large, risks tend to sit in the areas nobody has reviewed for years: outdated architectural patterns, huge configuration files, and permissions that are left alone and ignored over time. Small pieces of work not done to good standards start to pile up and suddenly require more effort and time than just doing it properly.
There had been a recent penetration test on the system which uncovered one medium severity issue. The client now wanted a deeper view of the security of the system, with items that their own engineers could validate.
The audit is organised as a feedback loop, with each stage checking the work of the one before.
To start, we gather context for the agents to use. Connecting to services via Model Context Protocol (MCP) with read-only permissions, we pull together information from existing documentation, codebases, IaC (Infrastructure-as-Code) templates, previous penetration test results – and anything else relevant to the system.
An orchestrating agent will then manage the audit using this context – with what it has been supplied, it divides the endpoints in the solution up to a security subagent, all running in parallel where possible. These subagents have a much tighter scope, only concerned with the endpoint assigned and what security holes exist within.
Keeping each agent to a single endpoint matters, because language models lose focus and misread context when they work across a large surface. As each one finishes, they report their findings back to the orchestrator.
Once complete, we can then start the validation process. Whilst it’s likely the findings are mostly correct, language models are non-deterministic by default and are able to produce false positives. A separate validation agent works through each reported finding, traces the case through the code, and tests the attack vector in an isolated lower environment.
Findings that fail validation are returned to the orchestrator, which can start a new subagent to examine them again from a different angle. Findings that hold up proceed to report generation, where each is ranked by a severity × likelihood matrix, and paired with a remediation path down to the specific line of code or configuration block.
The audit runs multiple passes for the same reason validation exists: no single pass of a language model can be fully relied upon.
A Senior Engineer was watching every step of the way – they led the work, reviewed the quality of the output throughout, and redirected the agents when they drifted off task. Then once the validation step was complete, they reviewed the finding using their knowledge and context of the system built up over time. This is in line with our view on building trustworthy AI systems: the automation does the volume, and people remain accountable for the judgement.
The final review and remediation planning were carried out jointly with the client’s engineering and security teams, as a purple-team exercise rather than a handover.
The audit found four critical vulnerabilities that the penetration test had missed.
All were security configuration omissions, the quiet kind of misconfiguration that is easy to overlook in a large, ageing codebase but stands out when each endpoint is analysed in isolation. The audit also identified the original medium-severity issue, which gave us a direct point of comparison with the penetration test.
All four findings were upheld under formal review by the client’s internal security team. The client received a full report of every finding, ranked and prioritised by severity, with a clear remediation plan and timeline.
None of the techniques used were new – the difference was the time it took. A traditional penetration test of a solution this size could take weeks, and a thorough security review even longer. With parallel subagents, an automated validation feedback loop, and generated reporting we reduced that to days, without sacrificing accuracy or human oversight.
As we argued in a recent Insight, we can now move our security audits from semi-annual to a continuous part of the engineering cycle, which is now essential for any solution in the current landscape. The framework from this audit is reusable, and the process can now be automated as part of the development pipelines. The client can also re-audit the entire legacy estate as code changes occur.
Frontier AI tools have permanently expanded the scale of vulnerability detection. The organisations that secure their infrastructure best will not be those that simply find more bugs, but those that embed automated, human-led verification loops into their engineering cycle to close the gaps before they can be exploited.
