We built the testing we wanted to buy
Security teams ship faster than they can test. That gap is not a discipline problem or a budget problem; it is a structural one, and everyone working in application security has felt it.
AIPTx is our attempt at closing it: penetration testing that runs on your release cadence, and that proves what it finds rather than flagging it.
The report always described a system that had already changed
AIPTx is built by IntelligenceX, which is why our engineering writing lives on the IntelligenceX blog. Same team, same work, two names.
Penetration testing is scheduled work applied to something that does not hold still. A test is scoped in one sprint, run in the next and reported in the one after that, and by the time the findings land, the application they describe has moved on. Nobody in that chain is doing their job badly. The cadence simply does not match the thing it is measuring.
The second problem is what the report contains when it does arrive. Most of a tester's time goes to breadth (enumerating surface, then confirming the same handful of issue classes that recur across every engagement) and comparatively little goes to the depth only a person can supply. That split is the wrong way round, and the half being crowded out is the half worth paying for.
So AIPTx tests continuously rather than periodically, and validates by exploitation rather than by pattern match. When it reports something, it has already demonstrated the finding is reachable and real, because a finding nobody has proven is just another row in a queue somebody has to triage.
Four positions you can argue with
Finding something is the easy half
The industry solved detection volume a decade ago. What it did not solve is the question that follows every finding: is this real, is it reachable, and does it matter here. That question is why we validate by exploitation rather than reporting matches.
A score you cannot decompose is a score you cannot defend
We publish our risk weightings because a security team should be able to argue with a remediation order on specifics rather than distrusting it in general.
Automation should give people back the interesting work
Not replace them. Breadth-first testing is the part that scales; architectural reasoning and novel abuse cases are the part that should not have to.
Say what the product does not do
We publish the limits of autonomous testing on our own product pages. It costs a sentence, and it is the fastest way to establish that everything else was written honestly.
Who is behind it
We are a small team building one focused product. If you become a customer, you will meet most of us.
We are based in London
The position we would want a vendor to take on ours
You would be giving us details of your systems, the vulnerabilities in them, and evidence that those vulnerabilities work. We take the same position on that data that we would want a vendor to take on ours.
Come and look at it
The fastest way to judge whether this is any good is to point it at something.