Execution system and method for ai agents based on trusted execution environments

Abstract

This disclosure provides an execution system and method for an AI agent based on a trusted execution environment. The trusted execution environment includes: a logical zone configured to deploy and run the AI ​​agent; a vault zone configured to store sensitive credentials; a secure inter-process communication interface located between the logical zone and the vault zone, supporting only the transmission of preset instructions between the logical zone and the vault zone; and an isolation unit configured to provide hardware-level protection to the vault zone to prevent direct access from the logical zone to the vault zone. The vault zone further includes: a policy verification module configured to evaluate execution requests from the logical zone according to preset risk control rules to determine whether to authorize the execution request to access the sensitive credentials in the vault zone.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence (AI) technology, and more specifically to execution systems and methods for AI agents based on trusted execution environments. Background Technology

[0002] With the development and application of AI technology, AI agents are widely used in various scenarios. Existing AI systems treat the entire Trusted Execution Environment (TEE) enclave as a single trust boundary. AI agents and sensitive information run in the same memory space without any isolation or protection mechanisms, making sensitive information highly susceptible to leakage during AI agent operation. Furthermore, existing AI systems cannot achieve cross-domain collaborative operations. Interactions between different domains, such as Web2 applications (centralized web applications), Web3 applications (decentralized blockchain applications), and Real-World Assets (RWA), require separate execution, resulting in cumbersome and inefficient operations. Moreover, facing regulatory requirements to provide compliance proof without compromising user privacy, existing technologies lack corresponding privacy-protected compliance verification solutions, making it difficult to balance regulatory compliance needs with user privacy protection. Summary of the Invention

[0003] According to some embodiments of this disclosure, an execution system for an AI agent based on a trusted execution environment is provided. The trusted execution environment includes: a logical area configured to deploy and run the AI ​​agent; a vault area configured to store sensitive credentials; a secure inter-process communication interface located between the logical area and the vault area, supporting only the transmission of preset instructions between the logical area and the vault area; and an isolation unit configured to provide hardware-level protection to the vault area to prevent direct access from the logical area to the vault area. The vault area further includes: a policy verification module configured to evaluate execution requests from the logical area according to preset risk control rules to determine whether to authorize the execution request to access the sensitive credentials of the vault area.

[0004] According to some embodiments of this disclosure, a cross-domain identity management method is provided. The method is based on an execution system according to embodiments of this application and includes: deriving a root seed from a user's decentralized identifier; deriving multiple domain-specific credentials adapted for access to multiple domains from the root seed; encapsulating the multiple domain-specific credentials into unified identity data; and encrypting the unified identity data using a sealing key, wherein the sealing key is based on a hardware identifier of a hardware component of the execution system and a digital fingerprint of an AI agent.

[0005] According to some embodiments of this disclosure, a compliance verification method is provided. This method is based on an execution system according to embodiments of this application and includes: an AI agent generating a verification report about a user's transaction, the verification report containing a hardware identifier of a hardware component of the execution system and a hash value of the AI ​​agent's digital fingerprint; the AI ​​agent initiating a user authentication request to a vault, wherein the user authentication request contains the user's identity data; the AI ​​agent receiving a compliance tag returned from the vault, wherein a policy verification module in the vault verifies the consistency between the identity data contained in the request and the user's identity data in the vault and generates a compliance tag based on the verification result; the AI ​​agent embedding the compliance tag into the verification report; the AI ​​agent signing the verification report using the private key of the hardware component; and the AI ​​agent transmitting the signed verification report to a compliance audit platform for completing transaction compliance verification.

[0006] According to some embodiments of this disclosure, an account operation method is provided. This method is based on an execution system according to embodiments of this application and includes: an AI agent receiving an account operation request and zero-knowledge proof information submitted by a user; the AI ​​agent retrieving historical behavioral fingerprint data of the user's account and analyzing the historical behavioral fingerprint data to calculate a confidence value; the AI ​​agent comparing the calculated confidence value with a threshold, and initiating a private key release request for the account to the vault if the confidence value is greater than the threshold; and the vault's policy verification module verifying the association between the account and the user's identity data in the vault, and releasing the private key used to operate the account to the account management platform after successful verification.

[0007] According to some embodiments of this disclosure, a transaction authorization control method is provided. This method is based on an execution system according to embodiments of this application and includes: an AI agent receiving natural language instructions related to a transaction input by a user, and parsing the received natural language instructions into a standardized executable transaction payload; a biometric identification module of the execution system performing biometric identity verification of the user and feeding back the biometric identity verification result to the AI ​​agent; if the biometric identity verification is successful, the AI ​​agent initiating a transaction operation request to a vault, the transaction operation request including the user's identity information and the transaction operation action; a policy verification module of the vault verifying the consistency between the identity information contained in the transaction operation request and the user's identity data in the vault, as well as the rationality of the transaction operation action, and generating a compliance signature based on multi-party computational signature after successful verification; the AI ​​agent receiving the compliance signature from the vault; and the AI ​​agent providing the executable transaction payload along with the compliance signature to the platform involved in the transaction to execute the transaction. Attached Figure Description

[0008] Embodiments of this disclosure will be illustrated by way of example rather than limitation in conjunction with the accompanying drawings, wherein similar reference numerals refer to similar elements.

[0009] Figure 1 This is a schematic diagram illustrating the architecture of an AI agent-based execution system according to an embodiment of this application.

[0010] Figure 2 This is a flowchart illustrating a cross-domain identity management method according to an embodiment of this application.

[0011] Figure 3 This is a flowchart illustrating a compliance verification method according to an embodiment of this application.

[0012] Figure 4 This is a flowchart illustrating an account operation method according to an embodiment of this application.

[0013] Figure 5 This is a flowchart illustrating a transaction authorization control method according to an embodiment of this application.

[0014] Figure 6 This is a schematic diagram illustrating the transaction risk prevention and control process according to an embodiment of this application.

[0015] Figure 7 This is a schematic block diagram illustrating a computer device that can be used to implement an execution system according to embodiments of this application. Detailed Implementation

[0016] The features and exemplary embodiments of various aspects of this application will now be described in detail. Numerous specific details are set forth in the following detailed description to provide a comprehensive understanding of this application. However, it will be apparent to those skilled in the art that this application can be implemented without requiring some of these specific details. The following description of embodiments is merely intended to provide a better understanding of this application by illustrating examples. This application is by no means limited to any specific configuration presented below, but covers any modifications, substitutions, and improvements to elements, components, and steps without departing from the spirit of this application. Well-known structures and techniques are not shown in the accompanying drawings and the following description in order to avoid unnecessarily obscuring this application.

[0017] Furthermore, the various operations will be described as multiple discrete operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must depend on the order. In particular, these operations do not necessarily have to be performed in the order presented.

[0018] The phrases “in an embodiment,” “in one embodiment,” and “in some embodiments” are used repeatedly throughout this document. These phrases do not usually refer to the same embodiment; however, they may refer to the same embodiment. Unless the context otherwise specifies, the terms “comprising,” “having,” and “including” are synonyms. The phrases “A or B” and “A / B” mean “(A), (B), or (A and B).”

[0019] Figure 1 This is a schematic diagram illustrating the architecture of an AI agent execution system based on a trusted execution environment according to an embodiment of this application. Figure 1 As shown, the execution system 100 according to an embodiment of this application includes: a Trusted Execution Environment (TEE) 101, which includes: a logical area 1 configured to deploy and run an AI agent 1-1; a vault area 2 configured to store sensitive credentials 2-1; a secure inter-process communication (IPC) interface 3 located between the logical area 1 and the vault area 2, supporting only the transmission of preset instructions between the logical area 1 and the vault area 2; and an isolation unit 4 configured to provide hardware-level protection for the vault area 2 to prevent direct access from the logical area 1 to the vault area 2. The vault area 2 further includes: a policy verification module 2-2 configured to evaluate execution requests from the logical area 1 according to preset risk control rules to determine whether to authorize the execution request to access the sensitive credentials of the vault area 2.

[0020] As the core security carrier, the Trusted Execution Environment provides the entire system with an operating space isolated from external insecure environments. It avoids threats to the core modules and sensitive data of the system from the bottom layer, laying the overall security foundation of the system and ensuring that the operation of AI agents, the storage of sensitive credentials, and the verification of requests are all carried out within the security boundary.

[0021] The separate deployment of the logic zone and the vault zone achieves both physical and logical isolation between the operation of the AI ​​agent and the storage of sensitive credentials: the logic zone focuses on the deployment and operation of the AI ​​agent, and is only responsible for receiving user instructions and initiating access requests. It does not directly handle sensitive credentials, thus eliminating the risk of leakage or tampering of sensitive data due to abnormal behavior that may occur during the operation of the AI ​​agent; the vault zone is dedicated to the centralized storage of sensitive credentials, forming a dedicated secure storage space for sensitive data and improving the storage security of sensitive credentials.

[0022] The design of the secure inter-process communication interface strictly controls the communication content between the logic area and the vault area by limiting the transmission of only preset instructions. Only necessary interaction instructions are allowed, eliminating the transmission of irrelevant or malicious instructions, reducing the system's attack surface, and achieving orderly and secure interaction between the two areas. This ensures the normal initiation and response of AI agent requests while preventing data leakage during the communication process.

[0023] The hardware-level protection provided by the isolation unit prevents the logical area from directly accessing the vault area at the hardware level, completely cutting off the possibility of the logical area obtaining sensitive credentials through illegal means. Compared with software-level isolation, hardware-level protection has higher security and anti-attack capabilities, further strengthening the isolation and protection effect of the vault area and ensuring that sensitive credentials are not accessed by unauthorized parties.

[0024] The built-in policy verification module in the vault area evaluates the execution requests initiated by the logic area through preset risk control rules, realizing compliance and security verification of sensitive credential access requests. It can accurately identify high-risk requests and refuse authorization, preventing sensitive credentials from being illegally accessed or abused. At the same time, it realizes proactive risk prevention and control, and improves the security and controllability of the system.

[0025] In some implementations, preset instructions may include transaction signature retrieval instructions and session key retrieval instructions. Preset instructions standardize operations, prevent unauthorized commands from triggering access to sensitive credentials, and strengthen system security.

[0026] In some implementations, the isolation unit 4 can be the memory management unit (MMU) or page table of the execution system 100. Thus, isolation functionality is achieved using existing hardware modules, eliminating the need for additional independent isolation hardware, reducing system hardware costs, and improving system compatibility and feasibility.

[0027] In some implementations, the secure IPC interface 3 prohibits the transmission of sensitive credentials from vault 2 to logical area 1 in plaintext. This eliminates the risk of sensitive credential leakage at the data transmission stage, thus enhancing communication security.

[0028] In some implementations, pre-defined risk control rules may include at least one of the following: transaction limits, transaction address whitelists, transaction frequency thresholds, and cross-domain operation permissions, to adapt to various application needs. Transaction limits can prevent sensitive credentials from being used for large-scale illegal transactions; transaction address whitelists can restrict the access and operation scope of sensitive credentials; transaction frequency thresholds can identify abnormally high-frequency requests and prevent attacks such as brute-force attacks and malicious access; cross-domain operation permissions can control the legitimacy of cross-domain access and avoid the abuse of sensitive credentials in cross-domain scenarios.

[0029] In some implementations, sensitive credentials 2-1 may include at least one of the following: root seed, domain-specific credential, unified identity data, and private key fragments, to adapt to various application needs. The root seed, as the sole source of global identity, provides the foundation for the generation of domain-specific credentials and unified identity data; domain-specific credentials and unified identity data support identity recognition and verification in cross-domain scenarios; private key fragments prevent the risk of leakage caused by storing the complete private key. The storage and security protection of various sensitive credentials ensure the secure implementation of system authentication, cross-domain access, account operations, and other functions.

[0030] The execution system according to the embodiments of this application stores sensitive credentials in a vault area, achieving centralized and isolated secure storage of sensitive credentials and effectively preventing unauthorized access, tampering, or leakage. Hardware-level isolation provided by the isolation unit prevents direct access from the logical area to the vault area at the hardware level, further strengthening the security barrier of the vault area. Through instruction and transmission restrictions on the secure IPC interface, a strict security control mechanism is provided for the access and transmission of sensitive credentials, ensuring normal request and response interactions between the two areas while mitigating the risk of data leakage during transmission, forming a dual "storage-transmission" security protection. Furthermore, a comprehensive risk assessment is conducted through a policy verification module, achieving controllability and compliance of sensitive credential access, further preventing the risk of sensitive credential abuse, and comprehensively ensuring the secure and stable operation of the system and sensitive data.

[0031] Figure 2 This is a flowchart illustrating a cross-domain identity management method according to an embodiment of this application. The cross-domain identity management method 200 according to an embodiment of this application is based on an execution system 100 according to an embodiment of this application. Figure 2 As shown, the cross-domain identity management method 200 includes steps S201 to S204.

[0032] In step S201, the root seed is derived from the user's decentralized identifier (DID).

[0033] Decentralized identifiers are decentralized digital identity identifiers that conform to W3C (World Wide Web Consortium) standards. They are URIs (Uniform Resource Identifiers) that are created and managed by users independently, free from the control of traditional centralized institutions (such as platforms or institutional servers), and possess global uniqueness.

[0034] In some implementations, the root seed is derived from a decentralized identifier using the Hierarchical Deterministic Wallet (HID) algorithm. The HID algorithm is a key management algorithm that uses a unique root seed and deterministic derivation rules to generate a hierarchical key tree (e.g., parent key → child key → grandchild key).

[0035] In step S202, multiple domain-specific credentials adapted for accessing multiple domains are derived from the root seed.

[0036] The term "domain" as used in this application refers to an external application or service scenario that has an independent authentication system and independent access control, i.e., various independent platforms where users need to authenticate and access operations, including but not limited to Web2 applications, Web3 applications, real-world assets (RWA), and other fields.

[0037] In step S203, multiple domain-specific credentials are encapsulated into unified identity data.

[0038] In some implementations, encapsulation can be a process of standardizing multiple domain-specific credentials, such as unifying the data format, field specifications, and encoding format of each credential to ensure that the credential information format of different domains is consistent, and then summarizing and integrating the standardized credential information of each domain.

[0039] In step S204, the unified identity data is encrypted using a sealing key, wherein the sealing key is based on the hardware identifier of the hardware component of the execution system and the digital fingerprint of the AI ​​agent.

[0040] The hardware identifier of a hardware component is its unique identifier, such as a hardware serial number or a chip's unique ID. The digital fingerprint of the AI ​​agent is its own unique identifier, formed by combining its operating parameters, program characteristics, and verification information. Together with the hardware identifier, it constitutes the security foundation for identity verification, ensuring the security and reliability of subsequent encryption, access control, and other operations. In some implementations, a sealing key is generated by standardizing the hardware identifier of the hardware component and the digital fingerprint of the AI ​​agent, followed by a hash operation. In some implementations, the hardware component can be the central processing unit (CPU) of the execution system, with its serial number serving as a unique identifier.

[0041] In some implementations, method 200 further includes storing the root seed and multiple domain-specific credentials in a vault area of ​​a trusted execution environment. This achieves centralized management and isolation protection of sensitive data, preventing data leakage, ensuring the security of subsequent cross-domain authentication and root seed invocation, and facilitating rapid retrieval and use of relevant data, thus guaranteeing the security and convenience of the entire identity management process.

[0042] In some implementations, method 200 further includes storing the unified identity data in a non-volatile memory located outside the trusted execution environment of the execution system. This achieves long-term data retention and secure storage, avoiding storage pressure within the trusted execution environment while ensuring data traceability and verifiability. It also provides data support for subsequent cross-domain authentication, balancing data security and ease of use.

[0043] In some implementations, method 200 further includes invalidating the unified identity data when one of the multiple domain-specific credentials is manipulated. This effectively prevents the risk of data tampering and misuse, ensures identity data security and compliance, and avoids damage to the overall system and sensitive data caused by unauthorized operations.

[0044] In some implementations, method 200 further includes: when the execution request is for obtaining unified identity data, the policy verification module reads the hardware identifier of the hardware component of the execution system and the digital fingerprint of the AI ​​agent, and verifies the consistency between the read hardware identifier and digital fingerprint and the hardware identifier and digital fingerprint on which the unified identity data is based when it is encrypted; and if the consistency verification passes, the unified identity data is loaded into the vault area of ​​the trusted execution environment. This effectively prevents security risks such as unauthorized access and data tampering, ensuring the security and integrity of the unified identity data, and ensuring that only legitimate and compliant access requests can obtain the unified identity data. It also further strengthens data security and provides a secure and reliable foundation for subsequent cross-domain authentication.

[0045] Figure 3 This is a flowchart illustrating a compliance verification method according to an embodiment of this application. Figure 3 As shown, The compliance verification method 300 according to embodiments of this application is based on the execution system 100 according to embodiments of this application. For example... Figure 3 As shown, the compliance verification method 300 includes steps S301 to S306.

[0046] In step S301, the AI ​​agent generates a proof report about the user's transaction. The proof report includes the hardware identifier of the hardware components of the execution system and the hash value of the AI ​​agent's digital fingerprint. It should be understood that a "transaction" can be a transaction for the various "domains" described above, such as a transaction for a Web2 application, a transaction for a Web3 application, or a transaction for a real-world asset (RWA).

[0047] In step S302, the AI ​​agent initiates a user authentication request to the vault area regarding the user, wherein the user authentication request contains the user's identity data.

[0048] In step S303, the AI ​​agent receives the compliance tag returned from the vault, where the policy verification module in the vault verifies the consistency between the identity data included in the request and the user's identity data in the vault and generates a compliance tag based on the verification result. It should be understood that the user's identity data in the vault can be... Figure 2 The same identity data generated in the cross-domain identity management method 200 shown.

[0049] In step S304, the AI ​​agent embeds the compliance label into the certification report.

[0050] In step S305, the AI ​​agent signs the proof report using the private key of the hardware component.

[0051] In step S306, the AI ​​agent transmits the signed certification report to the compliance audit platform for completion of transaction compliance verification.

[0052] In some implementations, compliance labels may include Boolean user authentication status, transaction risk level assessment results, and digital fingerprints of AI agents.

[0053] According to the compliance verification method of this application, the legitimacy of the report-generating entity is pre-locked by generating a verification report containing the hardware identifier of the execution system and the hash value of the AI ​​agent's digital fingerprint. By initiating an identity verification request through the AI ​​agent and verifying the consistency of identity data through the policy verification module to generate a compliance tag, the accuracy of user identity verification is ensured, and the isolation and protection of the vault area prevents the leakage of user identity data, achieving synergy between privacy protection and identity verification. By embedding the compliance tag into the verification report, the compliance auditor can quickly obtain core compliance information such as identity verification status and transaction risk level. Simultaneously, the AI ​​agent's digital fingerprint contained in the tag further corroborates the authenticity and completeness of the report. By using the private key of the hardware component to sign the verification report, relying on the immutability and anti-forgery characteristics of the hardware-endorsed private key, the report is effectively prevented from being tampered with or forged during transmission and storage, ensuring the integrity and legitimacy of the report. By transmitting the signed verification report to the compliance audit platform, the compliance audit is efficiently advanced, allowing the auditor to complete transaction compliance verification without obtaining the user's original identity data, thus meeting regulatory compliance requirements while maximizing the protection of user privacy.

[0054] Figure 4 This is a flowchart illustrating an account operation method according to an embodiment of this application. For example... Figure 4 As shown, The compliance verification method 400 according to embodiments of this application is based on the execution system 100 according to embodiments of this application. For example... Figure 4 As shown, the compliance verification method 400 includes steps S401 to S406.

[0055] In step S401, the AI ​​agent receives the user's application for account operations and zero-knowledge proof information. The account can include, but is not limited to, accounts for Web2 applications and accounts for Web3 applications. The zero-knowledge proof feature prevents the leakage of sensitive user identity data, balancing the dual needs of identity verification and privacy protection.

[0056] In step S402, the AI ​​agent retrieves the user's historical behavior fingerprint data of the account and analyzes the historical behavior fingerprint data to calculate the confidence value.

[0057] In some implementations, historical behavioral fingerprint data includes at least one of the following: the trajectory of IP addresses used by the user's account, the frequency of account usage, and the social relationship graph related to the account. In other implementations, the confidence value is obtained by standardizing the items in the historical behavioral fingerprint data and then performing a weighted sum. Through the analysis of multi-dimensional behavioral data, a quantitative assessment of the legitimacy of current account operations can be achieved, making the determination of operational risks more objective and accurate, effectively distinguishing between legitimate and abnormal operations, and providing a scientific basis for subsequent private key release decisions.

[0058] In step S403, the AI ​​agent compares the calculated confidence value with a threshold, and if the confidence value is greater than the threshold, initiates a private key release request for the account to the vault. By comparing the confidence value with the threshold, a pre-security threshold for private key release is constructed, preventing unauthorized operations from triggering private key calls at the source, further strengthening account security protection, and avoiding the risks of accidental release and misuse of private keys.

[0059] In step S404, the policy verification module of the vault verifies the association between the account and the user's identity data in the vault, and releases the private key used to operate the account to the account management platform after successful verification. The policy verification module of the vault further verifies the association between the account and the user's identity data stored in the vault to ensure that the release of the private key is only for legitimate accounts and legitimate users.

[0060] According to the account operation method in this application embodiment, a full-process security closed loop of "identity verification - behavior verification - secure release of private key" is constructed through the collaborative cooperation of AI agent, vault area and policy verification module. This ensures the legality and security of account operations, while also taking into account the convenience and compliance of operations, and is suitable for account management needs in multiple scenarios such as Web2 and Web3.

[0061] Figure 5 This is a flowchart illustrating a transaction authorization control method according to an embodiment of this application. Figure 5As shown, the transaction authorization control method 500 according to an embodiment of this application is based on the execution system 100 according to an embodiment of this application. Figure 5 As shown, the transaction authorization control method 500 includes steps S501 to S506.

[0062] In step S501, the AI ​​agent receives the user's input of transaction-related natural language instructions and parses the received instructions into standardized executable transaction payloads. This process effectively solves the problems of ambiguity and non-standardization in natural language instructions, achieving efficient integration of convenient user input and precise system execution. It lowers the barrier to entry for users and provides a standardized data foundation for subsequent transaction authorization and compliance verification, ensuring the standardization of transaction operations.

[0063] In step S502, the biometric identification module of the execution system performs biometric identity verification on the user and feeds back the biometric identity verification result to the AI ​​agent. Relying on the uniqueness and non-replicability of biometrics, the first security threshold for transactions is constructed, confirming the legitimacy of the user's identity from the source, effectively preventing the risks of identity forgery and illegal account theft to initiate transactions, and building a solid identity security defense for subsequent transaction operations.

[0064] In step S503, if the biometric identity verification is successful, the AI ​​agent initiates a transaction operation request to the vault area. The transaction operation request includes the user's identity information and the transaction operation action.

[0065] In step S504, the policy verification module of the vault area verifies the consistency between the identity information contained in the transaction operation request and the user's identity data in the vault area, as well as the rationality of the transaction operation action. After the verification is passed, a compliance signature is generated based on multi-party signature calculation.

[0066] By having an AI agent initiate transaction requests to the vault and the vault conducts dual verification, illegal and abnormal transactions are further screened out. This ensures the legitimacy of the transaction parties and prevents unreasonable transactions (such as exceeding permissions or exceeding the amount in violation of regulations) from proceeding, thereby strengthening transaction compliance and security.

[0067] In step S505, the AI ​​agent receives the compliance signature from the vault. Leveraging the vault's isolation and protection features, the security of private key usage is ensured, preventing private key leakage and misuse. Simultaneously, the compliance signature provides a legal basis for transaction authorization, ensuring that transaction operations comply with regulatory and system security standards.

[0068] In step S506, the AI ​​agent provides the executable transaction payload along with the compliance signature to the multi-party computation signature module to complete the authorization of the transaction. After receiving the compliance signature, the AI ​​agent submits the executable transaction payload and the compliance signature together to the multi-party computation signature module to complete the transaction authorization, thereby achieving the standardization and security of transaction authorization and ensuring that the transaction authorization process is traceable and verifiable.

[0069] In some implementations, method 500 further includes: if the identity information included in the transaction operation request is inconsistent with the user's identity data in the vault, or if the transaction operation is unreasonable, the AI ​​agent directly rejects the transaction. This rapid response mechanism can promptly block illegal and abnormal transactions, minimize transaction risks, and further improve the transaction security loop.

[0070] In some implementations, method 500 further includes steps S507 to S511 to implement transaction risk control procedures, such as... Figure 6 As shown.

[0071] In step S507, the AI ​​agent collects the transaction risk factors in real time.

[0072] In some implementations, risk factors may include, but are not limited to, transaction amount, contract interaction security, device integrity, and geographic location. Bit It identifies anomalies and user behavior characteristics. Through multi-dimensional content, it achieves comprehensive and real-time capture of transaction risks, covering not only the core risks of the transaction itself, but also related risks such as those related to devices and user behavior. This provides comprehensive and reliable data support for subsequent risk level determination, avoiding misjudgments due to the omission of risk factors.

[0073] In step S508, the AI ​​agent analyzes the collected risk factors to determine the transaction risk level. Through comprehensive analysis of multi-dimensional data, accurate quantification of transaction risk is achieved, clearly distinguishing between low, medium, and high levels of transaction risk. This provides a scientific basis for subsequent threshold adjustments and transaction decisions, avoiding risk assessment bias caused by a single risk factor.

[0074] In step S509, the AI ​​agent initiates a transaction operation update request to the vault area, which includes the transaction risk level. This request ensures the vault area can promptly obtain the real-time risk status of transactions, providing an accurate basis for subsequent threshold adjustments.

[0075] In step S510, the strategy verification module of the vault adjusts the threshold for the number of multiple parties on which the multi-party computation signature is based based on the transaction risk level, and generates an updated compliance label. By dynamically adjusting the threshold for the number of multiple parties on which the multi-party computation signature is based based on the transaction risk level and generating an updated compliance label, the linkage and adaptation between "risk level and verification threshold" are achieved—lowering the threshold in low-risk scenarios to ensure transaction efficiency; raising the threshold in high-risk scenarios to strengthen security protection. At the same time, the updated compliance label can accurately reflect the real-time compliance status of the current transaction, providing the latest compliance basis for subsequent transaction authorization and further strengthening transaction compliance.

[0076] In step S511, the AI ​​agent receives the updated compliance signature from the vault area and decides whether to continue or block the transaction based on the updated compliance signature. By deciding whether to continue or block the transaction based on the updated compliance signature, the system can respond promptly to changes in risk during the transaction process, quickly block high-risk transactions, and efficiently allow low-risk transactions, thereby maximizing the prevention of transaction risks without affecting the convenience of normal transactions.

[0077] The transaction authorization control method according to the embodiments of this application constructs a full-process secure and compliant transaction system encompassing "instruction parsing - identity verification - request verification - compliance signature - transaction authorization" through the coordinated operation of AI agents, biometric recognition modules, vault areas, and multi-party computational signature modules. This system ensures the legality, security, and compliance of transactions while improving the convenience of transaction operations and adapting to various transaction needs. Furthermore, through dynamic risk control, transaction risk prevention and control is upgraded from "static verification" to "real-time dynamic prevention and control," which not only improves the transaction security protection system but also enhances the compliance and flexibility of transactions.

[0078] Figure 7 A schematic diagram of a computer system that can implement an execution system according to an embodiment of the present invention is shown. It should be understood that... Figure 7 The computer system 700 shown is merely an example and should not impose any limitations on the functionality and scope of use of the execution system according to embodiments of the present invention.

[0079] like Figure 7 As shown, the computer system 700 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the computer system 700. The processing device 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0080] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, cameras, accelerometers, gyroscopes, sensors, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, motors, electronic speed controllers, etc.; storage devices 708 including, for example, flash cards; and communication devices 709. Communication device 709 allows computer system 700 to communicate wirelessly or wiredly with other devices to exchange data. Although... Figure 7 A computer system 700 with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead. Figure 7 Each box shown can represent a device or multiple devices as needed.

[0081] In particular, according to some embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer programs. For example, a computer-readable medium is provided having a computer program stored thereon, the computer program containing program code for performing various methods according to embodiments of the present application. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 709, or installed from a storage device 708, or installed from a ROM 702. When the computer program is executed by the processing device 701, various methods according to embodiments of the present invention are implemented.

[0082] It should be noted that the computer-readable medium according to embodiments of the present invention may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. A computer-readable storage medium according to embodiments of the present invention may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. Additionally, a computer-readable signal medium according to embodiments of the present invention may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (Radio Frequency), etc., or any suitable combination thereof.

[0083] Computer program code for performing operations according to embodiments of the present invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0084] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, synchronization methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0085] This invention can be implemented in other specific forms without departing from its spirit and essential characteristics. For example, the algorithm described in a particular embodiment can be modified without departing from the basic spirit of the invention. Therefore, the present embodiments are to be regarded as exemplary rather than limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and all changes falling within the meaning and scope of the claims and their equivalents are thus included within the scope of the invention.

Claims

1. An execution system for an AI agent based on a trusted execution environment, characterized in that, The trusted execution environment includes: The logical area is configured to deploy and run the AI ​​agent; The vault area is configured to store sensitive credentials; A secure inter-process communication interface, located between the logic area and the vault area, only supports the transmission of preset instructions between the logic area and the vault area; and An isolation unit is configured to provide hardware-level protection for the vault area to prevent direct access from the logical area to the vault area. The vault area further includes a policy verification module, configured to evaluate execution requests from the logic area according to preset risk control rules to determine whether to authorize the execution request to access the sensitive credentials in the vault area.

2. The execution system according to claim 1, characterized in that, The isolation unit is the memory management unit or page table of the execution system.

3. The execution system according to claim 1, characterized in that, The secure inter-process communication interface prohibits the transmission of the sensitive credentials from the vault area to the logic area in plaintext.

4. The execution system according to claim 1, characterized in that, The preset risk control rules include at least one of the following: transaction limit, transaction address whitelist, transaction frequency threshold, and cross-domain operation permission.

5. A cross-domain identity management method, characterized in that, The method is based on the execution system of claim 1, and includes: Derive the root seed from the user's decentralized identifier; Multiple domain-specific credentials adapted for accessing multiple domains are derived from the root seed; Encapsulate the multiple domain-specific credentials into unified identity data; and The unified identity data is encrypted using a sealing key, wherein the sealing key is based on the hardware identifier of the hardware component of the execution system and the digital fingerprint of the AI ​​agent.

6. The cross-domain identity management method according to claim 5, characterized in that, The hardware component is the central processing unit of the execution system.

7. The cross-domain identity management method according to claim 5, characterized in that, The root seed is derived from the decentralized identifier using a hierarchical deterministic wallet algorithm.

8. The cross-domain identity management method according to claim 5, characterized in that, Also includes: The root seed and the plurality of domain-specific credentials are stored in the vault area of ​​the trusted execution environment.

9. The cross-domain identity management method according to claim 8, characterized in that, Also includes: The unified identity data is stored in a non-volatile memory of the execution system located outside the trusted execution environment.

10. The cross-domain identity management method according to claim 9, characterized in that, Also includes: When one of the multiple domain-specific credentials is manipulated, the unified identity data becomes invalid.

11. The cross-domain identity management according to claim 9, characterized in that, Also includes: When the execution request is a request to obtain the unified identity data, the policy verification module reads the hardware identifier of the hardware component of the execution system and the digital fingerprint of the AI ​​agent, and verifies the consistency between the read hardware identifier and digital fingerprint and the hardware identifier and digital fingerprint on which the unified identity data is based when it is encrypted. as well as If the consistency verification passes, the unified identity data is loaded into the vault area of ​​the trusted execution environment.

12. A method for proving compliance, characterized in that, The method is based on the execution system of claim 1, and includes: The AI ​​agent generates a proof report about the user's transactions, the proof report including the hardware identifier of the hardware components of the execution system and the hash value of the digital fingerprint of the AI ​​agent; The AI ​​agent initiates a user authentication request for the user to the vault area, wherein the user authentication request contains the user's identity data; The AI ​​agent receives the compliance tag returned from the vault area, wherein the policy verification module in the vault area verifies the consistency between the identity data contained in the request and the user's identity data in the vault area and generates the compliance tag based on the verification result; The AI ​​agent embeds the compliance label into the certification report; The AI ​​agent signs the proof report using the private key of the hardware component; and The AI ​​agent transmits the signed certification report to the compliance audit platform for transaction compliance verification.

13. The compliance proof method according to claim 12, characterized in that, The compliance labels include Boolean user authentication status, transaction risk level assessment results, and the digital fingerprint of the AI ​​agent.

14. An account operation method, characterized in that, include: The AI ​​agent receives user-submitted account operation requests and zero-knowledge proof information; The AI ​​agent retrieves the user's historical behavioral fingerprint data of the account and analyzes the historical behavioral fingerprint data to calculate a confidence value; The AI ​​agent compares the calculated confidence value with a threshold, and if the confidence value is greater than the threshold, it initiates a private key release request for the account to the vault. as well as The policy verification module in the vault area verifies the association between the account and the user's identity data in the vault area, and releases the private key used to operate the account to the account management platform after the verification is passed.

15. The account operation method according to claim 14, characterized in that, The historical behavioral fingerprint data includes at least one of the following: the trajectory of IP addresses used by the user when operating the account, the frequency of the user's account usage, and the social relationship graph related to the account.

16. The account operation method according to claim 15, characterized in that, The confidence value is obtained by standardizing each item in the historical behavioral fingerprint data and then performing a weighted summation.

17. A transaction authorization control method, characterized in that, The method is based on the execution system according to claim 1, and includes: The AI ​​agent receives natural language instructions related to transactions input by the user and parses the received natural language instructions into standardized executable transaction payloads; The biometric identification module of the execution system performs biometric identity verification of the user and feeds back the biometric identity verification result to the AI ​​agent; Once the biometric identity verification is successful, the AI ​​agent initiates a transaction operation request to the vault area. The transaction operation request includes the user's identity information and the transaction operation action. The strategy verification module in the vault area verifies the consistency between the identity information contained in the transaction operation request and the user's identity data in the vault area, as well as the rationality of the transaction operation action, and generates a compliance signature based on multi-party computation signature after the verification is passed; The AI ​​agent receives the compliance signature from the vault area; and The AI ​​agent provides the executable transaction payload, along with the compliance signature, to the platform involved in the transaction to execute the transaction.

18. The transaction authorization control method according to claim 17, characterized in that it further comprises: If the identity information contained in the transaction operation request is inconsistent with the user's identity data in the vault area, or if the transaction operation is unreasonable, the AI ​​agent will directly reject the transaction.

19. The transaction authorization control method according to claim 17, characterized in that it further comprises: The AI ​​agent collects the transaction risk factors in real time. The AI ​​agent analyzes the collected risk factors to determine the transaction risk level; The AI ​​agent initiates a transaction operation update request to the vault area, and the transaction operation update request includes the transaction risk level. The strategy verification module in the vault adjusts the threshold of the number of multiple parties on which the multi-party calculated signature is based based on the transaction risk level, and generates an updated compliance label; The AI ​​agent receives the updated compliance signature from the vault area and continues or blocks the transaction based on the updated compliance signature.

20. The transaction authorization control method according to claim 19, characterized in that, The risk factors include transaction amount, contract interaction security, device integrity, geolocation anomaly, and user operation behavior characteristics.

Images