Hadrian Features: Atlas, Nova, AI Agents, and Limits Explained

Hadrian is an outside-in offensive security platform with two products. Atlas continuously discovers and validates exposures across an organization’s external attack surface, while Nova runs a scoped agentic penetration test on demand.

Atlas is the product for external asset visibility. Nova is the product for an audit-oriented pentest.

Hadrian does not publicly describe source-code scanning as part of either product. CodeAnt AI’s code-aware penetration testing connects runtime testing with source context when the assessment begins in a repository.

This guide covers Hadrian’s documented capabilities as of July 31, 2026.

TL;DR: Hadrian features at a glance

Choose Atlas for a current map of internet-facing exposure and Nova for a bounded external pentest. The combined suite feeds Atlas’s current attack-surface context into an on-demand Nova test.

If the test must start in code, use this guide to penetration-testing access models to select the required level of source and system access.

What features does Hadrian actually include?

Hadrian organizes its technology into phases called Sense, Plan and Attack. Discovery flows into contextual planning before controlled exploitation moves verified findings into remediation.

Atlas keeps this loop running against the external perimeter. Nova applies the attack logic to a customer-defined pentest.

This workflow is closer to continuous penetration testing than to a vulnerability scanner that reports a software version and stops. When comparing AI pentesting and traditional DAST, ask the product to prove and chain a weakness instead of treating the “AI” label as evidence.

Hadrian’s documented scope is narrower than a full application-security program. It covers internet-facing assets and exposure validation, not the continuous code security scanning performed on repositories and build pipelines.

1. Sense: continuous external asset discovery

Sense starts from customer-supplied domain names, according to Hadrian’s contract. Hadrian then uses passive data and active algorithms to expand the digital-asset map.

Atlas can discover assets beyond a static inventory, but it does not literally start without scope. Onboarding begins with domains the customer is authorized to test.

The documented discovery inputs include:

• passive monitoring of IPv4 space;

• DNS changes, WHOIS records, and certificate transparency logs;

• technical fingerprinting and non-technical signals such as logos and brand colors;

• direct AWS, Google Cloud, and Azure integrations;

• a predictive subdomain model called Subwiz; and

• context from edge devices, IoT systems, third-party SaaS, look-alike domains, and infostealer data.

Passive scans run hourly according to the Atlas FAQ, and an infrastructure change can trigger event-driven testing. Compare that cadence with the inventory and retest requirements in a continuous pentesting requirements checklist.

Ask Hadrian to name each trigger and measure the resulting detection latency. The response should also define when active testing begins.

Asset attribution and shadow IT

Hadrian says Sense builds an organization profile from 32 categories of technical and visual factors. Machine learning associates exposed assets with that profile instead of treating every discovered subdomain as owned.

The Asset Graph displays relationships between attributed assets. An analyst can then trace how an entry point may connect to a higher-value system.

Atlas is designed to find internet-facing systems that development or business teams created outside the central inventory. A cloud penetration testing checklist can reconcile those discoveries with the environments the business believes it operates.

Before granting a cloud connector access, map the expected paths with a cloud AI pentesting scope guide. Apply the resulting scope to each AWS, Azure and Google Cloud integration.

Hadrian also advertises look-alike-domain detection and dark-web monitoring. The pricing page lists infostealer credential-leak detection as a paid add-on, so confirm the exact dark-web coverage in the order form.

Discovery also needs a clean handoff into vulnerability validation. A fingerprint may suggest that an exposed component is affected, but a specific record such as CVE-2026-28292 in CodeAnt’s vulnerability database is context for investigation, not proof that the discovered instance is exploitable.

*Hadrian’s public platform tour shows an organization-level grade beside the number of assets in each security band. Source: Hadrian’s official public platform tour, captured July 31, 2026.*

2. Plan: context, blast radius, and risk prioritization

Plan divides findings into potential and verified risks. A potential risk may come from non-intrusive evidence such as version fingerprinting, while a verified risk has been validated through what Hadrian calls an ethical attack.

The two labels keep theoretical exposure separate from a reproduced exploit.

Hadrian’s priority model combines exploitability and business impact with available threat context. Asset relationships can raise a lower-severity weakness when its attack path reaches a critical system.

This approach does not rely on CVSS severity alone. Teams can add likelihood data from FIRST’s Exploit Prediction Scoring System and active-exploitation evidence from the CISA Known Exploited Vulnerabilities Catalog to their service-level rules.

Ask Hadrian to explain one asset’s complete score rather than showing only the final number. The explanation should connect asset attribution and the event that triggered testing to the weakness the agent validated.

It should then identify what the agent reached and explain the system’s business importance. The explanation must also state what new evidence would lower the priority.

This trace separates an attack path from a cluster of related alerts.

CodeAnt applies a similar graph question earlier in the software lifecycle through code-security attack paths, where repository findings can be connected before deployment.

3. Attack: agentic exploit validation

Attack is Hadrian’s active validation phase. The platform fingerprints the technology and selects tests relevant to that context before attempting to prove exploitability.

Hadrian’s example is that a WordPress-specific check should not run against an SAP system. A verified result includes the steps taken in a proof of concept, plus risk context and remediation guidance.

A reproduced exploit provides stronger evidence than an unauthenticated version match, but it still needs rules of engagement. NIST SP 800-115 recommends defining test scope and logistics before addressing data handling and incident response.

Before an automated test, use a pentest authorization letter to identify targets and allowed techniques. Reconcile those permissions with the penetration-test statement of work.

An external penetration testing methodology gives the proof-of-value a stable sequence. Begin with reconnaissance before moving into enumeration and controlled validation.

Capture the evidence produced during exploitation. Finish with cleanup and retesting.

Attack paths and transparent proof

Atlas says its agents chain weaknesses rather than test each exposure in isolation. Nova adds escalation within real asset context and visibility into the tests and evidence collected during that exploration.

The output should let a technical reviewer reproduce the finding without rerunning an uncontrolled exploit.

Ask for a sample involving a concrete application flaw such as broken object-level authorization. A reviewer should be able to compare the steps with the OWASP Web Security Testing Guide and a focused IDOR vulnerability guide.

The evidence should identify the first unauthorized action and the later step that created business impact. A path diagram without request data or scope context cannot support that review.

Remediation, sharing, and regression testing

Hadrian presents each finding with a human-readable explanation and step-by-step fix guidance. A risk lead field assigns ownership, while Secure Share exposes a specific risk without granting full platform access.

The risk timeline records discovery and assignment through resolution. After a finding is marked resolved, regression testing can check the fix.

Run one sample through the team’s penetration-test retest process. Create and assign the ticket, deploy the fix, then confirm that the retest changes both portal state and audit evidence.

4. Atlas: continuous exposure management

Atlas packages Hadrian’s complete three-phase workflow into a continuous external exposure-management service. The documented internet-facing workflow is agentless and cloud-delivered, with pricing based on total asset count.

Hadrian says deployment takes minutes and does not require software installation.

Atlas says it launches new tests when the attack surface changes instead of waiting for a weekly batch. This can reduce the interval between a deployment and its next security assessment.

Measure that trigger-to-evidence interval against a manual baseline when evaluating the benefits of AI pentesting.

If event-driven testing is the buying reason, compare Atlas with the criteria in this continuous pentesting tools evaluation. Record when an authorized asset change is discovered and when active validation begins.

Continue the same timeline through notification and ticket creation to confirmed closure.

Atlas retains its asset map and exposure history over time. Detected technologies and business labels can inform later validation.

When Atlas and Nova are purchased together, Hadrian says Atlas scopes Nova against the current attack surface. The customer does not have to rebuild the target list for each engagement.

For cloud-heavy estates, include one authorized route that crosses exposed services and permissions in the evaluation; cloud exploit chains are where a relationship graph should add more value than isolated severity scores.

5. Nova: on-demand agentic penetration testing

Nova is Hadrian’s bounded testing product. Under the May 6, 2026 EULA, one Pentest entitlement covers one external web application identified by a single target URL.

The customer selects the target and enters application context before setting exclusions and launching the test. Hadrian says most Nova tests complete within 24 to 48 hours depending on scope, with each finding reviewed by a human for accuracy and safety.

*Hadrian’s public tour presents a three-step Nova launch flow in which customers select a target and configure the test before setting its scan rate. The image was captured from Hadrian’s official public platform tour on July 31, 2026.*

The output includes proof of exploitability and reproduction steps, followed by risk context and remediation guidance. Nova also produces a PDF report mapped to SOC 2 and ISO 27001 as well as NIS2.

Framework mapping can organize evidence, but one pentest does not establish compliance. SOC 2 penetration-testing requirements depend on the organization’s controls and risk assessment as well as auditor expectations and test scope.

Apply the same constraint when reviewing an AI pentesting compliance report.

*Hadrian’s public tour shows a running Nova test with separate views for Overview, Recon and Risks plus category-level results. Source: Hadrian’s official public platform tour, captured July 31, 2026.*

As of July 31, 2026, Nova starts at €3,000 per test and Hadrian advertises bundles for repeated testing. Before buying a bundle, run the automated pentesting checklist against one representative application.

Start with authenticated and multi-tenant behavior, then cover APIs and cloud dependencies. The same test should exercise rate limits and exclusions before checking evidence depth and retest behavior.

Customers can set Nova’s rate limit within Hadrian’s documented thresholds, although the EULA warns that a lower rate may extend completion time. The EULA also treats customer-entered out-of-scope text as guidance rather than a warranted hard control.

Use these automated pentesting questions to document how the test stops and who reviews a high-impact action. Include the process used when a target becomes unavailable.

A broader pentesting vendor evaluation can compare those controls with tester independence and report ownership. It should also establish scope and retest terms.

6. Hadrian’s AI architecture

Hadrian uses “agentic AI” across the testing lifecycle. Sense agents predict and attribute assets, including hidden subdomains found by Subwiz, while the Plan phase decides what deserves deeper testing.

The AI Orchestrator selects context-relevant risk-finding mechanisms. Purpose-built Attack agents then attempt exploitation and chain techniques rather than relying on a single general chatbot.

Hadrian says its offensive-security specialists train the system and review Nova findings. A technical evaluation should still request the test policy and model-change controls, then document human escalation criteria and evidence retention.

The current Nova schedule says third-party foundation models may help plan and conduct tests as well as produce reports. Hadrian says customer inputs and Nova output do not train those third-party models, with foundation-model inference occurring in the European Union.

Hadrian controls methodology coverage and agent strategy. It also controls the safety architecture and report structure rather than exposing those choices to the customer.

The schedule does not identify the providers or model versions. It also leaves the evaluation set and action-level guardrails undisclosed.

Use the OWASP guidance for LLM applications to ask about prompt manipulation and excessive agency. The NIST AI Risk Management Framework provides a neutral structure for governance and change control.

Add the failure modes in this automated pentesting mistakes guide to the proof-of-value plan.

7. Integrations, API, and reporting

Hadrian calls the platform API-first. Its public directory includes engineering and IT service-management integrations alongside collaboration and monitoring tools.

Named connectors include Jira and ServiceNow for work management, plus Slack and Microsoft Teams for collaboration. The directory includes SentinelOne and Datadog for security monitoring.

Other listed systems include GLPI alongside Zendesk and HubSpot.

The public page contains duplicated copy under Slack and SentinelOne, so a logo does not establish connector behavior. Ask the seller to demonstrate which objects each integration reads and writes.

The demo should show whether findings create tickets and whether status or comments sync in both directions. Test any claimed asset import or alert delivery against the team’s DevSecOps automated-pentesting workflow.

Reporting differs by product. Atlas exposes the live portal and proof-of-concept logs alongside attack-chain descriptions and remediation instructions.

The portal also supports sharing and a risk timeline, while Nova adds the compliance-ready PDF. Test both views when evidence must serve engineers and executives, much as CodeAnt separates a consolidated code-security dashboard from a shareable pentest sample report.

What is good about Hadrian’s feature set?

The platform connects external asset discovery to exploit validation and remediation priority. Atlas fits an external inventory that changes faster than the security team can maintain it manually.

Nova gives that team a scoped, repeatable test without a conventional scheduling cycle.

Proof-of-concept steps and asset context explain the finding, while ownership and lifecycle tracking move it toward remediation. Retesting can then show whether the fix changed the result.

Use this guide to choosing an AI pentesting provider to examine that workflow’s coverage and validation. The same review should establish safety and auditability.

Hadrian limitations and buying checks

Hadrian’s documented scope has clear boundaries and a few claims that deserve verification:

1. The primary scope is external. Atlas maps internet-facing assets, and Nova tests an authorized external target. Do not assume internal-network, endpoint, Active Directory, repository, or build-pipeline coverage unless it is written into the order form.

2. Discovery still needs an authorized seed. The customer supplies the in-scope domain names and warrants authority over tested assets. This matters for shared hosting, SaaS tenants, subsidiaries, and acquired infrastructure.

3. Nova’s free-text exclusions are guidance. Hadrian’s EULA says it does not warrant strict compliance with customer-entered out-of-scope guidance. Put material exclusions into the signed rules of engagement and test the control before production use.

4. “Zero false positives” is a product claim, not an accuracy guarantee. The Atlas page says exposures are independently validated before notification. The EULA separately disclaims warranties of completeness, accuracy, availability, and timeliness. Evaluate a sample and retain your own triage process.

5. Some features cost extra. Atlas pricing is tied to total asset count, while M&A assessment and infostealer credential-leak detection are listed as add-ons. Nova is priced per test.

6. Public AI detail is limited. Hadrian explains agent roles and human training, but not the evaluation data, model versions, exploit guardrails, or change-management process a mature buyer may need.

7. Source-code controls are not in the published Hadrian scope. Hadrian describes external behavior and exposed components, not repository-native SAST, software composition analysis, secret scanning, infrastructure-as-code scanning, or a generated software bill of materials.

An external validator cannot replace controls that examine a change before deployment. A code scanner cannot discover a forgotten public subdomain either.

The SAST-versus-DAST distinction maps each control to the stage where it has evidence. A SAST and DAST tools comparison turns that lifecycle boundary into evaluation criteria.

Hadrian vs CodeAnt AI features

Hadrian and CodeAnt overlap in AI-assisted offensive testing, but their documented centers of gravity differ.

Choose Hadrian when continuous discovery of an external attack surface is the first requirement. Choose CodeAnt when the control must start with repository and pipeline security.

CodeAnt’s workflow examines proprietary code and dependencies before checking secrets and infrastructure configuration, then records the result in an SBOM. It is also the better fit when application testing needs source context.

A layered program can use EASM to find what the business exposed. Developer-native controls can reduce what gets exposed next.

Who should choose Hadrian?

Hadrian fits a security operations team that lacks confidence in a large or fast-changing internet-facing inventory. Atlas is the relevant product when that inventory needs continuous visibility and event-driven validation.

Nova fits a team that wants an on-demand external pentest with human-reviewed findings and a PDF report. Use a web-application AI pentest buying guide to test its authenticated coverage against the actual application.

Hadrian is a weaker standalone fit for internal-network or identity validation. Its published scope also does not cover source-code analysis and pull-request review.

Evaluate repository and build-pipeline coverage directly when it is the primary concern. The broader defensive and offensive security model helps keep one control from being treated as the entire program.