Continuous integration and delivery changed the tempo of software. Teams merge dozens of times a day, infrastructure is redefined on every commit, and a new build can reach production in minutes. Security testing never caught up with that tempo. It still lives in two modes that both fight the pipeline instead of moving with it.
The first mode is the scanner. Static analysis, dependency checks and dynamic scanners run on every build, and they are useful, but they mostly report potential issues. A SAST tool flags a pattern. A dependency scanner flags a known CVE in a package you may never call. The result is a long queue of findings that a human still has to triage, and alert fatigue quietly becomes the real vulnerability.
The second mode is the penetration test. A skilled human, or a firm, probes the application, chains weaknesses together and confirms what is actually exploitable. The output is trustworthy, but it is a snapshot. It happens once or twice a year, on a version of the system that has already changed by the time the report lands. In a pipeline that ships continuously, a point in time assessment is structurally behind.
So the pipeline has fast tooling that produces noise, and slow expertise that produces proof, and nothing that gives you both at the cadence of your merges. That gap is exactly where autonomous testing is arriving.
What Autonomous Testing Actually Means
Autonomous does not mean another scanner with a chatbot bolted on. It means agents that reason about a target the way a tester does. They enumerate, form a hypothesis, try to exploit it, and only report the finding once they have proven it with a working exploit and the raw evidence behind it. The unit of output is not a maybe. It is a demonstrated attack path.
That shift matters for CI/CD for two reasons. First, proof of exploitation collapses the triage queue. If a finding arrives with the exact request, the response and the resulting access, there is nothing to reproduce and nothing to argue about. You fix it or you accept it, and you do that in minutes rather than in a backlog. Second, agents chain. Real breaches are rarely one bug. They are a leaked secret that unlocks a cloud role, a server side request that reaches a metadata endpoint, a misconfigured registry that yields a token. A scanner sees each of these in isolation. An autonomous agent walks the chain, which is the only view that reflects how attackers actually operate.
Why it Fits the Pipeline and the Supply Chain
The modern attack surface is not just the app. It is the pipeline itself and everything the pipeline touches. Secrets committed to git history. Infrastructure as code that quietly grants a wildcard permission. A container image with a forgotten backdoor. A CI runner with credentials that reach production. These are supply chain problems, and they change on every commit, which is precisely the cadence that periodic testing cannot serve.
Autonomous testing that runs inside or alongside the pipeline can look at each of these on every meaningful change. Not a quarterly audit of the supply chain, but a continuous one, with the same proof based output. That is the promise, and it is a real one.
The Blocker Nobody Likes to Say Out Loud
There is a catch, and it is the reason many teams have kept AI security testing at arm’s length. To reason, most autonomous tools send your data to a model they do not control. Your internal IP addresses, your hostnames, sometimes your credentials and your source code travel to a cloud endpoint so the model can think about them.
For a lot of organizations that is simply not allowed. A bank, a hospital, a defense supplier or any operator of critical infrastructure cannot ship internal topology and secrets to a third party. Compliance forbids it. Client contracts forbid it. In some sectors the law forbids it. And even where it is technically permitted, sending production data to an external model is a risk many security teams are right to refuse. So the most capable new testing approach ends up locked out of the environments that need it most.
Why it Has to Stay Local
The way through is not to abandon autonomous testing. It is to make it run without your data ever leaving. Two ideas make that practical.
The first is running the reasoning model locally. Open weight models are now good enough to drive this kind of work on hardware a team can own, which means the intelligence lives inside your boundary instead of on someone else’s servers.
The second is tokenization at the boundary. Before anything reaches a model, real values are replaced with deterministic placeholders. An IP becomes a stable token, a hostname becomes another, and the model reasons over the structure without ever seeing the real thing. The real values are reinjected locally, for the moment a tool actually runs, then masked again on the way back. Done properly, this is compatible with air gapped setups and leaves no path for exfiltration.
Put together, local reasoning and boundary tokenization turn autonomous testing from something the security team has to veto into something they can actually deploy in the pipeline.
How to Evaluate it for Your Own Pipeline
If you are looking at this category, a few questions separate the real thing from the demo. Does every finding come with proof of exploitation, or just a severity score.? Where does target data go, and can the whole thing run without any external call? Are the results reproducible, so a developer can rerun the exact path? And is the methodology open enough to audit, because a black box making claims about your security is its own risk?
Autonomous security testing is going to become part of CI/CD the same way automated testing did. The teams that adopt it early will trade a quarterly snapshot for continuous, proof based coverage. But the version that lasts in the enterprise will be the one that keeps your data on your own machines. Autonomous is what makes it fast enough for the pipeline. Local is what makes it safe enough to allow.
Mehdi Boutayeb is co-founder of ASC-IT and works on Darkmoon, an open source autonomous penetration testing platform. He previously worked as an engineer at Airbus.