An artificial intelligence execution control method, system, device and medium based on a hardware root of trust

Abstract

This invention discloses an artificial intelligence execution control method, system, device, and medium based on a hardware root of trust, relating to the field of artificial intelligence execution control technology. The method includes receiving and standardizing execution tasks; generating structured execution behavior objects and generating authorization payloads accordingly; verifying the authorization payloads through execution gating nodes, allowing requests if successful and blocking them otherwise; collecting state summaries before and after execution, verifying the authenticity of the results based on target predicates and state differences; conducting risk assessment and feedback based on the verification results; and writing task, authorization, gating, execution, verification, and risk information into a chained audit log. The system also includes a local trusted execution gateway, a multi-level authorization chain, trust domain isolation, dynamic trial-and-error controlled execution, manual takeover / emergency circuit breaker / rollback recovery, and a cross-terminal continuous execution mechanism. This invention achieves unified authorization, gating, verification, risk feedback, and audit traceability for execution requests, improving the controllability, authenticity, and auditability of execution behavior.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence execution control technology, and in particular to an artificial intelligence execution control method, system, device and medium based on hardware root of trust. Background Technology

[0002] With the continuous improvement of computer application environments, the complexity of business systems, and artificial intelligence capabilities, automated execution technology has evolved from the early stage of fixed action execution based on scripts and macro commands to the process execution stage based on robotic process automation, and further to the goal-driven execution stage based on artificial intelligence agents. Traditional scripts, macro commands, and fixed automation tools mainly simulate keyboard input, mouse clicks, window switching, command triggering, or interface calls through predefined action sequences to complete repetitive tasks. This type of technology has a simple structure, but it heavily relies on the stability of the execution environment and the prior exhaustive search of execution steps. Once the interface elements, control hierarchy, interface parameters, or system state change, it is easy to cause execution failure, false triggering, or process interruption.

[0003] Following scripting and macro technologies, Robotic Process Automation (RPA) technology has gradually developed. RPA systems improve the configurability and reusability of automated business processes through graphical process orchestration, control recognition, rule configuration, exception handling, and scheduling mechanisms. However, the essence of RPA remains the automatic execution of predefined process nodes and rule sets. It primarily addresses the problem of repetitive execution of established processes, rather than unified authorization, unified gating, unified result verification, and unified auditing in multi-agent environments. When AI capabilities are introduced into RPA systems, they are typically used only for identification, prediction, or decision support, failing to form a complete governance loop at the execution control sovereignty level.

[0004] In recent years, the development of large-scale models, multimodal models, and AI agent technologies has enabled artificial intelligence systems to gradually acquire the ability to understand natural language tasks, decompose task steps, invoke tools, select execution paths, and dynamically adjust to changes in the environment. Such systems can perform actual operations on target terminals, applications, or business systems through browser automation interfaces, desktop automation interfaces, application programming interfaces (APIs), operating system APIs, or input signal injection paths. As artificial intelligence systems shift from "answering questions" to "invoking tools, collaborating with agents, and autonomously executing tasks," execution governance has become one of the core technical challenges for the practical application of artificial intelligence.

[0005] Existing technologies have at least the following shortcomings. First, traditional scripts, macros, and fixed automation tools can only execute predefined actions and cannot form a unified representation and structured behavior model around task objectives, thus failing to handle dynamic environments, multi-path execution, and multi-step replanning scenarios. Second, traditional RPA lacks a governance loop based on AI-driven dynamic decision-making, and cannot establish unified authorization, gating, verification, risk, and audit controls before, during, and after execution. Third, while existing common AI agent solutions can plan actions, they typically lack hardware-level release control; execution requests often directly enter the software interface or local agent path, lacking a trusted control node at the front end of the execution path capable of ultimately releasing or blocking execution requests.

[0006] Fourth, existing solutions typically consider action issuance, successful interface call, completion of process nodes, or log writing as execution completion, without further verifying whether the target predicate is satisfied or whether the differences in state before and after execution are consistent with the task objective. This makes it difficult to accurately identify situations where an action has been issued but the objective has not been achieved or the result deviates from the original intent. Fifth, existing solutions generally lack multi-level authorization chains, trust domain isolation, local trusted execution gateways, dynamic trial-and-error controlled execution, and cross-terminal continuous execution governance mechanisms, making it difficult to support unified execution control in multi-agent, multi-terminal, multi-tenant, and multi-organizational environments. Sixth, existing logs are mostly discrete records, lacking pre-sequence summary association, trusted signatures, and anti-tampering mechanisms, making it difficult to form a highly trusted chain of responsibility for auditing and accountability in high-responsibility scenarios.

[0007] As artificial intelligence (AI) systems increasingly enter real-world business systems through cloud policies, local agents, browser execution interfaces, application interfaces, and operating system call interfaces, execution control should no longer be viewed as a functional issue of a local script or a single agent, but rather as an infrastructure issue for AI execution control. Therefore, a new technical solution is urgently needed to establish unified authorization boundaries, execution release, result verification, risk feedback, and audit traceability mechanisms for execution requests without weakening the execution capabilities of AI, thereby improving the controllability, authenticity, auditability, and accountability of AI execution behavior. Summary of the Invention

[0008] One of the objectives of this invention is to provide an artificial intelligence execution control method, system, device, and medium based on a hardware root of trust. By converting task objectives into structured execution behavior objects, an authorization payload bound to the execution boundary, environmental context, and subject identity is generated. This ensures that any execution request must pass through an execution gating node directly coupled to the hardware root of trust for final release or blocking before entering the target system.

[0009] The second objective of this invention is to provide a unified execution governance framework that covers physical input paths, virtual input paths, browser automation paths, application interface paths, operating system call paths, and local proxy paths. This framework enables different execution paths to be incorporated into a unified authorization, gating, verification, risk, and audit governance system, thereby avoiding loopholes or governance blind spots caused by differences in execution paths.

[0010] The third objective of this invention is to provide a local trusted execution gateway that prevents cloud tasks and policies from being directly executed on the target host. Instead, they must first be received, verified, bound, gated, and cached by the trusted execution gateway deployed locally, thereby forming a unique and effective entry point locally.

[0011] The fourth objective of this invention is to provide a multi-level authorization chain and trust domain isolation mechanism to support authorization transfer, permission reduction, revocation linkage, cross-domain approval, and responsibility division in multi-agent collaboration, multi-user, multi-device, multi-organization, and multi-tenant environments.

[0012] The fifth objective of this invention is to provide a mechanism for verifying the authenticity of execution results and a chain audit mechanism. Instead of using the issuance of actions or the writing of logs as the sole basis for execution completion, the degree of satisfaction of target predicates, the differences in states before and after execution, and the consistency of the environment are used as the basis for judgment, and an immutable continuous audit chain is formed.

[0013] To achieve the above-mentioned objectives, the present invention provides the following technical solution:

[0014] This invention proposes an artificial intelligence execution control method based on a hardware root of trust. The method includes at least the following steps: receiving an execution task and performing task standardization; converting the standardized task into a structured execution behavior object; generating an authorization payload based on the structured execution behavior object; sending the authorization payload to an execution gating node directly coupled to the hardware root of trust for verification; allowing the execution request to enter the target system if the verification passes, and blocking the execution request if the verification fails; obtaining a state summary before and after execution and verifying the authenticity of the result based on the target predicate, state differences, and environmental consistency; performing a risk assessment based on the verification results and triggering feedback control; and writing task, authorization, gating, execution, verification, and risk information into a chained audit log.

[0015] The structured execution behavior object preferably includes: task identifier, task source, target description, target object identifier, action primitive set, execution path type, object location method, environmental constraints, time window, risk level, result judgment rules, rollback strategy, manual takeover strategy, and audit strategy. The action primitive set may consist of one or more of the following: input primitives, browser operation primitives, application interface call primitives, operating system call primitives, and local proxy execution primitives.

[0016] The authorization payload preferably includes: task identifier, behavior summary, target summary, environment summary, device binding identifier, user binding identifier, proxy chain identifier, trust domain identifier, time window, random number, anti-replay counter, policy version, sensitivity level, execution path whitelist, candidate action boundary, manual takeover trigger parameter, rollback authorization parameter, and signature information generated or verified by the hardware root of trust. Fields in the authorization payload are bound item-by-item to the structured execution behavior object to prevent action replacement, boundary expansion, or context drift after authorization.

[0017] In this invention, the hardware root of trust is the execution permission sovereign node. The hardware root of trust can be deployed as a secure zone within a standalone security chip, TPM module, security microcontroller, execution permission control board, or as a protected execution control zone within a local trusted execution gateway. The hardware root of trust undertakes at least one or more of the following responsibilities: protected key storage, authorized signature verification, random number and counter management, execution permission control, and audit signatures.

[0018] In this invention, the execution gate node is located at a necessary position in the execution path. For the physical input path, the execution gate node is located on the signal forwarding link before the input signal enters the target host; for the virtual input path, the execution gate node is located before the virtual input driver is submitted to the operating system input stack; for the browser automation path, the execution gate node is located between the browser execution agent and the browser control interface; for the application interface path, the execution gate node is located before the application interface request is submitted to the target application; for the operating system call path, the execution gate node is located between the call agent and the system service boundary; for the local agent path, the execution gate node is located at the final release point of the local trusted execution gateway.

[0019] The local trusted execution gateway is preferably deployed on the target host's local side and is logically or hardware isolated from the target host's operating system. Execution requests from the cloud task center, upper-layer platform, external agent, or mobile terminal do not directly enter the target host, but are first received by the local trusted execution gateway. The local trusted execution gateway completes task reception, authorization verification, trust root interaction, path gating, state caching, and audit caching, forming the only valid entry point for AI execution requests to enter the target host.

[0020] In a preferred embodiment, this invention supports a multi-level authorization chain. The main authorization token is generated from the original task, and sub-authorization tokens are derived from the main authorization token and used for the execution of sub-tasks, candidate actions, or sub-agents. Sub-authorization tokens must not expand the action boundaries, execution path range, environment range, or time window defined by the main authorization token. When the main authorization token is revoked or expires, the relevant sub-authorization tokens also expire. The integrity of the authorization chain is verified during execution, ensuring that each atomic action can be traced back to the original task source.

[0021] In a preferred embodiment, this invention supports trust domain isolation. In addition to user and device binding, the executed task carries one or more identifiers from the user trust domain, device trust domain, organization trust domain, and tenant trust domain. The execution gating node further verifies whether the current execution context matches the trust domain identifier during authorization verification. Cross-domain execution requires additional approval, dual-subject confirmation, or security policy conditions; otherwise, the execution request is rejected or a circuit breaker is triggered.

[0022] In a preferred embodiment, the present invention supports dynamic trial-and-error controlled execution. The system allows the AI ​​agent to generate multiple candidate actions within the authorized boundaries based on environmental changes, but each candidate action must be re-associated or derived with atomic authorization before execution and verified by a gating node; if a candidate action fails and the risk does not exceed the threshold, the system is allowed to replan according to preset rules; if the number of consecutive failures, risk score, deviation degree, or environmental inconsistency reaches the threshold, permission tightening, manual takeover, emergency circuit breaker, or rollback recovery are automatically triggered.

[0023] In a preferred embodiment, the present invention supports continuous execution across terminals and sessions. The first terminal initiates a task and forms an execution status packet, which is then migrated to the second terminal through a secure channel. After the local trusted execution gateway on the second terminal verifies the integrity of the execution status packet, authorization continuity, terminal trustworthiness, and session consistency, it continues execution of the unfinished task from the breakpoint. The entire process is uniformly written into the same chained audit record sequence.

[0024] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0025] Compared with traditional scripts, macro commands, and fixed automation tools, this invention achieves unified pre-control of execution requests by combining structured execution behavior objects, authorized payloads, and hardware trust root gating, thus avoiding governance gaps where execution behavior can directly fall into the target system.

[0026] Compared with traditional RPA, this invention not only focuses on the process execution itself, but also introduces execution release sovereign nodes, result authenticity verification, risk feedback tightening and chain auditing mechanisms, so as to upgrade automatic execution from process automation to trusted execution governance.

[0027] Compared with ordinary AI agent execution solutions, this invention forms a unified execution control system that is more suitable for multi-subject, multi-terminal, multi-tenant, and high-responsibility scenarios through local trusted execution gateway, multi-level authorization chain, trust domain isolation, dynamic trial and error controlled execution, and cross-terminal continuous execution.

[0028] This invention can organically combine authorization, gating, verification, risk feedback and audit records without weakening the execution capabilities of artificial intelligence, thereby improving the controllability, authenticity, auditability, accountability and continuous governance capabilities of artificial intelligence execution behavior. Attached Figure Description

[0029] Figure 1 This is a diagram of the overall system architecture.

[0030] Figure 2 This is a diagram illustrating the execution path gating.

[0031] Figure 3 Diagram of the local trusted execution gateway architecture;

[0032] Figure 4 This diagram illustrates a multi-level authorization chain and trust domain isolation. Detailed Implementation

[0033] The present invention will be further described in detail below with reference to experimental examples and specific embodiments. However, this should not be construed as limiting the scope of the above-mentioned subject matter of the present invention to the following embodiments; all technologies implemented based on the content of the present invention fall within the scope of the present invention.

[0034] 1. System Overall Architecture

[0035] like Figure 1 As shown, the artificial intelligence execution control system of the present invention includes at least a user terminal, a management control terminal, a cloud-based task and strategy center, a task input module, a task standardization module, an execution behavior object modeling module, an authorized payload generation module, a local trusted execution gateway, a hardware root of trust, an execution gating module, a target host, a status acquisition module, a result verification module, a risk assessment module, and an audit chain storage module.

[0036] User terminals are used to initiate natural language tasks, structured tasks, or policy tasks; management and control terminals are used to configure policy templates, approve cross-domain requests, and issue manual takeover instructions; the cloud-based task and policy center is used to centrally store policies, uniformly orchestrate tasks, and maintain models and agent execution logic; the local trusted execution gateway is deployed on the target host's local side to receive execution tasks and authorization data from the cloud or other terminals, and to implement local trusted control over execution requests; the hardware root of trust is used to provide protected key storage, signature verification, random number management, and access control; and the execution gating module is used to ultimately allow or block various execution paths.

[0037] 2. Structured execution behavior objects

[0038] The execution behavior object can be represented in the form of structured data records, such as, but not limited to, JSON structure, binary TLV structure, Protocol Buffers structure, or other equivalent structures. Preferably, the execution behavior object includes the following fields: task_id, task_source, target_desc, target_object_id, action_primitives, path_type, locator_rule, precondition_set, goal_predicate_set, time_window, risk_level, rollback_rule, handover_rule, and audit_rule.

[0039] Among them, `task_id` is used to uniquely identify the task; `task_source` is used to identify the source of the task; `target_desc` is used to represent the target description; `target_object_id` is used to identify the target object; `action_primitives` is used to store one or more action primitives; `path_type` is used to represent the execution path type; `locator_rule` is used to describe the object location method; `precondition_set` is used to characterize the execution preconditions; `goal_predicate_set` is used to represent the target predicate set; `time_window` is used to limit the allowed execution time window; `risk_level` is used to represent the initial risk level; `rollback_rule` is used to represent the rollback strategy; `handover_rule` is used to represent the manual takeover strategy; and `audit_rule` is used to represent the audit logging strategy.

[0040] Action primitives can further include action type, action parameters, parameter constraints, dependent actions, maximum number of retries, atomic authorization flag, and rollback flag. The execution parameters corresponding to action primitives differ across path types. For example, action primitives for physical input paths may include key values, coordinates, press duration, and input sequence; action primitives for browser automation paths may include element location rules, event types, script fragments, and browser context flags; and action primitives for application interface paths may include interface name, parameter set, and response validation rules.

[0041] 3. Authorized payload and hardware root of trust

[0042] The authorized payload is preferably generated based on the structured execution behavior object, and its fields include at least: task identifier, behavior summary, target summary, environment summary, device binding identifier, user binding identifier, proxy chain identifier, trust domain identifier, time window, random number, anti-replay count, policy version, sensitivity level, execution path whitelist, candidate action boundary, manual takeover trigger parameters, rollback authorization parameters, and signature information.

[0043] The action digest can be obtained by hashing the key fields of the object performing the action after normalization encoding; the target digest can be obtained by encoding the target predicate set and the target object identifier; the environment digest can be obtained by normalizing one or more of the host identifier, application version, window context, process identifier, session identifier, network environment identifier, and trust domain identifier in the execution environment. The signature information can be digitally signed by the hardware root of trust using a protected key on the authorized message combining the above digests.

[0044] The hardware root of trust may include a protected key area, an authorization verification logic area, a random number and counter management area, an access control area, and an audit signature area. The protected key area is used to store private keys, root keys, or derived key materials; the authorization verification logic area is used to verify signature information, time windows, anti-replay counters, and binding relationships; the random number and counter management area is used to generate random numbers, increment counters, and verify the uniqueness of requests; the access control area is used to output allow or block signals at the execution gating node; and the audit signature area is used to sign or digest audit blocks.

[0045] 4. Local trusted execution gateway and unique valid entry point.

[0046] like Figure 3 As shown, a local trusted execution gateway includes at least a task receiving unit, an authorization verification unit, a trust root communication unit, an execution gating unit, a state cache unit, an audit cache unit, a risk threshold control unit, and a cross-terminal state continuity unit. Execution tasks and authorization payloads sent by the cloud task center, upper-layer platform, or other terminals preferably first enter the task receiving unit; the task receiving unit then forwards them to the authorization verification unit for pre-parsing and field integrity checks; the trust root communication unit then interacts with the hardware trust root to complete signature verification, anti-replay verification, and binding relationship comparison; after successful verification, the execution gating unit outputs a release control signal, sending the execution request to the execution interface allowed by the target host.

[0047] To establish a single valid entry point, the target host's input interface, virtual input driver interface, browser execution proxy interface, application interface call channel, and operating system call proxy interface are configured to accept only execution requests approved through the execution gating unit. Any execution request that bypasses the local trusted execution gateway and is submitted directly to the target host is rejected by the target host's interception policy or triggers an alarm. Thus, the local trusted execution gateway establishes a single valid entry point on the local side.

[0048] A local trusted execution gateway can be logically or hardware isolated from the target host. For example, in logical isolation, the local trusted execution gateway runs within a protected service process, a restricted container, or a trusted virtual machine; in hardware isolation, the local trusted execution gateway can be deployed on a dedicated control board, an external control module, or an edge security box. Regardless of the form, the ultimate goal is to centralize the local allowance logic for execution requests within the controlled unit.

[0049] 5. Execution path gating

[0050] like Figure 2 As shown, the execution gating node covers multiple types of execution paths. For physical input paths, the execution gating node is located at the signal forwarding position before the input signal enters the target host. Only after verification is passed is the key signal, mouse signal, or other input signal allowed to be sent to the target host. For virtual input paths, the execution gating node is located before the virtual input driver is submitted to the operating system input stack. It is used to determine whether to inject input events at the driver level or agent level.

[0051] For browser automation paths, the execution gate node is located between the browser execution proxy and the browser kernel control interface. Only after successful verification is it allowed to send control commands such as clicks, input, navigation, and script execution to the browser. For application interface paths, the execution gate node is located between the application proxy and the target application API. Only after successful verification is it allowed to initiate API calls to the target application. For operating system call paths, the execution gate node is located between the system call proxy and the system service boundary, determining whether to allow process creation, file access, configuration modification, or system resource calls. For local proxy paths, the execution gate node is located at the final approval point within the local trusted execution gateway.

[0052] 6. Verification of Results and Risk Scoring

[0053] The result authenticity verification module does not rely on the issuance of actions as the basis for completion. Instead, it determines whether the task objective has truly been achieved based on the target predicate and state differences. The pre-execution state summary and post-execution state summary can each consist of one or more of the following: interface state, file state, database state, session state, resource state, and context state. The target predicate can represent field appearance, object attribute change, state value relationship, resource change relationship, permission state satisfaction relationship, or business rule satisfaction relationship.

[0054] Preferably, the result authenticity verification module first performs a difference analysis on the pre-execution state summary and the post-execution state summary to obtain a state difference vector; then, based on the target predicate set, it determines whether the difference vector satisfies the task objective. If it does, the module outputs "execution successful"; if there is partial satisfaction or the result deviates, the module outputs "execution deviation"; if the objective is not achieved or an abnormal state occurs, the module outputs "execution error".

[0055] The risk scoring module preferably uses the following example model for scoring: RiskScore = w1 × DeviationLevel + w2 × FailureCount + w3 × SensitiveLevel + w4 × DomainConflict + w5 × ContextUncertainty. Where DeviationLevel represents the degree of deviation from the target, FailureCount represents the number of consecutive failures, SensitiveLevel represents the resource sensitivity level, DomainConflict represents the degree of trust domain conflict, ContextUncertainty represents environmental uncertainty, and w1 to w5 are preset weights. Based on the RiskScore, low-risk, medium-risk, and high-risk zones can be defined, triggering normal continuation, tightened permissions, manual confirmation, emergency circuit breaker, or rollback recovery respectively.

[0056] 7. Multi-level authorization chain and trust domain isolation

[0057] like Figure 4 As shown, the multi-level authorization chain preferably includes a main authorization token, sub-authorization tokens, and atomic authorization fragments. The main authorization token is generated from the original task; sub-authorization tokens are derived from the main authorization token and are used for the execution of subtasks, sub-agents, or tool agents; atomic authorization fragments are used for candidate actions or single-step action execution. Sub-authorization tokens preferably inherit the task identifier, root signature chain, and time window upper limit of the main authorization token, while rewriting the reduced action boundaries, path ranges, object boundaries, and environment ranges. When issuing, the parent token identifier, child token identifier, reduction rules, and issuance time should be recorded. Upon revocation, if the main authorization token is revoked, the corresponding sub-authorization tokens and atomic authorization fragments are simultaneously revoked according to the parent-child mapping relationship.

[0058] Trust domain isolation is preferably achieved through a combination of user trust domains, device trust domains, organization trust domains, and tenant trust domains. Each execution task must be bound to at least one trust domain identifier. When verifying authorization, the execution gating node verifies not only the signature, digest, and time window, but also whether the current execution context matches the trust domain identifier in the authorization. For cross-domain execution, the system can employ additional approval, dual-subject confirmation, dual-signature confirmation, or policy whitelist control. In a multi-tenant environment, each tenant's key space, gateway cache space, and audit storage space can be logically or physically isolated.

[0059] 8. Dynamic trial-and-error controlled execution, manual takeover, and continuous execution across terminals.

[0060] Dynamic trial-and-error controlled execution allows the AI ​​agent to generate multiple candidate actions within the authorization boundary. The candidate action generator can generate a set of candidate actions based on the current environment state, target predicate, and previous execution results; the atomic authorization generation unit generates corresponding atomic authorization fragments based on the candidate action set; the execution gating node verifies one by one whether the candidate action is within the authorization boundary. If a candidate action fails but the risk does not exceed the threshold, it can be replanned within a preset number of attempts; if the number of failures, domain conflicts, or context inconsistencies exceed the threshold, permission tightening, manual takeover, circuit breaking, or rollback recovery are triggered.

[0061] Manual takeover can be implemented by the manual takeover management module. The system switches to manual takeover mode when the risk score reaches a threshold, critical resources conflict, trust domains are inconsistent, the target object changes abnormally, audit chain verification fails, or the environmental context undergoes significant changes. In manual takeover mode, automatic execution is suspended, and operations are continued by authorized human operators; all operations are still recorded through execution gating nodes and the audit chain during the takeover process. Emergency circuit breaking is used to immediately block current and subsequent execution requests when a high-risk event occurs. Rollback recovery can be achieved through reverse operation scripts, transaction compensation, state snapshot recovery, or resource version recovery.

[0062] Cross-terminal continuous execution is achieved through execution status packets. The execution status packet preferably includes: task identifier, current step index, list of incomplete actions, summary of preceding audit blocks, authorization chain fragment, current state summary, environment summary, terminal identifier, session identifier, and signature information. After the first terminal forms the execution status packet, it sends it to the second terminal via a secure channel. The second terminal's local trusted execution gateway verifies the integrity of the execution status packet, authorization continuity, terminal trustworthiness, and session consistency. Upon successful verification, execution resumes from the breakpoint.

[0063] 9. Specific Applications

[0064] 9.1 Automated Execution of Personal Terminal Browsers

[0065] Users submit webpage information entry tasks via natural language. The system, in its cloud-based task and strategy center, standardizes these tasks into execution behavior objects that include the target webpage, target fields, submission conditions, and result judgment rules, and generates an authorization payload. After verification by the local trusted execution gateway, the browser's automated proxy only executes page navigation, element location, field filling, and button triggering operations when the gate node allows it. Upon completion, the system compares the webpage's state before and after submission, the returned page state, and the target predicate for a match. If a match is found, the task is considered successful; otherwise, if fields are not entered or the page redirects abnormally, it is considered a deviation or an anomaly.

[0066] 9.2 Enterprise Terminal Application Interface Execution

[0067] Enterprise-side financial applications require an AI agent to write the approval results into the business interface. The system transforms tasks into structured execution behavior objects, binding the approval number, target interface, allowed fields, time window, and tenant trust domain to the authorization payload. During execution, the local trusted execution gateway verifies the authorization, application interface whitelist, organization trust domain, and tenant trust domain. If the interface parameters are inconsistent with the authorization boundaries, the process is immediately blocked and written into the audit chain.

[0068] 9.3 Multi-agent collaborative execution

[0069] The platform agent breaks down complex tasks into sub-agents and tool agents. A main authorization token is generated first, and then sub-authorization tokens are derived based on the scope of the sub-tasks. Before executing each atomic action, a sub-agent must submit an atomic authorization fragment to its local trusted execution gateway for verification. If a sub-agent attempts to call a tool outside its boundaries, it is blocked due to authorization chain verification failure.

[0070] 9.4 Dynamic Trial and Error Controlled Execution

[0071] The AI ​​agent performs file organization tasks in a desktop environment. Due to the uncertainty of file naming and location, the system continuously generates candidate actions based on the environment, such as candidate file location, candidate directory writing, and candidate rollback strategies. Each candidate action must pass atomic authorization verification and trust domain verification. If three consecutive actions fail and the risk score exceeds the threshold, the system triggers manual intervention.

[0072] 9.5 Continuous execution across terminals

[0073] A mobile terminal initiates a maintenance work order processing task, and the cloud generates a task object and authorized payload. During execution, some steps need to be completed on the office host. The first terminal generates a status packet and sends it to the second terminal through a secure channel. After the second terminal's gateway verifies the integrity of the status packet, the terminal identifier, session consistency, and authorization continuity, it continues execution from the point where the unfinished action index was located.

[0074] 9.6 Manual takeover and rollback of high-risk business

[0075] In high-risk fund approval scenarios, if the system detects a change in the target account's status that is inconsistent with the original target predicate, and the risk score exceeds the threshold, the execution gating node immediately triggers a circuit breaker, while simultaneously notifying manual approval personnel to take over. If some status changes have already occurred, the rollback recovery module restores the account to its pre-execution state based on transaction compensation and snapshot recovery strategies, and records the entire process of takeover, circuit breaker, and rollback in the audit chain.

[0076] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An artificial intelligence execution control method based on hardware root of trust, characterized in that, The process includes the following steps: receiving task information and standardizing the task; generating structured execution behavior objects based on the standardized task information; Generate an authorization payload based on the structured execution behavior object; On the necessary execution path before the execution request enters the target host, the authorized payload is verified by an execution gating node directly coupled to the hardware root of trust. The execution request is allowed if the verification passes, and blocked if the verification fails. The specific operation corresponding to the structured execution behavior object is executed. A pre-execution state summary and a post-execution state summary are collected, and the execution result is verified for authenticity based on the target predicate, state differences, and environmental consistency. Risk assessment and feedback control are performed based on the verification results. Task, authorization, gating, execution, verification, and risk information are written into a chained audit log. The hardware root of trust is configured as an execution release sovereign node, deployed as a secure area in an independent security chip, TPM module, security microcontroller, execution control board, or a protected execution control area in a local trusted execution gateway, and is used to perform one or more of the following operations: protected key storage, authorized signature verification, random number and counter management, execution release control, and audit signature. The execution gating node is located at a necessary position in the execution path and verifies one or more of the following: authorized signature, behavior digest consistency, environment binding, device binding, time window, and anti-replay conditions. The hardware root of trust may include a protected key area, an authorization verification logic area, a random number and counter management area, an access control area, and an audit signature area; the protected key area is used to store private keys, root keys, or derived key materials; the authorization verification logic area is used to verify signature information, time windows, anti-replay counts, and binding relationships; The random number and counter management area is used to generate random numbers, increment counters, and verify the uniqueness of requests; the access control area is used to output allow or block signals at the gating node; and the audit signature area is used to sign or confirm the audit block.

2. The method according to claim 1, characterized in that, The structured execution behavior objects include at least one of the following: task identifier, task source, target description, target object identifier, action primitive set, execution path type, object location method, environmental constraints, time window, risk level, result judgment rules, rollback strategy, manual takeover strategy, and audit strategy.

3. The method according to claim 1, characterized in that, The authorized payload includes at least one of the following: task identifier, behavior summary, target summary, environment summary, device binding identifier, user binding identifier, proxy chain identifier, trust domain identifier, time window, random number, anti-replay count, policy version, sensitivity level, execution path whitelist, candidate action boundary, manual takeover trigger parameter, rollback authorization parameter, and signature information.

4. The method according to claim 3, characterized in that, The execution path includes one or more of the following: physical input path, virtual input path, browser automation path, application interface path, operating system call path, and local proxy path.

5. The method according to claim 1, characterized in that, It also includes a local trusted execution gateway, which is deployed on the local side of the target host and configured as follows: Receive execution tasks and authorization payloads, perform authorization verification, interact with hardware root of trust, perform path gating, cache execution status and cache audit records; The local trusted execution gateway serves as the only valid entry point before the target host. The target host's input interface, virtual input interface, browser execution interface, application call interface, and operating system call interface only accept execution requests that have been allowed through the local trusted execution gateway.

6. The method according to claim 1, characterized in that, The verification of the execution result authenticity includes: obtaining the state summary before execution and the state summary after execution; calculating the state difference between the state summary before execution and the state summary after execution; determining whether the state difference satisfies the target predicate; outputting execution success when the state difference satisfies the target predicate, and outputting execution deviation or execution exception when the state difference does not satisfy the target predicate.

7. The method according to claim 1, characterized in that, The risk assessment calculates a risk score based on one or more of the following factors: the degree of deviation from the target, the number of consecutive failures, the sensitivity level, the degree of trust domain conflict, and environmental uncertainty. Based on the risk score, it triggers continued execution, tightened permissions, manual takeover, emergency circuit breaker, or rollback recovery.

8. The method according to claim 1, characterized in that, The chain audit record includes at least a task identifier, a stage identifier, a previous block summary, a current block summary, a timestamp, a subject identifier, a key status summary, and signature information, and forms an immutable continuous audit chain through association of previous block summaries and signature verification.

9. The method according to claim 1, characterized in that, The authorization payload supports a multi-level authorization chain, and the execution authorization includes at least a main authorization token and a sub-authorization token. The sub-authorization token is derived from the main authorization token and is used for the execution of sub-tasks, candidate actions, or sub-agents.

10. The method according to claim 9, characterized in that, The sub-authorization token inherits the task identifier and signature chain of the main authorization token, and writes the reduced action boundary, execution path range, environment range and time window. The sub-authorization token shall not expand the execution boundary defined by the main authorization token.

11. The method according to claim 9, characterized in that, When the main authorization token is revoked, expired, or expires, the sub-authorization tokens associated with the main authorization token also become invalid. During execution, the integrity of the authorization chain is verified to ensure that each atomic action can be traced back to the original task source.

12. The method according to claim 1, characterized in that, The authorization payload also includes a trust domain identifier, which includes one or more of the following: user trust domain, device trust domain, organization trust domain, and tenant trust domain. When verifying authorization, the execution gating node further verifies whether the current execution context matches the trust domain identifier.

13. The method according to claim 12, characterized in that, Execution requests across trust domains must meet one or more of the following conditions: additional approval, dual-subject confirmation, dual-signature confirmation, or policy whitelist. If these conditions are not met, the execution request will be rejected or a circuit breaker will be triggered.

14. The method according to claim 1, characterized in that, The method supports dynamic trial-and-error controlled execution, including: generating multiple candidate actions within the authorization boundary; re-associating or deriving atomic authorizations for each candidate action; verifying whether each candidate action satisfies the authorization boundary and environment boundary; replanning when a candidate action fails and the risk does not exceed the threshold; and triggering permission tightening, manual takeover, emergency circuit breaker, or rollback recovery when the number of trial attempts, deviation degree, domain conflict, or risk score exceeds the threshold.

15. The method according to claim 14, characterized in that, The execution process, failure results, replanning paths, and threshold triggering results of the candidate actions are all written into the chained audit log.

16. The method according to claim 8 or 15, characterized in that, The method supports manual takeover, emergency circuit breaker, and rollback recovery. When the risk score reaches the threshold, the trust domain is inconsistent, the target object changes abnormally, the audit chain verification fails, or the environmental context changes significantly, it switches to manual takeover mode, triggers circuit breaker, or performs rollback recovery.

17. The method according to claim 16, characterized in that, The rollback recovery is achieved based on one or more of the following methods: reverse operation script, transaction compensation, state snapshot recovery, or resource version recovery.

18. The method according to claim 1, characterized in that, It also includes steps that can be executed continuously across terminals: Generate an execution status package on the first terminal, which includes a task identifier, a list of incomplete actions, a summary of the preceding audit block, and a summary of the current status. The execution status packet is sent to the second terminal through a secure channel; On the second terminal, verify the integrity, authorization continuity, terminal trustworthiness, and session consistency of the execution status packet; After successful verification, the unfinished task continues execution from the breakpoint recorded in the execution status packet; The execution processes on the first and second terminals are written into the same chain of audit records.

19. An artificial intelligence execution control system based on a hardware root of trust, characterized in that, include: The task input module is used to receive task execution information; The task standardization module is used to standardize the processing of task execution information; The execution behavior object modeling module is used to generate structured execution behavior objects based on the standardized execution task information. The authorization payload generation module is used to generate authorization payloads based on the structured execution behavior object; the hardware trust root module is used to perform authorization signature verification, protected key storage, random number management, and execution release control; the execution gating module, directly coupled to the hardware trust root module, is used to verify the authorization payload on the necessary execution path before the execution request enters the target host and output the release or blocking result; the execution module is used to execute the specific operation corresponding to the structured execution behavior object; and the result verification module is used to verify the authenticity of the execution result based on the target predicate, state difference, and environmental consistency. The risk assessment module is used to conduct risk assessment and feedback control based on the verification results. The audit log module is used to write task, authorization, gating, execution, verification, and risk information into a chain of audit logs; The hardware root of trust is configured as an execution release sovereign node, deployed as a secure area in an independent security chip, TPM module, security microcontroller, execution control board, or a protected execution control area in a local trusted execution gateway, and is used to perform one or more of the following operations: protected key storage, authorized signature verification, random number and counter management, execution release control, and audit signature. The execution gate node is located at a necessary position in the execution path and verifies one or more of the following: authorization signature, behavior digest consistency, environment binding, device binding, time window, and anti-replay conditions. The hardware root of trust may include a protected key area, an authorization verification logic area, a random number and counter management area, an access control area, and an audit signature area; the protected key area is used to store private keys, root keys, or derived key materials; the authorization verification logic area is used to verify signature information, time windows, anti-replay counts, and binding relationships; The random number and counter management area is used to generate random numbers, increment counters, and verify the uniqueness of requests; the access control area is used to output allow or block signals at the gating node; and the audit signature area is used to sign or confirm the audit block.

20. The system according to claim 19, characterized in that, It also includes a local trusted execution gateway module, which includes a task receiving unit, an authorization verification unit, a trust root communication unit, an execution gating unit, a state cache unit, an audit cache unit, and a risk threshold control unit.

21. The system according to claim 20, characterized in that, The local trusted execution gateway module serves as the only valid entry point before the target host. The target host's input interface, virtual input interface, browser execution interface, application call interface, and operating system call interface only accept execution requests that have been approved by the local trusted execution gateway module.

22. The system according to claim 20, characterized in that, It also includes an authorization chain management module and a trust domain management module. The authorization chain management module is used to generate a main authorization token, sub-authorization tokens and atomic authorization fragments, and to perform authorization revocation and linkage failure control. The trust domain management module is used to verify one or more identifiers among user trust domains, device trust domains, organization trust domains, and tenant trust domains, and to control cross-domain execution approval or circuit breaking.

23. The system according to claim 19, characterized in that, It also includes a dynamic trial-and-error control module and a manual takeover management module. The dynamic trial-and-error control module is used to generate candidate actions, perform replanning, and control the trial-and-error threshold within the authorized boundaries. The manual takeover management module is used to trigger manual takeover, emergency circuit breaker, or rollback recovery when the risk score reaches a threshold or abnormal conditions are detected.

24. The system according to claim 19, characterized in that, It also includes a cross-terminal state migration module, which is used to form an execution state package, migrate the execution state package through a secure channel, and continue to execute unfinished tasks after verifying the integrity, authorization continuity, terminal trustworthiness and session consistency of the execution state package on the second terminal.

25. An artificial intelligence execution control device based on a hardware root of trust, characterized in that, It includes a processor, a memory, a hardware root of trust unit, an execution gating unit, an execution interface, a status acquisition unit, and an audit storage unit; the memory stores a computer program, which, when executed by the processor, causes the device to perform the method described in any one of claims 1 to 18; The hardware trust root unit is used to perform protected key storage, authorized signature verification, random number management and access control; the execution gating unit is used to control the access or blocking of execution requests on the necessary execution path before the execution request enters the target host; the execution interface is used to connect to one or more of the target host's physical input interface, virtual input interface, browser execution interface, application call interface or operating system call interface.

26. The device according to claim 25, characterized in that, The hardware trust root unit is deployed as one of the following: an independent security chip, a TPM module, a security microcontroller, a motherboard security zone, or a gateway protected execution control zone.

27. The device according to claim 25, characterized in that, The execution interface includes at least one of a physical input interface, a virtual input interface, a browser execution interface, an application execution interface, and an operating system call interface, and is configured to respond only to execution requests that have been granted by the execution gating unit.

28. The device according to claim 25, characterized in that, The device also includes a local trusted execution gateway functional unit, which is used to receive execution tasks and authorized payloads from the cloud task center, upper-layer platform or other terminals, and form a unique valid entry point on the local side.

29. The device according to claim 25, characterized in that, The audit storage unit is used to store a chain of audit records that include at least a task identifier, a previous block digest, a current block digest, a timestamp, a subject identifier, and a signature. Integrity verification is achieved through association with the previous block digest and signature verification.

30. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the method according to any one of claims 1 to 18.

31. The computer-readable storage medium according to claim 30, characterized in that, The computer program is configured to perform at least one of the following functions: authorized payload generation, multi-level authorization chain verification, trust domain matching verification, dynamic trial and error control, cross-terminal execution status packet verification, result authenticity verification, risk assessment feedback, and chain audit log generation.

Images