Multi-agent dynamic orchestration and safe scheduling system based on model software

Abstract

This invention belongs to the technical field of computer system management, and relates to a multi-agent dynamic orchestration and secure scheduling system based on model-based software. The system includes: an intent parsing and risk labeling module, which outputs intent operation sequences; a security context token generation module, which creates security context tokens containing permission locks and operation licenses; a state machine scheduling and execution module, which schedules agents to execute operation steps with a risk level lower than a preset security threshold; a gating verification scheduling module, which outputs verification reports; and a binding execution authorization module, which receives the verification reports, updates the status of the security context tokens to authorized or terminates the current task flow and triggers a security mechanism. This invention solves the problem of lacking security constraint mechanisms for high-risk operations, lacking permission control and operation boundary limitation measures, and making it difficult to prevent security incidents caused by permission abuse.

Description

Technical Field

[0001] This invention belongs to the technical field of computer system management and relates to a multi-agent dynamic orchestration and secure scheduling system based on model-based software. Background Technology

[0002] With the rapid development of artificial intelligence and distributed system technologies, multi-agent collaborative architecture has been widely applied in complex scenarios such as computer system management and network security testing due to its advantages. However, current multi-agent scheduling systems typically have the following limitations in terms of secure scheduling: First, they lack a risk classification mechanism for task operations. They only manage agent behavior through simple permission divisions, which cannot accurately assess the risk level based on the operation type and target object attributes. This leads to high-risk operations being scheduled together with low-risk operations, resulting in insufficient targeted security control. Second, high-risk operations lack effective dual security constraints. There is neither a pre-execution verification mechanism nor operational boundary restrictions during execution, making them prone to security incidents due to permission abuse or malicious exploitation of agents.

[0003] To address some technical issues in multi-agent collaboration, existing technologies have proposed relevant optimization solutions. For example, the multi-agent penetration testing tool orchestration and unified invocation method and computer equipment disclosed in application number 202511805862.6, by constructing a semi-centralized multi-agent collaboration framework composed of a master agent, a reconnaissance agent, and an attack agent, and by using dynamic knowledge graphs to model the relationships between hosts, ports, services, and vulnerabilities, automates the entire penetration testing process.

[0004] However, existing technologies focus on penetration testing tasks, with the design goal of efficiently completing vulnerability detection and exploitation. They are not optimized for the security scheduling needs of dynamic orchestration of multiple agents in general computer system management, lack security constraint mechanisms for high-risk operations, and do not set up permission control and operation boundary limitation measures, making it difficult to prevent security incidents caused by permission abuse. At the same time, the security verification process depends on the knowledge fusion stage and does not achieve the decoupling design of task execution flow and security verification flow. When facing diverse high-risk operations in general system management, the security and controllability are insufficient. Summary of the Invention

[0005] To address the aforementioned problems, this invention provides a multi-agent dynamic orchestration and secure scheduling system based on modeling software.

[0006] A multi-agent dynamic orchestration and safe scheduling system based on model-based software includes:

[0007] The intent parsing and risk labeling module parses externally inputted high-level task instructions into atomic operation steps with a logical sequence, and outputs a structured sequence of intent operations with risk labels.

[0008] The security context token generation module iterates through the sequence of intent operations marked with risk and creates security context tokens containing permission locks and operation licenses for high-risk operation steps with risk levels higher than the preset security threshold.

[0009] The state machine scheduling and execution module constructs a task state machine based on the intention operation sequence, maps high-risk operation steps to gated state nodes and associates them with the bound security context token, and schedules the intelligent agent to execute operation steps with a risk level lower than a preset security threshold.

[0010] The gating verification scheduling module extracts the permission lock from the corresponding security context token when the task state machine transitions to the gating state node. Based on the pre-verification conditions defined in the permission lock, it schedules the verification agent to verify the output data and outputs a verification report with a digital signature.

[0011] The binding execution authorization module receives the verification report. If the report conclusion meets the pre-verification conditions, it updates the status of the security context token to authorized, extracts the operation license as the running parameter, and schedules the agent to execute high-risk operation steps within the scope defined by the operation license. If the conditions are not met, it terminates the current task process and triggers the security mechanism.

[0012] In a further embodiment of the present invention, the intent parsing and risk labeling module is used to perform the following steps:

[0013] The program's intelligent model decomposes high-level task instructions into atomic operation steps with a logical sequence.

[0014] Assess the potential impact of atomization steps on the target procedure and label the risk level;

[0015] Based on the risk level of atomic operation steps, define the safety assertions that must be satisfied before execution;

[0016] Atomized operation steps, risk levels, and security assertions are combined into a structured sequence of intended operations.

[0017] A further aspect of this invention involves assessing the potential impact of atomization operations on the target program to classify risk levels, including the following steps:

[0018] Obtain the step type and target object properties of the atomic operation steps;

[0019] A composite risk value is calculated using a pre-defined risk assessment algorithm, which involves a weighted sum of the basic risk score for each step type and the risk score for the target object's attributes.

[0020] The composite risk value is mapped to a pre-defined set of discrete risk levels to determine the risk level of the atomized operation step.

[0021] A further aspect of the present invention involves creating a security context token that includes a permission lock and an operation license, comprising the following steps:

[0022] Read the list of security assertions corresponding to high-risk operation steps, concatenate the logical expression text of the security assertions and add a verification condition header to generate an access lock string;

[0023] The process parses the content of high-risk operation steps, retrieves the corresponding constraint template from the pre-set permission rule library according to the step type, fills the target object and step parameters into the constraint template, and generates an operation license object containing the allowed operation scope field.

[0024] A further aspect of the present invention involves constructing a task state machine based on an intentional operation sequence, comprising the following steps:

[0025] Map each atomic operation step in the intended operation sequence to a state node of the task state machine;

[0026] Mark the state nodes corresponding to high-risk operation steps as gated state nodes that require condition triggering;

[0027] Write the identifier of the security context token into the binding field of the gated state node.

[0028] A further aspect of this invention involves scheduling the intelligent agent to operate at a risk level below a preset safety threshold, comprising the following steps:

[0029] When the task state machine transitions to a normal state node corresponding to a low-risk operation step, the standard low-risk operation agent is scheduled to execute that step.

[0030] Receive the execution result returned by the standard low-risk operation agent, and store the execution result as the output data of the executed step in the context data cache of the task state machine with the step index as the key.

[0031] A further aspect of this invention involves scheduling a verification agent to verify the output data based on pre-verification conditions defined in the permission lock, including the following steps:

[0032] The extracted permission lock string is parsed to identify the pre-verification conditions and instantiated into a verification task descriptor containing the task type and input data identifier.

[0033] Extract the output data of the executed steps from the context data buffer based on the input data identifier;

[0034] Select a verification agent based on the task type, and send the verification task descriptor and the extracted output data to the verification agent to execute the verification logic.

[0035] A further aspect of the present invention involves receiving a verification report, including the following steps:

[0036] Use the pre-stored public key of the corresponding verification agent to decrypt and verify the digital signature of the verification report;

[0037] If the signature verification passes, the Boolean conclusion field in the verification report is parsed and compared with the conditions required by the access lock to determine whether the pre-verification conditions are met.

[0038] A further aspect of the present invention involves scheduling an intelligent agent to perform high-risk operations within the scope defined by an operating license, comprising the following steps:

[0039] Extract the operation license from the authorized security context token;

[0040] The operation license is passed to the agent as an operational parameter;

[0041] During execution, the intelligent agent restricts the scope of operations related to system calls, memory access addresses, or file paths based on the operating license.

[0042] A further aspect of the present invention involves triggering a security mechanism, including the following steps:

[0043] Generate a security alert event containing the failure node identifier and a verification report summary and send it to the monitoring system;

[0044] Trigger the rollback mechanism, schedule the rollback agent to read the intermediate state data stored in the context data cache, and restore the system state to the consistency checkpoint before the high-risk operation steps were executed.

[0045] In summary, the present invention has the following beneficial technical effects:

[0046] 1. Create a security context token bound to high-risk operation steps and define dual security constraints including permission locks and operation licenses. Authorize high-risk operations during multi-agent task execution. The permission lock is generated based on security assertions parsed from the task intent. The execution of high-risk operations is premised on passing context-related security verification. The operation license defines the operation boundary for the authorized operation after verification, reducing the probability of security events caused by exceeding the permission limit or the agent being exploited.

[0047] 2. Construct a task state machine and map high-risk operation steps to gating state nodes that require condition triggering to achieve decoupling and asynchronous scheduling of task execution flow and security verification flow. When the state machine flows to the gating node, the main task flow is paused, and the verification agent is scheduled to verify the preconditions defined in the permission lock. The task execution logic and security verification logic are separated, and the verification process is executed by the agent. The separated scheduling mechanism enhances the verification process and provides security checkpoints for the entire task flow.

[0048] 3. When scheduling high-privilege agents to perform operations, the operation license extracted from the security context token is passed as a running parameter, which restricts the execution of high-risk operations to the minimum privilege range. After receiving the operation license, the internal execution logic of the high-privilege agent is designed to execute tasks according to the operation range defined in the license. After the high-privilege agent is authorized, any operation attempts that exceed the scope of the license will be blocked by its own security mechanism, realizing continuous supervision and hard restriction of authorized behavior, thereby improving security. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings are used to provide a further understanding of the present invention.

[0050] Figure 1 A schematic diagram of the framework in the embodiments of this application is disclosed.

[0051] Figure 2 A flowchart illustrating an embodiment of this application is disclosed. Detailed Implementation

[0052] The following is in conjunction with the appendix Figures 1-2 A preferred description of the present invention is provided below.

[0053] See attached document Figures 1-2 This invention proposes a multi-agent dynamic orchestration and secure scheduling system based on model-based software, comprising:

[0054] The intent parsing and risk labeling module parses externally inputted high-level task instructions into atomic operation steps with a logical sequence, and outputs a structured sequence of intent operations with risk labels.

[0055] The security context token generation module iterates through the sequence of intent operations marked with risk and creates security context tokens containing permission locks and operation licenses for high-risk operation steps with risk levels higher than the preset security threshold.

[0056] The state machine scheduling and execution module constructs a task state machine based on the intention operation sequence, maps high-risk operation steps to gated state nodes and associates them with the bound security context token, and schedules the intelligent agent to execute operation steps with a risk level lower than a preset security threshold.

[0057] The gating verification scheduling module extracts the permission lock from the corresponding security context token when the task state machine transitions to the gating state node. Based on the pre-verification conditions defined in the permission lock, it schedules the verification agent to verify the output data and outputs a verification report with a digital signature.

[0058] The binding execution authorization module receives the verification report. If the report conclusion meets the pre-verification conditions, it updates the status of the security context token to authorized, extracts the operation license as the running parameter, and schedules the agent to execute high-risk operation steps within the scope defined by the operation license. If the conditions are not met, it terminates the current task process and triggers the security mechanism.

[0059] In one embodiment of the present invention, the intent parsing and risk labeling module is used to perform the following operations:

[0060] The program intelligence model decomposes high-level task instructions into atomic operation steps with a logical sequence; assesses the potential impact of atomic operation steps on the target program to mark risk levels; defines safety assertions that must be satisfied before execution of atomic operation steps based on risk levels; and combines atomic operation steps, risk levels, and safety assertions into a structured sequence of intent operations.

[0061] In one embodiment of the present invention, assessing the potential impact of the atomization operation step on the target program to classify the risk level includes the following steps:

[0062] Obtain the step type and target object attributes of the atomized operation steps; calculate the composite risk value using a preset risk assessment algorithm, which involves a weighted sum of the basic risk score of the step type and the risk score of the target object attributes; map the composite risk value to a preset set of discrete risk levels to determine the risk level of the atomized operation steps.

[0063] Specifically, the intent parsing module, located in the task orchestration and security scheduling execution engine, receives task instructions from external systems via a RESTful API interface. This RESTful API is a standardized interface for clients and servers to exchange information over the Internet. The interface transmits task instructions in JSON format, which are text strings with a length not exceeding 256 characters. These instructions describe unstructured operational requirements for the target binary program, such as diagnosing and repairing memory leaks in the server.bin file under high load. The intent parsing module then calls the program intelligence model deployed in the local memory of the same execution engine to automatically parse the advanced task instructions. The program intelligence model is based on a deep learning model with a Transformer architecture. It is a language model that adjusts instructions based on operational requests and corresponding operation log corpora. It can also understand professional terminology in the operational field and map natural language instructions into structured operation sequences.

[0064] The parsing process uses a program intelligent model to segment and perform dependency parsing on the text of high-level task instructions, extracting core action verbs, target objects, and constraints. These semantic elements are then filled into a predefined operation semantic template, resulting in a structured parsing result. The parsing result is expressed as a list of atomic operation steps with a logical sequence. Each step is represented by a triplet data structure, which includes the step type, target object, and step parameters.

[0065] The risk assessment module in the execution engine iterates through the list of atomic operation steps. For each atomic operation step in the list, the risk assessment module evaluates it based on a pre-defined risk assessment algorithm. The input to the risk assessment algorithm is the triplet content of the atomic operation step. Internally, the risk assessment algorithm matches the step type with a pre-defined risk keyword library and combines it with the attributes of the target object to calculate a quantified risk value that satisfies the following formula:

[0066]

[0067] in, Indicates the first The composite risk value of each atomization operation step; Indicates the type of this step. It is a lookup function that returns a predefined base risk score for the step type, ranging from 0 to 1; This indicates the target object attribute of this step. It is a function that returns a risk score for an object based on factors such as whether the object is a critical core program and whether there are known vulnerabilities. The score range is also between 0 and 1. and These are preset weighting coefficients. foot .

[0068] The system has two preset safety thresholds to classify and control risks. The first is a risk level label threshold, which is a preset discrete label, such as "high". When the risk level of an atomic operation step is labeled "high", the system will identify it as a "high-risk operation step" that requires enhanced safety control. The second is a risk value mapping threshold, including a low-risk upper limit threshold. and high-risk lower limit threshold The risk assessment module calculates the composite risk value based on the formula. Comparison with risk value mapping threshold, if < If, then it is mapped to a low-risk level; if ≤ < If so, it is mapped to a "medium" risk level; if ≥ If the risk level is high, it is mapped to a “high” risk level. The risk value mapping threshold is determined based on the statistical analysis of historical operation logs, the potential impact assessment of common vulnerabilities, and industry security standards. It can be adjusted in the system configuration file. The risk level label threshold is used to trigger the security control mechanism for the highest risk level operation in subsequent processes.

[0069] Low risk upper limit threshold and high-risk lower limit threshold The settings are based on risk quantification and grading methods widely used in the field of information security. For example, the Common Vulnerability Scoring System (CVSS) classifies risk values ​​of 0.1-3.9 as "low," 4.0-6.9 as "medium," and 7.0-10.0 as "high." Similar proportional relationships are mapped to a normalized risk value range of 0-1, and the high-risk lower limit threshold is set as the dividing point between medium and high risk. Setting it to 0.7 will serve as the dividing line between low and medium risk. With a setting of 0.3, 30% of risky operations are classified as "low risk". These operations are usually read-only queries, status monitoring, log analysis, etc., which have low inherent impact and are easy to roll back. The system adopts a standard, low-overhead scheduling strategy for such operations, thereby improving the overall task execution efficiency while ensuring basic safety.

[0070] The risk assessment module queries the security rule base based on the risk level and instantiates one or more verifiable security assertions. Security assertions are conditions defined in the form of logical expressions that must be true before the step is executed. For example, for a step with a high risk level that modifies the memory management function of a binary file, the generated security assertion is that the memory access range of the generated target code does not exceed the range of the original function, and the modified file must pass the address space layout randomization compatibility check.

[0071] The security rule base is a key-value database that represents risk levels or specific operation types. The values ​​of the security rule base are one or more security assertion templates. Security assertion templates are frameworks of logical conditional statements predefined according to industry security standards and internal audit requirements when deploying the system. During execution, they are populated with specific context parameters to be instantiated as executable verification conditions. For example, the modified file hash value equals the expected hash value. It is a baseline value representing a correct or secure state obtained during the task initialization phase or through a pre-set baseline file library, such as the SHA-256 hash value pre-calculated and stored for a known secure version of the binary file.

[0072] The risk assessment module integrates and encapsulates atomic operation steps with logical sequence, risk levels marked for each step, and defined security assertions into a JSON data format object. This JSON object is a data structure used to represent an unordered collection of key-value pairs. The JSON object is the structured risk-marked sequence of intent operations generated in this step. The sequence serves as a data carrier and can be used for subsequent scheduling and security verification processes by the execution engine.

[0073] For example, suppose the high-level task instruction from external input is a diagnostic and repair program, such as data_processor.bin, referring to an executable binary file or script related to data processing. In a concurrent scenario involving data race conditions, the intent parsing module calls the program's intelligent model to parse it, obtaining a list containing three atomic operation steps:

[0074] Step 1 involves running the data race detection tool ThreadSanitizer on the target program, with the type set to analysis and diagnosis and the parameters set to tool options.

[0075] Step 2 involves locating and generating a memory region patch for atomic operation replacement based on the detection report. The type of patch is code generation, and the parameter is the report path.

[0076] Step 3 involves applying the patch to the memory image of the program copy in the sandbox environment. The type of the patch is memory patch, and the parameters are the patch file path and the sandbox program handle.

[0077] The risk assessment module evaluates each step according to a formula, and assigns a basic risk score to each step for type analysis and diagnosis in step 1. The risk score is relatively low, assumed to be 0.2, and the target object is a typical business application. Set it to 0.1, and take... , ,set up =0.6 higher than =0.4 Based on judgment, high-risk operations, such as memory writes and system call hijacking, can immediately lead to process crashes or security vulnerabilities even when applied to ordinary objects, while low-risk operations, such as log reading, have relatively limited direct harm even when applied to critical objects. Therefore, assigning a higher weight to the risk of operation types reflects the design consideration that operation behavior types have a higher weight in risk assessment.

[0078] Based on the above calculations, , obtained Value below the low-risk upper limit threshold Therefore, step 1 is marked as low risk and an empty list of security assertions is generated.

[0079] For step 3, the basic risk score for its type memory patching The risk score is extremely high, assumed to be 0.9. Furthermore, the target object is a copy of a core business application, indicating high importance and a risk of memory manipulation vulnerabilities. Therefore, the object risk score is... It should be increased, set to 0.6, and the calculation yields... , obtained Value higher than the high-risk lower limit threshold Therefore, step 3 is marked as a high-risk level.

[0080] The risk assessment module queries the security rule base based on the high-risk level. The security rule base predefines two security assertion templates for high-risk operations such as memory patching: "The patch operation does not involve inter-process communication (IPC) related system calls" and "The assertion and the patch segment permission set are a subset of the original segment permission set".

[0081] The module fills the specific parameters of step 3 into the security assertion template, instantiates and generates two specific security assertions, and encapsulates all information into a new structured risk-tagged intent operation sequence JSON object, where step 1 contains its logical order, low risk level and no security assertion; step 3 contains its logical order, high risk level and the above two instantiated security assertions for use in subsequent steps.

[0082] In one embodiment of the present invention, creating a security context token containing a permission lock and an operation license includes the following steps:

[0083] Read the list of security assertions corresponding to high-risk operation steps, concatenate the logical expression text of the security assertions and add a verification condition header to generate an access lock string; parse the content of the high-risk operation steps, retrieve the corresponding constraint template from the preset permission rule library according to the step type, fill the target object and step parameters into the constraint template, and generate an operation license object containing the allowed operation scope field.

[0084] Specifically, the token management module located in the task orchestration and security scheduling execution engine receives the structured risk-tagged intent operation sequence generated by the intent parsing and risk labeling module, initializes an empty array to temporarily store the generated security context token, and iterates through each atomic operation step in the risk-tagged intent operation sequence in a sequential iterative manner. For the currently traversed atomic operation step, it accesses the risk level field in its data structure to obtain the risk level label of that step.

[0085] The risk level label is compared with the preset risk level label threshold. The risk level label threshold is a string constant loaded from the configuration file when the execution engine starts. It is used to trigger high-risk identification. Its string is "high". The risk level label threshold is set based on the risk level classification defined in the intent parsing and risk labeling module. The highest level is set as the risk level label threshold to ensure that the operation with the greatest potential harm is subject to key control.

[0086] If the risk level of the current step is equal to the risk level label threshold, the step is determined to be a high-risk operation step; otherwise, it is determined to be a non-high-risk step. When a high-risk operation step is identified, a local hash function is called to generate a globally unique 128-bit identifier in combination with the timestamp, which serves as the token ID of the security context token. At the same time, a binding field is established in the token's data structure to uniquely associate the token ID with the logical order index value of the high-risk operation step in the intent operation sequence.

[0087] A security context token is a digital credential object that contains four essential attributes: token ID, binding step index, permission lock, and operation license. The token ID is used to uniquely identify the authorized credential instance in a distributed scheduling environment.

[0088] The security context token defines dual security constraints. The generation process of the access lock is based on the string expression that encodes all the pre-verification conditions generated by security assertions. Its content comes from the list of security assertions defined for the corresponding steps in the intention operation sequence of the risk marker. The logical expression text of these security assertions is concatenated according to a preset format, and a verification condition header is appended to the concatenated string to form a complete access lock string. For example, if there are two security assertions, the access lock is "security assertion 1 and security assertion 2 are satisfied at the same time".

[0089] An operation permit defines a JSON object that minimizes the scope of the operation. Its generation relies on predefined constraint templates in the permission rule base. The generation process involves parsing the triplet content of high-risk operation steps, retrieving the corresponding constraint template from the predefined permission rule base based on the step type, and populating the template with the target object and step parameters to instantiate the operation permit object. The permission rule base is a key-value pair store, where the key is the step type and the value is a JSON-formatted constraint template. For example, for the "memory patch" type, it includes a allowed memory address range field and a system call whitelist field. The generated security context token is added to a temporary storage array, and after iteration, the entire array is used as the output of this step.

[0090] For example, the token management module receives a sequence of intent operations with structured risk tags generated by the intent parsing and risk labeling module. Step 3 is marked as high risk and has two specific security assertions. The loaded risk level label threshold is the string "high". When traversing the sequence, when it reaches step 1, its risk level is read as low. After comparing it with the risk level label threshold, it is not equal to the risk level label threshold. Therefore, step 1 is not identified as a high-risk operation. When it reaches step 3, its risk level is read as high. After comparing it with the risk level label threshold, it is equal to the risk level label threshold. Therefore, step 3 is identified as a high-risk operation step.

[0091] The security context token generation module generates a security context token for step 3 by calling a hash function, taking the current timestamp 1700000000 and step index 3 as inputs, to generate token ID a1b2c3d4e5f6, and then binding the token ID to step index 3.

[0092] Read the two security assertions corresponding to step 3: "Patch operation does not involve inter-process communication (IPC) related system calls and assertions" and "Patch segment permission set is a subset of the original segment permission set". Connect these two assertion texts with AND and add the header VERIFY_CONDITIONS: to form the permission lock string VERIFY_CONDITIONS: Patch operation does not involve inter-process communication (IPC) related system calls AND Patch segment permission set is a subset of the original segment permission set.

[0093] The triplet content of step 3 is parsed. Its step type is memory patching. The permission rule base is queried to find the constraint template corresponding to the key memory patching. The security context token generation module contains the fields allowed_memory_segments and allowed_syscalls. The memory image of the target object sandbox program copy is mapped to the memory segment address range 0x400000-0x401000. The step parameter patch file path is mapped to the allowed system calls memcpy for memory copying and mprotect for memory protection. Thus, the operation license object is instantiated as {allowed_memory_segments: [[0x400000, 0x401000]], allowed_syscalls: [memcpy, mprotect]}. The fields define a list of physical or virtual memory address ranges that the agent is allowed to access. Each range is represented by an array of start and end addresses. The agent is prohibited from accessing memory regions outside this list.

[0094] The security context token generation module outputs an array containing security context tokens. The complete data structure is {token_id: a1b2c3d4e5f6, bound_step_index: 3, permission_lock: VERIFY_CONDITIONS: The patch operation does not involve inter-process communication (IPC) related system calls AND the patch segment permission set is a subset of the original segment permission set, operation_license: {allowed_memory_segments: [[0x400000, 0x401000]], allowed_syscalls: [memcpy, mprotect]}}.

[0095] In one embodiment of the present invention, constructing a task state machine based on an intentional operation sequence includes the following steps:

[0096] Map each atomic operation step in the intent operation sequence to a state node of the task state machine; mark the state node corresponding to the high-risk operation step as a gated state node that requires conditional triggering; write the identifier of the security context token into the binding field of the gated state node.

[0097] In one embodiment of the present invention, the scheduling agent's execution risk level is lower than a preset safety threshold, including the following steps:

[0098] When the task state machine transitions to a normal state node corresponding to a low-risk operation step, it schedules a standard low-risk operation agent to execute the step; it receives the execution result returned by the standard low-risk operation agent and stores the execution result as the output data of the executed step in the context data cache of the task state machine with the step index as the key.

[0099] Specifically, the state machine initialization module in the task orchestration and safety scheduling execution engine receives the intention operation sequence marked with risk and the array of safety context tokens. The state machine scheduling and execution module parses the intention operation sequence, extracts the logical sequence of all atomic operation steps, and instantiates the task state machine by calling the finite state machine construction library according to this logical sequence.

[0100] A task state machine is a finite state machine model used to control and track the progress of task execution, constructed according to the logical order of the intention operation sequence with structured risk labels. In a task state machine, each atomic operation step is mapped to an independent state node. A state node is a discrete stage in the task execution process, and its activation and transition are controlled by the execution engine according to a preset logical order. The identifier of the state node is consistent with the logical order index of the step in the sequence. Traversing all state nodes, for each node, the risk level of the corresponding step in the intention operation sequence is queried. If the risk level of the step is equal to or higher than the risk level label threshold used in the security context token generation module, the state machine scheduling and execution module marks the state node as a gated state node that requires condition triggering to activate.

[0101] Gated state nodes, as special state nodes in the task state machine, correspond to operation steps where the risk level reaches or exceeds the risk level label threshold. When such a state node is activated, the execution engine will not immediately schedule and execute its corresponding operation, but will pause and trigger an independent verification process, which will be described in subsequent steps. Otherwise, it is marked as a normal state node, which can be executed without additional conditions. After the node marking is completed, the token binding operation is performed. The security context token array from the security context token generation module is traversed, and the binding step index field inside each token in the array is read.

[0102] In the task state machine, search for a state node whose identifier matches this index value. If found and the node has been marked as a gated state node, set a binding field in the node's metadata and store the unique token ID of the security context token in it, thereby completing the binding between the token and the node. After binding, start the execution engine of the task state machine. The execution engine starts scheduling from the initial state node with identifier 1. The execution engine first determines the type of the current node. For ordinary state nodes, the execution engine determines the content of the triplet of the atomic operation steps corresponding to the node.

[0103] The execution engine encapsulates the parameters of atomic operation steps into task instructions, sends them to the agent through an inter-process communication message queue, and waits for the agent to return the execution result. The agent refers to a software agent instance. The agent resource manager schedules low-risk agents with corresponding operation capabilities and preset permission levels. After the agent completes its execution, its output data is received by the execution engine of the task state machine and temporarily stored in the context data buffer. The buffer stores data with the index of the subsequent steps as the key. The execution engine automatically attempts to flow to the next state node according to the logical order of the state machine and repeats the above node type judgment and scheduling process.

[0104] Low-risk operation steps refer to atomic operation steps with a risk level below the risk level label threshold. The risk level label threshold is defined as "high" in the security context token generation module. Therefore, in this step, steps with a low or medium risk level are considered low-risk operation steps. A standard low-risk operation agent refers to a software agent with restricted permissions, capable only of performing non-intrusive operations such as analysis, querying, and monitoring. For example, it can read file content but cannot modify system configurations.

[0105] For example, the state machine initialization module receives a structured risk-tagged intent operation sequence generated by the intent parsing and risk labeling module example, which includes step 1 (index 1, low risk) and step 3 (index 3, high risk). It also receives a security context token array containing tokens generated by the security context token generation module example. The sequence is parsed in the logical order of [1, 3]. The task state machine is instantiated, and two state nodes are created with node IDs 1 and 3. The sequence risk level is queried. Step 1 has a low risk, which is lower than the risk level label threshold, so node 1 is marked as a normal state node. Step 3 has a high risk, which is equal to the risk level label threshold, so node 3 is marked as a gated state node.

[0106] Perform token binding. Read the unique token in the token array in the security context token generation module example. The binding step index is 3. Find the gated state node with node ID 3 in the task state machine and write the token ID a1b2c3d4e5f6 of the token into the binding field of this node.

[0107] After initialization, the execution engine of the state machine is started. The execution engine starts from the initial node 1. Since node 1 is a normal state node, the execution engine runs the ThreadSanitizer tool according to its corresponding step 1. This tool is used for data race detection in the target program. The standard static analysis agent is scheduled through the agent resource manager. The execution engine encapsulates the target program path data_processor.bin and tool options into a task instruction and sends it to the agent. The agent executes the instruction tsandata_processor.bin in the controlled sandbox and generates a data race detection report.

[0108] The agent returns the report content, such as a JSON text containing a list of potential competing locations, to the execution engine. After receiving it, the execution engine stores it in the context data buffer with the key step_1_output. The execution engine automatically moves to the next node, namely node 3. Since node 3 is a gated state node, the execution engine pauses here and no longer continues to automatically schedule execution, but waits for the subsequent gated verification process to be triggered. The task state machine completes initialization and executes the first low-risk step. The current state of the system is that node 1 has been executed and its output has been cached; node 3 is in a paused state waiting to be activated.

[0109] In one embodiment of the present invention, a verification agent is scheduled to verify the output data according to the pre-verification conditions defined in the permission lock, including the following steps:

[0110] The extracted permission lock string is parsed to identify the pre-verification conditions, and instantiated into a verification task descriptor containing the task type and input data identifier. The output data of the executed steps is extracted from the context data buffer based on the input data identifier. The verification agent is selected based on the task type, and the verification task descriptor and the extracted output data are sent to the verification agent to execute the verification logic.

[0111] Specifically, when the execution engine of the task state machine transitions to the gating state node, it first sets its internal global execution flag to a paused state, thus suspending the main task execution thread. The execution engine then reads the binding fields from the gating state node's metadata to obtain the token ID of the security context token bound to it. Using this token ID, the execution engine searches the security context token array from the security context token generation module to locate the corresponding complete security context token data structure. Finally, the execution engine extracts the string stored in the permission lock field bound to the current gating node from the permission lock field of the security context token's data structure.

[0112] After extraction, the execution engine performs syntax parsing on the permission lock string to identify one or more pre-verification conditions encoded within it. Each verification condition is instantiated into an executable verification task descriptor, which includes the task type, verification target, verification logic, and identifiers of the required input data. The identifiers of the required input data point to the output data of the preceding executed steps stored in the context data buffer of the task state machine. For example, if the verification condition involves checking patch content, the input data identifier points to the detection report generated in step 1.

[0113] The execution engine invokes an independent verification agent scheduler. Based on the task type in the verification task descriptor, the verification agent scheduler selects an independent verification agent instance with corresponding verification capabilities from the pre-registered verification agent resource pool. The verification agent scheduler sends the verification task descriptor and the actual input data retrieved from the context data buffer to the verification agent through remote procedure call or message passing, and begins to execute the verification task, which contains specific input and verification logic, instantiated from the pre-verification conditions.

[0114] A verification agent is a permission-independent and single-function software proxy used to perform security assertion verification. During system deployment, each security assertion template, such as "the patch segment permission set is a subset of the original segment permission set," registers a unique assertion identifier and expected input data pattern with the verification subsystem. When registering with the verification agent scheduler, the corresponding verification agent must declare the list of assertion identifiers it can process. When the permission lock is parsed and a verification task descriptor is generated, the descriptor contains the target assertion identifier and the extracted input data. After receiving the task, the verification agent calls its internal corresponding verification function based on the assertion identifier, passes in the input data, executes the specific verification logic, and finally returns a Boolean conclusion. This allows security rule updates and verification capability upgrades to be performed independently.

[0115] During system initialization, the verification agent registers its type and capabilities with the verification agent scheduler. After receiving task instructions and input data, the verification agent runs preset verification logic in its independent execution environment. The verification logic includes static code analysis, data integrity verification, security policy matching, or logical expression evaluation. After verification, the verification agent generates a verification report. The conclusion of the verification report is a Boolean value, and its judgment is based on the result of the logical AND operation of all sub-conditions after the verification agent runs the verification logic. It indicates whether all verification conditions are met and provides a detailed verification process log.

[0116] To ensure the authenticity and immutability of the report, the verifying agent uses its private key to digitally sign the hash value of the report, generating signature data. The original report and the digital signature are then packaged together into a final response packet. The verifying agent returns the response packet to the execution engine of the task state machine. Upon receiving the digitally signed verification report, which is a result document generated by the verifying agent and cryptographically signed using an asymmetric encryption algorithm to ensure the credibility of the report's source and the integrity of its content, the execution engine verifies the validity of the digital signature using the pre-stored public key of the corresponding verifying agent.

[0117] All validating agents must register with the system's validating agent scheduler upon deployment, submitting their unique identifier, capability description, and the public key from their asymmetric encryption key pair. The scheduler stores the public key in an access-controlled internal secure storage area, such as a hardware security module or an encrypted keystore. When the scheduler distributes a validating task, it also attaches the target agent identifier. Upon receiving a validating report, the execution engine retrieves the corresponding public key from the secure storage area based on the agent identifier in the report for signature verification. This mechanism ensures the verifiability of the report's source.

[0118] If the signature is valid, the execution engine parses the original report, reads its conclusion field, and compares the value of the conclusion field with the conditions required by the access lock. If the conclusion is true, the pre-verification conditions are satisfied; if the conclusion is false or ambiguous, the conditions are not satisfied, and the gating verification process is completed.

[0119] For example, when the task state machine transitions from node 1 of the state machine scheduling and execution module example to the gated state node of node 3, the execution engine pauses the main thread, reads the token ID a1b2c3d4e5f6 bound to node 3, and retrieves the corresponding token in the token array output by the security context token generation module example. The execution engine extracts VERIFY_CONDITIONS from the permission lock field of the token, which is used for the string: patch operation does not involve inter-process communication (IPC) related system calls AND the patch segment permission set is a subset of the original segment permission set.

[0120] The execution engine parses the string and identifies two verification conditions. For the first condition, the patch operation does not involve inter-process communication-related system calls. The execution engine generates a verification task descriptor of type system call analysis and specifies its input step_1_output data, which is the data from the key in the context data buffer, i.e., the detection report generated by ThreadSanitizer in the state machine scheduling and execution module example. The report contains a list of called functions. For the second condition, the patch segment permission set is a subset of the original segment permission set. The execution engine generates another verification task descriptor of type memory permission mapping analysis. The input data is also associated with step_1_output as the output of step 1 and the metadata of the patch to be applied.

[0121] The execution engine schedules and verifies the agent. Based on the task type and system call analysis, the verification agent selects a static analysis verification agent from the resource pool and sends the first task descriptor and the actual detection report data to the verification agent. Based on the type memory permission mapping analysis, another memory security verification agent is selected and the second task descriptor and data are sent.

[0122] The first verification agent checks the function list in the analysis report and confirms that no IPC-related system calls are listed. Its verification logic returns true. The second verification agent compares the permissions of the original memory segment in the report (e.g., readable and writable) with the permissions declared in the patch file (e.g., writable only) to determine whether the latter is a subset of the former. Here, the verification logic returns false.

[0123] Each verification agent packages its true or false conclusion and log, signs each with its private key, and returns it to the execution engine. The execution engine uses the public keys of both agents to verify the validity of the signature and then parses the report. For the first condition, if the conclusion is true, it is satisfied; for the second condition, if the conclusion is false, it is not satisfied. The execution engine performs a logical AND operation on all conditions, and the result of true / false is false. Therefore, the execution engine ultimately determines that the pre-verification conditions are not met.

[0124] In one embodiment of the present invention, receiving a verification report includes the following steps:

[0125] The digital signature of the verification report is decrypted and verified using the pre-stored public key of the corresponding verification agent. If the signature verification passes, the Boolean conclusion field in the verification report is parsed and compared with the conditions required by the access lock to determine whether the pre-verification conditions are met.

[0126] In one embodiment of the present invention, the scheduling agent performs high-risk operations within the scope defined by the operation license, including the following steps:

[0127] Extract the operation license from the authorized security context token; pass the operation license as a runtime parameter to the agent; during execution, the agent restricts the scope of system calls, memory access addresses, or file paths based on the operation license.

[0128] In one embodiment of the present invention, triggering the security mechanism includes the following steps:

[0129] Generate a security alarm event containing the failure node identifier and verification report summary and send it to the monitoring system; trigger the rollback mechanism, schedule the rollback agent to read the intermediate state data stored in the context data cache, and restore the system state to the consistency checkpoint before the high-risk operation steps were executed.

[0130] Specifically, the execution engine of the task state machine executes the corresponding routing logic based on the judgment result of the verification report conclusion in the gating verification scheduling module. If the gating verification scheduling module determines that the pre-verification conditions are met, the execution engine first performs a write operation on the internal state field of the security context token bound to the current gating state node, updating its value from the initial locked state to authorized. This update operation signifies that the permission lock has been unlocked, and the execution engine access status has been updated to the authorized state of the security context token. The authorized state is used as the enumeration type field value inside the security context token to indicate that the permission lock it is bound to has been opened, and the corresponding operation license can be used for authorized execution.

[0131] The complete operation license JSON object is extracted from its operation license field. The execution engine parses the JSON object and serializes the constraint fields, such as the list of allowed memory address ranges and the system call whitelist, into a configuration file or parameter dictionary that can be read by the agent.

[0132] The execution engine, through the agent resource manager, schedules high-privilege operation agents corresponding to the current gated state node. High-privilege operation agents are those granted privileges exceeding the standard agent permission set, capable of performing potentially dangerous operations such as directly modifying memory, writing system files, and binary patching. Their execution is constrained by an operation license. When scheduling high-privilege operation agents, the engine, in addition to passing task parameters, also transmits the serialized operation license and startup configuration to the secure execution sandbox driver via secure local inter-process communication. The driver embeds an operation license parser, and its workflow is as follows:

[0133] Receive and parse: Receive licenses and agent startup commands from the execution engine;

[0134] Environment preparation involves calling fork() as a system call to create a child process. Within the child process, before the external command exec() loads the agent program, an isolation environment is configured according to the contents of the operation license.

[0135] System call filtering, based on the allowed_syscalls whitelist in the license, uses the Linux operating system's kernel security mechanism to install a strict system call filter for child processes, allowing only calls within the whitelist;

[0136] Memory space constraints, based on allowed_memory_segments, define the range of allowed memory address segments. This can be achieved by monitoring and restricting the memory access addresses of child processes through the ptrace() system call or by combining interfaces, or by using sandbox technology to perform boundary checks in user space.

[0137] File and capability restrictions: Set the capability set of a process and use namespaces to restrict its visible file system view;

[0138] After the controlled execution completes the above constraint configuration, the child process is allowed to continue execution and load the target agent program. During the agent's operation, any unauthorized behavior that violates the license, such as initiating a disabled system call or accessing unauthorized memory, will be blocked by the underlying system and a violation event will be generated and reported. High-privilege agents, such as memory-patching agents, are designed to run in this controlled environment, and their own logic can also integrate secondary checkpoints and the underlying sandbox mechanism to form a defense-in-depth.

[0139] When a high-privilege agent is launched, the execution engine injects the serialized operation license and the specific parameters of the current task, such as the target program handle and patch data, as mandatory runtime parameters into the agent's execution context via inter-process communication or environment variables. During runtime, the high-privilege agent first loads and parses the operation license. Operation license extraction and parsing refers to reading and deserializing the JSON object stored in the operation license field from the authorized token data structure and converting it into runtime parameters. Its core operation logic embeds checkpoints to ensure that all actions, including but not limited to system call selection, memory access addresses, and target file paths, fall within the scope defined by the operation license. Any attempts to exceed this scope will be intercepted by the agent's own security module and an error will be returned. After the high-privilege agent completes execution, its execution results and audit logs are returned to the execution engine, along with the corresponding token ID for traceability.

[0140] If the pre-verification conditions are not met in the gating verification scheduling module, the execution engine immediately marks the global state of the task state machine as "failed" and stops scheduling any subsequent nodes. At the same time, the execution engine calls the independent security event handling module.

[0141] According to the preset policy, the security event handling module performs at least the following actions: 1. Generate a security alarm event containing at least the failed node ID, token ID, timestamp, event level, event type, and detailed description fields, and send it to the central monitoring system via the Syslog protocol or event bus; 2. Trigger the preset rollback mechanism. The rollback mechanism will schedule the rollback agent to restore the system state to the consistency checkpoint before the high-risk operation steps were performed, based on the intermediate state data stored in the context data cache. For example, if the rollback agent needs to use the cached original file copy or original memory image data for recovery operations, the rollback agent will be scheduled to restore the system state to the consistency checkpoint before the high-risk operation steps were performed.

[0142] For example, based on the judgment result in the gating verification scheduling module example, the verification report concludes that it is false and does not meet the pre-verification conditions. Therefore, the execution engine enters the failure handling branch. The execution engine first sets the global state of the task state machine to failure and stops the flow to any node after node 3. The execution engine calls the security event handling module. The security event handling module generates a security alarm event according to the configuration policy. The content of the security alarm event is: timestamp 2023-10-01T10:30:00Z, event level ERROR, event type VERIFICATION_FAILED, associated task ID taken from state machine ID, and detailed description: the pre-verification failed in the high-risk step 3 (token ID: a1b2c3d4e5f6), and the specific reason was that the memory permission subset assertion failed.

[0143] The security alarm event is immediately sent to the monitoring system, and the security event handling module triggers the rollback mechanism. Since step 3 has not yet been executed in this example and the system state has not been modified, the rollback mechanism is still triggered as a security practice. The rollback mechanism checks the context data cache and finds that only the output of step 1 exists. If there are modified intermediate files, such as temporary files during the analysis process, the rollback mechanism will schedule the file cleaning agent to delete them.

[0144] In another scenario, where the verification result in the gated verification scheduling module is true and all conditions are met, the execution engine will proceed to the success branch. The execution engine will update the status of token a1b2c3d4e5f6 to authorized and extract the operation license object {allowed_memory_segments: [[0x400000, 0x401000]], allowed_syscalls: [memcpy, mprotect]} generated in the security context token generation module example. The execution engine will serialize this object into a string and schedule the high-privilege memory patching agent to start with the command mem_patch_agent--target- The command `handle0x400500 --patch-filepatch.bin --license'{allowed_memory_segments:...}` specifies the license for forced injection. The memory patching agent parses the `license` parameter at runtime and works in conjunction with the secure execution sandbox driver. When the agent attempts to perform a patch, it checks if the target address 0x400500 is within the allowed segment [0x400000, 0x401000] and ensures that it only calls the `memcpy` and `mprotect` system calls. If the settings are met, the patch is executed and a success result is returned.

[0145] Each of the modules can be implemented in whole or in part through software, hardware, or a combination thereof. It supports hardware embedded in or independent of the processor in the computer device, and also supports software stored in the memory of the computer device, so that the processor can call and execute the operations corresponding to each of the above modules.

[0146] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A multi-agent dynamic orchestration and secure scheduling system based on model-based software, characterized in that, include: The intent parsing and risk labeling module parses externally inputted high-level task instructions into atomic operation steps with a logical sequence, and outputs a structured sequence of intent operations with risk labels. The security context token generation module iterates through the sequence of intent operations marked with risk and creates security context tokens containing permission locks and operation licenses for high-risk operation steps with risk levels higher than the preset security threshold. The state machine scheduling and execution module constructs a task state machine based on the intention operation sequence, maps high-risk operation steps to gated state nodes and associates them with the bound security context token, and schedules the intelligent agent to execute operation steps with a risk level lower than a preset security threshold. The gating verification scheduling module extracts the permission lock from the corresponding security context token when the task state machine transitions to the gating state node. Based on the pre-verification conditions defined in the permission lock, it schedules the verification agent to verify the output data and outputs a verification report with a digital signature. The binding execution authorization module receives the verification report. If the report conclusion meets the pre-verification conditions, it updates the status of the security context token to authorized, extracts the operation license as the running parameter, and schedules the intelligent agent to execute high-risk operation steps within the scope defined by the operation license. If the conditions are not met, the current task flow will be terminated and a security mechanism will be triggered.

2. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, The intent parsing and risk labeling module is used to perform the following steps: The program's intelligent model decomposes high-level task instructions into atomic operation steps with a logical sequence. Assess the potential impact of atomization steps on the target procedure and label the risk level; Based on the risk level of atomic operation steps, define the safety assertions that must be satisfied before execution; Atomized operation steps, risk levels, and security assertions are combined into a structured sequence of intended operations.

3. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 2, characterized in that, Assess the potential impact of atomization steps on the target procedure and assign risk levels, including the following steps: Obtain the step type and target object properties of the atomic operation steps; A composite risk value is calculated using a pre-defined risk assessment algorithm, which involves a weighted sum of the basic risk score for each step type and the risk score for the target object's attributes. The composite risk value is mapped to a pre-defined set of discrete risk levels to determine the risk level of the atomized operation step.

4. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, Create a security context token containing permission locks and operation licenses, including the following steps: Read the list of security assertions corresponding to high-risk operation steps, concatenate the logical expression text of the security assertions and add a verification condition header to generate an access lock string; The process parses the content of high-risk operation steps, retrieves the corresponding constraint template from the pre-set permission rule library according to the step type, fills the target object and step parameters into the constraint template, and generates an operation license object containing the allowed operation scope field.

5. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, Constructing a task state machine based on the intended operation sequence includes the following steps: Map each atomic operation step in the intended operation sequence to a state node of the task state machine; Mark the state nodes corresponding to high-risk operation steps as gated state nodes that require condition triggering; Write the identifier of the security context token into the binding field of the gated state node.

6. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, When the risk level of the scheduling agent is lower than a preset safety threshold, the following steps are included: When the task state machine transitions to a normal state node corresponding to a low-risk operation step, the standard low-risk operation agent is scheduled to execute that step. Receive the execution result returned by the standard low-risk operation agent, and store the execution result as the output data of the executed step in the context data cache of the task state machine with the step index as the key.

7. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, The verification agent is scheduled to verify the output data according to the pre-verification conditions defined in the permission lock, including the following steps: The extracted permission lock string is parsed to identify the pre-verification conditions and instantiated into a verification task descriptor containing the task type and input data identifier. Extract the output data of the executed steps from the context data buffer based on the input data identifier; Select a verification agent based on the task type, and send the verification task descriptor and the extracted output data to the verification agent to execute the verification logic.

8. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, Receiving the verification report includes the following steps: Use the pre-stored public key of the corresponding verification agent to decrypt and verify the digital signature of the verification report; If the signature verification passes, the Boolean conclusion field in the verification report is parsed and compared with the conditions required by the access lock to determine whether the pre-verification conditions are met.

9. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, The scheduling agent performs high-risk operations within the scope defined by the operating license, including the following steps: Extract the operation license from the authorized security context token; The operation license is passed to the agent as an operational parameter; During execution, the intelligent agent restricts the scope of operations related to system calls, memory access addresses, or file paths based on the operating license.

10. The multi-agent dynamic orchestration and secure scheduling system based on model-based software according to claim 1, characterized in that, Triggering the security mechanism includes the following steps: Generate a security alert event containing the failure node identifier and a verification report summary and send it to the monitoring system; Trigger the rollback mechanism, schedule the rollback agent to read the intermediate state data stored in the context data cache, and restore the system state to the consistency checkpoint before the high-risk operation steps were executed.

Images