An automated penetration testing system and method based on multi-agent collaboration and multi-dimensional anti-illusion mechanism

Abstract

The application relates to the technical field of network security and artificial intelligence, and discloses an automatic penetration testing system and method based on multi-agent cooperation and multi-dimensional anti-illusion mechanism. The system establishes a test task within the scope of written authorization, generates a candidate test path carrying an evidence mark based on a security knowledge base, and verifies knowledge evidence, rule compliance and path dependence; the subtasks are disassembled according to topological dependence and distributed to professional agents according to ability tags, health states and loads, the multi-dimensional actual state and the expected state are quantitatively compared during execution, the branch is blocked and re-planned when the deviation exceeds the threshold, and the results are reviewed based on multi-source evidence after execution; the state is written into a unified collection through a data gateway and a normalized serialized hash chain is formed. The application can improve the controllability, execution consistency and traceability of automatic penetration testing.

Description

Technical Field

[0001] This invention relates to the field of cybersecurity and artificial intelligence, and in particular to a system and method for automating penetration testing within the boundaries of written authorization through multi-agent collaborative scheduling, multi-dimensional anti-illusion closed-loop verification, manual high-risk approval, and persistent traceable data. Background Technology

[0002] Penetration testing is a technical activity that identifies the exposed surfaces, configuration flaws, and known vulnerabilities of an information system by simulating security testing behaviors. To avoid unnecessary impact on the production environment, the testing process typically needs to be executed within a clearly defined target scope, time window, operation type, and concurrency limit, and process evidence must be preserved for verification. Traditional penetration testing mainly relies on security personnel to select tools, orchestrate steps, and judge results based on asset information. When the target scale is large or the asset type is complex, task breakdown, state synchronization, and evidence preparation require a significant amount of manual work.

[0003] Existing automated testing tools can perform asset discovery, service identification, or vulnerability template detection according to preset scripts, but fixed processes often struggle to dynamically adjust subsequent steps based on actual feedback. Large language models possess natural language understanding and path planning capabilities, enabling them to generate test suggestions based on asset and vulnerability information. However, the content generated by large language models depends on the training corpus and the current context, and its output may contain non-existent vulnerability identifiers, operations that do not match the target fingerprint, invalid dependencies between preceding and following steps, or inconsistencies between expected and actual states. Directly delivering the generated operations to execution nodes may result in invalid tasks, out-of-bounds operations, or erroneous results.

[0004] Some solutions employ a single-rule filtering model for output, or require manual review of the report after execution. While single-rule filtering can identify explicitly prohibited operations, it struggles to verify the source of the knowledge referenced by the model and the reachability of test paths consisting of multiple steps within the current asset topology. Reviewing only after execution fails to address environmental changes and state deviations during the process. Furthermore, when handling multiple concurrent assets, monolithic execution programs are prone to information disconnects between path planning, execution scheduling, result aggregation, and task status.

[0005] A search revealed that Chinese invention patent application CN119025878A (published on November 26, 2024, entitled "An Automatic Penetration Testing Method Based on a Multi-Agent Large Language Model") discloses a penetration testing solution knowledge base, a penetration testing tool library, and intelligent agents for knowledge retrieval, task planning, task scheduling, tool invocation, and task summarization. It also reduces the illusion in large language model decision-making through retrieval enhancement generation technology. The key focus of this solution is on using knowledge corpus retrieval and multi-agent division of labor to generate test steps, select tools, and summarize results. However, it lacks a unified closed loop throughout the entire testing process, addressing how to bind each path node to traceable knowledge evidence, simultaneously perform compliance checks on operational rules and path dependency reachability checks before execution, block affected branches based on actual state deviations during execution, and review results based on multi-source evidence after execution.

[0006] Chinese invention patent application CN119150912A (published on December 17, 2024, entitled "A Large Language Model-Driven Penetration Testing Intelligent Agent System and Testing Method") discloses a memory unit composed of a penetration testing knowledge base, an intelligent unit implemented by a large model, and a task planning state machine that breaks down penetration testing tasks into controllable sub-tasks. It also utilizes knowledge graphs and retrieval enhancements to improve the interpretability and consistency of the large model's output. This solution mainly focuses on knowledge enhancement, task planning, and tool invocation. However, it does not systematically explain how the per-operation boundary verification of written authorization scope, the approval of additional conditions for high-risk operations, the unified interface and hash chain auditing for writing task and result states, and the security degradation and recovery mechanisms in case of intelligent decision service anomalies operate collaboratively.

[0007] Therefore, there is a need for an automated penetration testing technology that can integrate knowledge evidence, operational rules, path dependencies, execution status, and outcome evidence, and place model decisions and multi-agent execution processes under a unified authorization boundary and state machine control, in order to reduce the probability of unexecutable paths, misjudgments of results, and out-of-bounds operations.

[0008] From the perspective of internal implementation in computer systems, it is also necessary to address issues such as the difficulty in using a unified metric to measure discrete and continuous states in multi-dimensional state comparisons, the difficulty in achieving consistency verification between heterogeneous knowledge retrieval results and graph path relationships under the same evidence identifier, the need to simultaneously satisfy node dependencies and agent loads in multi-agent concurrent scheduling, and the potential instability of hash verification results due to inconsistencies in field order or encoding representation in audit records. These issues directly affect the accuracy of path verification, the determinism of task scheduling, and the integrity of audit data. Summary of the Invention

[0009] The purpose of this invention is to provide an automated penetration testing system and method based on multi-agent collaboration and multi-dimensional anti-illusion mechanisms, which enables candidate test paths to have traceable knowledge evidence and be verified by rules and path dependencies before being issued for execution, enables the actual state during execution to be fed back to the path decision-making process, enables the execution results to be verified by multi-source evidence, and enables high-risk operations, state writing and abnormal degradation to be uniformly controlled.

[0010] To achieve the above objectives, this invention provides an automated penetration testing system based on multi-agent collaboration and a multi-dimensional anti-illusion mechanism, comprising an authorization task management layer, an intelligent decision-making layer, a multi-dimensional anti-illusion verification unit, a multi-agent collaborative scheduling layer, a controlled execution layer, and a data gateway. The authorization task management layer acquires written authorization scope information, test target information, and operational constraint information, establishes task status records, and verifies the authorization boundaries before issuing test operations. The intelligent decision-making layer retrieves security knowledge base information based on the test target and generates candidate test paths composed of path nodes and dependency edges. Each path node carries the target object, operation type, pre-state, expected state, and knowledge evidence identifier.

[0011] The multi-dimensional anti-illusion verification unit sequentially performs knowledge evidence consistency verification, operational rule compliance verification, and path dependency reachability verification to obtain a verified test path. The multi-agent collaborative scheduling layer decomposes the verified test path into sub-tasks with dependencies and distributes them to dedicated agents based on capability tags. After authorization by the task management layer, the controlled execution layer invokes atomic capability components to perform non-destructive test operations and converts discrete echoes into unified result data. The multi-dimensional anti-illusion verification unit further compares the expected state with the actual execution state. If the execution deviation exceeds a threshold, it blocks the path branch and replans; if the deviation does not exceed the threshold, it performs result consistency verification based on multi-source evidence. The data gateway persists the task state, results, and audit records after the verification is passed. In the specific implementation, the execution deviation is synthesized by normalized differences from multiple applicable state dimensions according to policy weights; the multi-agent collaborative scheduling selects execution nodes based on path topology dependencies, agent capability tags, health status, and current load; the data gateway normalizes and serializes audit records and calculates the current hash based on the previous hash and the current record to form a chain-like integrity verification relationship.

[0012] This invention also provides an automated penetration testing method, including authorized task creation and boundary verification, knowledge retrieval and evidence binding, candidate test path generation, knowledge evidence consistency verification, operation rule compliance verification, path dependency reachability verification, subtask decomposition and agent capability matching, controlled execution, execution deviation monitoring, result consistency verification, and data persistence.

[0013] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described automated penetration testing method.

[0014] This invention achieves the following beneficial effects: Each path node in the candidate test path is associated with knowledge evidence and undergoes rule and graph path verification before execution, reducing the entry of nodes without a source or with invalid dependencies into the execution queue; comparing the expected and actual states during execution allows for blocking and replanning of affected branches when the environment changes; distributing subtasks to dedicated agents according to capability tags ensures that path decision-making, concurrent execution, and state synchronization remain correlated; high-risk operations are intervened through manual approval, and state write operations are uniformly converged through a data gateway to form hash chain audit records, improving the boundary controllability and post-event traceability of the testing process; switching to a fixed non-destructive template when the intelligent decision service is abnormal maintains basic testing capabilities. Furthermore, knowledge version synchronization and cache invalidation control reduce the impact of asynchronous vector retrieval results and graph relationship states on path verification; versioned weighting based on historical confirmation contributions and dynamic load scoring based on operational metrics allow for controlled updates of the deviation judgment scale and agent distribution strategy based on historical execution characteristics and operational resource status; incremental hash verification through verification anchors reduces repetitive full computation on long audit chains. Attached Figure Description

[0015] Figure 1 A schematic diagram of the five-layer system architecture and data middleware structure provided in this embodiment of the invention; Figure 2 This is a schematic diagram illustrating cross-language communication and data truth value transfer relationships provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the overall process of the automated penetration testing method provided in this embodiment of the invention. Figure 4 A flowchart of the multidimensional anti-hallucination closed-loop verification provided in this embodiment of the invention; Figure 5 This is a schematic diagram of the multi-agent cooperative scheduling and state synchronization relationship provided in an embodiment of the present invention; Figure 6 This is a flowchart of manual approval process for high-risk operations provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the hash chain auditing and service degradation recovery mechanism provided in an embodiment of the present invention. Detailed Implementation

[0016] Example 1: The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. The examples are used to illustrate the connection relationships between modules, the data flow process, and specific implementation methods, and are not intended to limit the present invention to a particular programming language, database product, or model service. Unless the context otherwise requires, the test operations in this embodiment refer to non-destructive security verification operations performed within the scope of the written authorization, excluding destructive operations such as deleting data, blocking core services, or altering production data.

[0017] In this implementation, the authorized scope information refers to at least one of the following confirmed by the test client: target address set, domain name set, asset identifier, test time window, allowed operation set, prohibited operation set, concurrency limit, rate limit, and authorization validity period. Test target information refers to addresses, operating system types, service types, port statuses, asset fingerprints, and known vulnerability clues read from or pre-imported from the authorized targets. Operational constraint information refers to the role permissions, target scope, tool version, execution time limit, request frequency, concurrency, and data processing requirements that apply to specific test steps.

[0018] A candidate test path is a directed graph consisting of multiple path nodes and dependency edges between them. A path node describes a test intent that can be independently verified and scheduled, and at a minimum includes a path node identifier, target object, operation type, input conditions, prerequisite state, expected state, knowledge evidence identifier, risk attribute, and candidate capability label. Dependency edges describe the state continuity between two path nodes; for example, a subsequent path node can only perform templated vulnerability detection on a service if the preceding path node confirms that the service is open.

[0019] Knowledge evidence refers to structured records retrieved from a security knowledge base that can support the generation of path nodes. Knowledge evidence can include vulnerability entities, product and version applicability conditions, asset fingerprint entities, test tactical nodes, preconditions, state transition relationships, and historical successful paths or reasons for historical failures. Each piece of knowledge evidence has a unique evidence identifier, source identifier, version information, update time, and applicable conditions, enabling the path nodes generated by the model to be traced back to specific data sources.

[0020] like Figure 1 As shown, the system in this embodiment is divided into five layers according to their responsibilities: a human-machine global control and decision-making layer, a large-model core intelligent decision-making layer, a multi-agent collaborative scheduling layer, a penetration capability atomic orchestration layer, and a real-environment execution layer. These five layers are connected through synchronous calls, asynchronous messages, and state sharing mechanisms, and all access the data middleware layer. This layered division is used to isolate security boundaries, model inference, and tool execution, ensuring that model output cannot bypass the authorized task control layer and directly reach the real-environment execution layer.

[0021] The human-machine global management decision layer serves as the system entry point, setting up authorized task management services, a security constraint engine, high-risk operation approval services, task monitoring services, and end-to-end auditing services. This layer can be implemented using service programs with concurrent processing capabilities, providing external interfaces for task creation, startup, pause, cancellation, approval, and status query, while internally maintaining the task state machine. Task statuses include at least: created, pending verification, planned, pending execution, executing, pending approval, paused, completed, failed, and canceled. Any status change carries the status source, triggering event, and tracking identifier, written to the data gateway. In an implementation consistent with the disclosure, the security constraint engine can use the Casbin policy engine to implement RBAC / ABAC access control, constructing policy judgment objects from user roles, target resources, operation types, and task contexts, and using target address whitelists, prohibited operation types, rate limits, and concurrency limits as policy conditions; asynchronous task management can be achieved through Asynq and Redis working together to maintain the task state machine.

[0022] The core intelligent decision-making layer of the large model includes a security knowledge base, a retrieval enhancement generation pipeline, a test path planner, a multi-dimensional anti-illusion verification unit, and a risk assessment service. The security knowledge base can be composed of a vector database and a graph database. The vector database is used to retrieve vulnerability descriptions, product fingerprints, and test instructions based on semantic similarity, while the graph database stores relationships between products, versions, vulnerabilities, pre-existing states, test operations, expected states, and historical results. The test path planner can call the large language model or a locally deployed language model; the model interface is encapsulated through a unified gateway to switch models without changing the upper-layer data schema. In one specific implementation, LlamaIndex can be used to build the retrieval enhancement generation pipeline, Milvus can be used to store vector data such as CVE vulnerabilities and asset fingerprints and perform semantic nearest neighbor retrieval, and Neo4j can be used to store test tactics, pre-existing states, and state transition relationships and perform path relationship queries; the retrieved knowledge entities are bound to path nodes through evidence identifiers, source versions, and applicable conditions.

[0023] The multi-agent collaborative scheduling layer includes a task decomposition and distribution engine, a dedicated agent cluster, and an information sharing bus. The dedicated agent cluster comprises at least asset detection agents, vulnerability detection agents, controlled verification agents, and status monitoring agents. Each agent declares its capability tags, input data patterns, output data patterns, and health status using a unified base class. The scheduling layer does not directly assign tasks based on agent names; instead, it matches the capability tags required by subtasks with the capability sets of online agents to support horizontal scaling and failover for agents of the same type.

[0024] The penetration testing capability atomic orchestration layer is used to encapsulate different underlying tools and verification plugins into atomic capability components. Each atomic capability component has a component identifier, component version, capability tag, allowed input fields, output fields, default timeout value, risk level, and isolation requirements. As an example, an asset detection component, a templated vulnerability detection component, and a read-only configuration verification component can be encapsulated separately. The system masks the differences in underlying tool parameters and output formats by using a unified input / output data mode; the agent only transmits structured task data and does not directly concatenate unvalidated command strings.

[0025] The real-world execution layer consists of an environment adaptive adapter, a protocol execution channel, an echo collector, and a result normalizer. The environment adaptive adapter selects the execution strategy based on the target operating system, service protocol, and the applicability of atomic capability components. The protocol execution channel can include HTTP, TCP, and authorized remote management channels. The echo collector records the start time, end time, target object, component version, return code, original echo summary, and evidence location. The result normalizer converts the echoes from different components into unified result data, including at least the subtask identifier, actual state, evidence set, execution status, error reason, and completion time.

[0026] The data middleware layer comprises a relational database, a cache, a vector database, a graph database, and a message queue. The relational database serves as the sole persistent source of truth for task, approval, result, and audit data; the cache maintains the task state machine, the online state of the agent, and the queue of pending approvals; the vector and graph databases constitute a security knowledge base; and the message queue is used for the asynchronous transmission of subtasks and execution events. The state in the cache is only used to accelerate scheduling; state changes are ultimately based on the records written to the relational database by the data gateway.

[0027] like Figure 2 As shown, the front-end interactive interface and the human-machine global control decision layer can transmit task configurations via Hypertext Transfer Protocol (HTTP) and receive task progress and approval requests via long-lived connections. The human-machine global control decision layer and the core intelligent decision layer of the large model communicate via synchronous remote procedure calls (RPCs) to transmit requests for path planning, knowledge querying, risk assessment, path verification, and result review. Synchronous calls set task identifiers and trace identifiers to ensure that responses correspond to the tasks that initiated the requests. Specifically, the Go control layer and the Python intelligent decision layer can communicate via synchronous gRPC to transmit requests and responses such as PlanAttackPath, AssessRisk, ValidatePath, and ReviewResult; synchronous calls carry task_id and trace_id to correlate inference results with task status and audit records. The front-end and the Go control layer can communicate via WebSocket long-lived connections to push task progress and approval requests in real time.

[0028] When the human-machine global control decision layer issues sub-tasks to the agent cluster and the agent cluster reports execution events, asynchronous transmission can be achieved through a message queue. The message body must at least include the message type, task identifier, sub-task identifier, path node identifier, idempotent key, generation time, and load summary. Before processing a message, the consumer queries the idempotent key; if the same idempotent key has already been written, it returns a processed status without repeating the execution, thus reducing redundant testing caused by repeated message delivery. In one specific implementation, both the Go control layer issuing execution instructions to the Agent and the Agent reporting execution events to the Go control layer are accomplished through asynchronous RabbitMQ messages, decoupling the time-consuming execution process from synchronous planning requests; the message queue only transmits sub-tasks or execution events that have undergone structured validation.

[0029] The state sharing bus can use a publish-subscribe mechanism to publish events such as task pause, task cancellation, approval completion, path replanning, and agent state changes. When an agent receives a task pause or cancellation event, it stops accepting new subtasks and safely terminates any interruptible operations in progress. For read-only probe operations that cannot be immediately interrupted, the agent stops subsequent requests after completing the current network request and reports the termination position. In one specific implementation, state broadcasting between Go internal services uses Redis Pub / Sub. The Go management layer and the Python intelligent decision-making layer share task and agent states through Redis; Redis serves only as a scheduling and state sharing cache, while the relational database remains the persistent truth source.

[0030] The data gateway serves as the unified endpoint for state write operations. Task services, approval services, scheduling services, and agent result consumers do not directly update the relational database. Instead, they invoke the interfaces defined by the data gateway to create tasks, update task states, create subtasks, update subtask results, create approval records, and write audit logs. The data gateway completes the writing of business records and audit records within the same transaction, thus preventing audit records from being missing even when business states have changed.

[0031] This embodiment incorporates authorized task management, knowledge evidence constraints, candidate path verification, multi-agent scheduling, controlled execution, and data persistence into a layered architecture and unified state machine. This ensures that the test intent generated by the model cannot bypass authorization boundaries and directly affect the real environment. This solves the problems of disconnect between planning, execution, state, and auditing in traditional automated penetration testing, as well as the difficulty in timely blocking of out-of-bounds operations. It also improves the overall controllability, scalability, and execution consistency of the system.

[0032] Example 2: The intelligent decision-making layer receives the task identifier, asset set, vulnerability clue set, and policy configuration. The system first normalizes the target information, converting domain names into standardized domain name formats, addresses into standard address range representations, and mapping product names and version numbers to standard entities in the knowledge base. The normalization results are used to generate retrieval queries and are written into the planning context along with the task authorization scope to prevent the model from expanding to unauthorized targets in subsequent steps.

[0033] The knowledge retrieval phase executes vector retrieval and graph relation retrieval respectively. Vector retrieval returns candidate knowledge entities ranked by similarity based on the target fingerprint and vulnerability clues; graph relation retrieval queries applicable vulnerabilities, current states, and permitted testing tactics based on standard product entities. The system deduplicates and filters the returned results based on validity period, retaining knowledge evidence with identifiable sources and version applicability that matches the target information. The preset number can be configured according to the size of the knowledge base, for example, retaining five to twenty pieces of evidence per retrieval category, but the final number is not a limitation on the scope of protection. For example, the system can receive normalized target information via gRPC, initiate a Top-K vector retrieval to Milvus to obtain candidate CVEs or asset entities related to the target fingerprint, and then use the candidate entity identifier as the entry point for Neo4j graph relation query to obtain its current state, permitted testing tactics, and state transition paths; only entities that simultaneously meet the conditions of identifiable source, valid version, target applicability, and graph relation reachability are written into the knowledge evidence set.

[0034] In a further implementation, the security knowledge base assigns a global `knowledge_id` and `knowledge_version` to the same knowledge object, and synchronously writes them to the `sync_epoch` when writing to the vector database and graph database. During the retrieval phase, only vector records with consistent `knowledge_id`, `knowledge_version`, and `sync_epoch` are combined with graph entities to form valid knowledge evidence. When version inconsistencies are detected, the corresponding entity is added to the resynchronization queue and is not used for path generation until the dual-database reconstruction or incremental synchronization is completed. On the Milvus side, HNSW or IVF_FLAT approximate nearest neighbor indexes can be used, and index parameters can be configured according to the knowledge base size and query latency requirements. On the Neo4j side, indexes can be created based on product identifiers, version identifiers, and relationship types to narrow the scope of path relationship queries.

[0035] For repeated searches, the system can concatenate the target fingerprint summary, knowledge_version, sync_epoch, and policy version to calculate the search cache key, and cache the candidate knowledge entity identifiers and their similarity ranking. When the knowledge entry version, graph relationship version, or security policy version is updated, the cache key changes accordingly, and the old cache automatically becomes invalid. For the same search key within the same task, the verified candidate set can be reused directly, thereby reducing repeated vector searches and graph path queries, while avoiding the reuse of expired knowledge across versions.

[0036] The test path planner constructs a constrained cue context using the authorization scope, target information, and knowledge evidence set. The model output uses predefined structured data instead of free text; each path node must be populated with the target object, operation type, prerequisite state, expected state, and knowledge evidence identifier. The structure validator rejects outputs lacking necessary fields, referencing non-existent evidence identifiers, or whose target object does not belong to the authorization set. If the model continuously outputs data that does not conform to the structure, the system stops the current planning and returns to manual review mode without automatically performing any action.

[0037] The data import process for the security knowledge base includes source verification, structure transformation, version tagging, and relationship construction. When importing vulnerability records, the source document identifier and release date are saved; asset fingerprint records save the product name, version range, and identification fields; and test tactical records save the preconditions and allowed state transitions. When a knowledge entry is withdrawn or its version becomes invalid, the system updates its status to "unavailable for new path planning." Completed historical tasks retain snapshots of the evidence referenced at the time, thus demonstrating the knowledge version upon which the path generation was based.

[0038] In another implementation, the security knowledge base can use a single database to store vector fields and graph relationship fields, or multiple services can provide search results separately, as long as they can provide traceable evidence identifiers and state transition relationships for candidate path nodes. Message queues, state caches, and relational databases can also be implemented using middleware with equivalent functionality.

[0039] This embodiment utilizes a collaborative retrieval system combining vector and graph databases, and binds traceable knowledge evidence—including source, version, and applicable conditions—to each path node, ensuring that path generation is constrained by real knowledge and state transition relationships. This addresses the problem of large language models generating fictitious vulnerabilities, incorrect tools, or inapplicable test steps due to knowledge gaps, version mismatches, or unclear citation sources, thereby improving the interpretability and knowledge consistency of candidate test paths.

[0040] Example 3: Dependency edges between path nodes are generated by the planner and reconfirmed by the path validator. Dependency edges can be divided into hard dependencies and soft dependencies. Hard dependencies mean that the subsequent node must execute after the preceding node succeeds and produces a specified state; soft dependencies mean that the result of the preceding node is used to adjust the parameters of the subsequent node, but an alternative path can be selected if the preceding node fails. The scheduler only generates executable subtasks for nodes that satisfy all hard dependencies, and for nodes that do not satisfy soft dependencies, it selects degraded parameters or initiates replanning according to the substitution rules.

[0041] like Figure 4 As shown, multi-dimensional anti-illusion verification is implemented before, during, and after path generation. The first dimension is knowledge evidence constraint. Before path generation, the system provides the model with a filtered set of knowledge evidence, and after path generation, it verifies the knowledge evidence identifier node by node. The verification content includes whether the evidence exists, whether the evidence version is valid, whether the applicable product and version of the evidence matches the target fingerprint, and whether the preconditions described by the evidence have been met by the current path. Nodes with inconsistent evidence are marked as insufficient evidence and do not proceed to the next dimension of verification.

[0042] The second dimension is the compliance verification of operational rules. Rules can consist of role-based access control policies, address whitelists, prohibited operation sets, allowed tool sets, rate limits, and concurrency limits. The system converts each path node into a rule judgment object, sequentially checking the target address, operation type, parameter range, component version, and execution time limit. The rule verification result includes a pass flag, a rule hit identifier, severity, and correction suggestions. If a prohibited operation or target out-of-bounds rule is hit, the node is directly rejected; if a correctable rule is hit, correction suggestions are written to the correction context and the planner is requested to regenerate the rule.

[0043] The third dimension is path dependency reachability verification. The path verifier treats path nodes as graph nodes and dependency edges as directed edges, checking for the existence of circular hard dependencies, isolated nodes, and unreachable target nodes. For each adjacent node, the path verifier compares the expected state of the preceding node with the preceding state of the following node, and queries the graph database to see if the corresponding state transition is allowed. For example, a vulnerability template node adapted to a specific service only meets the prerequisite after the service identification node outputs a specific service fingerprint. If a service identification node is missing in the path, subsequent nodes are judged as having incomplete dependencies. Before distribution, the path verifier performs cycle detection and topology sorting on the hard dependency subgraph; when a circular hard dependency exists, it directly returns a dependency exception reason code without generating an executable topology sequence; topology sorting only determines the order of dependencies, and the actual distribution still needs to simultaneously satisfy the dependent subtask state and agent resource conditions.

[0044] The knowledge evidence consistency verification confirms that the product version referenced by N2 and N3 is consistent with the target clue. The rule compliance verification confirms that all three nodes are within the authorized target and allowed operation set, and the request rate is written into the operation constraint. The path dependency reachability verification confirms that N2 uses the protocol state of the previous node as a precondition, N3 uses the service fingerprint of N2 as a precondition, and the graph database has a corresponding state transition relationship, thus outputting a verified test path.

[0045] This embodiment verifies path reachability by using rules based on authorization target, time window, operation type, parameter range, and component version, combined with the preceding states and state transition relationships in a directed graph. This ensures that non-compliant nodes and nodes with invalid dependencies are rejected or replanned before execution. This solves the problem that a single blacklist is insufficient to identify path logic errors and situations where the current asset state does not support subsequent operations, reducing the probability of invalid and out-of-bounds execution.

[0046] Example 4: The fourth dimension is execution deviation monitoring. Before each subtask is executed, the scheduler writes the expected state of the path nodes into the subtask. After the agent reports the actual state, the execution monitor selects an applicable dimension from port status, service fingerprint, protocol response, return code, evidence completeness, and execution duration, and calculates the difference in each dimension. Discrete states can be recorded as zero when they have the same value and as one when they have different values; continuous states can be normalized by dividing the difference between the actual value and the expected value by the allowable range. The weights of each dimension are determined by the policy configuration. Execution deviation It can be determined by the following formula: ; In the formula, Indicates the number of state dimensions involved in the comparison. Indicates the first Normalized variance of each state dimension Indicates the first Weights for each state dimension, This indicates execution deviation. Weights and preset deviation thresholds are configured according to the task strategy; when a key state dimension is set as a hard constraint, branch blocking is triggered even if the overall execution deviation does not exceed the threshold, due to inconsistency in that key state. The execution monitor constructs a correction context from the deviation dimension, actual state, original expected state, and original path node identifier, and feeds it back to the path planner. To prevent the model from changing its safety judgment criteria during the inference process, the weights and deviation thresholds of each state dimension are read from the versioning strategy configuration and bound to the task identifier when the task is created; the configuration version remains unchanged during task execution unless the task is paused and switched with the confirmation of authorized personnel.

[0047] To further achieve verifiable adaptive calibration of the weights, the system can summarize historical deviation samples according to the policy calibration cycle. For the first... For each state dimension, the proportion of cases where an anomaly was triggered and confirmed as effective blocking after result evidence review or manual sampling is calculated, thus obtaining the confirmation contribution value. ;Will After normalizing to zero to one, the learning step size is used. The current weights are smoothly updated, and all candidate weights are normalized again to generate the next policy configuration version. An example update relationship is as follows: ; ; In the formula, Indicates the first The confirmed contribution value of each state dimension within the current calibration period. This represents a smooth update step size between zero and one. This represents the candidate weights before normalization. This indicates the normalized weights to be written to the next policy configuration version. The calibration process is performed in a separate policy update phase; running test tasks do not immediately rewrite their bound weight versions, thus maintaining consistent judgment criteria during the execution of the same task.

[0048] The fifth dimension is result evidence verification. The result verifier does not directly confirm test success based on the model's natural language judgment. Instead, it reads standardized results and original evidence summaries to verify the consistency of the target object, component version, timestamp, and return code. For conclusions supported by two independent types of evidence, the system comparison tool echoes the evidence against the protocol response evidence, or compares the currently executed evidence against the repeated verification evidence. The verifier outputs "verification passed," "verification failed," or "retry required," along with a list of anomalies and their confidence levels. If evidence is missing, points to different targets, or the result contradicts the expected state, the conclusion is not included in the final test result.

[0049] Each of the five dimensions generates a verification record. The verification record includes at least the task identifier, path node identifier, verification dimension, input summary, verification status, reason code, evidence identifier, and completion time. Subsequent dimension verification uses the set of nodes that passed the previous dimension verification; if any dimension fails, the system only rolls back the affected node and its successor nodes, without re-executing completed nodes that are unrelated to the exception and whose evidence is still valid, in order to reduce duplicate network requests.

[0050] In one implementation, the system maintains a version number for each path node. The planner initially generates a node with a version number of one; when rule verification, path validation, or execution deviations trigger corrections, a new version node is generated while retaining the original version. Unexecuted subtasks that depend on this node are updated to the new version, while executed subtasks retain their original versions and the reason for failure is recorded. The final report references the actually effective node version and corresponding evidence, facilitating a review of the path correction process.

[0051] The result reviewer compares the target identifier, execution time, component version, and original echo summary of ST3, confirming that the result is consistent with the service fingerprint of ST2, and confirming that at least two pieces of evidence support the same conclusion. After the review is passed, the data gateway updates the ST3 result, task status, and audit log in the same transaction. If the review finds insufficient echo, the status is set to "retry required"; if the retry still cannot form complete evidence, no affirmative vulnerability conclusion is output, but insufficient evidence is recorded in the report.

[0052] The results report is generated from the reviewed and approved path nodes and evidence records. Each finding in the report must be associated with at least the target object, path node version, knowledge evidence identifier, execution component version, execution time, review status, and audit record scope. For nodes with abnormal review status or insufficient evidence, the report uses a pending confirmation status and explains the missing evidence, without presenting model inferences as verified facts. After the report is generated, a file summary is calculated and written to the audit record, ensuring that the report content corresponds to the task results in the database.

[0053] In another implementation, the multi-dimensional anti-hallucination verification unit can add dimensions such as historical path consistency verification, inter-model cross-verification, or manual sampling review. The added dimensions still need to output verification status, reason codes, and evidence, and the task state machine determines whether to pass, roll back, or pause. They should not bypass authorized boundary verification, execution deviation monitoring, and result evidence review.

[0054] This embodiment calculates the execution deviation between the actual and expected states in multiple dimensions and performs consistency verification by combining execution evidence from independent sources. When the deviation exceeds a threshold, only the affected branches are blocked, and a corrective context is fed back. This solves the problems of predetermined paths failing due to dynamic changes in the execution environment, misjudgments arising from models relying solely on natural language feedback, and the continued propagation of abnormal branches, thereby improving the accuracy of results and the efficiency of closed-loop correction.

[0055] Example 5: Each subtask includes at least a task identifier, path identifier, path node identifier, node version, set of dependent subtasks, capability tags, input data, expected state, risk level, operational constraints, timeout value, number of retries, and idempotency key. The capability matcher selects agents from online agent registration information whose capability tags cover the subtask requirements, whose health status is normal, and whose current load is below a threshold. When multiple agents meet the requirements simultaneously, they can be sorted according to the current number of tasks, the most recent heartbeat time, and historical success rate. Capability matching adopts a two-stage selection: the first stage filters candidate agents according to whether the set of capability tags required by the subtask is covered by the agent's capability set and the health status; the second stage prioritizes agents with fewer current tasks in the candidate set, and can deterministically sort them by referring to the most recent heartbeat time and historical success rate when the load is the same.

[0056] In dynamic load balancing implementation, each candidate agent can be... Maintain the length of the queue to be executed Average execution latency of the most recent window Historical failure rate and computing resource utilization The values ​​are then normalized to zero or one. The scheduler calculates the dynamic load score according to the weights in the versioned scheduling policy. Choose the option that satisfies both ability and dependency conditions. A smaller intelligent agent. One calculation relationship for the dynamic load score is: ; In the formula, , , and These represent the scheduling weights corresponding to queue length, execution latency, failure rate, and resource utilization, respectively, with the sum of all weights being one. These weights are recalculated when the agent completes a task, reports operational metrics via heartbeat, or when the lease status changes. When two agents have the same score, they can be deterministically sorted according to the time they last received a task and the agent's identifier to reduce hotspots caused by continuously assigning tasks to the same node.

[0057] After starting up, the agent registers its agent type, host identifier, and capability set with the management service and sends heartbeats at preset intervals. The management service maintains the online status based on the most recent heartbeat time. Subtasks are sent to the queue corresponding to the capability tag via message queues; after consuming the message, the agent first publishes a claim event to the state sharing bus, and then invokes the atomic capability component. Upon completion, it reports the execution status, actual status, evidence set, and error information. After receiving the results, the scheduler writes them through the data gateway and determines whether the dependent subtasks can enter the executable state.

[0058] When an agent fails to execute a task, the scheduler determines the handling method based on the failure type. Recoverable errors such as temporary network unavailability or message processing timeouts can be re-enqueued after a maximum of the required retries. Semantic errors such as inapplicable components, changed target fingerprints, or execution deviations exceeding thresholds are not directly retried but are fed back to the multi-dimensional anti-illusion verification unit for path correction. When an agent loses connection, subtasks that have been claimed but not confirmed for completion are reassigned to other agents with the same capabilities after the lease expires.

[0059] The information sharing bus only transmits structured events related to collaboration, such as asset discovery, service confirmation, discovery of candidate vulnerabilities, evidence generation, subtask failure, and path update. Each event carries the source agent and evidence identifier. Other agents cannot generate new execution operations solely based on the event text; instead, the scheduler must generate subtasks based on the updated path nodes and authorization constraints, thus maintaining the separation of information sharing and execution control among agents.

[0060] The input data pattern for atomic capability components can include target address, target port, protocol type, component parameters, timeout value, and rate limit. The output data pattern can include return code, raw echo summary, identification result, evidence location, and exception information. The component adapter is responsible for converting the uniform input into parameters that the underlying tools can recognize and parsing the tool output into uniform results. The component adapter does not accept arbitrary command lines directly output by the model; all parameters must be mapped from defined fields and validated for type, length, and allowed values.

[0061] The plugin management service maintains component versions, digital digests, enabled status, and applicable environments. The scheduler only selects component versions that are enabled and whose digital digests have passed verification. Components run in restricted processes or containers, with execution environment settings including network scope, file system permissions, processor and memory limits. The isolated environment is reclaimed after execution completes or exceeds a timeout value. For components that require writing to temporary files, writing is only permitted to the task's dedicated temporary directory, and cleanup is performed according to the evidence retention policy after the task is completed.

[0062] The environment-adaptive adapter first performs low-impact protocol negotiation or service identification to determine the target operating system type and service type, and then selects an execution strategy based on the component's applicability. If the identification result is inconsistent with the target fingerprint in the path node, the adapter does not attempt to expand the detection range, but instead reports the actual fingerprint and triggers execution deviation handling. The controlled execution layer also applies request rate and concurrency limits to ensure that the request frequency for the same target does not exceed the authorized constraints.

[0063] In a security test example, the asset detection agent invokes the asset detection component to confirm open ports in the authorized address, the service identification agent generates a service fingerprint based on the protocol response, and the vulnerability detection agent only invokes templated detection components that match the service fingerprint and version conditions. The system retains the template identifier, template version, and echo summary, but does not specify the specific payload content in the specification. For candidate nodes requiring high-risk verification, the system... Figure 6 The process shown is pending approval, and the verification method can be restricted to read-only verification that does not change the target data.

[0064] For concurrent tasks, the scheduler maintains concurrency counts at both the task and target levels. The task-level concurrency count limits the number of subtasks that can execute simultaneously within the same task, while the target-level concurrency count limits the number of test requests that can be received simultaneously for the same target. Subtasks are incremented atomically upon acquisition and decremented upon completion, failure, cancellation, or lease expiration. If an agent exits abnormally, causing the count to not be released properly, the state monitoring service compensates based on lease expiration events to prevent tasks from remaining in a perpetual waiting state.

[0065] In another implementation, dedicated agents can be deployed on the same computing node or distributed across multiple test nodes. The scheduler selects agents based on capability tags and health status, thus deployment location does not alter the task breakdown and status feedback logic. For tasks requiring resource isolation, independent containers can be created for each subtask; for read-only probes with high response latency requirements and low risk, execution can be performed within a constrained process.

[0066] This embodiment generates subtasks based on topological dependencies, matches dedicated agents with capability tags, utilizes message queues and state sharing buses for asynchronous collaboration, and invokes atomic capability components encapsulated with a unified data pattern in an isolated environment. This solves problems such as task contention, repetitive execution, heterogeneous tool interfaces, agent disconnection, and mutual interference between execution environments in multi-asset concurrent testing, improving scheduling throughput, fault recovery capabilities, and component replaceability.

[0067] Example 6: The risk assessment service scores operations before subtask distribution. Scoring inputs may include a basic vulnerability score, operational risk value, target importance, and authorization constraint sensitivity. Each input is normalized to zero to ten, and weights are configured by the security policy. Risk Scoring It can be determined by the following formula: Wherein, the vulnerability base score associated with knowledge evidence can be obtained by normalizing the CVSS base score in the corresponding CVE record, and the operational risk value, target importance and authorization constraint sensitivity can be obtained by mapping the pre-configured risk matrix; the weights of each item are configured by the versioned security policy, rather than being directly generated or modified by the large language model at runtime.

[0068] ; In the formula, This represents the basic vulnerability score associated with knowledge evidence. Indicates the risk value of the operation type. Indicates the importance of the target. Indicates the sensitivity of authorization constraints. , , and These represent the corresponding weights. This represents the risk score. The system maps the risk score to low, medium, high, and severe levels based on configured thresholds. The score is only used to determine the execution control method and does not replace knowledge evidence and path verification.

[0069] like Figure 6 As shown, when the risk level reaches high or severe, or when a path node hits a mandatory approval rule, the scheduler does not distribute the subtask to the agent, but instead sets the subtask status to pending approval. The approval record includes the target object, operation type, knowledge evidence, risk score, impact analysis, atomic capability components, suggested constraints, and application time. The pending approval record is written to a relational database and simultaneously written to a cache queue, and a long-connection service pushes notifications to terminals with approval permissions.

[0070] The approval terminal can return "Approved," "Rejected," or "Approved with Additional Conditions." Upon approval, the scheduler re-verifies the authorization validity period and target status before resuming the subtask. Upon rejection, the system cancels the subtask and sends the rejection reason to the path planner, which can only generate an avoidance path that does not include the rejected operation. When approved with additional conditions, the approval terminal can limit the request rate, concurrency, execution time limit, allowed component versions, or evidence retention methods. The data gateway writes the additional conditions into the subtask, and the security constraint engine verifies them again before distribution.

[0071] Approval decisions have a limited validity period. If the target fingerprint, path node version, component version, or authorization scope changes after approval, the original approval decision is no longer directly applicable. The system will then re-assign the subtask to pending approval or re-assess the risk. This process prevents the approval of old paths from being reused for new paths whose content has changed. All events related to the creation, viewing, decision-making, restoration, and cancellation of the approval process are logged.

[0072] like Figure 5 As shown, the task decomposition and capability matching machine traverses the path nodes according to the topological order of the verified test path, converting each path node into one or more subtasks. For nodes that can be executed in parallel and do not have common resource constraints, the scheduler places the subtasks in the same parallel group; for nodes with hard dependencies, the subsequent subtask records the identifier of the previous subtask as a dependency. If the same target has a concurrency limit, the scheduler also assigns the subtasks to the corresponding rate-limiting buckets according to the target identifier.

[0073] Assuming the risk score of the operation corresponding to ST3 reaches the approval threshold, the system creates a pending approval record. Approver reviews the objective, component version, impact analysis, and rate limiting recommendations, then selects additional conditions to approve, adjusting the request per second limit to a lower value and setting an execution time limit. After the security constraint engine re-verifies, the scheduler writes the additional conditions into ST3 and distributes them. The controlled execution layer performs templated checks in an isolated environment, collecting return codes, protocol echo summaries, and template identifiers.

[0074] This embodiment uses risk quantification, a security constraint engine, and a manual approval module to suspend, reject, or conditionally allow high-risk operations, and invalidates the original approval when the target, path, or component changes. This solves the problems of automated systems lacking human-in-the-loop control for high-risk operations, the incorrect reuse of old approvals, and the inability to assign approval conditions to specific sub-tasks, thus improving the boundary security and approval effectiveness of high-risk testing.

[0075] Example 7: Figure 7 As shown in (a) above, the end-to-end audit service uses chained hashing to record task status changes and key operations. Audit Log This can include user ID, task ID, path node ID, operation type, resource type, resource ID, detail summary, source address, trace ID, and creation time. The data gateway normalizes and serializes the fields according to a fixed name order, fixed character encoding, and fixed null value representation to avoid different summaries for the same content due to different field orders. For example, user_id, task_id, path_node_id, operation_type, resource_type, resource_id, detail_summary, source_address, trace_id, and created_time can be treated as a fixed sequence of fields; missing fields are represented by fixed null values, and strings are encoded using a unified UTF-8 encoding before normalization and serialization. This field sequence is one example and can be adjusted while maintaining the fixed field order, encoding, and null value rules.

[0076] For the first audit record, the preceding hash can be set to a preset initial value. For the second... The audit record was read by the data gateway. Current hash of the audit record ,Will Compared with the current audit record The normalized serialized content is concatenated and the current hash is generated using a secure hash algorithm. The calculation relationship is as follows: In one specific implementation, the current hash uses SHA-256 pairs. The calculated hash and the current hash are written into the prev_hash field and the current_hash field, respectively. Here, SHA-256 is used for hash chain digest calculation. If sensitive fields need to be stored in encrypted form, a symmetric encryption mechanism can be used, but the hash chain digest function will not be replaced by a symmetric encryption algorithm.

[0077] ; In the formula, Indicates the first The current hash of the audit record. This indicates the current hash of the previous audit record. This represents the normalized serialized content of the current audit record, symbolized by... This indicates that the hashes are concatenated in a preset order. The audit query service can recalculate subsequent hashes starting from any record and compare them with the database value. If they do not match, the corresponding segment is marked as having an integrity anomaly. The hash chain is used to detect record changes and does not replace database access control and backup mechanisms.

[0078] For long-running tasks, the data gateway can also record data at preset intervals. Generate verification anchors. Each anchor must store at least the record sequence number, current_hash, task identifier, and creation time. Verification is required for the [record name missing]. When locating a record and its subsequent segments, the audit query service will first locate the record no later than the first record. The most recent trusted anchor point of each record is used to recalculate the sequence from that anchor point to the end of the target segment, without having to recalculate from the first record. When a new audit record is written, only the hash of the new record relative to the current tail of the chain is calculated and the next anchor point is updated, thus forming an incremental verification process.

[0079] In high-concurrency deployments, audit records can be consistently sharded according to task_id. Each shard maintains its own local hash chain and periodically writes the anchor digest, shard number, and time window identifier of each shard into the global anchor chain. During integrity verification, the global anchor chain is checked first, and then local incremental recalculation is performed on shards that have anomalies or require spot checks. This allows concurrent audit writes to reduce the serial computation pressure on a single global chain while maintaining the chain-like traceability relationship.

[0080] like Figure 7 As shown in (b), the global management service periodically calls the health check interfaces of the intelligent decision-making service and the agent management service. Each check records the response time and status code. If the intelligent decision-making service fails to respond three times consecutively or the number of consecutive timeouts reaches a configurable threshold, the task state machine marks the dynamic planning capability as unavailable, stops sending new path planning requests to the intelligent decision-making service, and enters a pre-defined rule template mode. The threshold of three times is one implementation example and can be adjusted according to the detection cycle and network conditions. Corresponding to one deployment method in the briefing, the L1 Go scheduling layer performs gRPC-based Heartbeat checks on the L2 Python intelligent decision-making service and the L3 Agent, respectively. When the Python intelligent decision-making service fails heartbeats three times consecutively or the number of consecutive timeouts reaches the configured threshold, only new dynamic path planning requests are bypassed, and the Go scheduler selects a fixed, non-destructive test template that has been manually reviewed from the pre-defined rule base.

[0081] The pre-defined rule template mode only selects fixed, non-destructive test templates that match the target type and have already undergone manual review, such as asset connectivity verification, port status identification, and authorized templated vulnerability detection. Templates contain clearly defined target fields, preconditions, execution steps, rate limits, and result judgment rules; dynamic expansion of operations based on free text is not allowed. Tasks already in the high-risk approval process remain suspended and will not be automatically released due to downgrading.

[0082] After the intelligent decision-making service recovers, the system first performs a health check request and knowledge base connection check, and confirms that the service version and path data pattern are compatible. After the health check passes a preset number of times consecutively, the task state machine allows new tasks to resume dynamic programming. Fixed template results that have been completed and verified during the degradation period are retained; dynamic path nodes that have not yet been executed undergo knowledge retrieval and path verification again, and the model outputs that were not completed before the failure are not directly used. During the recovery process, the compatibility of the gRPC service version and path data pattern is also checked; new tasks are allowed to re-enter dynamic programming only after the consecutive health checks reach the policy configuration number, and dynamic path nodes that have not yet been executed before the failure must complete knowledge retrieval, rule verification, and path dependency verification again.

[0083] The audit hash chain can be generated using the following logic, where canonical_serialize represents normalized serialization with a fixed field order: def append_audit_record(previous_hash, audit_record): canonical_bytes = canonical_serialize(audit_record) current_hash = sha256(previous_hash + canonical_bytes) audit_record.prev_hash = previous_hash audit_record.current_hash = current_hash persist_in_same_transaction(audit_record) return current_hash In the above process, the front end receives statuses such as "planning," "executing," "pending approval," and "completed" via long-lived connections. All statuses are determined by task status records in the relational database; the cache is only used for push and scheduling. During audit queries, the system sequentially verifies the preceding hash and current hash of each record to determine the integrity of records in the task creation, path planning, approval, execution, and result writing chain.

[0084] When a data gateway performs cross-table writes, it can use database transactions to ensure that task status, subtask results, and audit records are committed simultaneously. If any step in the audit hash calculation, business record writing, or transaction commit fails, the data gateway rolls back the write operation and returns a retryable error. The caller must not bypass the data gateway to independently write the business status. For duplicate writes caused by message consumption, the data gateway queries existing records using idempotent keys and returns the existing processing results, thus maintaining the uniqueness of the state in the relational database.

[0085] This embodiment unifies state write operations through a data gateway, writes business records and hash chain audit records within the same transaction, and switches to a pre-audited non-destructive template when the intelligent decision service malfunctions, and re-verifies unexecuted paths after recovery. This solves the problems of inconsistent state and audit results caused by scattered writes, difficulty in detecting modified audit records, and task loss of control or interruption due to model service failures, thus improving data integrity, traceability, and system resilience.

[0086] Example 8: As Figure 3 As shown, automated penetration testing begins with the creation of an authorized task. The user uploads a written authorization document or enters an authorization record identifier on the task creation interface, and inputs the test target. The system extracts the authorization subject, target address range, validity period, allowed operations, and restrictions. For fields that cannot be automatically extracted, the system requires user confirmation before generating the authorization range information. When the task starts, the system checks whether the current time is within the authorization validity period and test time window, whether the target address belongs to the authorized target set, and whether the authorization document is valid. If any condition is not met, the task remains in a pending verification state and returns a reason.

[0087] After authorization verification, the system verifies the user's identity token and role permissions, and sends the task request to the security constraint engine. The security constraint engine generates a verification request based on roles, resources, operations, and context, where the context may include the task risk level, target importance, current concurrency, and request rate. Upon successful verification, the data gateway creates a task record and writes the first audit record, changing the task status from "created" to "planned."

[0088] To illustrate the data interfaces between the layers, an interface snippet corresponding to this embodiment is given below. The code snippet describes data fields and call relationships, is not limited to a specific framework version, and does not contain payloads for performing destructive operations on the target. First, the intelligent decision-making service can use the following remote procedure call interface: syntax = "proto3"; service AIService { rpc PlanAttackPath(PlanAttackPathRequest) returns(PlanAttackPathResponse); rpc AssessRisk(AssessRiskRequest) returns (AssessRiskResponse); rpc ValidatePath(ValidatePathRequest) returns(ValidatePathResponse); rpc ReviewResult(ReviewResultRequest) returns(ReviewResultResponse); } message PlanAttackPathRequest { string task_id = 1; repeated AssetInfo assets = 2; repeated VulnerabilityInfo vulnerabilities = 3; StrategyConfig strategy = 4; } message PlanAttackPathResponse { string path_id = 1; repeated AttackNode nodes = 2; repeated AttackEdge edges = 3; float confidence = 4; repeated string evidence_ids = 5; } The task identifier in `PlanAttackPathRequest` is used to associate the task status. The asset set and vulnerability clue set are derived from the authorized target. The policy configuration includes allowed operations, rate limits, and approval thresholds. The nodes and edges in `PlanAttackPathResponse` constitute candidate test paths, and the evidence identifier set is used to constrain the node source. Risk assessment, path verification, and result review are each handled as independent interfaces, enabling the global management service to save interface inputs and outputs and verification status at different stages.

[0089] The data gateway, security constraint engine, and task scheduler in the global management layer can achieve specific data access and scheduling through interface isolation, for example: type DataGateway interface { CreateTask(ctx Context, task *Task) error UpdateTaskStatus(ctx Context, taskID string, status string) error CreateSubTask(ctx Context, subTask *SubTask) error UpdateSubTaskResult(ctx Context, subTaskID string, result Result)error CreateApproval(ctx Context, approval *Approval) error WriteAuditLog(ctx Context, log *AuditLog) error } type HarnessEngine interface { CheckOperation(ctx Context, op Operation) (*CheckResult, error) GetBlockedOperations(ctx Context, taskID string) ([]string, error) } type TaskScheduler interface { ScheduleTask(ctx Context, task *Task) error DispatchSubTask(ctx Context, subTask *SubTask, agentID string)error PauseTask(ctx Context, taskID string) error ResumeTask(ctx Context, taskID string) error } The DataGateway interface enables all business write operations to generate audit logs simultaneously. The HarnessEngine interface accepts a structured Operation object, which contains the target object, operation type, component identifier, and context constraints; it does not accept any unvalidated commands. The TaskScheduler interface performs scheduling, pausing, and resuming based on the task state machine.

[0090] A multidimensional anti-hallucination verification unit can consist of multiple verification layers with a unified check interface. A pseudocode example of the process without specific test loads is as follows: async def build_verified_path(context): evidence = await knowledge_constraint(context) candidate = await planner.generate(context, evidence) rule_result = await rule_validator.check(candidate,context.constraints) if rule_result.passed: return await replan(candidate, rule_result.reason) path_result = await path_validator.check(candidate,evidence.graph) if path_result.passed: return await replan(candidate, path_result.reason) return candidate async def monitor_and_review(node, actual_state, evidence): deviation = compare_state(node.expected_state, actual_state) if deviation > node.deviation_threshold: await block_branch(node.id) return await replan(node, deviation) return await result_reviewer.check(node, actual_state, evidence) In the pseudocode above, knowledge_constraint outputs the evidence set, and the planner generates candidate paths only within the context formed by the evidence set and the authorization constraints; rule_validator and path_validator output the pass status and reason, respectively; monitor_and_review blocks the branch before requesting replanning when the execution deviation exceeds the threshold, to avoid continuing to execute the successor node before the new path is generated.

[0091] The following is a complete example of business interaction. Testers create task T and upload valid authorization records. The authorization scope includes the target address set S, the daily test time window, the request limit per second, and the allowed operation set. The authorization task management service writes the authorization record status, target set summary, and authorization expiration time to task T. The security constraint engine confirms that the current user has the role permissions to create and start tasks, and confirms that the task target belongs to set S. The data gateway creates the task record and the first audit record.

[0092] The intelligent decision-making layer receives asset clues from task T. The vector database returns vulnerabilities and detection descriptions related to the service fingerprint, and the graph database returns the state transition relationships between service identification, template detection, and result verification. The system forms an evidence set E. The path planner generates nodes N1 to N3: N1 is used to confirm port and protocol status, N2 is used to identify the service fingerprint, and N3 is used to invoke the templated detection component adapted to the service fingerprint. Each node is bound to an evidence identifier and connected via dependency edges N1 to N2 and N2 to N3.

[0093] The scheduler converts N1 to N3 into subtasks ST1 to ST3. ST1 is distributed to the asset detection agent, while ST2 and ST3 remain in a waiting state. ST1 returns evidence of port openness and protocol response; if the execution deviation does not exceed the threshold and the result verification passes, ST2 enters the executable state. ST2 returns the actual service fingerprint; if the actual fingerprint differs from the expected fingerprint in the path, the execution monitor blocks ST3, writes the actual fingerprint into the correction context, and requests the planner to reselect a detection node that matches the actual fingerprint. If the actual fingerprint matches, ST3 enters the executable state.

[0094] To adapt threshold settings to different testing environments, the system can maintain policy configurations according to task type. Preset deviation thresholds, risk level thresholds, retry counts, heartbeat failure counts, and evidence completeness thresholds all have recorded configuration versions. When a task is created, the adopted configuration version is written to the task record. During task execution, even if the administrator publishes a new configuration, already started tasks will still use the original configuration unless the task is paused and switched by authorized personnel. The system can statistically suggest thresholds based on the actual status verified in historical tasks, but suggested values ​​must be approved before becoming effective configurations; security thresholds cannot be directly modified from model outputs.

[0095] This embodiment employs a sequentially connected method flow consisting of authorized task creation, knowledge retrieval, path generation and verification, subtask distribution, controlled execution, deviation monitoring, result verification, and persistence. The inputs and outputs of each stage are solidified through a unified interface and idempotent control. This addresses the problems of traditional penetration testing steps relying on manual sequencing, inconsistent interface semantics, duplicate messages leading to repeated tests, and the inability to recover from a clear state after anomalies, thus improving the determinism and feasibility of the automated process.

[0096] Example 9: This example corresponds to claim 9, and adds risk approval and service anomaly degradation control to the automated penetration testing method described in Example 8. Before subtask distribution, the system determines the risk level based on candidate test paths, operation types, target importance, and authorization constraints; when the risk level reaches the preset approval level, the corresponding subtask is paused, and the target object, operation details, risk level, impact analysis, proposed invoked components, and suggested constraints are written into the pending approval record, and the manual approval decision returned by the approval terminal is obtained.

[0097] When a manual approval decision is "approved," the system restores the corresponding subtask after re-verifying the authorization validity period and target status. When a manual approval decision is "rejected," the corresponding subtask is canceled, and a path replanning is triggered based on the rejection reason. When a manual approval decision is "approved with additional conditions," the rate limit, concurrency conditions, execution time limit, or component version conditions are written into the corresponding subtask, and the security constraint engine verifies them again before distribution. If the target fingerprint, path node version, component version, or authorization scope changes, the original approval decision becomes invalid, and the approval process re-enters.

[0098] Meanwhile, the system periodically acquires the heartbeat status of the intelligent decision-making service and records the response time and status code. When the number of consecutive heartbeat failures reaches a preset number, dynamic path planning stops, and no new planning requests are sent to the intelligent decision-making service. Instead, a fixed non-destructive test template that matches the test target type and has been manually reviewed is selected from the pre-set rule base. High-risk subtasks that are already in the pending approval state remain suspended and are not automatically released due to downgrading.

[0099] Once the intelligent decision-making service recovers, the system sequentially performs service health checks, knowledge base connection checks, and path data pattern compatibility checks. Dynamic path planning resumes after the health checks pass a preset number of times. Fixed template results completed during the degradation period and verified for consistency are retained. Dynamic path nodes that have not yet been executed undergo knowledge retrieval and path verification again; model outputs not completed before the failure are not directly used.

[0100] This embodiment incorporates risk level assessment, manual approval with additional conditions, and intelligent decision-making service heartbeat monitoring as pre-controls for subtask distribution during method execution. It also stops dynamic planning and selects a fixed, non-destructive template when a service fails. This addresses the issues of lack of manual intervention at high-risk nodes, approval constraints not following task execution, and the continued generation or distribution of uncontrollable operations when large-scale model services malfunction. It ensures the test method can safely degrade and recover under abnormal scenarios.

[0101] Example 10: The system described in this example can be deployed on one or more electronic devices. The electronic device includes a processor, memory, network interface, and bus. The memory stores program instructions, and when the processor executes these instructions, it implements authorized task management, knowledge retrieval, test path planning, multi-dimensional anti-hallucination verification, multi-agent scheduling, execution monitoring, result verification, and persistent auditing. The computer-readable storage medium can be a disk, solid-state storage, read-only memory, or other non-transitory media capable of storing program instructions.

[0102] The electronic device described in this embodiment can also communicate with independent policy labeling services, knowledge base synchronization services, and audit verification services to perform versioned weight updates, heterogeneous knowledge base synchronization, and incremental hash integrity verification, respectively.

[0103] This embodiment stores the program instructions for implementing the above-described automated penetration testing method in a computer-readable storage medium, enabling the processor to run according to a predetermined authorization, verification, scheduling, execution, and auditing process. This solves the problem of programmatic implementation and consistent execution of the method in different electronic devices or deployment environments, and facilitates system replication, upgrades, and engineering deployment.

[0104] Example 11: This example provides a test and evaluation method for quantitatively verifying the effectiveness of multidimensional anti-hallucination closed-loop, dynamic scheduling, and result verification. For the same set of authorized test samples, a baseline process and the process of this invention are configured separately. The baseline process uses single-rule filtering or fixed scheduling, while the process of this invention enables knowledge evidence consistency verification, path dependency verification, execution deviation closed-loop, version-based weighting, and dynamic load scoring. The final state of each sample is evaluated based on a confirmation label formed by manual verification results, target system logs, and independent execution evidence, and true positives are recorded. True negative False positives and false negatives .

[0105] Test accuracy False alarm rate and underreporting rate The following formulas can be used to calculate the results: ; ; ; In the formula, This indicates the number of test results that have been determined to be valid by the system and confirmed to be valid. This indicates the number of results that were determined to be invalid by the system and confirmed to be invalid. This indicates the number of results that the system determined to be valid but were later confirmed as invalid. This indicates the number of results that were not confirmed as valid by the system but were actually valid after review. In addition to the above indicators, it can also record the number of invalid nodes blocked before the candidate path is executed, the number of subtasks completed per unit time, the agent load dispersion, the average path replanning latency, the hash chain incremental verification time, and the average knowledge retrieval latency.

[0106] For the adaptive weighting mechanism, policy versions generated in multiple consecutive calibration periods can be replayed on the same validation set to compare the versions. and It saves version numbers, sample ranges, weight vectors, and evaluation results; for dynamic load balancing mechanisms, it can compare the average completion latency and load dispersion of two scheduling methods—fixed polling and dynamic load scoring—under a fixed agent size and the same task set; for incremental hash verification, it can compare the number of verification records and the time consumed by recalculating from the first record to the most recent verification anchor. This forms a quantitative R&D verification link that can be directly reproduced from system logs.

[0107] The above embodiments illustrate the main structure and processing of the present invention. Those skilled in the art can adjust specific communication protocols, database types, model types, index structures, caching strategies, weight calibration periods, scheduling weights, and verification anchor intervals without altering the overall technical concept of authorization boundary control, evidence constraint path generation, pre-execution verification, in-execution deviation feedback, post-execution evidence review, and multi-agent collaboration.

Claims

1. An automated penetration testing system based on multi-agent collaboration and multi-dimensional anti-hallucination mechanisms, characterized in that, It includes an authorized task management layer, an intelligent decision-making layer, a multi-dimensional anti-hallucination verification unit, a multi-agent collaborative scheduling layer, a controlled execution layer, and a data gateway; The authorization task management layer is used to obtain written authorization scope information, test target information and operation constraint information, establish a task status record corresponding to the test task, construct the target object, operation type, component identifier and task context of the test operation to be issued into an permission determination object, and verify whether the test operation is within the boundary defined by the written authorization scope information and the operation constraint information based on at least one of the authorization target scope, authorization time window, allowed operation set, rate limit and concurrency limit. The intelligent decision layer is used to retrieve a security knowledge base based on the test target information and generate candidate test paths based on the retrieved knowledge evidence. The candidate test paths include multiple path nodes connected by dependency edges. Each path node carries at least the target object, operation type, pre-state, expected state and knowledge evidence identifier. The multidimensional anti-illusion verification unit is used to sequentially perform knowledge evidence consistency verification, operation rule compliance verification, and path dependency reachability verification on the candidate test path. The knowledge evidence consistency verification verifies at least that the knowledge evidence identifier referenced by the path node exists, the version is valid, and the applicable conditions match the target fingerprint. The path dependency reachability verification verifies at least that the state inheritance relationship of adjacent path nodes matches the allowed state transition relationship in the security knowledge base, thus obtaining the verified test path. The multi-agent collaborative scheduling layer is used to decompose the verified test path into multiple sub-tasks according to the topological dependency relationship. Based on the capability tags of each sub-task, it selects candidate agents from online agents whose capability sets cover the required capabilities and whose health status is normal. It also distributes the multiple sub-tasks to the selected dedicated agents based on the current load of the candidate agents and receives the actual execution status and execution evidence reported by the dedicated agents. The controlled execution layer is used to call the atomic capability component corresponding to the subtask to perform non-destructive test operations after the authorized task management layer allows it, and convert discrete echoes into unified result data; The multi-dimensional anti-illusion verification unit is also used to select at least two applicable state dimensions from port status, service fingerprint, protocol response, operation return code and evidence completeness, determine the normalized difference of each state dimension, and synthesize the execution deviation between the expected state and the actual execution state according to the preset weight. When the execution deviation exceeds the preset deviation threshold, the corresponding path branch is blocked and the correction context containing the reason for the deviation is fed back to the intelligent decision layer for replanning. When the execution deviation does not exceed the preset deviation threshold, the unified result data is checked for consistency based on multi-source execution evidence. The data gateway is used to persist the task status record, the unified result data and the corresponding audit record after the result consistency verification is passed, and to perform normalized serialization of the current audit record using a fixed field order, fixed character encoding and fixed null value representation. It obtains the current hash value of the previous audit record as the preceding hash, and concatenates the preceding hash with the normalized serialized content of the current audit record to calculate the current hash value, so as to form an audit hash chain.

2. The automated penetration testing system according to claim 1, characterized in that, The security knowledge base includes a vector database for storing vulnerability entities and asset fingerprint entities, and a graph database for storing test tactical nodes, prerequisite nodes, state transition relationships, and historical path results. The vector database and the corresponding knowledge objects in the graph database share knowledge entity identifiers and knowledge version numbers. The intelligent decision layer is used to form a retrieval vector based on the test target information, obtain a preset number of candidate knowledge entities from the vector database based on the vector approximate nearest neighbor index, obtain the path relationships associated with the candidate knowledge entities from the graph database, and write the knowledge entity identifier, source version, applicable target conditions, and retrieval similarity into the knowledge evidence set. For duplicate retrieval requests with the same target fingerprint digest, knowledge version, and policy version, the candidate knowledge entity cache is reused, and the corresponding cache is invalidated when any version changes; only knowledge objects whose knowledge entity identifier and knowledge version number are consistent in the vector database and the graph database, whose source is valid, and whose applicable conditions match the target fingerprint are used to generate the candidate test path.

3. The automated penetration testing system according to claim 2, characterized in that, The compliance verification of the operation rules includes sequentially verifying whether the target address belongs to the authorized target set, whether the current time belongs to the authorized time window, whether the operation type belongs to the allowed operation set, whether the operation parameters meet the rate limit and concurrency limit, and whether the called atomic capability components have a valid version identifier; the path dependency reachability verification includes mapping the candidate test path to a directed graph, judging one by one whether the previous expected state of the adjacent path node meets the next preceding state, and querying the graph database to see if there is an allowed state transition relationship between adjacent path nodes. If any verification fails, a reason code and the identifier of the path node to be corrected are output.

4. The automated penetration testing system according to claim 1, characterized in that, For discrete state dimensions, the difference is recorded as zero when the actual value is the same as the expected value, and as one when they are different. For continuous state dimensions, the absolute value of the difference between the actual value and the expected value is normalized relative to the allowable range of variation. The initial weights of each state dimension and the preset deviation threshold are determined by the strategy configuration version bound to the test task. After the strategy calibration period ends, the candidate weights of the next strategy configuration version are updated and normalized according to the confirmation contribution value of each state dimension to the effective blocking result in the historical deviation sample. Test tasks that have already started continue to use the strategy configuration version bound to them when they were created. When the key state dimensions configured as hard constraints are inconsistent, the corresponding path branch blocking is directly triggered. The result consistency verification includes verifying the consistency between the execution evidence and the target object, the consistency between the unified result data and the original echo, the consistency between at least two independent types of evidence, and the consistency between the result timestamp and the task execution time window.

5. The automated penetration testing system according to claim 1, characterized in that, The multi-agent collaborative scheduling layer maps the verified test path into a directed acyclic graph with path nodes as graph nodes and dependent edges as directed edges, and generates subtasks according to topological order. Each subtask includes a task identifier, a parent path node identifier, a set of dependent subtasks, a capability label, an input data pattern, an output data pattern, a timeout value, and an idempotent key. The multi-agent collaborative scheduling layer first filters online agents according to capability labels and health status, then normalizes and weights the candidate agents' queue length, recent execution latency, historical failure rate, and processor or memory resource utilization to form a dynamic load score. The selection order of candidate agents is determined according to the dynamic load score, and the dynamic load score is refreshed when a task completion event or heartbeat status update occurs. The subtasks are asynchronously distributed through a message queue, and the agent status and subtask status are published through a state sharing bus. The current subtask is set to an executable state only after all dependent subtasks have reached a preset completion status. The atomic capability components encapsulate asset detection tools, vulnerability detection tools, or controlled verification plugins using a unified input / output data pattern and run in a restricted environment.

6. The automated penetration testing system according to claim 1, characterized in that, The authorized task management layer also includes a security constraint engine and a high-risk operation approval module; the security constraint engine is used to form a structured permission judgment object based on user role, target resource, operation type and task context, and output the permission verification result in combination with the target whitelist, prohibited operation set and rate limiting concurrency strategy. The high-risk operation approval module is used to switch the task status of the corresponding subtask to the pending approval status when the risk level reaches the preset approval level. It writes the operation details, risk level, impact analysis and constraint suggestions into the pending approval queue and pushes them to the approval terminal. Based on the approval decision returned by the approval terminal (pass, reject, or pass with additional conditions), it restores the subtask to the executable state, cancels the subtask and triggers the avoidance path replanning, or writes additional constraints into the subtask and re-executes the verification of the security constraint engine, and restores the subtask after the verification passes.

7. The automated penetration testing system according to claim 1, characterized in that, The data gateway is used to converge the status write operations of tasks, subtasks, approvals, and execution results to a unified write interface. It normalizes and serializes the preceding hash field with at least one of the following in the current audit record: user identifier, task identifier, path node identifier, operation type, resource identifier, details summary, tracking identifier, and creation time, according to a preset field order. It calculates the current hash value using the SHA-256 secure hash algorithm and persists it in the same transaction as the business record. It generates integrity verification anchors containing record sequence numbers and current hash values ​​at preset record intervals. During integrity review, it recalculates subsequent hashes sequentially starting from the trusted verification anchor closest to the record to be verified to perform incremental integrity verification. The authorized task management layer is also used to perform heartbeat detection on the intelligent decision layer and the dedicated intelligent agent. When the number of consecutive heartbeat failures reaches a preset number, it bypasses dynamic path planning and switches to a pre-approved fixed non-destructive test template mode. After the intelligent decision service recovers, it sequentially passes service health verification, knowledge base connection verification, and path data mode compatibility verification. After passing the preset number of consecutive tests, it switches back to dynamic path planning mode.

8. An automated penetration testing method based on multi-agent collaboration and multi-dimensional anti-hallucination mechanisms, characterized in that, include: The process involves acquiring written authorization scope information, test target information, and operational constraint information; establishing test tasks; constructing permission judgment objects containing target objects, operation types, component identifiers, and task contexts for the test operations to be issued; verifying authorization boundaries; retrieving security knowledge bases based on the test target information; generating candidate test paths consisting of multiple path nodes and dependency edges; ensuring each path node carries a knowledge evidence identifier, knowledge version, pre-existing state, and expected state; sequentially verifying knowledge evidence consistency, operational rule compliance, and path dependency reachability of the candidate test paths to obtain verified test paths; decomposing the verified test paths into multiple sub-tasks according to their topological dependencies; and distributing these sub-tasks to dedicated intelligent agents with matching capabilities based on capability tags, health status, and dynamic load scores generated from agent operation metrics. After the authorization boundary verification passes, the atomic capability component is invoked to perform non-destructive testing operations and obtain the actual execution status and execution evidence. Normalized difference quantities are determined from at least two applicable state dimensions, and the execution deviation between the expected state and the actual execution state is synthesized according to the weights in the policy configuration version. When the execution deviation exceeds a preset deviation threshold, the corresponding path branch is blocked, and the test path is replanned based on the cause of the deviation. When the execution deviation does not exceed the preset deviation threshold, result consistency verification is performed based on multi-source execution evidence. After the result consistency verification passes, the test results and task status are persisted by the data gateway. The current hash value of the previous audit record is concatenated with the normalized serialized content of the current audit record to calculate the current hash value to form an audit hash chain. Incremental integrity verification is performed on the audit hash chain based on periodic verification anchors.

9. The automated penetration testing method according to claim 8, characterized in that, Before distributing the subtask, the process also includes determining the risk level based on the candidate test path, operation type, target importance, and authorization constraints. When the risk level reaches a preset approval level, the corresponding subtask is paused and a manual approval decision is obtained. When the manual approval decision is to pass with additional conditions, the rate limit conditions, concurrency conditions, execution time limits, or component version conditions returned by the approval terminal are written into the subtask. Furthermore, the system periodically acquires the heartbeat status of the intelligent decision-making service. When the number of consecutive heartbeat failures reaches a preset number, dynamic path planning is stopped, and a fixed non-destructive test template matching the test target type is selected from the pre-set rule base. Dynamic path planning is resumed after the intelligent decision-making service recovers and passes the health check.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the automated penetration testing method as described in claim 8 or 9.

Images