We aimed an autonomous AI attacker at OpenNHP. On the protected plane it found nothing.

A common assumption in offensive security is that a capable enough AI agent will eventually discover and exploit a vulnerable service. The OpenNHP project makes the opposite bet: if a service cannot be discovered, it cannot be attacked. Ben Chen from the OpenNHP team reached out with a simple, testable question, and we agreed to answer it in the open.

Can an autonomous AI pentester discover or attack a service protected by OpenNHP? We ran the experiment against the OpenNHP public demo, fully autonomously, non destructive, and we are publishing exactly what happened. This is the attacker side of a joint writeup. The OpenNHP team will follow with the defender side.

The test

We pointed Darkmoon, our GPL-3.0 autonomous AI penetration testing platform, at the public demo at opennhp.org/demo. Darkmoon runs a full engagement on its own: an LLM orchestrator drives specialist sub agents through recon, discovery, exploitation and reporting, and every finding ships with the exact command and raw response. We treated the deployment as a realistic target, with a single rule agreed with the OpenNHP team: no denial of service, nothing destructive that could affect a public demo.

The demo has two planes. The NHP-protected hosts (server2, ac2 and the access controller) sit behind OpenNHP Single Packet Authorization. The exposed demo components (the public auth plugin and its helper hosts) are reachable by design, so that a visitor can exercise the knock flow and understand how the protection works. Same autonomous attacker, same effort, pointed at both.

The protected plane: nothing to attack

On the three NHP-protected hosts, Darkmoon produced zero findings. Not zero exploitable findings, zero of anything. The autonomous attack chain never even started, because there was no reachable port to fingerprint. We confirmed it four independent ways, and all four timed out with no response:

• curl over HTTP and HTTPS to server2, ac2 and ac: every request timed out with exit code 28, no banner, no response.
• A targeted naabu port scan on 22, 80, 443 and 8080 against all three hosts: zero open ports found.
• Raw TCP connect probes via bash /dev/tcp: every attempt timed out, exit code 124.
• ICMP: no response.

There was nothing to enumerate, fingerprint or exploit. This is the central result, and it matches the OpenNHP design exactly: authentication before connection. You cannot attack what you cannot see, and to a scanner that does not hold a valid credential, the protected hosts are simply not there.

The exposed surface: an ordinary web target

On the parts of the demo that are intentionally public, Darkmoon behaved like any capable attacker and produced 51 findings. It is worth being precise about what this is: these are the deliberately exposed demo helper components, not the NHP protection itself. Every finding below exists only because a host is reachable. Move that same host behind NHP and the list goes to zero.

The four high severity findings are one condition seen from several angles: the exposed auth backend reflects any Origin back with Access-Control-Allow-Credentials set to true, and it returns the access token in a cross origin readable JSON body. In isolation that is a textbook cross origin credential exposure. The OpenNHP team has clarified that this permissive behavior on the demo auth component is intentional, a teaching feature meant to help visitors understand the protection model rather than a flaw in OpenNHP itself. We are reporting it because it is what an autonomous attacker surfaces against that reachable surface, and we think the honest framing is the useful one. The remaining findings are ordinary web hygiene: missing security headers, clickjacking, credentials passed in URL query strings, cookie scoping, TLS certificate naming. Each one has the exact command and raw response in the full report.

The pivotal detail: where the boundary really sits

The single most useful observation of the whole exercise is not a vulnerability at all, and we did not score it as one. The demo config.json publicly serves the agent private keys for both clusters, including the protected Cluster 2. This is clearly intentional for a public demo, because a visitor needs a working agent identity to perform the knock, and the file says so.

We call it out because it draws the boundary with precision. Without that agent key, the protected host cannot be discovered or attacked at all. With it, the knock succeeds and the host becomes an ordinary reachable service again. In other words, OpenNHP does not make a service unbreakable. It makes it unreachable until a valid credential is presented, and it relocates the entire attack surface onto the secrecy of the agent credential. For any real attacker who does not already hold that credential, and that is every real attacker, the zero on the protected plane is what stands.

Sword and shield

This is why the two projects fit together. Darkmoon is the sword: a fully autonomous AI attacker that assumes it can reach a target and reasons its way to proof of exploitation. OpenNHP is the shield: it removes the one thing every attack chain starts with, discoverability. Run the sword against the shield and the interesting result is not a clever exploit, it is silence. The attack never begins.

For an audience tired of vendor claims, we think a real autonomous attacker stopped cold at the discovery layer, with the exact commands to reproduce it, is a stronger and more shareable proof point than any benchmark. Darkmoon validates that the offensive AI is genuinely capable on a reachable target. OpenNHP validates that eliminating discoverability changes the attack model at the root.

Methodology and honesty

The run was fully autonomous and non destructive, aligned to NIST SP 800-115 and the OWASP testing guide, with MITRE ATT&CK mapping on the exposed findings. Everything is reproducible against the same public demo. In the spirit of an honest evaluation, we also excluded a candidate finding that did not survive manual verification rather than pad the count, and we flagged the intentionally public keys as an observation rather than a vulnerability. Whether the results validate the OpenNHP design or reveal something to improve, the point of the exercise is that the method is transparent.

Read the full report

The complete assessment, with every finding, the raw requests and responses, and the protected host confirmation, is available in full. Nothing is summarized away.

Credit and what is next

Thanks to Ben Chen and the OpenNHP team for proposing an open, objective test and for welcoming an independent evaluation by an autonomous AI pentester. You can read about the defensive design at opennhp.org. This post is the attacker side of a joint writeup. The OpenNHP team will publish the defender side next, referencing these results. Same result, two perspectives: the attack surface you remove is the one you never have to defend.