Today we are launching Neo v1, out of beta and available for everyone: an autonomous security platform that runs continuous exploitability testing across your applications and APIs, maps your attack surface, reviews code and pull requests, red teams your internal network, and triages your vulnerability backlog, all inside one context layer purpose-built for your entire organization.
Neo is powered by hundreds of specialist agents that work in parallel, coordinated by a harness that plans each run, on infrastructure that runs offensive testing safely at this scale: every run executes in an isolated sandbox, in our managed cloud or inside your own network. Built against real enterprise environments, it automates the manual work between Jira, ServiceNow, Linear, Slack, Claude, your IDEs, and CI/CD, so the work moves without anyone carrying it between tools.
Back in 2025 we believed AI would accelerate the attacker side faster than the defender side: more exploitation, more noise, and enterprises forced to compete with attacks arriving at a speed they were never built for. That turned out to be more extreme than we assumed. Exploitation speed is at an all-time high. Neo is built to solve this.
How Neo works
Neo runs across your whole environment, from applications, APIs, repositories, and cloud accounts to the internal network, and plugs into the integrations your teams already work in, GitHub, Jira, ServiceNow, Linear, and Slack. It works continuously, chaining weaknesses across those systems into the full attack paths that cross them, with the ability to pivot and contextualize through specialized agents.
You choose how much to delegate. Run Neo task by task and you stay in the loop: you set the scope and watch the work. Or hand it the scope once and let it run on its own. Neo then works continuously in the background, testing every deploy, picking up new assets as they appear, and re-proving past fixes, with no one assigning the work.
Every run reads and writes a shared context: your assets and how they connect, the architecture and its threats, every past vulnerability, and the standard each team holds. Nothing starts from zero. Neo correlates attack paths across features instead of testing each in isolation, carries past vulnerabilities forward so they cannot quietly return, and keeps the same bar in front of every team as it works. When a run confirms an issue, you can open a pull request or a ticket from it, and once the fix is merged Neo replays the original exploit and keeps that check running on later deploys. Pentesting, red teaming, triage automation, regressions, and threat modeling all work from that same context, and the five below are the ones teams reach for most.
Paste a target URL, add credentials if the surface sits behind a login, and pick Fast or Thorough. Neo tests the running application for injection, access control, SSRF, and business logic flaws, and chains findings together. You can follow the run while it works. Each finding includes the payload, an execution trace, and steps to reproduce. Findings that cannot be reproduced are not included in the report.
“it was able to find things that normally or in the past were exclusive for manual pen tests”
Three learnings
1. Unified exploitable testing across the stack. Attackers do not care about the acronyms. They move through apps, APIs, cloud, and identity as one surface, and the testing has to match: prove what is exploitable across all of it, in one place, not another queue split by tool. And AI-driven attacks hill-climb: July's rogue OpenAI agent chained a zero-day in a package registry cache proxy into a sandbox escape, minted its own correctly-signed identity tokens, and went from a single worker pod to cluster-admin in under thirteen hours. Pointed findings are not enough: what counts is the full chain, proven and prioritized by where it leads.
2. Regression is the future. Every scanner and every pentest starts from zero, finds a vulnerability, and forgets it the moment it is fixed. Months later a deploy quietly brings the same class of bug back and you pay to find it again. Software engineering solved this with regression tests years ago: every bug fixed becomes a test that runs forever, and the code gets harder to break over time. Security is finally able to work the same way, because an AI system can understand an exploit well enough to re-prove it on every deploy rather than just remember its signature.
3. Humans are the designers. A new model tops CyberGym and half the industry declares the security engineer obsolete. We saw the opposite. AI is genuinely better at the task level, and fast at pattern matching at scale. It outworked whole toolchains this year. But deciding what matters and setting the standard an organization lives by is design work, and that gap is enormous. The CISO's job now is to empower the engineers who can do it. We built Neo for them.
The AI maturity curve in security
Across the teams we worked with these past months, a clear pattern emerged in how far an organization has actually come. It matters because your real risk is not set by the tools you own. It is set by the distance between where you sit on this curve and the speed the attackers are already moving at. Almost everyone is still on Level I, and that band is wider than it sounds: a single point tool sits there, but so does a sophisticated team running its own harness on frontier models, because both are hands-on, cover only what someone points them at, and reset on every run. Level II is where testing stops being something you run and becomes something that runs, continuous and verified against what is genuinely exploitable, though a fixed bug class can still return quietly on a later deploy. Level III is the one that accumulates instead of resetting, and few teams are there yet, because reaching it is less about the tooling than about the cross-team process to sustain it. Most organizations cannot say which of these they are on, so here is the map we started using.
| Level I: Assisted | Level II: Autonomous | Level III: Compounding | |
|---|---|---|---|
| How testing runs | Hands-on, by a few engineers | Continuous, runs itself | On every commit and deploy |
| Coverage | A handful of apps | The whole stack | The whole stack, plus every past fix |
| Reporting | Raw findings | Verified findings | Findings plus regression rules |
| The backlog | Keeps growing | Starts shrinking | Stays closed |
| Where developers sit | Reports after the fact | One shared queue | Inside the dev workflow |
| Human effort | High | Medium | Low |
| The constraint | Skills and tooling | Trust and integration | Regression discipline |
| How testing runs | Hands-on, by a few engineers |
|---|---|
| Coverage | A handful of apps |
| Reporting | Raw findings |
| The backlog | Keeps growing |
| Where developers sit | Reports after the fact |
| Human effort | High |
| The constraint | Skills and tooling |
| How testing runs | Continuous, runs itself |
|---|---|
| Coverage | The whole stack |
| Reporting | Verified findings |
| The backlog | Starts shrinking |
| Where developers sit | One shared queue |
| Human effort | Medium |
| The constraint | Trust and integration |
| How testing runs | On every commit and deploy |
|---|---|
| Coverage | The whole stack, plus every past fix |
| Reporting | Findings plus regression rules |
| The backlog | Stays closed |
| Where developers sit | Inside the dev workflow |
| Human effort | Low |
| The constraint | Regression discipline |
The traditional approach is the constraint
Most of what slows a team down at this point is not the tooling they have. It is a way of thinking they inherited. The clearest example is how teams use the models themselves. The mistake is treating the model like a scanner. That is the traditional approach, and it leaves most of the capability on the table. The right way is to build a harness and let the model operate like a real attacker: explore every path, chain findings together, and validate exploitability against the running environment, not just the code. All of it can run safely, in contained sandboxes with full logging. The exploitable attack paths that matter tend to show up only once the model is allowed to think and act that way.
The same correction applies to everything around the model. Security teams do not need another tool in the stack; they need the stack to collapse into something they can act on quickly. One unified finding database instead of a separate queue per vendor. Triage automated with LLMs, so people spend their attention on what is real rather than on sorting. Attack paths computed continuously, rather than drawn once in a quarterly review and stale by the time anyone reads them. None of that is exotic now. It is just a different starting assumption about what the work is.
What we did not expect is how long that correction takes to land. Across the enterprises we worked with this year, the pace has been slower than we assumed even after we adjusted for it, and the bottleneck is almost never the technology. It is process. Who owns an agent run. Which team accepts a finding. How scope gets approved, how results enter the existing queue, who signs off on acting automatically. Those questions are answered by committees and calendars, not by models, and they are what actually sets how fast an organization can move. Any team serious about closing the gap should start working on the process now, in parallel with the tooling, because that is the part that will take the longest.
Security benchmarks measure the wrong thing
Every buyer evaluating an AI security tool this year is quoting numbers that do not mean what they appear to mean. The standard benchmarks hand the model the bug description and grade a thin band of exploit writing. None of that looks like the work a security team actually does: reconnaissance, verification, triage, re-testing a fix, staying inside a scope someone agreed to.
Running our own evaluations changed what we thought was worth measuring. Pattern matching at scale is where these models are genuinely strong. Point one at a surface and it recognizes the shape of a bug faster and across more of the estate than a team can.
We are building a new benchmark for this and will open-source it, so every team can see what these models are actually good at and design the harness around it. Tarun presented the behavioral audit behind it at BSidesLV 2026, and the data is written up in Watching security agents work.
Availability, pricing, and limitations
We started ProjectDiscovery to make the best of security accessible to everyone, and Neo is designed with that same intent. Pay as you go is priced per seat each month and includes monthly credits with top-ups when a month runs long. Every capability is part of it, with nothing gated behind an add-on.
Enterprises get control over where it runs. The sandbox runs in our managed cloud by default, or self-hosted inside your own network over an encrypted tunnel. A dedicated VPC with static egress IPs supports firewall allowlisting and internal network auditing, and inference can run through your own model provider keys or open-weight models hosted by us. Enterprise plans add SSO and SAML provisioning, org-level spend controls, and volume discounts.