Twenty AI Agents. Zero Breaches.

Last week, we pointed PentAGI , an open-source autonomous penetration testing framework that deploys a coordinated swarm of specialist AI agents , at a live Azure VM running Helixar Nexus and Vigil Endpoint. The swarm ran for hours. It spawned agents for reconnaissance, enumeration, vulnerability analysis, and exploitation. It found real things. It documented them with professional rigour. And when it was done, the server was still standing: zero authentication bypass, zero data exfiltration, zero exploitation.

We are publishing the full results here, because honest security reporting requires more than announcing that nothing broke. It requires showing what was found, what held, and what we are fixing.

What PentAGI Is

PentAGI is not a scanner with a better dashboard. It is a multi-agent orchestration framework that deploys a structured team of specialised AI agents, each with distinct roles, working in parallel toward a shared objective. A top-level orchestrator decomposes the target into assessment phases, delegates to specialist agents (reconnaissance, service enumeration, vulnerability analysis, report writing), synthesises findings, and adapts the attack plan based on what each agent discovers.

It is, in effect, what a senior red team lead does when running a structured penetration assessment , translated into an autonomous pipeline that operates at machine speed, without fatigue, and without the incremental hesitations of human-paced testing.

The framework is open-source and available on GitHub. The vxcontrol team has built something genuinely impressive: the agent orchestration is sophisticated, the reporting output is professional-grade, and the test coverage across phases is comprehensive. We chose it for this exercise precisely because we wanted something that would press on the system the way a motivated attacker would , not spray signatures at it.

The Test Configuration

A freshly deployed system with no prior hardening history is a realistic scenario , and arguably a stress test of defaults. Attackers frequently target systems in the first hours after deployment, before operators have completed post-install hardening. This was deliberate.

What the Swarm Found

PentAGI's assessment ran across three primary phases: comprehensive port scanning and service discovery, web service enumeration and technology verification, and API documentation and client certificate discovery. Each phase produced a structured report. The findings were real.

These are correct findings. They should have been caught in our own pre-test audit. We are publishing them here and not burying them in an appendix because security posture improves when teams are honest about findings, not just about outcomes.

What the Swarm Could Not Do

Everything in the authenticated attack surface was inaccessible.

PentAGI tested default credentials against org_id=1 , the confirmed valid tenant , over the full duration of the assessment. The swarm attempted admin@helixar.com/admin, root@helixar.com/root, administrator@helixar.com/administrator, and contextually derived credentials including variations on the product name and deployment domain. None worked. Not because the credential list was exhausted, but because the passwords in use were not defaults, and the rate limiting made exhaustive testing structurally infeasible.

The Rate-Limiting Gauntlet

One of the clearest validation points from this test was how effectively rate limiting transformed the attack profile on the login endpoint.

Nexus implements IP-based rate limiting at approximately 10–12 failed authentication attempts, triggering a 60-second lockout enforced via a Retry-After header (with observed enforcement running to 90+ seconds in practice). In PentAGI's credential testing phase, this reduced 40+ attempted combinations to under 50 total attempts over the full session , with approximately 75% of elapsed time spent waiting out lockout periods.

The OWASP Authentication Testing Guide identifies credential brute-forcing as the most reliable attack path against fresh deployments where default credentials may be active. Rate limiting does not eliminate the risk , a patient attacker with a small high-confidence wordlist can still operate within the window , but it converts a one-hour automated sweep into a weeks-long effort. Against a system that does not use common defaults, that distinction is decisive.

“Rate limiting converted a one-hour sweep into a multi-week effort. Against a system without common defaults, that distinction is decisive.”

The mTLS Wall

Port 8444, hosting the Mantis Control Plane, was completely impenetrable.

The service requires mutual TLS authentication , a client certificate signed by the internal Mantis CA , before any TCP handshake completes a useful exchange. PentAGI correctly characterised the authentication model and tested every viable path to certificate acquisition: direct file path discovery across 21 paths, API endpoint testing across 9 endpoints, and JavaScript bundle analysis for embedded certificate data. All paths returned either the SPA index or HTTP 404. No certificates were exposed.

The SSL/TLS configuration on port 8444 is by any measure excellent: TLS 1.3-only enforcement (1.2 and below disabled), x25519 and secp256r1 key exchange with perfect forward secrecy on all cipher suites, and zero exposure to Heartbleed, POODLE, BEAST, or CRIME. The zero-trust model , no accessible public endpoints at all without the right transport-layer credentials , functioned exactly as designed.

The Security Headers Assessment

PentAGI performed a complete HTTP security header analysis against port 8443. The implementation was strong across all primary controls:

• HSTS: max-age=31536000; includeSubDomains , correctly enforced
• X-Frame-Options: DENY , clickjacking protection active
• X-Content-Type-Options: nosniff , MIME sniffing blocked
• Content Security Policy: restrictive implementation (JavaScript execution blocked from inline and untrusted sources)
• Cache-Control: no-cache, no-store, must-revalidate
• Referrer-Policy: strict-origin-when-cross-origin

The one noted exception: style-src includes 'unsafe-inline', permitting inline style injection. The JavaScript execution policy is strict, which limits XSS exploitability, but inline style injection can facilitate CSS injection attacks in specific contexts. This will be tightened in the next CSP revision.

Phase Two: Removing the Safety Net

The next test phase will run against an authenticated session, with several security controls deliberately removed.

We want to understand the authenticated attack surface in detail: how far a compromised session gets, what the IDOR risk profile looks like against the multi-tenant architecture, how the cross-organisation isolation holds under systematic testing, and whether the agent enrollment token path provides a viable route to Mantis Control Plane client certificate acquisition. We will also assess session security controls: CSRF, session fixation, and cookie attribute enforcement.

We will publish those results with the same level of detail as this report, including any exploitation that succeeds.

Why We Published the Full Report

The threat landscape in 2026 does not primarily consist of human red teamers running manual assessments. It consists of autonomous agents, available at commodity pricing via open-source frameworks like PentAGI, running at machine speed against infrastructure that was designed with human-paced threats in mind.

The CISA penetration testing guidance and NIST SP 800-115 both emphasise continuous assessment over point-in-time testing. Running PentAGI against our own infrastructure is one implementation of that principle , using the same category of tool that adversaries now have access to. Publishing the results is an extension of it: if the findings are real, they should be public.

Agentic red teaming changes the economics of security validation in the same way it changes the economics of attacking. Security teams that restrict their own testing to quarterly point-in-time assessments are now structurally behind adversaries who can run continuous automated pressure at marginal cost. The answer is not to slow down the attackers. It is to close the gap on the defenders.