Long-Running Security Agents Need a Boundary, Not a Bigger Prompt

A security agent that runs for ten minutes is a tool. A security agent that keeps working across an application, a network, a codebase, and a vulnerability backlog is an operational system.

That distinction matters more than the word autonomous.

On September 28, ProjectDiscovery said that Neo was free to try. The announcement described Neo as a system for long security tasks across applications, networks, code, and vulnerability backlogs, with shared agent context. The current Neo pricing page describes the same product as a platform for autonomous testing, discovery, vulnerability triage, code review, red teaming, and cloud security.

The interesting part is not that another security product added an agent. It is that the product is making duration and continuity part of the security workflow. Once an agent can keep context across a long task, the primary security question changes from “what did the model say?” to “what could this run reach, and what can we prove it did?”

A long task creates a larger trust boundary

A short model call has a relatively small failure surface. It can still produce a dangerous recommendation, but the call normally ends. The operator reviews the output and decides whether to act.

A long-running security task has more state. It may retain the target, findings, credentials, tool results, and intermediate decisions across many steps. It may move from discovery to validation, then from validation to a ticket or pull request. The model is only one part of that loop.

The rest of the loop includes:

• target selection and scope
• credentials and authenticated sessions
• network access and egress
• tool invocation
• state retained between steps
• evidence captured for review
• actions that change code, tickets, or infrastructure

If those pieces are not explicit, “shared context” can quietly become shared authority.

ProjectDiscovery’s public product material shows that the company understands this distinction. Its current plan comparison lists scope guardrails, sandboxing, agent logs, model controls, and deployment options including dedicated VPCs and private network access. The security and privacy documentation says agent actions are logged and describes scoped runs, while the project documentation describes boundaries for runs.

Those are not decorative enterprise features. They are the controls that turn a persistent agent from an opaque loop into an auditable one.

The product shape is a control-plane decision

Neo’s current plans make the architecture visible:

• Free: The public page lists limited one-time usage, standard models, one seat, and US-hosted operation with zero data retention. That is useful for trying workflows, but it is not a substitute for a team control plane.
• Pay as you go: The page lists a weekly allowance, frontier models, up to five seats, and a more powerful sandbox. Continuity and collaboration make identity and scope more important.
• Enterprise: The page lists custom usage, on-premises or dedicated VPC deployment, private network access, SSO, and SAML. Those options move the trust boundary closer to the operator’s network and identity system.

This is not a recommendation. It is a map of where the responsibility moves.

Free access lowers the cost of experimentation. It does not remove the need to define targets. A more powerful sandbox reduces some execution risk. It does not answer whether the agent is allowed to test production. A VPC can narrow network exposure. It does not prove that the run stayed inside the approved scope.

The boundary has to be represented in the control loop, not merely promised in the interface.

Shared context is useful, and dangerous

Security work is unusually dependent on continuity. A finding from reconnaissance can change the next test. A code review can explain an API behavior that a black-box scan could not. A vulnerability backlog can supply historical evidence that prevents the agent from reopening a closed issue.

Shared context can make those workflows faster and less repetitive.

It can also preserve a bad assumption. If an agent incorrectly treats a staging host as production, every later step can inherit that mistake. If a secret enters the context, later tools may treat it as available working material. If an early scan produces a false positive, a long task can spend its remaining budget trying to prove the wrong story.

This is why long-running agents need checkpoints and verifiers, not just larger context windows. Each transition should answer a narrow question:

1. Is this target still in scope?
2. Is this credential still authorized for this target?
3. Is this action read-only, evidence-producing, or state-changing?
4. What evidence supports the next step?
5. Does a human need to approve the transition?

A shared notebook is not a security boundary. It is only a memory mechanism. The boundary comes from the enforcement around that memory.

What the announcement does not prove

ProjectDiscovery’s September 28 post proves that Neo was announced as free to try and that the company positions it for long security tasks with shared agent context. The current product and documentation pages describe the advertised controls.

They do not, by themselves, prove how every control behaves in every deployment. They do not establish that an agent will always respect a scope declaration, that every generated finding will be valid, or that a log makes an action safe after the fact.

Those are open implementation questions. An operator should test them before trusting the system with sensitive work:

• Can a run reach an address outside its declared scope?
• Are tool calls blocked, or merely recorded, when they cross a boundary?
• Can a user revoke credentials while a task is active?
• Are secrets redacted from shared context and exported logs?
• Can an operator reconstruct the exact model, prompt, tools, and permissions used for a finding?
• What happens when the task pauses, resumes, or changes models?

The right evaluation is not a polished demo. It is a boundary test with a harmless target, a deliberately denied action, and a log that can be independently reviewed.

The operator consequence

Treat a long-running security agent like a service account with a work queue, not like a chatbot with extra buttons.

Give it a named identity. Give it a narrow project scope. Separate discovery from exploitation and evidence collection from remediation. Keep production access out of the default path. Require approval before actions that change code, tickets, credentials, or infrastructure. Export the run log to the same system that records the resulting finding.

Then test the negative path. A security control that only works when the task behaves perfectly is not a control. It is a hope that has been given a label.

ProjectDiscovery is right to make the workflow long-running. Security work is not a single prompt. But duration makes the control plane more important, not less.

The model is not the boundary. The boundary is the system that decides what the model can reach, what it may change, and how the operator can prove what happened.

Sources

• ProjectDiscovery announcement on X, September 28, 2026.
• ProjectDiscovery Neo pricing and capability comparison, accessed October 2, 2026.
• Neo security and privacy documentation, accessed October 2, 2026.
• Neo project and scope documentation, accessed October 2, 2026.