One of the first questions we get about Atomic is how we allow autonomous testing without giving an AI unrestricted access to a customer’s environment.
The answer is the Edgescan Harness.
Atomic can decide what it wants to do next. It can form hypotheses, investigate findings and adapt its approach during an assessment.
What it can’t do is execute actions directly.
Atomic proposes actions. The Harness decides whether those actions are allowed.
That separation is deliberate and sits at the centre of the architecture.
During an assessment, Atomic is provided with the context it needs to reason about the target, including the assessment objective, relevant intelligence already held within the Edgescan platform, results of testing completed so far, and potentially client-uploaded information.
Atomic operates as multiple specialist agent teams, each focused on a particular area of testing. The lead agent within each team is given the relevant context and directs its specialist agents to investigate particular areas or follow up on what they discover.
Sensitive execution context, including credentials and the authorised scope, is controlled by the Harness rather than being handed directly to the agents.
This means Atomic isn’t following a fixed script. Each team can adapt its testing based on what it finds, but anything it wants to execute still has to go through the Harness.
Before anything is executed, however, the request goes through the Harness.
Every time.
What happens when Atomic wants to act?
Take a simple example.
Atomic is testing an authenticated application and discovers a new endpoint. Something in the response looks interesting, so one of the agents decides it’s worth investigating.
That’s exactly what we want an autonomous system to do. It has found something we didn’t necessarily know was there and is adapting its testing based on what it has learned.
But what if that endpoint turns out to be outside the agreed scope of the assessment?
Atomic doesn’t get to make that call.
Its proposed action goes to the Harness, which checks the target against the authorised scope. If it isn’t allowed, the request is refused.
The same principle applies to the tools Atomic wants to use and how it wants to use them. Tools have to be explicitly registered and permitted. Security-sensitive parameters and mandatory safety settings are controlled by the Harness, not by the AI. Actions that aren’t permitted as part of the assessment are blocked before execution.
And if the Harness can’t determine that an action is permitted, it doesn’t run it.
We deliberately fail closed.
Why not just tell the AI what it’s allowed to do?
We do. But there’s a big difference between giving a model instructions and enforcing a control.
The ability of AI to reason is exactly what makes Atomic interesting. We want it to look at the result of one test, work out what that might mean and decide what it should investigate next.
But that reasoning is probabilistic.
I don’t want the security boundary of a customer assessment to be probabilistic.
That’s why the Harness is architecturally separate from the AI model. The controls are deterministic and enforced outside it.
An agent can decide that an action is a great idea. It can propose it. But if the Harness says no, it doesn’t happen.
The model provides the intelligence. The Harness provides the control.
Once an action is approved, it is executed through Edgescan-controlled platform capabilities. The result comes back to Atomic, which can reason about what it has learned and decide what to try next.
That new action goes back through exactly the same process.
Autonomous, but accountable
Putting every action through the Harness gives us something else that’s increasingly important with autonomous testing: a record of what actually happened.
We can see what Atomic proposed, what was permitted or refused, what was executed and what evidence came back.
That’s important because I think the conversation around autonomous security testing is going to change quite quickly.
Today, much of the focus is understandably on capability: “Can AI actually find vulnerabilities? Can it adapt? Can it perform meaningful security testing?”
Increasingly, I think enterprise security teams will also be asking: “Can I safely allow this system to test my environment, and can you show me exactly what it did?”
Those questions are every bit as important.
Atomic should be able to investigate, adapt and follow interesting attack paths. That’s the point.
It just shouldn’t be able to decide where the boundaries are.
That’s the job of the Harness.
Contact us and see how Edgescan runs autonomous testing inside enforced controls.
Learn how the Edgescan Harness controls out AI-Native autonomous testing.
