The phrase has been attached to at least three different products in the last eighteen months, and they are not the same thing.
The first is a vulnerability scanner with a language model writing the report. The scanning is the same scanning it always was, pattern matching against a database of known issues, and the model turns the output into readable prose. Useful. Not a penetration test.
The second is a system that reasons about an application and produces a list of things it believes are wrong. This is a real advance on the first. It can spot classes of issue that signature matching misses, because it is reading logic rather than looking for known strings. But it stops at the belief. It tells you what it thinks is exploitable.
The third attempts the exploitation and reports what worked.
Only the third is doing what a penetration tester does, and the distinction is not academic. It changes what the output is worth.
Why the third category is different
A penetration test is not a list of weaknesses. It is a demonstration.
When one of our engineers finishes an engagement, the report does not say that an endpoint appears to lack an authorisation check. It says that using a standard user account, we retrieved the records of every other user on the platform, and here is the request we sent and the data that came back. The difference is between a hypothesis and a fact, and everything downstream depends on which one you have.
Consider what a security team does with each. Given a hypothesis, someone has to investigate it: read the code, work out whether the theoretical path is reachable in the deployed configuration, decide whether the mitigating control two layers up already handles it. That investigation takes hours and it happens for every finding on the list, including the ones that turn out to be nothing.
Given the fact, the work is remediation. The question has already been answered.
This is why a severity score without a proof of exploitation is worth so much less than it appears. Severity describes the impact if the issue is real and reachable. Both of those conditions are assumptions until something confirms them. A list of forty high severity findings where nobody has established reachability is not a prioritised worklist. It is forty investigations, and the prioritisation is guesswork.
The number that means nothing
Run a dependency audit on any mature application and you will get a large number. Twelve hundred vulnerabilities. Three thousand. The number is technically accurate and almost entirely useless, and every engineering team already knows this, which is why the output gets ignored.
The reason it is useless is worth stating precisely. Most of those vulnerabilities are in code paths the application never executes. Some are in development dependencies that never reach production. Others are real but sit behind a control that makes them unreachable. A handful are genuinely exploitable, and nothing in the output distinguishes them from the rest.
The useful question was never how many vulnerabilities exist. It is which ones an attacker can actually chain into access, and that question can only be answered by trying.
What has actually changed
Everything above was true before machine learning entered the picture. Skilled offensive engineers have always worked this way. The reason autonomous testing matters is not that it introduced a better methodology. It is that the existing methodology was rate limited by the number of engineers available and the number of days they had.
A traditional engagement has a fixed window and an agreed scope. Two weeks, these applications, this environment. Within that window a good tester covers a great deal of ground. Outside it, nothing is being tested, and the application continues to change.
That is the actual gap. Not quality, availability. A report is accurate on the day it is written and progressively less accurate every day afterwards, and the rate of decay is set by how often you deploy. For a team shipping weekly, an annual test describes a product that no longer exists.
Autonomous testing addresses that specific problem: running the same class of work continuously instead of in scheduled windows. It is worth being precise about the claim, because the more common framing, that these tools find things humans miss, is the less interesting one.
The question that decides everything
If you are evaluating a tool in this category, there is one capability that determines whether any of the rest matters.
Can it authenticate?
Testing a real application means holding a session across a long sequence of requests, refreshing tokens before they expire, following identity provider redirects, and in many environments authenticating against a cloud provider to reach the services behind the application. Every one of those is a place where an automated system can quietly fail.
Quietly is the important word. A tool that cannot authenticate does not stop and report that it could not authenticate. It runs. It produces findings, severities and a coverage percentage. What it has actually tested is the unauthenticated portion of the application: the login page, the public routes, the marketing pages. The authenticated application, where the business logic lives and where the findings that matter are, was never reached.
The output looks like a penetration test in every respect except the one that counts.
So the question to put to any vendor, including us, is not what the tool found. It is what the tool could reach before it started looking. Ask to see the scope of what was actually accessed. Ask how the session was maintained. If the answer is vague, the findings are describing a small corner of your application.
Two further questions worth asking, in the same spirit. Does the tool show its reasoning, or does a finding arrive with no account of how it was reached. And are the requests logged, so you can verify the exploit yourself rather than taking the report on trust. A finding you cannot independently reproduce is a finding you have to believe.
Where the line currently sits
Autonomous testing covers more ground, more often, than a scheduled engagement can. What it does not yet fully replicate is a narrowing set of judgements: which of two low severity findings chains into something serious, when a plausible looking result is not real, where a target's business logic makes an unusual path worth pursuing.
That set is smaller than it was a year ago and it continues to shrink. But it is a frontier that moves rather than a settled division of labour, and a vendor telling you the frontier is already behind them is selling something.
Where Deus Rex sits
Deus Rex is built to run the third kind of testing: find, confirm by exploitation, and deliver the fix as a pull request you can review, merge or close.
The answer to the question that decides everything is no. There are no platform limitations, no tech stack requirements, no carve-outs for complexity. If your application runs, Deus Rex can reach it. Web, iOS and Android today, with further surfaces to follow, and no assumptions made about what sits underneath.
The reason we can say that is the reason the company exists. Deus Rex is built by Cyrex, which has spent twelve years running offensive engagements against some of the hardest software being shipped, for studios and enterprises where a live failure is a serious event. Every attack path the platform knows how to walk, one of our engineers walked first. The methodology was not designed for a product. It was the methodology, and the platform runs it continuously.
deusrex.ai
Written by
Tim De Wachter
CTO Deus Rex
