Executive Summary
CyberOps is a reliable, stable, fully agentic penetration-testing platform built utilizing loop engineering. It coordinates a real offensive toolkit across long-running authorized missions, maintains durable mission state, and turns tool output into structured evidence and analyst-grade findings. The platform is virtualized: the same core architecture can run on premises or in cloud infrastructure, depending on the environment.
CyberOps is a fully agentic penetration-testing platform built to run real offensive workflows reliably from discovery through validation, analysis, and reporting. It combines autonomous planning, live tool execution, persistent mission state, deterministic tasking, runtime controls, recovery logic, and evidence-driven findings in one platform. It is designed for long-running, tool-heavy missions where the agent has to retain what it has learned, recover when something fails, continue making progress, and produce an outcome a human can review and defend. Ollama is the current model runtime used for testing, but CyberOps is model-flexible and can use other LLMs.
CyberOps implements loop engineering across the full operating model rather than treating the agent as a single prompt-and-response cycle. Missions can recur, parallel work is isolated through worktrees so tasks do not collide, specialized agents handle distinct functions, connectors provide integration points, and persistent external state survives any individual model run.
Three pillars define the system.
- First, CyberOps is virtualized and deployment flexible. The backend, frontend, operator, state store, passive telemetry, and model runtime are packaged as services that can run on premises or in cloud infrastructure. The core architecture does not depend on a particular hosting model, model provider, or control plane. Isolated, segmented, and air-gapped deployments remain supported where those operating conditions matter.
- Second, CyberOps uses a ReAct loop engineered for reliable execution across long-running offensive work. Planning is grounded in deterministic host and CVE facts. Service discovery triggers deterministic enumeration chains so coverage does not depend on model memory. The platform protects its capability context from prompt truncation, recovers from invalid actions, and finalizes missions even when the planner fails. Tool execution was refined through testing to account for real scanner behavior: long-running or quiet processes are evaluated through progress-based watchdogs and process-tree CPU activity, while per-tool throttling prevents a single task from consuming the host. The result is an autonomous platform built to sustain real offensive workflows over time.
- Third, CyberOps treats post-exploitation analysis as seriously as execution. Raw scanner output creates more volume than value unless it is correlated, deduplicated, enriched, and triaged. The platform therefore runs an analyst pipeline after mission completion that merges duplicate findings on full signal identity, enriches retained findings with public exploitability and threat data, and uses a grounded LLM pass to write the “so-what” analysis while leaning on deterministic scoring signals for verdicts. In live testing, this pipeline reduced roughly 444 raw findings to about 118 review-worthy items while preserving the full evidence trail.
1. Problem Statement and Design Goals
Traditional scanners can cover a large environment quickly, but they produce a volume of findings that still has to be correlated, validated, and prioritized by a human. Human-led penetration tests provide deeper analysis, but they take time and cannot run continuously across an environment. CyberOps uses agents to run and coordinate real offensive tooling, retain what is learned during a mission, follow up on discovered services, validate exposures, and produce evidence-backed findings. That requires the platform to handle long-running tools, incomplete output, parallel tasks, changing mission state, and recovery when an action fails.
CyberOps starts from the observation that real offensive automation has to satisfy four simultaneous requirements.
- It must execute a real toolkit rather than simulate one. Practical penetration testing is not a single-model reasoning exercise; it is an orchestration problem over scanners, enumerators, protocol checkers, CVE validators, and exploit-validation tools whose outputs are heterogeneous and often messy.
- It must be virtualized and deployment-flexible. CyberOps can run on premises, in cloud infrastructure, and in isolated or air-gapped environments without changing the core execution architecture. The same platform can be deployed where the customer operates it, whether that is a local environment, private cloud, or cloud-hosted infrastructure. Isolated and air-gapped deployments remain available for organizations that need to keep offensive security operations, target data, and supporting infrastructure inside their own environment.
- It must use a reliability-engineered agent loop. The planner reads the current mission state, decides which target, tool, and action CyberOps should take next, and updates the assessment plan as new findings are collected. If not properly designed it can lose context, select an invalid action, or spend too much time on one host. CyberOps grounds planner decisions in verified facts, automatically queues required follow-up work, recovers from invalid actions, preserves assessment coverage, and ensures every mission reaches an auditable conclusion.
- It must produce findings a human can review and act on. Autonomous testing generates large volumes of tool output, duplicate detections, partial evidence, and uncertain results. CyberOps correlates and deduplicates findings, preserves the underlying evidence, enriches validated exposures with exploitability and threat context, and prioritizes what should be reviewed first.
Those constraints translate into concrete design goals:
- Virtualized deployment on premises or in cloud infrastructure
- Model-runtime flexibility; Ollama is the current testing baseline, this is not a product constraint
- Real tool execution with live output streaming
- Reliable, long-running agent execution
- Explicit rules of engagement and approval gating
- Human-reviewable, evidence-rich deliverables
The rest of the system architecture can be understood as an attempt to satisfy those goals across long-running missions, regardless of the selected deployment environment or model runtime.
2. System Architecture
CyberOps is organized into a small set of tightly scoped services that separate orchestration, execution, state, and reporting.
At the top of the stack is a Next.js frontend that acts as the operator console and report surface. The user workflow is intentionally funnel-shaped: scope definition leads into missions, missions produce findings and evidence, and those culminate in a client-ready report. The frontend and backend run as virtualized services and can be placed on premises or in cloud infrastructure without changing the core operator workflow.
The backend is a FastAPI service that functions as the system brain. It owns orchestration, mission state, agent planning, task dispatch, tool-result parsing, finding extraction, triage, enrichment, and report generation. This is where the ReAct loop lives, where world-state updates are persisted, and where guardrails are enforced.
Real offensive execution is delegated to an operator service packaged in a Kali-based container. The operator exposes an HTTP and server-sent-events interface to the backend and runs the toolchain directly through subprocess execution. This design decouples orchestration from tool execution. The backend does not need to embed scanner binaries or shell logic; it issues structured execution requests and consumes streamed output. The operator uses host networking to reach authorized LAN targets directly.
CyberOps also integrates a Greenbone/OpenVAS stack for authoritative CVE and exposure validation. Rather than treating OpenVAS as the entire product, the system positions it as one component in a broader offensive workflow. OpenVAS scans run asynchronously at campaign scope and feed deep vulnerability evidence back into the shared state model. Additionally, CyberOps could be easily extended you use any commercially available scanner as its vulnerability management source.
Postgres stores all durable system state: scopes, targets, runs, tasks, findings, evidence, notes, approvals, and derived outputs. Zeek provides passive telemetry that can be folded into host understanding and early planning. The model runtime is abstracted behind the agent interface. Ollama is the current base for testing, but CyberOps is not bound to Ollama or any particular model. A deployment can use a different LLM runtime without changing the rest of the platform.
Looked at through a loop-engineering lens, the architecture contains the expected primitives. Campaigns support continuous execution and scheduling metadata; parallel agent work is isolated through worktree-based workspace boundaries so concurrent tasks do not step on each other; the mission itself is decomposed into role-specialized agents such as planner, recon, validator, detection, and reporting; connector abstractions exist for integrating external systems; and durable state is persisted outside any single model context in the database-backed notebook, evidence, and run records. In other words, the loop is not just the planner cycle. It is the broader control system around the planner. The platform does not rely on a single conversation with a single model. It is relying on an engineered loop with scheduling, isolation, specialization, integration, memory, and runtime control.
The key architectural point is that the platform separates execution, orchestration, presentation, and reporting while keeping mission state and evidence durable. Those virtualized services can run on premises or in cloud infrastructure. Reporting remains downstream of real evidence rather than synthetic summaries.
3. The Agent Loop
The CyberOps loop is a hypothesis-driven ReAct system engineered for offensive work rather than a scripted scanner with a prompt attached. It is fully agentic in the systems sense: recurring mission execution, isolated parallel workspaces, role-specialized agents, connectors, persistent state, and recovery behavior all shape the behavior of the core ReAct cycle.
Each iteration follows a simple structure. The planner reads a compact projection of the current mission state: discovered hosts, open ports, service facts, prior observations, tester notes, queued work, and grounded CVE context. It determines what the current evidence suggests should be investigated, identifies the current phase of the assessment, and selects a single target, tool, and next action. The operator runs the tool and streams the output. The backend converts the result into structured evidence and findings, updates the mission state and assessment plan, and repeats until the mission is complete or a graceful stop condition fires.
3.1 Grounding and anti-hallucination controls
The planner is not allowed to invent core facts. Host updates are passed through hallucination gates, and CVEs are only accepted when they are grounded in deterministic scanner output. The system feeds the planner a bounded, explicit CVE inventory and rejects fabricated identifiers. Without those limits, the planner could present nonexistent exposures or uncertain evidence as confirmed findings.
3.2 Capability persistence under prompt pressure
CyberOps keeps the available toolset and allowed-action context protected within each planning prompt. As mission history grows, the planner continues to receive an explicit, bounded catalog of the tools it can use rather than relying on the model to recall capabilities from earlier context. This keeps action selection tied to the actual platform, prevents accumulated mission detail from displacing critical capability information, and reduces invalid or unsupported actions.
3.3 Invalid-action resilience
CyberOps uses deterministic capability data from tool telemetry to validate the planner’s output before execution. The review confirms that the selected tool, target, and action are available, authorized, and applicable to the current mission state. LLM hallucinations are discarded, and recognized aliases can be mapped to an approved capability when the match is clear. The planner can adapt the assessment as evidence changes while every action executed by the platform remains tied to verified capabilities.
3.4 Deterministic chains after discovery
CyberOps does not rely on the LLM to remember every obvious next step. Once discovery establishes exposed services, the backend injects deterministic enumeration chains keyed off service characteristics. A port-to-chain map queues follow-up work such as web fingerprinting, content discovery, SSH review, SMB inspection, or TLS analysis without another LLM call.
3.5 Separation of plan, notebook, and state
The system also distinguishes between the kickoff plan, free-form notes, and durable mission state. The kickoff plan is generated from passive and early active context before deeper execution begins. It remains separate from the free-text notebook so the assessment strategy is not buried under accumulated observations. The planner can retain the original approach, use notes for working context, and rely on durable state for verified mission facts as the assessment progresses.
3.6 Tiered context budgets
CyberOps uses different context strategies for planning and reporting. Planning runs on a focused view of the current mission state so the agent can make clear decisions about the next target, tool, and action. Reporting receives a broader evidence set so it can connect findings, supporting output, validation results, and analyst context into a complete assessment record.
This gives CyberOps an agent loop that can operate efficiently during the assessment while still producing detailed, evidence-backed reporting at the end. The LLM drives assessment decisions and analysis, while deterministic mission state, capability validation, tasking, and evidence handling keep the platform operating consistently across long-running offensive work.
4. Execution Reliability and Systems Engineering
The agent loop directs the assessment. The CyberOps runtime provides the execution layer needed to run scanners, enumerators, protocol checkers, and validation tools under real operating conditions. Those tools can run for long periods, spawn child processes, consume significant CPU, and emit output irregularly. The runtime is designed to manage that behavior while preserving mission progress, platform stability, and evidence.
CyberOps uses progress-based watchdogs rather than relying on arbitrary wall-clock timeouts. A tool is considered inactive only when it produces no output and its process tree shows no CPU activity for a sustained period. CPU usage is measured across the full process subtree under /proc, not just the parent wrapper, so child processes performing useful work are recognized as active even when the top-level process is quiet.
The operator also enforces per-tool CPU budgets. A feedback-controlled duty-cycle governor applies SIGSTOP and SIGCONT across a tool’s process group to keep execution near the configured CPU limit. This allows deep scans and wide fan-out tasks to continue making progress without allowing one tool to consume the host.
CyberOps supports concurrent deterministic service-enumeration chains while preserving state consistency. Parallel tasks execute independently, collect and cache their results, and return those results to the main loop for controlled state updates. This increases assessment coverage and speed without allowing concurrent tasks to corrupt shared mission state.
The runtime also preserves a mission through transient failures, planner timeouts, and degraded conditions. CyberOps retries work with backoff, continues with deterministic queued tasks when appropriate, and always reaches a finalization path that preserves collected evidence and generates an end-state report.
5. Offensive Depth and Rules of Engagement
CyberOps is not a narrow web scanner wrapped in an agent loop. Its operator exposes a broad offensive toolkit that covers network discovery, service enumeration, web analysis, CVE validation, screenshot capture, and controlled exploit verification.
By function, the stack includes:
- Discovery and network enumeration through tools such as Nmap, Naabu, and a wider Nmap NSE family
- Web fingerprinting and content discovery through HTTPX, Katana, Feroxbuster, WhatWeb, Nikto, WPScan, and JoomScan
- Protocol and service auditing through SSH-Audit, NetExec, Enum4linux-ng, SMBMap, LDAPSearch, SNMP utilities, SSLScan, and Testssl.sh
- CVE validation and vulnerability scanning through Nuclei, Nuclei-CVE, OpenVAS, and service-specific checks
- Visual evidence capture through Gowitness
- Controlled exploit validation through Searchsploit and Metasploit auxiliary, check, and exploit modes
What makes that depth usable is the Rules-of-Engagement model. CyberOps exposes four aggression profiles: recon, safe, aggressive, and maximum. Each profile defines a policy bundle over vulnerability scanning, intrusive behavior, brute-force allowance, exploitation mode, and concurrency. In effect, RoE is a first-class control surface for the loop.
6. Analyst Pipeline: Turning Volume into Signal
Even a successful autonomous mission can fail the operator if it ends in unmanageable volume. CyberOps therefore treats the post-run analyst pipeline as a second core subsystem rather than a reporting afterthought.
The pipeline begins with correlation and deduplication. Findings are not merged on title similarity alone. Instead, CyberOps deduplicates on full signal identity: host, IP, port, service, and weakness identity, such as shared CVE, shared NVT object identifier, or a combined category-title-host-port-service match. This is intentionally strict. Loose deduplication can erase meaningful distinctions between exposures that happen to look similar, while overly narrow matching leaves the human reviewer buried in repeats.
Retained findings are then enriched with external but keyless public signals. These include EPSS exploit probability, CISA Known Exploited Vulnerabilities membership, NVD CVSS and CWE context, and curated deep links into major public references such as NVD, CVE.org, CISA KEV, EPSS, Exploit-DB, and MITRE ATT&CK. Enrichment is a configurable capability: deployments can use external signals where permitted without making them a prerequisite for core operation.
Only after those deterministic signals are attached does the analyst LLM run. Its role is not to invent prioritization from scratch. Its role is to combine grounded signals into a more coherent verdict, explain exploitability, summarize impact, and surface next actions. In practice, this yields two views of the same mission output: the full evidence-rich finding set, and a smaller “review these first” subset.
In live testing, CyberOps reduced approximately 444 raw findings to roughly 118 review-worthy items while preserving the underlying evidence. The analyst pipeline combines deterministic vulnerability data with machine-assisted analysis to give the human reviewer a smaller, clearer set of findings to assess and defend.
The system also records tester overrides and preserves them from future re-triage. Those overrides are then fed back as precedent into future prompts. This creates a narrow but practical adaptation loop: the analyst pass can become more aligned with operator judgment without surrendering deterministic evidence control.
7. Evaluation and Live Evidence
CyberOps has been validated in a live end-to-end assessment. In a fresh full-scope run under a maximum-RoE mission, the platform completed a 238-step mission to an assessment_complete state. The run produced 498 findings, 23 screenshots, and a final report. EPSS enrichment was verified against live CVE findings. Searchsploit returned expected exploit references, and Metasploit check mode executed successfully through the operator.
The run exercised the full CyberOps workflow rather than an isolated feature. The planner directed the assessment using the current mission state. The operator executed discovery, enumeration, validation, enrichment, and controlled exploit-review actions through the available toolchain. Tool output was converted into structured evidence and findings, retained in the mission record, and passed into the analyst pipeline for correlation, prioritization, and reporting.
The result was a complete assessment record containing the findings, supporting evidence, screenshots, exploit-reference data, enrichment results, and final report. The test demonstrated that CyberOps can sustain a long-running mission, coordinate a heterogeneous offensive toolkit, update the assessment as evidence is collected, and produce an evidence-backed output for human review.
8. Positioning and Practical Implications
CyberOps combines autonomous offensive depth with a virtualized architecture that can run on premises or in cloud environments. It is built for long-running, evidence-driven offensive validation without tying the core platform to a specific deployment model or LLM runtime.
Compared with conventional scanners, CyberOps does not stop at detection. Compared with human-only penetration tests, it can run continuously and repeatably across an environment. The platform preserves mission state, controls runtime behavior, recovers from invalid actions, executes deterministic follow-up work, and produces an auditable end state.
Self-hosting, cloud deployment, and LLM selection are implementation choices. CyberOps is defined by the engineered loop that keeps the assessment moving, preserves evidence, operates within policy, and produces findings a human can review and defend.
9. Conclusion
CyberOps addresses the real challenge in autonomous penetration testing: building a fully agentic offensive system that remains dependable through long-running, tool-heavy missions, whether it runs on premises or in the cloud and regardless of the LLM runtime selected.
The architecture supports that through virtualized service boundaries, durable mission state, and separation between orchestration and execution. The agent loop grounds decisions in verified data, queues deterministic follow-up work, validates actions against available capabilities, preserves critical context, and finalizes the mission even when the workflow is degraded. The analyst pipeline correlates duplicate findings, enriches validated exposures with deterministic signals, prioritizes review, and produces evidence-rich reporting.
CyberOps brings those capabilities together in one platform that can plan, execute, adapt as evidence changes, and finish with a complete assessment record. It is not defined by a specific hosting model or LLM. It is defined by an engineered loop that preserves state, manages tool execution, enforces policy, retains evidence, and completes the mission.
Publishing Link
https://www.linkedin.com/pulse/engineering-reliable-virtualized-fully-agentic-pentest-death-plqke