A method and apparatus for life cycle management of business operation tasks

Abstract

The application provides a life cycle management method and device for a business operation task, and the method comprises the following steps: obtaining a business operation task and obtaining an inference track corresponding to the task; performing multi-dimensional plan consistency verification on the inference track to obtain a consistency verification result; if the verification result meets a consistency condition, performing business operation risk assessment based on the multi-dimensional consistency verification result and operation attributes of the inference track in a risk dimension to obtain a risk assessment result; if the risk assessment result meets a risk approval condition, generating an approval request corresponding to the inference track and sending the approval request to a user business system to obtain an approval result of the inference track; and if it is determined that the inference track meets an execution access condition, executing the inference track by using a security sandbox to complete life cycle management of the task. The application can realize complete and safe management and control of the business operation task.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence security technology, and in particular to a method and apparatus for lifecycle management of business operation tasks. Background Technology

[0002] With the rapid development of large language model technology, AI agents have been deployed on a large scale in enterprise-level scenarios, capable of autonomously completing complex business operations such as order placement, fund approval, maintenance, and data processing, significantly improving the efficiency of business automation. However, due to the black-box reasoning characteristics of large language models, agents are highly vulnerable to security threats such as injection of hints, unauthorized access, parameter drift, erroneous reasoning, or link hijacking when processing business operations in complex instruction and long context scenarios. This can lead to irreversible high-risk incidents such as erroneous fund transfers, accidental deletion of production data, and leakage of sensitive information, which restricts the application of AI agents in key areas such as finance, government affairs, and energy.

[0003] In existing technologies, secure access solutions for business operations can be mainly categorized as follows: The first type is static authentication schemes, such as Role-Based Access Control (RBAC). RBAC restricts the scope of tool calls by pre-setting user roles and permission whitelists. Its core logic is to assign fixed roles to the entities involved in business operations, allowing only the corresponding roles to call tools within the pre-set whitelist. However, static authentication schemes can only restrict permissions for single tools and cannot identify unauthorized calls by multiple tools combined. They also cannot detect hidden risks such as deviations from planned objectives or abnormal parameter drift during inference. Furthermore, static permissions cannot adapt to real-time risk changes in the inference trajectory, resulting in numerous blind spots in protection.

[0004] The second type is content filtering-based protection solutions. For example, when encountering the risk of malicious injection, keyword detection and semantic matching can be used to filter malicious content in user input and model output data. The core logic is to set detection nodes at the user input and model output stages to identify and intercept content containing injection features. However, content filtering solutions can only cover known attack patterns and are ineffective against long-context implicit injection and adversarial malicious injection. Furthermore, they cannot globally verify the overall rationality of the tool call chain and its consistency with the original target, making them easily bypassed in the face of complex attacks.

[0005] The third category is the manual approval solution, which is a general management and control solution for enterprise-level business operation tasks. However, this solution has high manual approval costs and long processing times, and cannot be adapted to scenarios of large-scale, automated execution of business operation tasks.

[0006] Existing technologies cannot fundamentally solve the problems of pre-execution preparation and access management during the execution of business operation tasks. Therefore, there is an urgent need for a lifecycle management method for business operation tasks that can form a security protection chain of "pre-execution verification - execution control". Summary of the Invention

[0007] In view of this, embodiments of the present invention provide a lifecycle management method and apparatus for business operation tasks, which can form a security control chain for business operation tasks, thereby significantly reducing the error execution rate of high-risk business operations without affecting task execution efficiency.

[0008] One aspect of the present invention provides a lifecycle management method for business operation tasks, the method comprising the following steps: Obtain business operation tasks from user business systems and derive corresponding inference trajectories based on these tasks; the inference trajectories include the operational attributes of multiple subtasks obtained from the decomposition of the business operation tasks in the risk dimension. The inference trajectory is subjected to multi-dimensional plan consistency verification to obtain the multi-dimensional consistency verification results corresponding to the inference trajectory; among which, the multi-dimensional plan consistency verification includes target consistency verification, parameter legality verification, and permission compliance verification. If the multidimensional consistency verification result meets the consistency condition, business operation risk assessment is performed based on the multidimensional consistency verification result and the operational attributes of all subtasks corresponding to the inference trajectory in the risk dimension, and the risk assessment result corresponding to the inference trajectory is obtained. If the risk assessment result corresponding to the inference trajectory meets the risk approval conditions, an approval request corresponding to the inference trajectory is generated and sent to the specific approval user in the user's business system to obtain the approval result corresponding to the inference trajectory. If the inference trajectory is determined to meet the execution access conditions based on the risk assessment results or approval results, the execution of the inference trajectory is realized by using a security sandbox, thereby completing the lifecycle management of business operation tasks.

[0009] In some embodiments of the present invention, the business operation task includes the following information: task type, task initiating user identifier, application resource type, target action, target object, and key task parameters; Obtain business operation tasks from user business systems, and derive corresponding inference trajectories based on these tasks, including: The task parsing submodule obtains the business operation task, determines the permission boundaries and prohibited operations of the executing agent based on the task type, task initiator user identifier and application resource type contained in the business operation task, determines the task execution constraints based on the target action, target object and key task parameters contained in the business operation task, and inputs the business operation task, the determined permission boundaries, prohibited operations and task execution constraints into the executing agent to obtain the inference trajectory.

[0010] In some embodiments of the present invention, the inference trajectory includes the execution operations corresponding to multiple sub-tasks obtained by decomposing the business operation task, the dependencies between sub-tasks, and the tools to be called by each sub-task, tool call parameter constraints, preconditions and postconditions. The target consistency check is used to check the matching degree between the business operation task and the execution operation corresponding to all sub-tasks. The parameter validity check is used to check whether the execution operation corresponding to each sub-task and the tool call parameter constraints of each sub-task conform to the preset business rules. The permission compliance check is used to check whether the execution operation corresponding to each sub-task, the tool to be called by each sub-task, and the tool call parameter constraints of each sub-task are within the permission boundary. The operational attributes of the risk dimension include one or more of the following: financial risk attributes, access risk attributes, data security risk attributes, operational characteristic risk attributes, historical behavior risk attributes, environmental context risk attributes, and compliance and audit risk attributes.

[0011] In some embodiments of the present invention, the multi-dimensional plan consistency verification also includes logical consistency verification, which is used to verify whether the dependency relationship between subtasks is abnormal and whether the preconditions and postconditions of each subtask can be satisfied. When the reasoning trajectory includes the cited evidence for each subtask, the multi-dimensional plan consistency check also includes evidence citation consistency check, which verifies whether the cited evidence for each subtask is authentic and valid; and The consistency condition is that the verification result of any verification dimension in the plan consistency verification is greater than a specific threshold and / or the consistency result of multiple dimensions is greater than the preset plan consistency threshold.

[0012] In some embodiments of the present invention, after obtaining the inference trajectory, the method further includes: generating a trajectory hash value corresponding to the inference trajectory.

[0013] In some embodiments of the present invention, the approval request includes an inference trajectory, a multidimensional consistency verification result corresponding to the inference trajectory, a risk assessment result corresponding to the inference trajectory, and a trajectory hash value corresponding to the inference trajectory. If the inference trajectory is approved, the approval result includes the authorization token corresponding to the inference trajectory. The authorization token includes the trajectory hash value, the authorization subject identifier, the authorization validity period, the scope of authorization authority, and the digital signature. If the risk assessment result corresponding to the inference trajectory is at a low risk level, the number of specific approval users is zero; if the risk assessment result corresponding to the inference trajectory is at a medium risk level, the number of specific approval users is one; if the risk assessment result corresponding to the inference trajectory is at a high risk level, the number of specific approval users is multiple. The risk approval condition is that the risk assessment result corresponding to the reasoning trajectory is at the medium-risk or high-risk level; and The entry criteria are that the risk assessment result corresponding to the reasoning trajectory is at a low risk level, or that the approval result corresponding to the reasoning trajectory contains an authorization token and the authorization token is within its validity period.

[0014] In some embodiments of the present invention, the authorization token is generated based on a decentralized identifier, the digital signature is generated within the trusted execution environment using a private key stored in the trusted execution environment based on the SM2 algorithm, and the hash algorithm is the SM3 algorithm.

[0015] In some embodiments of the present invention, the method further includes, prior to executing the inference trajectory: The security sandbox generates a verification hash value corresponding to the inference trajectory to be executed, and compares the consistency between the verification hash value and the trajectory hash value. Both the verification hash value and the trajectory hash value are generated using a hash algorithm, specifically the SM3 algorithm.

[0016] In some embodiments of the present invention, the method further includes: Upon obtaining a business operation task, an audit trail identifier is generated, and the operation logs of the inference trajectory generation module, plan verification module, risk assessment module, approval module, and security sandbox are recorded, thereby generating an audit record corresponding to the business operation task. The audit records corresponding to the business operation tasks include audit trace identifiers, inference trajectory generation module identifiers, business operation task identifiers, trajectory hash values, multidimensional consistency verification results, risk assessment results, approval results, execution results of the security sandbox, and timestamps; the audit records are stored in a hash-based manner.

[0017] Another aspect of the present invention provides a lifecycle management device for business operation tasks, the device comprising: The inference trajectory generation module is used to acquire business operation tasks from the user's business system and obtain corresponding inference trajectories based on the business operation tasks; wherein, the inference trajectory includes the operational attributes of multiple sub-tasks obtained by decomposing the business operation tasks in the risk dimension. The plan verification module is used to perform multi-dimensional plan consistency verification on the inference trajectory to obtain the multi-dimensional consistency verification result corresponding to the inference trajectory; wherein, the multi-dimensional plan consistency verification includes target consistency verification, parameter legality verification and permission compliance verification; The risk assessment module is used to assess the business operation risk based on the multidimensional consistency verification result and the operational attributes of all subtasks corresponding to the inference trajectory in the risk dimension, when the multidimensional consistency verification result meets the consistency condition, and to obtain the risk assessment result corresponding to the inference trajectory. The approval module is used to generate an approval request corresponding to the inference trajectory and send it to a specific approval user in the user's business system when the risk assessment result corresponding to the inference trajectory meets the risk approval conditions, so as to obtain the approval result corresponding to the inference trajectory. The security sandbox is used to execute a reasoning trajectory when the execution access conditions are met based on risk assessment results or approval results, thereby completing the lifecycle management of the business operation task.

[0018] The lifecycle management method and apparatus for business operation tasks proposed in this invention can replace the current black-box reasoning process of the intelligent agent with a standardized and verifiable reasoning trajectory generated by a reasoning trajectory generation module. A plan verification module performs pre-verification on the reasoning trajectory to identify plan deviations. Based on multi-dimensional consistency verification results and operational attributes of the risk dimension, the risk level of the reasoning trajectory is dynamically calculated, and authorization verification is achieved in conjunction with user approval, thus forming a pre-verification security protection scheme. A security sandbox is used to execute the reasoning trajectory based on the principle of least privilege, forming a real-time control security protection scheme. The method proposed in this application utilizes a security protection chain of "pre-execution verification - execution-time control," which can significantly reduce the false execution rate and effectively prevent high-risk incidents without affecting the execution efficiency of the intelligent agent.

[0019] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0020] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings: Figure 1 This is a flowchart illustrating a lifecycle management method for business operation tasks according to an embodiment of the present invention.

[0022] Figure 2 This is a flowchart illustrating a lifecycle management method for business operation tasks in another embodiment of the present invention.

[0023] Figure 3 This is a schematic diagram of the process of generating the hash chain structure of audit records in one embodiment of the present invention.

[0024] Figure 4 This is a schematic diagram of the lifecycle management device for business operation tasks in one embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0026] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0027] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0028] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0029] Traditional protection methods often rely on static permission whitelists, output content filtering, or manual approval, which not only affects the efficiency of automated execution but also makes it difficult to cover hidden deviations in the execution plan generation process. At the same time, existing solutions lack standardized evidentiary mechanisms and cannot meet the control requirements of highly compliant scenarios such as finance and government affairs.

[0030] Based on this, this application proposes a lifecycle management method that can fundamentally solve the problem of business operation risk. It can perform verifiable consistency checks on the plans and inference processes generated by the agent before the execution of business operation tasks, trigger authorization processes for business operation scenarios that are not in a low-risk environment, implement sandbox constraints, and achieve end-to-end auditability and evidenceability. The core logic of this application's method is as follows: The black-box inference process of the current agent is replaced by a standardized and verifiable inference trajectory generated by the inference trajectory generation module; a plan verification module, completely independent of the inference trajectory generation module, performs pre-verification of the consistency of the inference trajectory and the business operation task's objectives, parameter legality, and permission compliance, and sets an independent consistency scoring gate to identify plan deviations; since consistency verification cannot implement additional control over operations that appear consistent in form but have a significant impact on actual business (such as transfers, core configuration modifications, and batch deletions), this application also designs a method to dynamically classify the risk level of the inference trajectory based on multi-dimensional consistency verification results and operation attributes, and triggers an approval process for inference trajectories in a high-risk level; only inference trajectories carrying valid authorization tokens or in a low-risk level (i.e., meeting the execution access conditions) are allowed to execute in the security sandbox according to the principle of least privilege. Furthermore, this application can also generate hash chain-style tamper-proof audit records for the entire data chain, meeting the traceability and evidentiary requirements of strong compliance scenarios. Compared with existing technologies, the method proposed in this application can realize a complete security protection chain of "structured representation of inference trajectory + plan consistency verification + risk assessment + approval process + sandbox isolation execution + full-chain tamper-proof audit", forming a complete and automated security protection solution of "pre-execution verification - execution control - post-execution audit".

[0031] When the user initiating the task issues a specific business task to the user's business system for automated execution (such as report generation, work order processing, purchase ordering, account operation, or operation and maintenance management), the lifecycle management method proposed in this application is initiated and executed.

[0032] Figure 1 This is a flowchart illustrating a lifecycle management method for business operation tasks in one embodiment of this application. Figure 1 As shown, the method includes steps S110 to S150, as detailed below: Step S110: The inference trajectory generation module obtains the business operation task from the user's business system and obtains the inference trajectory corresponding to the business operation task based on the business operation task.

[0033] Business operation tasks can be structured, standardized data obtained by converting task request objects from user business systems. Task request objects can be structured or semi-structured data, or unstructured data represented in natural language. Business operation tasks may include one or more of the following information: task type, operator ID, application resource type, action type, target object, and critical parameters. The task type indicates the type of business operation task. Task types can be classified according to business function areas such as sales and marketing, procurement and supply chain, production and manufacturing, finance and funds, human resources, customer service, information technology, legal and compliance, etc., or according to task processing characteristics or data objects. The task initiator user identifier is used to determine the user role that initiates the business operation task. The task initiator user can be classified according to the scope of permissions such as global role, organizational role, department role, project role, data role, or functional role, or according to organizational level, etc. The application resource type is the business resource that needs to be used when executing the business operation task. It can be classified as static resource, dynamic resource, or pseudo-static content, or according to business resource elements, and the application resource type matches the business scenario. The target action indicates the action to be performed, such as approval or export. The target object indicates the object to be executed by the target action. The task key parameters indicate the scope constraints of the business operation task (such as quantity range, amount range, data range indicating data filtering conditions, resource range indicating the upper limit of resource usage, and the scope of influence that limits the business impact boundary, etc.). In addition, the business operation task may also include information such as a time context for indicating the execution time, a spatial context for indicating the execution environment, the execution subject, and the source system identifier of the business operation task, but the present invention is not limited thereto.

[0034] In some embodiments of the present invention, when the inference trajectory generation module includes a task parsing submodule and an execution agent, step S110 may be as follows: the task parsing submodule obtains the business operation task; determines the permission boundaries and prohibited operations of the execution agent based on the task type, task initiator user identifier, and application resource type contained in the business operation task; determines the task execution constraints based on the target action, target object, and key task parameters contained in the business operation task; and inputs the business operation task, the determined permission boundaries, prohibited operations, and task execution constraints into the execution agent to obtain the inference trajectory. When the inference trajectory generation module does not include a task parsing submodule but includes an execution agent, step S110 may be as follows: the execution agent obtains the business operation task and obtains the inference trajectory based on the business operation task. Wherein, the permission boundaries indicate the maximum range of actions allowed when the business operation task is executed; prohibited operations (which can be in the form of a set) indicate specific actions that are not allowed to occur when the business operation task is executed; and task execution constraints indicate real-time restrictions imposed on the operation object (such as operation parameters, execution process, and resource usage) when the business operation task is executed. For example, if the business operation task is "transfer 50,000 yuan to supplier A with the note 'payment for goods in February 2026'", then the task execution constraints can be "the payee is supplier A, the transfer amount is 50,000 yuan, and the purpose is payment for goods". The permission boundaries can be "the maximum single transfer is 100,000 yuan, transfers can only be made to supplier accounts on the whitelist, and transfers to personal accounts are prohibited". The prohibited operations can be "prohibiting modification of the transfer amount, prohibiting modification of the payee's account, and prohibiting the attachment of other execution instructions".

[0035] As an example, the task parsing submodule can parse business operation tasks using traditional RBAC (Role-Based Access Control), or TBAC (Task-Based Access Control) and its improvements; this invention is not limited thereto. For instance, the task parsing submodule can extract specific field information from business operation tasks using keyword recognition, regular expressions, field templates, or policy domain-specific languages, and combine this with predefined parsing templates to generate task execution constraints, permission boundaries, and prohibited operations. This application does not specifically limit the parsing process or parsing tools.

[0036] For the executing agent, the process of obtaining the inference trajectory based on the business operation task can be specifically as follows: The business operation task (and task execution constraints, permission boundaries, and prohibited operations) is input into the executing agent, and the executing agent can output a standardized inference trajectory (represented in JSON or a domain-specific language) according to a predefined output structure; or, the business operation task (and task execution constraints, permission boundaries, and prohibited operations) is input into the executing agent, and the executing agent outputs intermediate plans, tool call sequences, or execution intentions in the original way, and the output results of the executing agent are extracted, cleaned, and mapped through plan normalization, thereby converting them into a standardized and verifiable inference trajectory.

[0037] The reasoning trajectory mentioned in this application is not necessarily limited to the complete natural language thought chain of a large model, but refers to intermediate plan information that can be collected, constrained, normalized, and used for verification by each module. This information can include the operational attributes of multiple sub-tasks obtained from the decomposition of business operation tasks in the risk dimension, the execution operations corresponding to each sub-task, the tools to be called by each sub-task, the tool call parameter constraints for each sub-task, the preconditions for each sub-task, the postconditions for each sub-task, and the dependencies between sub-tasks. Each sub-task obtained from the decomposition of business operation tasks corresponds to an atomic-level executable or verifiable execution operation, such as atomic steps like "verify whitelist," "query balance," "execute transfer," and "generate receipt." The dependencies between sub-tasks, also known as dependency edges, represent pre- and post-dependencies or data dependencies between sub-tasks, such as "transfer can only be initiated after whitelist verification is passed." The tools to be called by each sub-task represent the functional interfaces or tools (provided by the user's business system) to be called when executing the sub-task, such as query tools, transfer tools, and deletion tools. The inference trajectory includes class tools and exported class tools, etc.; the tool call parameter constraints of each subtask are used to limit the fixed values, ranges, whitelists, formats, or relationships of interface or tool call parameters, such as "the receiving account must be equal to the supplier A's whitelist account, and the amount must not exceed 50,000 yuan"; the preconditions of each subtask represent the states that must be met before executing each subtask, such as "sufficient balance", "approved", and "permission verification passed", etc.; the postconditions of each subtask represent the results or states that should be met after executing each subtask, such as "generate receipt", "status changed to completed", and "written to audit record", etc. The information contained in the above inference trajectory is only an example, and the inference trajectory may also include other information, such as the reference evidence of each subtask calling tools, but this invention is not limited to this.

[0038] This application does not specifically limit the way business operation tasks are decomposed, as long as they can be divided into single, executable atomic actions. For example, the business operation task "transfer 50,000 yuan to supplier A with the remark 'payment for goods in February 2026'" can be divided into four sub-tasks: "verify whether supplier A's account is on the whitelist", "verify whether the account balance is greater than or equal to 50,000 yuan", "call the transfer tool to transfer 50,000 yuan to supplier A's account with the remark 'payment for goods in February 2026'", and "generate a transfer receipt and send it back to the user who initiated the task". The parameter constraints of the transfer node are: payee = supplier A's whitelist account, amount = 50,000 yuan, remark = "payment for goods in February 2026".

[0039] Inference trajectories can be the "entire-link intermediate inference content, including task planning, step breakdown, constraints, explanations, and tool invocation logic," generated by the executing agent to complete business operation tasks. A structured inference trajectory plan graph can serve as a standardized and verifiable carrier for the inference trajectory. This structured graph can be represented as... , The set of nodes formed by subtasks. For a set of dependent edges, It includes attributes for subtasks such as calling tools, tool call parameter constraints, preconditions, postconditions, and cited evidence.

[0040] In some embodiments of the present invention, the inference trajectory generated in step S110 can serve as a "standardized verifiable carrier" for subsequent security reviews. To achieve integrity protection and trusted verification, after obtaining the inference trajectory through step S110, the method proposed in this application may further include: generating a trajectory hash value corresponding to the inference trajectory using a hash algorithm by a trajectory hash generation module, thereby completing the hash locking of the inference trajectory (locking means binding it to the inference trajectory and making the trajectory hash value unchangeable). Specifically, the hash value of the inference trajectory can be calculated using a hash algorithm as the trajectory hash value. Alternatively, to reduce computational pressure, core features can be extracted from the inference trajectory to form an inference trajectory digest, and the unique hash value of the inference trajectory digest can be calculated using a hash algorithm as the trajectory hash value. This application does not specifically limit the type of hash algorithm; for example, the national cryptographic algorithm SM3 (adapted to domestic information technology innovation and compliance requirements) can be used, or the SHA-256 algorithm can also be used.

[0041] As an example, extracting core features from the inference trajectory refers to any field information whose changes will affect the execution result, risk assessment, or authorization conclusion. This may include information such as task objectives, target objects, tool call sequences, tool call parameter constraints, and the operational scope of subtasks, but excludes redundant natural language descriptions used only for interpretation. The extraction of core features can be achieved through methods such as fixed field identification or semantically equivalent field identification; this invention is not limited to these methods.

[0042] In addition, after obtaining the inference trajectory summary, the inference trajectory summary can be deterministically serialized and then hashed to obtain the trajectory hash value. The deterministic serialization method can be JSON normalization, Concise Binary Object Representation (CBOR), or Protocol Buffers (Protobuf), and this invention is not limited to these.

[0043] The pre-execution verification of the inference trajectory can be divided into three stages: plan consistency verification, business operation risk assessment, and authorized entity approval, involving steps S120, S130, and S140, which can realize differentiated security gating.

[0044] Step S120: After the inference trajectory generation module sends the inference trajectory to the plan verification module, the plan verification module can perform multi-dimensional plan consistency verification on the inference trajectory to obtain the multi-dimensional consistency verification result corresponding to the inference trajectory. The plan verification module can be constructed using one or more of the following: rule engine, policy-specific domain language (DSL), and dual-model architecture.

[0045] Existing technologies lack a consistency verification mechanism for the structured representations obtained through agent reasoning, making it impossible to identify hidden risks such as plan deviation, hint injection, and parameter anomalies before execution. To address this issue, this application designs a machine-verifiable reasoning consistency verification mechanism. Specifically, the verification dimensions of plan consistency verification may include target consistency verification, parameter legality verification, permission compliance verification, and logical consistency verification. When the reasoning trajectory includes reference evidence for each subtask, the verification dimension of plan consistency verification may also include evidence reference consistency verification.

[0046] The target consistency check verifies the matching degree between the business operation task and the execution operations corresponding to all subtasks. For example, it compares the target action, target object, and key parameters of the business operation task with each subtask and its attributes (such as execution operations, tool call parameter constraints, and the tools to be called) in the inference trajectory to see if they match. The parameter validity check verifies whether the execution operations corresponding to each subtask and the tool call parameter constraints of each subtask conform to preset business rules (such as being on a whitelist, conforming to format constraints, etc.). For example, it checks whether the amount format is numeric, whether the amount range is greater than zero, and whether the payee is located in [a specific location]. The whitelist of payees is used for: permission compliance verification to check whether the execution operation corresponding to each subtask, the tools to be called by each subtask, and the constraints of the tool call parameters of each subtask are within the permission boundaries; logical consistency verification to check whether the dependency relationship between subtasks is abnormal (such as broken chains, circular dependencies, or missing verification steps) and whether the preconditions and postconditions of each subtask can be met; evidence citation consistency verification to check whether the cited evidence (such as whitelist records, balance inquiries, approval forms, and work orders) of each subtask is authentic and valid (if the cited evidence is consistent with the cited content, it is considered valid).

[0047] This application does not limit the specific verification methods for each verification dimension; they can be designed according to requirements. For example, target consistency verification can be performed through semantic vector consistency alignment, parameter validity verification and permission compliance verification can be implemented through the fusion of rule engines and semantic models, and logical consistency verification can be performed using formal logic verification. Furthermore, this application can also be designed to perform target consistency verification, parameter validity verification, permission compliance verification, evidence citation consistency verification, and logical consistency verification in high-risk business scenarios.

[0048] As an example, after the plan consistency verification is completed, the target consistency verification result of the business operation task, the parameter legality verification result of each sub-task, the permission compliance verification result of each sub-task, the logical consistency of the business operation task, and the evidence citation consistency verification result of each sub-task can be directly obtained. In this application, the plan consistency verification result can be directly used as the multi-dimensional consistency verification result, that is, the target consistency verification result and logical consistency of the business operation task, as well as the parameter legality verification result, permission compliance verification result, and evidence citation consistency verification result of each sub-task can be used as the multi-dimensional consistency verification result; alternatively, the comprehensive value of the plan consistency verification result can be used as the multi-dimensional consistency verification result. When the multidimensional consistency verification result is a comprehensive value, the process of calculating the multidimensional consistency verification result in step S120 can be as follows: By combining the parameter legality verification results, permission compliance verification results, and evidence citation consistency verification results of each subtask, the parameter legality verification results, permission compliance verification results, and evidence citation consistency verification results of the business operation task can be obtained respectively (such as by using weighted summation, etc., but this invention is not limited to this); by combining the target consistency verification results, parameter legality verification results, permission compliance verification results, logical consistency verification results, and evidence citation consistency verification results of the business operation task (such as by weighted summation), the multidimensional consistency verification result corresponding to the inference trajectory can be obtained. For example, the multidimensional consistency verification result can be obtained by weighted summation of the verification results of all verification dimensions, and the formula can be expressed as: Multidimensional consistency verification result = Target consistency score × 30% + Parameter legality score × 20% + Permission compliance score × 20% + Logical consistency score × 20% + Evidence citation consistency score × 10%.

[0049] Step S130: If the multidimensional consistency verification result meets the consistency condition, the risk assessment module obtains the inference trajectory and performs a business operation risk assessment based on the multidimensional consistency verification result and the operational attributes of all sub-tasks corresponding to the inference trajectory in the risk dimension, thereby obtaining the risk assessment result corresponding to the inference trajectory.

[0050] As an example, this application does not specifically limit the consistency conditions. For instance, a consistency condition could be that the verification result of any verification dimension in the plan consistency check is greater than a specific threshold and / or the multi-dimensional consistency result (referring to the comprehensive value) is greater than a preset plan consistency threshold. This prevents a single key dimension from being masked by an excessively low total score while also preserving the flexibility of the comprehensive score. For example, if the value range for each verification dimension is 0-100 points, and the target consistency check result is 100 points, the parameter legality check result is 100 points, the permission compliance check result is 95 points, the logical consistency check result is 100 points, and the evidence citation consistency check result is 100 points, the comprehensive multi-dimensional consistency check result is 98.5 points, the specific threshold is 75 points, and the preset plan consistency threshold is 80 points, then because the consistency conditions are met, step S130 can be executed to determine the risk level for this reasoning trajectory. The specific threshold and the preset plan consistency threshold can be configured according to the business scenario.

[0051] If the result obtained in step S120 does not meet the consistency condition, the business operation task is blocked, and a structured blocking response containing the verification results of each verification dimension (which can be used to indicate the source of risk) is returned to the task initiating user. The returned response may also include audit trail identifiers and trail hash values.

[0052] In some embodiments of the present invention, the operational attributes of each subtask in the risk dimension include one or more of the following: financial risk attribute, permission risk attribute, data security risk attribute, operational characteristic risk attribute, historical behavior risk attribute, environmental context risk attribute, and compliance and audit risk attribute. Specifically, the financial risk attribute may be the financial scale corresponding to the execution operation of the subtask; the permission risk attribute may be the permission level (the minimum permission level required to execute the subtask); the data security risk attribute may be the data sensitivity (the sensitivity level of the data involved in the execution operation of the subtask); the operational characteristic risk attribute may be the irreversibility of the operation (whether the original state can be restored after the operation is executed); and the historical behavior risk attribute may be historical anomaly records (the operation type or the user's historical risk data). Some of the operational attributes in the risk dimension may be included in the inference trajectory, while others need to be supplemented by external systems (such as data sensitivity and historical anomaly records).

[0053] Step S130 requires risk assessment of each subtask based on the multidimensional consistency verification results and the operational attributes of each subtask in the risk dimension, thereby obtaining the risk assessment result corresponding to the inference trajectory. This application does not specifically limit the method of obtaining the risk assessment result of the inference trajectory based on the risk assessment result of each subtask; for example, it can be combined through maximum value, weighted summation, or priority rules. The risk assessment result of each subtask can be determined based on the comprehensive multidimensional consistency verification results (here referring to the comprehensive value corresponding to the inference trajectory) and the operational attributes of each subtask in the risk dimension, or it can be determined based on the multidimensional consistency verification results of each subtask (the average value of target consistency and logical consistency can be taken) and operational attributes. For example, the calculation formula for the risk assessment result of each subtask can be expressed as R = basic risk score of operation category + a1 × capital scale score + a2 × authority score + a3 × data sensitivity score + a4 × irreversibility score + a5 × historical anomaly score + a6 × (100 - plan consistency score), where a1 to a6 are the corresponding weights, and the plan consistency score can be the comprehensive value of the inference trajectory or the comprehensive value corresponding to each subtask. Similarly, the risk assessment result corresponding to the reasoning trajectory can be a comprehensive value or multiple discrete values ​​(such as a sequence composed of various risk scores).

[0054] Risk assessment results may include operational risk scores and risk analysis reports.

[0055] Step S140: When the risk assessment result corresponding to the inference trajectory meets the risk approval conditions, the approval module obtains the inference trajectory, multidimensional consistency verification result and risk assessment result corresponding to the business operation task from the inference trajectory generation module, the plan verification module and the risk assessment module respectively, generates the approval request corresponding to the inference trajectory and sends it to the specific approval user in the user's business system based on the preset approval process, and obtains the approval result corresponding to the inference trajectory.

[0056] Existing static access control cannot adapt to real-time risk changes in inference trajectories. It lacks a dynamic identification and authorization triggering mechanism for high-risk operations (i.e., irreversible and high-impact operations involving fund transfers, core permission changes, production data deletion / external transmission, system configuration modifications, etc.) and cannot balance the needs of automation efficiency and security control. Therefore, this application designs a hierarchical control strategy for business operation risks, triggering multiple authorizations only for high-risk operations, thus taking into account both the automation efficiency and security control of the intelligent agent.

[0057] This application can classify the operational risks of inference trajectories into multiple risk levels, such as high-risk, medium-risk, and low-risk levels. Assuming the risk level classification rules are: a risk score of 0-40 indicates low risk, 41-70 indicates medium risk, and 71-100 indicates high risk. In this case, the risk approval condition can be that the risk assessment result corresponding to the inference trajectory is at the medium-risk or high-risk level. This application does not specifically limit the risk approval conditions; they can be designed according to needs. This application also does not specifically limit the method or threshold for risk level classification; the above is merely an example.

[0058] As an example, the information carried in the approval request should be "sufficient for the approver to independently assess the risk and scope of authorization." This information may include the inference trajectory, the multi-dimensional consistency verification result corresponding to the inference trajectory, the risk assessment result corresponding to the inference trajectory, and the trajectory hash value corresponding to the inference trajectory. It may also include the business operation task type, target object, key task parameters, and audit trail identifiers used for auditing (i.e., the approval process in step S140 is strongly bound to the trajectory hash value and audit trail identifier). Figure 2 As shown, if the risk assessment result corresponding to the inference trajectory is at a low risk level, the number of specific approval users can be zero (i.e., skip the approval process in step S140 and directly execute step S150); if the risk assessment result corresponding to the inference trajectory is at a medium risk level, the number of specific approval users can be one (single-entity review); if the risk assessment result corresponding to the inference trajectory is at a high risk level, the number of specific approval users can be multiple (multi-authorization process). It should be noted that the specific approval users at the high risk level are users from other user business systems that are different from the task initiating user and are independent of each other (i.e., different account identities, different credentials, and different approval roles). For example, the specific approval users can be two independent authorization entities: the finance manager and the department manager.

[0059] For high-risk reasoning trajectories, threshold multi-signature approval (two or more authorized entities sign the same trajectory hash and audit trail identifier respectively, and it only takes effect after reaching the k-of-n threshold) or multi-party secure computation authorization (approval keys are stored in fragments by multiple parties, and multiple parties need to jointly compute to form the final authorization result, and no party can forge it alone) can be used to meet the authorization verification requirements of two or more independent entities.

[0060] In some embodiments of the present invention, if the inference trajectory approval is successful (i.e., all specific approval users acting as the authorizing subject have approved it), the approval result may include the authorization token corresponding to the inference trajectory; if the inference trajectory approval fails (any user among the specific approval users rejects the approval), the approval result may include a message indicating that the approval failed. In this case, the approval result does not include the authorization token, and the execution of the business operation task must be blocked. Specific approval users can use verifiable approval mechanisms such as workflow system approval, API callback with digital signature, secondary confirmation via enterprise IM / email / dedicated approval terminal, and others. Furthermore, the authorization token in the approval result can be set as a one-time valid token, automatically expiring if the authorization period expires or the trajectory hash does not match.

[0061] The authorization token may include a trajectory hash (the authorization token is strongly bound to the trajectory hash), the authorization subject identifier (i.e., the identifier of a specific approval user), the authorization validity period, the scope of authorization permissions, and a digital signature (all specific approval users need to provide a digital signature). The authorization token is generated based on the Decentralized Identifiers (DID) specification, and the digital signature is generated within the Trusted Execution Environment (TEE) using a private key stored in the TEE, based on a digital signature algorithm (such as the national cryptographic algorithm SM2). The digital signature and private key support remote verification (proving that the token and audit signature were indeed generated by the trusted environment, reducing the risk of forgery). The strong binding between the authorization token and the trajectory hash aims to prevent the inference trajectory from being tampered with or the risk of link hijacking after authorization. The scope of authorization permissions may include the following information: allowed tools or functional interfaces, allowed action types, allowed target resource range, maximum amount / data volume / record count, maximum number of executions, execution time window, restrictions on tool call sources, sandbox policy identifier, and whether operation retries are allowed. For example, the authorization token can be structured as follows: .

[0062] In this application, the DID is used to identify the verifiable identity of the approval subject or approval service, where the approval subject (i.e., the specific approval user) is the holder, the security sandbox is the verifier, and the enterprise identity / credential service is the issuer. Additionally, the authentication of the authorized subject can employ algorithms such as SM2.

[0063] The purpose of step S140 is to identify medium- to high-risk operations, suspend their execution, and send them for manual approval. Once approved, the operation is released to proceed with subsequent steps.

[0064] Step S150: If the inference trajectory meets the execution access conditions based on the risk assessment or approval results, the security sandbox is invoked, and the security sandbox (also known as the security sandbox module, which provides an isolated execution environment for business operations, offering resource isolation, permission restrictions, and behavior monitoring capabilities) executes the inference trajectory based on the principle of least privilege. The security sandbox is equipped with a Trusted Execution Environment (TEE) with an isolated memory area, which can parse the authorization token and inference trajectory and release execution permissions.

[0065] As an example, the execution access condition is either that the risk assessment result corresponding to the inference trajectory is at a low risk level (in which case the risk assessment module sends the inference trajectory to the security sandbox, or the risk assessment module sends both the inference trajectory and the risk assessment result to the security sandbox, which then determines whether the execution access condition is met), or that the approval result corresponding to the inference trajectory contains an authorization token, the authorization token is valid, and the digital signature verification is successful (in which case the security sandbox can receive the inference trajectory and authorization token sent by the approval module and determine whether the execution access condition is met). If the inference trajectory does not meet the execution access condition, a response to block the task execution is returned to the task initiating user.

[0066] In some embodiments of the present invention, the prior art lacks an isolation and control mechanism for the execution phase, which cannot prevent the authorized plan from being tampered with or replaced, thus breaking the protection loop. Therefore, before determining that the execution access conditions are met and the inference trajectory is executed by the security sandbox, the method proposed in this application may further include: the security sandbox using a hash algorithm to generate a verification hash value corresponding to the inference trajectory to be executed, and comparing the consistency between the verification hash value and the trajectory hash value. The inference trajectory will only be executed by the security sandbox if the verification hash value and the trajectory hash value are consistent, in order to prevent the approved plan from being tampered with; if they are inconsistent, the task execution will be blocked. The verification hash value can be generated in the following ways: directly re-normalize the inference trajectory and calculate the hash value, or calculate the node hash for each subtask in the inference trajectory and associate the node hash with the root hash (or Merkle root) of the inference trajectory for verification. In addition, before the security sandbox executes, it can also verify whether the trajectory hash value and the audit trail identifier correspond to the business operation task to be executed.

[0067] The principle of least privilege in a security sandbox includes restricting the type of tool calls, the range of call parameters, and the call rate. It also involves real-time monitoring of abnormal behavior during execution, immediately terminating execution (i.e., blocking the execution of business operations) and triggering an alarm upon the occurrence of an anomaly. For example, for the business operation task "transfer 50,000 yuan to supplier A with a note for payment in February 2026," the principle of least privilege in the security sandbox could be: only granting access to the transfer tool, limiting the amount of a single transfer to no more than 100,000 yuan, and only allowing transfers to whitelisted accounts, thereby monitoring the execution process in real time and ultimately completing the transfer operation. In other words, the principle of least privilege in a security sandbox is mainly reflected in the following aspects: only granting access to tools necessary to complete the current task, only granting access to parameter ranges within the approved scope, only granting necessary execution times and time windows, and explicitly prohibiting tools and actions unrelated to the current task. Furthermore, different tool types, call parameter ranges, and call rates can be dynamically determined for different task types, sub-task execution operations, risk assessment results, and authorized permission ranges.

[0068] After a business operation task is blocked from execution, a corresponding blocking notification message needs to be sent to the user's business system. The blocking notification message may include information such as the error reason, the trajectory hash value, the audit trail identifier, the multidimensional consistency assessment result, and the risk assessment result.

[0069] Existing technologies lack standardized, tamper-proof, and verifiable end-to-end auditing mechanisms, failing to meet the traceability and evidentiary requirements of stringent compliance scenarios and hindering precise allocation of responsibility. Figure 2 As shown, to achieve full lifecycle management, the method proposed in this application further includes step S160: when the inference trajectory generation module obtains the business operation task, the audit module generates a fully process-bound audit trace identifier (X-Audit-Trace-ID) and records the operation logs of the inference trajectory generation module, plan verification module, risk assessment module, approval module, and security sandbox, thereby generating the audit record corresponding to the business operation task. That is, the full-process records of the inference trajectory generation module, plan verification module, risk assessment module, approval module, security sandbox, and trajectory hash generation module are synchronized to the audit module, and the audit trace identifier is bound to the trajectory hash value, inference trajectory, multi-dimensional consistency assessment result, risk assessment result, approval result (such as authorization token), and security sandbox execution record. Through full-process audit traceability, cross-system evidence collection, responsibility attribution, and non-repudiation audits can be carried out by relying on the audit trace identifier, completing post-event review and compliance evidence collection.

[0070] The audit module generates a hash-chain-based, tamper-proof audit record structure and standardized, evidence-provable response fields bound to a global audit identifier. This results in audit records corresponding to business operation tasks, achieving end-to-end standardization and tamper-proof auditing. The audit records are characterized by their ability to block, trace, and provide evidence, meeting the control requirements of stringent compliance scenarios. Audit records may include audit trace identifiers, inference trajectory generation module identifiers (specifically, the executing agent identifier), business operation task identifiers, trajectory hash values, multi-dimensional consistency verification results, risk assessment results, approval results (specifically, authorization tokens), execution results from the security sandbox, and timestamps (which can be at the millisecond level).

[0071] Audit logs can be stored using hashing (e.g., using the SM3 algorithm), for example, refer to Figure 3 The calculation process, the first The hash value of an audit record can be represented as: || ,in, For the first The complete and standardized content of the audit record, For the first The timestamp of each audit record This is the chained hash value of the previous audit record. Furthermore, audit records can be digitally signed (e.g., using a private key within the TEE and the SM2 algorithm) to ensure their immutability and non-repudiation. In addition, audit records can be stored locally or synchronized to external storage such as WORM (Write Once Read Many) storage (which can be read-only), a blockchain evidence storage platform, or an enterprise compliance audit system.

[0072] In some embodiments of the present invention, if the inference trajectory is modified during the execution of the lifecycle management method proposed in this application, steps S120-S140 need to be re-executed, and the trajectory hash value needs to be regenerated. Specifically, changes in business operation tasks, executing agents, or user business systems constitute modifications to the inference trajectory. Changes in log description wording, explanatory text, display order, etc., that do not affect the execution semantics, are not considered modifications to the inference trajectory. Changes in business operation tasks may include the task initiating user modifying parameters such as the target object, amount, or data range; changes in executing agents may include changes in tool sequences, dependencies, or key parameters due to weight planning of the executing agent, or changes in permission policies or compliance policies that render the original plan no longer compatible; changes in user business systems may include specific approval users requesting adjustments to the inference trajectory and resubmission, or changes in external states necessitating a change in the execution path.

[0073] After step S150 is completed and the audit record is obtained in step S160, the execution result (execution status is normal completion or execution exception, etc.) and the audit record (or a summary of the audit record) can be returned to the user's business system. When transmitting the response to the task blocking execution, the execution result, and the audit record to the user's business system, formats such as HTTP status codes + JSON, gRPC status details, and message queue event bodies can be used to preserve the core meaning and evidentiary capabilities of the fields. In addition to specific data, the information returned to the user's business system may include audit trace identifiers, trace hash values, inference traces (or inference trace summaries), multidimensional consistency assessment results, risk assessment results, approval results, and authorization tokens, etc.

[0074] When transmitting data between modules, this application utilizes an internal bus for collaborative communication and employs encryption algorithms (such as the national cryptographic algorithm SM4-GCM) for both storage and transmission encryption, including the encrypted storage and transmission of authorization tokens and audit logs. When using the national cryptographic algorithm, this application can also combine it with a post-quantum cryptographic algorithm (ML-KEM). The post-quantum cryptographic algorithm is used to negotiate the shared key, while the national cryptographic algorithm is used for authentication, digestion, and encryption, achieving pluggable algorithm adaptation (specifically, the session key is negotiated via ML-KEM, key derivation is performed using HKDF-SM3, and then the corresponding function is executed using the national cryptographic algorithm), while simultaneously meeting compliance and quantum attack resistance requirements. Furthermore, this application can also use the HKDF-SM3 algorithm for key derivation and perform field separation using kdf_label to avoid mutual interference between subkeys used for different purposes.

[0075] Compared with existing technologies, the lifecycle management method proposed in this invention has the following significant technical advantages: ① The ability to identify risks before execution is significantly improved, which can effectively prevent hidden deviations such as prompt injection and plan deviation: This invention transforms the black-box reasoning process of the agent into a standardized reasoning trajectory plan graph, introduces a verifier independent of the executing agent to perform multi-dimensional consistency verification, and sets an independent scoring gate, which can cover hidden risks such as deviation from the plan target, abnormal parameters and unauthorized calls before execution.

[0076] ② Constructing a complete security control chain, balancing automation efficiency and security: This invention achieves tiered control of business operation risks through a process of "pre-consistency verification + dynamic risk grading + authorization gating + sandbox isolation execution": high-risk business operation tasks trigger dual authorization, medium-risk business operation tasks trigger single authorization, and low-risk business operation tasks maintain automated execution. This tiered control scheme can effectively reduce the false execution rate of high-risk business operations while ensuring that it does not increase execution delays.

[0077] ③ The authorization token is strongly bound to the inference trajectory, which can effectively prevent the risk of tampering after authorization: This invention strongly binds the authorization token to the hash value of the inference trajectory and the global audit identifier, and forces the verification of hash consistency before executing the inference trajectory in the sandbox, thereby solving the technical problems of plan replacement and link hijacking after authorization in the existing technology; at the same time, based on DID and TEE technology, the authorization token can be made unforgeable and non-repudiable, improving the security of the authorization process.

[0078] ④ The entire process is auditable and verifiable, meeting the requirements of strict compliance scenarios. This invention defines standardized audit record and response fields, which can prevent audit records from being tampered with through a hash chain structure and digital signatures, and achieve complete tracking of the entire chain through a global audit trace identifier. At the same time, the audit records support post-event review, compliance evidence collection and accurate division of responsibilities, which can solve the technical problems of existing audit logs being unable to provide evidence and assign responsibilities, and is suitable for the requirements of highly compliant scenarios such as finance and government.

[0079] Corresponding to the above method, the present invention also provides a lifecycle management device for business operation tasks. The device includes a computer device, which includes a processor and a memory. The memory stores computer programs / instructions, and the processor is used to execute the computer programs / instructions stored in the memory. When the computer programs / instructions are executed by the processor, the device implements the steps of the method described above.

[0080] like Figure 4 As shown, the lifecycle management device proposed in this application integrates a reasoning trajectory generation module, a trajectory hash generation module, a plan verification module, a risk assessment module, an approval module, a security sandbox, and an audit module. Each functional module independently and collaboratively executes the method steps of this invention. In a cloud-edge collaborative scenario, the security sandbox can be set on the edge side, while the other modules in the lifecycle management device can be set on the cloud side.

[0081] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0082] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0083] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0084] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A lifecycle management method for business operation tasks, characterized in that, The method includes the following steps: Obtain business operation tasks from user business systems, and obtain corresponding inference trajectories based on the business operation tasks; wherein, the inference trajectory includes the operational attributes of multiple sub-tasks obtained by decomposing the business operation tasks in the risk dimension; The inference trajectory is subjected to multi-dimensional plan consistency verification to obtain the multi-dimensional consistency verification result corresponding to the inference trajectory; wherein, the multi-dimensional plan consistency verification includes target consistency verification, parameter legality verification and permission compliance verification; If the multidimensional consistency verification result meets the consistency condition, a business operation risk assessment is performed based on the multidimensional consistency verification result and the operational attributes of all subtasks corresponding to the inference trajectory in the risk dimension, and the risk assessment result corresponding to the inference trajectory is obtained. If the risk assessment result corresponding to the inference trajectory meets the risk approval conditions, an approval request corresponding to the inference trajectory is generated and sent to the specific approval user in the user's business system to obtain the approval result corresponding to the inference trajectory. If the inference trajectory is determined to meet the execution access conditions based on the risk assessment results or approval results, the execution of the inference trajectory is realized by using a security sandbox, thereby completing the lifecycle management of the business operation task.

2. The method according to claim 1, characterized in that, The business operation task includes the following information: task type, task initiator user identifier, application resource type, target action, target object, and key task parameters; The step of obtaining business operation tasks from the user's business system and obtaining the corresponding inference trajectory based on the business operation tasks includes: The task parsing submodule obtains the business operation task, determines the permission boundaries and prohibited operations of the executing agent based on the task type, task initiator user identifier and application resource type contained in the business operation task, determines the task execution constraints based on the target action, target object and key task parameters contained in the business operation task, and inputs the business operation task and the determined permission boundaries, prohibited operations and task execution constraints into the executing agent to obtain the inference trajectory.

3. The method according to claim 2, characterized in that, The reasoning trajectory includes the execution operations corresponding to the multiple sub-tasks obtained from the decomposition of the business operation task, the dependencies between the sub-tasks, and the tools to be called by each sub-task, tool call parameter constraints, preconditions and postconditions. The target consistency check is used to check the matching degree between the business operation task and the execution operation corresponding to all sub-tasks. The parameter validity check is used to check whether the execution operation corresponding to each sub-task and the tool call parameter constraints of each sub-task conform to the preset business rules. The permission compliance check is used to check whether the execution operation corresponding to each sub-task, the tool to be called by each sub-task, and the tool call parameter constraints of each sub-task are within the permission boundary. The operational attributes of the risk dimensions include one or more of the following: financial risk attributes, access risk attributes, data security risk attributes, operational characteristic risk attributes, historical behavior risk attributes, environmental context risk attributes, and compliance and audit risk attributes.

4. The method according to claim 3, characterized in that, The multi-dimensional plan consistency verification also includes logical consistency verification, which is used to verify whether the dependencies between subtasks are abnormal and whether the preconditions and postconditions of each subtask can be met. When the inference trajectory includes cited evidence for each subtask, the multi-dimensional plan consistency check also includes an evidence citation consistency check, which verifies whether the cited evidence for each subtask is authentic and valid; and The consistency condition is that the verification result of any verification dimension in the plan consistency verification is greater than a specific threshold and / or the multi-dimensional consistency result is greater than a preset plan consistency threshold.

5. The method according to claim 1, characterized in that, After obtaining the inference trajectory, the method further includes: generating a trajectory hash value corresponding to the inference trajectory.

6. The method according to claim 5, characterized in that, The approval request includes the inference trajectory, the multidimensional consistency verification result corresponding to the inference trajectory, the risk assessment result corresponding to the inference trajectory, and the trajectory hash value corresponding to the inference trajectory. If the inference trajectory is approved, the approval result includes an authorization token corresponding to the inference trajectory. The authorization token includes the trajectory hash value, the authorization subject identifier, the authorization validity period, the authorization scope, and the digital signature. If the risk assessment result corresponding to the inference trajectory is at a low risk level, the number of specific approval users is zero; if the risk assessment result corresponding to the inference trajectory is at a medium risk level, the number of specific approval users is one; if the risk assessment result corresponding to the inference trajectory is at a high risk level, the number of specific approval users is multiple. The risk approval condition is that the risk assessment result corresponding to the reasoning trajectory is at the medium-risk or high-risk level; as well as The entry criteria are that the risk assessment result corresponding to the reasoning trajectory is at a low risk level, or that the approval result corresponding to the reasoning trajectory contains an authorization token and the authorization token is within its validity period.

7. The method according to claim 6, characterized in that, The authorization token is generated based on a decentralized identifier, the digital signature is generated within the trusted execution environment using a private key stored in the trusted execution environment based on the SM2 algorithm, and the hash algorithm is the SM3 algorithm.

8. The method according to claim 5, characterized in that, Before executing the inference trajectory, the method further includes: The security sandbox generates a verification hash value corresponding to the inference trajectory to be executed, and compares the consistency between the verification hash value and the trajectory hash value. Both the verification hash value and the trajectory hash value are generated using a hash algorithm, specifically the SM3 algorithm.

9. The method according to claim 1, characterized in that, The method further includes: Upon obtaining a business operation task, an audit trail identifier is generated, and the operation logs of the inference trajectory generation module, plan verification module, risk assessment module, approval module, and security sandbox are recorded, thereby generating an audit record corresponding to the business operation task. The audit records corresponding to the business operation tasks include audit trace identifiers, inference trajectory generation module identifiers, business operation task identifiers, trajectory hash values, multidimensional consistency verification results, risk assessment results, approval results, execution results of the security sandbox, and timestamps; the audit records are stored in a hash manner.

10. A lifecycle management device for business operation tasks, characterized in that, The device includes: The inference trajectory generation module is used to acquire business operation tasks from the user's business system and obtain corresponding inference trajectories based on the business operation tasks; wherein, the inference trajectory includes the operational attributes of multiple sub-tasks obtained by decomposing the business operation tasks in the risk dimension. The plan verification module is used to perform multi-dimensional plan consistency verification on the inference trajectory to obtain the multi-dimensional consistency verification result corresponding to the inference trajectory; wherein, the multi-dimensional plan consistency verification includes target consistency verification, parameter legality verification and permission compliance verification; The risk assessment module is used to assess the business operation risk based on the multidimensional consistency verification result and the operational attributes of all subtasks corresponding to the inference trajectory in the risk dimension, when the multidimensional consistency verification result meets the consistency condition, and to obtain the risk assessment result corresponding to the inference trajectory. The approval module is used to generate an approval request corresponding to the inference trajectory and send it to a specific approval user in the user's business system when the risk assessment result corresponding to the inference trajectory meets the risk approval conditions, so as to obtain the approval result corresponding to the inference trajectory. The security sandbox is used to execute a reasoning trajectory when the execution access conditions are met based on risk assessment results or approval results, thereby completing the lifecycle management of the business operation task.

Images