Trusted authorization method, system, device, medium and product for an agent

Abstract

The specification provides a trusted authorization method, system, device, storage medium and product for an agent. The method comprises: an agent in a terminal sending a binding request carrying a binding context to a trusted authorization component in the terminal according to the authorization intention of a user; the trusted authorization component generating registration materials in a trusted execution environment of the terminal based on the binding context and sending the registration materials to a server to enable the server to establish a corresponding binding relationship; the agent sending a task authorization request to the trusted authorization component, the task authorization request comprising task content and the binding context; the trusted authorization component generating an authorization result in the trusted execution environment based on the task authorization request and returning the authorization result to the agent; and the agent sending the authorization result and a task execution request comprising the task content to the server to enable the server to verify the authorization result based on the binding relationship and execute the task execution request after verification.

Description

Technical Field

[0001] This specification relates to the field of artificial intelligence technology, and more particularly to a trusted authorization method, system, electronic device, computer-readable storage medium, and computer program product for intelligent agents. Background Technology

[0002] With the development of artificial intelligence technology, intelligent agents have gradually evolved from simple information question-and-answer tools into automated systems capable of understanding user intent, planning task steps, and invoking external services to execute operations. In some application scenarios, intelligent agents may perform tasks such as payment, order placement, contract signing, account management, configuration changes, data access, or device control based on user instructions. These tasks typically involve security constraints related to user identity, account permissions, service recipients, and execution results, thus requiring high standards for the initiating entity, authorization source, and the completeness of the task content.

[0003] In related technologies, when users perform high-security services, they typically authenticate their identity or confirm transactions through methods such as account passwords, SMS verification codes, biometrics, device unlocking, digital certificates, hardware USB tokens, or mobile security components. These methods generally rely on the premise that the user directly operates the service terminal or application; that is, the service request, the user confirmation action, and the service execution interface are usually in a relatively clear interaction chain. The service system can determine whether to allow the continued execution of the corresponding operation based on the user's login status, device status, or one-time verification result.

[0004] However, in scenarios where intelligent agents participate in task execution, task requests may not be triggered directly by the user item by item on the service page. Instead, they may be automatically organized and initiated by the intelligent agent after understanding the user's intent. The intelligent agent may also call different service systems through plugins, interfaces, or task chains, making the correspondence between user intent, intelligent agent invocation behavior, specific task content, and the final execution object of the service system more complex. In this situation, if high-security tasks are still primarily initiated based on the intelligent agent's own runtime environment, login state, or long-term credentials, then if the intelligent agent's runtime environment is copied, credentials are stolen, interfaces are borrowed, or task content is tampered with, the service system often struggles to accurately determine whether the task still corresponds to the user's true authorized scope, posing a security risk. Summary of the Invention

[0005] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a trusted authorization method for an intelligent agent is proposed, applied to a terminal having a trusted execution environment, the terminal including a trusted authorization component and an intelligent agent, the method comprising: The intelligent agent sends a binding request carrying a binding context to the trusted authorization component according to the user's authorization intent. The binding context is used to characterize the association between the user, the intelligent agent, and the task to be executed on behalf of the user as indicated by the authorization intent. Based on the binding context, the trusted authorization component generates registration materials in the trusted execution environment and sends them to the server, so that the server establishes a corresponding binding relationship. The agent sends a task authorization request to the trusted authorization component, the task authorization request including task content and the binding context; Based on the task authorization request, the trusted authorization component generates an authorization result in the trusted execution environment and returns it to the agent; The agent sends the authorization result and a task execution request containing the task content to the server, so that the server can verify the authorization result based on the binding relationship and execute the task execution request after the verification is successful.

[0006] According to a second aspect of one or more embodiments of this specification, a trusted authorization method for an intelligent agent is proposed, applied to a server, the server including a trusted verification component and a task execution component, the method comprising: The trusted verification component receives registration materials sent by the terminal, and the registration materials are used to establish a binding relationship between the terminal, the user, the intelligent agent and the task executed on behalf of the user; The trusted verification component establishes the binding relationship based on the registration materials; The server receives a task execution request and authorization result sent by the intelligent agent. The task execution request includes the task content of the task to be executed. The authorization result is generated by the terminal based on the task content and the binding context. The binding context is used to characterize the association between the user, the intelligent agent and the task. The trusted verification component verifies the authorization result based on the binding relationship; If the authorization result is verified successfully, the trusted verification component sends the verification result to the task execution component; Upon receiving the verification result, the task execution component executes the task execution request.

[0007] According to a third aspect of the embodiments of this specification, a trusted authorization system for an intelligent agent is provided, including a server and a terminal having a trusted execution environment, the terminal including a trusted authorization component and an intelligent agent, and the server including a trusted verification component and a task execution component; The terminal is used to execute the trusted authorization method for intelligent agents as described in the first aspect; The server is used to execute the trusted authorization method for intelligent agents as described in the second aspect.

[0008] According to a fourth aspect of the embodiments of this specification, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor executes the executable instructions, it is used to implement the method described in the first aspect or the second aspect.

[0009] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in the first or second aspect.

[0010] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the first or second aspect.

[0011] As can be seen from the above embodiments, this specification introduces a successive authorization and server-side verification mechanism based on a trusted execution environment in the binding relationship establishment stage and the task execution stage, thereby constructing a trusted closed loop covering "authorization source - calling subject - task object" in the scenario where the intelligent agent performs high-security tasks on behalf of the user.

[0012] During the binding relationship establishment phase, the trusted authorization component on the terminal side generates registration materials in the trusted execution environment and sends them to the server based on the binding context representing the association between the user, the agent, and the task being executed. The server then establishes the binding relationship between the user, the terminal, the agent, and the task, providing a verifiable authorization basis for subsequent task requests initiated by the agent on behalf of the user, ensuring that each task execution can be traced back to a specific combination of user, terminal, and agent.

[0013] During the task execution phase, the trusted authorization component on the terminal side generates an authorization result associated with the specific task content and binding context within the trusted execution environment, based on the task content and binding context of the task to be executed. This authorization result is then sent to the server along with the task execution request. Upon receiving the task execution request, the server verifies the authorization result based on the pre-established binding relationship. Only after successful verification is the execution of the corresponding task permitted. Because the authorization result is generated within the trusted execution environment and is strongly bound to the task content and binding context, it prevents the authorization signature from being reused across tasks and scenarios, and also prevents the task content from being tampered with during transmission and still being executed.

[0014] Therefore, compared to directly delegating high-security credentials or long-term authorization capabilities to the agent's runtime environment, this embodiment can reduce the risk of abuse of high-security capabilities due to the agent's runtime environment being completely copied, stolen during runtime, being called by the same boundary through shell, or the task content being replaced. Compared to relying solely on account-level or token-level authorization, this embodiment can form a credible verification of "who initiated the task, what content was executed, and whether it was authorized by the corresponding terminal" by associating and verifying each task execution with the binding relationship and terminal authorization action, thereby improving the credibility and verifiability of the process of the agent performing high-security tasks on behalf of others.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the architecture of a trusted authorization system for intelligent agents, provided in an exemplary embodiment.

[0017] Figure 2 This is a schematic diagram of another trusted authorization system for intelligent agents provided in an exemplary embodiment.

[0018] Figure 3 This is an exemplary embodiment of a timing interaction diagram of a terminal and a server during the binding relationship establishment phase.

[0019] Figure 4 This is an exemplary embodiment providing a timing interaction diagram of a terminal and a server during the task execution phase.

[0020] Figure 5 This is a flowchart of a trusted authorization method for an intelligent agent provided in an exemplary embodiment.

[0021] Figure 6 This is a flowchart of another trusted authorization method for an intelligent agent provided in an exemplary embodiment.

[0022] Figure 7 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0024] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with relevant laws, regulations and standards, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0025] Terminology Explanation: 1. Intelligent Agent: Refers to an agent program implemented based on artificial intelligence technology, possessing the ability to perceive the environment, autonomously plan, and execute tasks in a closed loop, used to replace users in performing specific operations or invoking services. Unlike model instances that only implement information question-and-answer or dialogue interaction, intelligent agents integrate large language models, pluggable skill systems, and multi-channel communication interfaces to achieve autonomous task execution, multi-channel interactive access, localized deployment architecture, scalable skill systems, intelligent agent routing, and other technical functions. They can transform user intentions into automated work sequences that can directly control devices, invoke external services, and execute actual tasks.

[0026] 2. Trusted Execution Environment: This refers to a secure area within the device's main processor built on hardware isolation mechanisms. It provides execution space and storage protection independent of ordinary operating systems, ensuring that code and sensitive data running within it, such as keys, biometrics, and authorization logic, are protected from external software attacks, unauthorized access, or tampering.

[0027] 3. Trusted Authorization Component: This refers to a security function module deployed within the terminal, used to carry digital certificates, generate signatures, and perform local authorization verification, assuming the responsibility of a trusted root in high-security operations. For example, the trusted authorization component can be an implementation of a software USB key, which migrates the certificate storage and signature calculation of traditional hardware USB keys to a trusted execution environment, ensuring security while eliminating dependence on external physical hardware.

[0028] 4. High-Security Tasks: These refer to operations or business requests that meet preset security level requirements in one or more aspects, including the authenticity of the calling entity, the reliability of the authorization source, the clarity of execution boundaries, and the completeness of the task content. High-security tasks include, but are not limited to, payments, order placement, contract signing, account management, configuration changes, sensitive data export, device control, and permission granting.

[0029] 5. Trusted Verification Component: This refers to the verification function module located on the server side, which is used to establish and maintain the binding relationship between the terminal, user, intelligent agent and the task authorized to be executed on its behalf, and to comprehensively verify the authorization signature, binding status and the authenticity and integrity of the request when a task execution request is received, as a prerequisite for task execution.

[0030] As intelligent agents gradually acquire autonomous planning and cross-service invocation capabilities, they can complete complex business processes without real-time user intervention. However, if high-security credentials or long-term authorization capabilities are directly delegated to the intelligent agent's runtime environment, the high-security capabilities could be abused if the intelligent agent instance is completely copied, stolen at runtime, or used by malicious modules within the same boundary. Furthermore, if there are no strong constraints between the task request initiated by the intelligent agent, the specific task object, the authorization action on the terminal side, and the user's original intent, it becomes difficult to reliably verify key questions such as "who initiated the task, what task was executed, and whether authorization was obtained from the corresponding terminal." This can easily lead to a disconnect between authentication results and the specific task object, thus affecting the verifiability and reliability of the high-security task execution process.

[0031] Therefore, how to establish a verifiable correspondence between the task initiator, the scope of user authorization, and the content of the task to be executed in scenarios where intelligent agents perform high-security tasks on behalf of users, without significantly increasing the burden of repeated verification on users, is a technical problem that urgently needs to be solved.

[0032] To address the aforementioned issues, the embodiments in this specification utilize a trusted authorization component in the user-held terminal to carry a trusted root. During the execution of high-security tasks, the trusted authorization component on the terminal side performs successive authorization signatures within a trusted execution environment. The server then verifies the authorization results based on a pre-established binding relationship before executing the business, thereby incorporating the task object, the calling subject, and the authorization source into a trusted closed loop.

[0033] The embodiments in this specification do not directly implement high-security capabilities into the intelligent agent's operating environment. Instead, a trusted authorization component in the terminal acts as a trusted root in the binding and authorization process. This allows for the preservation of the intelligent agent's automation capabilities while providing a trusted authorization foundation for high-security tasks such as payment, contract signing, account management, configuration changes, sensitive data export, and device control.

[0034] Figure 1 This diagram illustrates the architecture of a trusted authorization system for intelligent agents, as provided in an embodiment of this specification. Figure 1 As shown, the overall architecture consists of two parts: the terminal side and the cloud service side, which communicate with each other via network 300. Network 300 can be a wired network, a wireless network, or a combination thereof, and is used to transmit interactive information such as binding requests, registration materials, task authorization requests, authorization results, and task execution requests between the terminal side and the cloud service side.

[0035] The terminal side includes terminal 100, which is an electronic device held or controlled by the user, such as a mobile phone, tablet computer, personal computer, or wearable device with computing capabilities. In terms of functionality and security boundaries, terminal 100 is further divided into three logical domains: user interaction and authorization domain, intelligent agent operation domain, and terminal trust layer.

[0036] The user interaction and authorization domain includes a trusted authorization component 102, which serves as the terminal-side interaction entry point and bearer of the soft U-shield capability. It is responsible for receiving high-security task intents initiated by users and performing local authorization confirmation. The intelligent agent operation domain includes an intelligent agent 101, which is responsible for business orchestration and autonomous task request initiation based on user intents, and performs actual operations on behalf of users. The terminal trusted layer includes a trusted execution environment 103, which provides a hardware-level isolated secure execution space for the trusted authorization component 102, undertakes the trusted root support of the entire system, and ensures that authorization signature and binding-related operations are completed in a protected environment.

[0037] It should be noted that the user interaction and authorization domain and the intelligent agent operation domain are used to represent different functional divisions and security boundaries. In actual deployment, they can be deployed in different applications and different operating units, or they can be deployed in the same application, the same process, or the same terminal domain. This embodiment does not limit this.

[0038] The cloud service side includes server 200, which can be a standalone cloud server or a distributed cluster composed of multiple nodes. Server 200 is equipped with a trusted verification component 201 and a task execution component 202. The trusted verification component 201 is responsible for core verification tasks such as binding verification and authorization verification. Specifically, it is used to establish and maintain binding relationships, which represent the trusted association between the user, terminal 100, agent 101, and the authorized task to be executed. Simultaneously, the trusted verification component 201 is also used to verify the integrity, authenticity, and binding consistency of the authorization result from agent 101 during the task execution phase. The task execution component 202 communicates with the trusted verification component 201 and, upon receiving a successful verification result, actually executes the high-security business operation indicated by the task execution request. The trusted verification component 201 and the task execution component 202 can be deployed on the same physical server or, depending on business load and isolation requirements, on different server nodes.

[0039] In the embodiments described in this specification, the term "component" can be understood as a functional unit based on logical function division, rather than being limited to a specific physical hardware implementation. Each component can be implemented as a software module, hardware circuit, a combination of software and hardware, or a combination thereof, and its specific physical deployment form can be flexibly determined according to the actual application scenario and resource constraints. For example, multiple logical components can run on the same physical device, and the same logical component can also be distributed and deployed in different physical nodes or operating environments in different deployment scenarios. The division of components in this specification is intended to clearly describe the functional structure and interaction relationships involved in the technical solution, and does not constitute a limitation on the physical architecture when implementing the technical solution.

[0040] Figure 2 This diagram illustrates an alternative architecture for a trusted authorization system for intelligent agents, as provided in an embodiment of this specification. Figure 2 As shown, in Figure 1 Based on the architecture shown, the user interaction and authorization domain also includes the access party 104, and the intelligent agent operation domain also includes the application plugin / access layer 105.

[0041] Access party 104 refers to the terminal-side application, client, or access channel that calls trusted authorization component 102. It serves as the user-facing interaction entry point for the terminal, carrying the access and interface display of terminal security capabilities, and cooperating with trusted authorization component 102 to complete binding processes, authorization confirmation, and other interactive procedures. Access party 104 can be an independent application running on terminal 100, a functional module within an application, a system-level service, or an access channel based on lightweight interface calls. This embodiment does not limit its specific implementation form.

[0042] Application plugin / access layer 105, deployed within the intelligent agent runtime domain, is used to handle access calls between intelligent agent 101 and terminal security capabilities, providing functions such as identifier acquisition, request forwarding, and protocol adaptation. In actual deployment, application plugin / access layer 105 can manifest as a plugin module integrated within intelligent agent 101, an independently running middleware service, or an adaptation layer working collaboratively with access party 104. This embodiment does not limit its specific implementation method.

[0043] Based on the above architecture, the access party 104 provides the end user with an operation interface for secure interaction with the trusted authorization component 102, while the application plugin / access layer 105 provides a standardized access path for the intelligent agent 101 to call the terminal's security capabilities. Together, they realize secure collaboration between the intelligent agent's runtime domain and the user interaction and authorization domain.

[0044] based on Figure 1 and Figure 2 Please refer to the system architecture shown. Figure 3It provides a timing interaction diagram of the terminal 100 and the server 200 during the binding relationship establishment phase. This binding relationship establishment phase is used to pre-build a trusted association between the user, terminal 100, intelligent agent 101 and the task authorized to be executed on behalf of the user before intelligent agent 101 executes the high-security task on behalf of the user, providing a basis for successive authorization verification in the subsequent task execution phase.

[0045] In S301, agent 101 generates a binding request carrying a binding context based on the user's authorization intent.

[0046] The user's authorization intent refers to the user's explicit expression through the access party 104 of their desire to delegate a specific type of high-security task to the intelligent agent 101 for execution. This authorization intent may include information such as the scope of the task specified by the user, the validity period of the authorization, and usage restrictions.

[0047] In some embodiments, after sensing the user's authorization intent, the intelligent agent 101 can first determine whether a valid binding relationship already exists for the task indicated by the authorization intent. This determination process may include: querying the binding state cache maintained locally by the intelligent agent 101; or initiating a binding state query request to the trusted verification component 201 of the server 200, whereby the trusted verification component 201 compares the stored binding relationships and returns the query results. When it is confirmed that no corresponding binding relationship has been established, the intelligent agent 101 enters the binding context generation process.

[0048] During the generation of the binding context, agent 101 can extract key binding elements from the user's authorization intent. Key binding elements may include a user identifier and a task identifier. The user identifier is a unique identifier that distinguishes different users and can be obtained from the current login session information provided by access party 104. The task identifier is used to define the boundaries of authorized operations and can be extracted from the range of operations selected or entered by the user on the access party 104's interface.

[0049] When certain binding elements cannot be directly extracted from the user's authorization intent, agent 101 can obtain the required binding elements from other components. For example, the agent identifier may not be generated by agent 101 itself, but provided by application plugin / access layer 105. Application plugin / access layer 105 is deployed within the smart agent runtime domain and is used to handle access calls between agent 101 and terminal security capabilities. Application plugin / access layer 105 can assign a unique agent identifier to agent 101 when it starts or registers, or maintain the identifier mapping relationship between agent 101 and other modules on terminal 100. Agent 101 can obtain an agent identifier that conforms to the system naming convention by calling the identifier acquisition interface provided by application plugin / access layer 105, and incorporate the agent identifier into the binding context.

[0050] In some embodiments, the binding context may further include a terminal identifier. The terminal identifier is an identity marker that uniquely distinguishes different terminals 100. It can be generated by the trusted authorization component 102 during the terminal initialization phase, or it can be calculated based on the hardware fingerprint and operating system instance identifier of the terminal 100. By adding the terminal identifier to the binding context, the association between the user, the agent 101, and the task can be further bound to a specific terminal 100. This makes the binding relationship not only limited to "which user performs which type of task through which agent," but also to "on which terminal," thereby further enhancing the determinism of the binding and preventing authorization abuse caused by the migration or copying of agent identifiers between different terminals.

[0051] In some embodiments, the binding context may also include an access party identifier. The access party identifier is used to characterize the end-side application, client, or access channel that invokes the trusted authorization component 102. When multiple access parties 104 are running on the terminal 100, for example, different applications or different business entry points acting as access parties, the trusted authorization component 102 may be invoked by different access parties 104. By adding the access party identifier to the binding context, the binding relationship can be associated with a specific access party 104. Thus, when the trusted verification component 201 in the server 200 establishes a binding relationship, it can record which access party 104 initiated the binding relationship; during subsequent task execution phases, when verifying the authorization result, it can also verify whether the access party identifier in the task request matches the access party identifier in the binding relationship, thereby providing more granular traceability of the authorization source. The access party identifier can be the application package name, digital certificate fingerprint, or access party registration number uniformly assigned by the system for the access party 104.

[0052] In the above embodiments, the intelligent agent 101 combines the acquired user identifier, intelligent agent identifier, task identifier, and optional terminal identifier and optional access party identifier according to a preset data structure to generate a binding context.

[0053] In S302, agent 101 sends a binding request to trusted authorization component 102.

[0054] This sending process can be implemented through inter-process communication mechanisms within terminal 100, secure message channels, or adaptation interfaces provided by application plugins / access layers 105. Agent 101 passes a binding request containing the binding context to trusted authorization component 102 to initiate the binding registration process. During this process, application plugins / access layers 105 can provide identifier acquisition and request forwarding functions, adapting agent 101's binding request to a format recognizable by trusted authorization component 102 and forwarding it.

[0055] In S303, the trusted authorization component 102 generates registration materials in the trusted execution environment 103 based on the binding context.

[0056] Upon receiving a binding request, the trusted authorization component 102 passes the binding context to the trusted execution environment 103 for processing. The trusted execution environment 103 is a secure area built on a hardware isolation mechanism within the main processor of the terminal 100. It provides execution space and storage protection independent of ordinary operating systems, ensuring that the code and sensitive data running within it are protected from external software attacks, unauthorized access, or tampering.

[0057] The registration materials are the core basis for the trusted verification component 201 in server 200 to establish a binding relationship, and the way they are generated is directly related to the trustworthiness of the binding relationship and the security of subsequent verification.

[0058] In some embodiments, after receiving a binding request sent by the agent 101 via S302, the trusted authorization component 102 transmits the binding context information carried in the binding request to the trusted execution environment 103, so as to execute the registration material generation process in the trusted execution environment 103. Since the trusted execution environment 103 is built based on a hardware isolation mechanism, it can provide a secure execution space independent of the ordinary operating system of the terminal 100. Therefore, placing the key generation steps of the registration material within the trusted execution environment 103 can prevent malicious programs at the ordinary operating system level from stealing or tampering with sensitive data during the generation process.

[0059] Within the Trusted Execution Environment 103, the process of generating registration materials may include the following steps: Step one involves validating the various binding element identifiers in the binding context information. The binding context information may include user identifiers, agent identifiers, task identifiers, and optional terminal identifiers and access party identifiers. Validation may include: checking if the format of each identifier conforms to preset specifications; checking if each identifier is empty or out of bounds; checking if the task identifier belongs to the system's predefined task enumeration range; and if the binding context includes an access party identifier, checking if that access party identifier belongs to the registered list of legitimate access parties. Validation prevents incorrectly formatted or invalid binding element identifiers from entering subsequent processes, avoiding binding relationship establishment failures or incorrect binding records due to abnormal input.

[0060] Step two: After the validity verification passes, a binding relationship index is generated based on the various binding element identifiers in the binding context information. The binding relationship index is an identifier used to uniquely retrieve and locate binding relationships on the server 200 side. Its generation method can be as follows: concatenate the various binding element identifiers in the binding context information in a preset order, perform fixed-length encoding on the concatenated data, and then perform hash calculation on the encoding result to obtain a fixed-length binding relationship index value. The hash algorithm used here is consistent with the hash algorithm used by the trusted verification component 201 on the server 200 side when establishing the binding relationship, to ensure that the binding relationship index generated on the terminal 100 side and the binding relationship index stored on the server 200 side can obtain consistent results based on the same algorithm, thereby enabling the server 200 to quickly retrieve the corresponding binding relationship based on the index. The hash algorithm can be SHA-256 (Secure Hash Algorithm 256-bit) or other cryptographic hash functions with collision resistance properties, but is not limited to these.

[0061] Step 3: Generate or retrieve a key pair associated with the binding relationship index based on the preset key. This key pair includes a public key and a private key. The specific implementation method of this step is as follows: The trusted authorization component 102 has a pre-set key. This pre-set key is a security key generated by the trusted execution environment 103 during the initialization phase of the trusted authorization component 102. It has application-dimensional uniqueness, meaning that each instance of the trusted authorization component 102 or each trusted authorization component 102 on the terminal 100 can have a different pre-set key. The pre-set key is used for two purposes: firstly, for access control, only trusted authorization components 102 holding a valid pre-set key can initiate registration with the trusted verification component 201; secondly, for key derivation, generating mutually isolated key pairs for the binding relationships of different users.

[0062] When generating key pairs, the trusted authorization component 102 can generate a key index within the trusted execution environment 103, based on a preset key and at least some of the binding element identifiers in the binding context information. For example, the preset key can be used as the root key of a key derivation function, with a combination of user identifier and agent identifier (or a combination of user identifier, agent identifier, and terminal identifier) ​​as the derivation factor, to calculate the key index through the key derivation function. A key derivation function is a cryptographic function that can generate one or more derived keys from a root key and one or more derivation factors, and it is computationally infeasible to deduce the root key from the derived keys.

[0063] Based on the generated key index, the trusted authorization component 102 can determine whether a key pair corresponding to the key index already exists in the secure storage area of ​​the trusted execution environment 103. The secure storage area of ​​the trusted execution environment 103 is a hardware-protected persistent storage space within the trusted execution environment 103, used to securely store sensitive data such as private keys. This area is inaccessible to ordinary operating systems.

[0064] If the determination result indicates that no corresponding key pair exists, it means that this is the first time the user has initiated a binding request for a specific task through the intelligent agent 101. The trusted authorization component 102 generates a new key pair in the trusted execution environment 103. The key pair can be generated using asymmetric cryptographic algorithms such as elliptic curve cryptography or RSA. In the generated new key pair, the public key can be exported outside the trusted execution environment 103, while the private key is stored in the secure storage area of ​​the trusted execution environment 103 and is set to be non-exportable. The non-exportability of the private key means that the private key cannot be read by any external entity after leaving the security boundary of the trusted execution environment 103, thereby ensuring the exclusivity of the signing capability.

[0065] If the determination result indicates that a corresponding key pair exists, it means that the user has previously established a binding relationship and generated a key pair through the intelligent agent 101. The trusted authorization component 102 directly calls the existing key pair without regenerating it. In this way, for the same user's repeated binding operations through the same intelligent agent 101, the existing key pair can be reused to maintain key consistency and avoid generating redundant keys.

[0066] Step four: Generate and output registration materials. The registration materials include at least certificate materials and a binding relationship index. The certificate materials contain the public key from the key pair generated or invoked in the previous steps. In some embodiments, the certificate materials may be a certificate chain containing the public key. A certificate chain is an ordered list of digital certificates, where each certificate is signed by the private key of its successor certificate, and the root certificate at the end of the chain is signed by a trusted certificate authority. The trusted authorization component 102 can generate a self-signed certificate or issue an application certificate based on a pre-installed device certificate in the trusted execution environment 103, encapsulating the public key in the certificate structure to form a certificate chain. The certificate chain serves as a key parameter for cloud-based signature verification, enabling the trusted verification component 201 to confirm the reliability of the public key's source by verifying the integrity and trustworthiness of the certificate chain. The binding relationship index serves as a key parameter for cloud-based retrieval of binding relationships, allowing the trusted verification component 201 to quickly locate and manage binding relationships after receiving the registration materials.

[0067] Throughout the entire process, the private key remains within the trusted execution environment 103 and is not output as part of the registration materials. Because the private key is hardware-bound to the trusted execution environment 103 of the terminal 100 and cannot be exported, even if the operating environment of the agent 101 is completely controlled by an attacker, the attacker cannot obtain the private key to forge the authorization signature, thereby ensuring the uniqueness and unforgeability of the authorization source.

[0068] In some embodiments, after the agent 101 sends a binding request to the trusted authorization component 102 in S302, the trusted authorization component 102 does not unconditionally trigger the generation of registration materials for any task. Instead, it can first determine whether the task indicated by the current authorization intent belongs to the scope of trusted authorization that needs to be enabled, and only enter the registration material generation process when it is determined that it is necessary.

[0069] The necessity of this pre-judgment lies in the fact that, in real-world applications, the tasks performed by Agent 101 are diverse, including high-security operations such as payment, contract signing, and account management, as well as routine operations like information retrieval, content recommendation, and state synchronization. If the binding relationship establishment and subsequent successive authorization process are triggered for all tasks, unnecessary terminal-side computational overhead, network interaction overhead, and user confirmation burden will be introduced. Therefore, by setting an authorization trigger judgment mechanism, trusted authorization capabilities can be focused on tasks that truly require high-security protection, achieving a balance between security and availability.

[0070] In one possible implementation, the authorization trigger determination can be performed independently by the terminal 100. After receiving the binding request, the trusted authorization component 102 can determine whether the task to be executed on behalf of the client, as indicated by the authorization intent, falls within the preset trusted authorization scope, based on the client-side preset authorization policy, and obtain the client-side authorization trigger determination result. The client-side preset authorization policy can be pre-configured within the trusted authorization component 102 or in the secure storage area of ​​the terminal 100. The trusted authorization scope is used to define which tasks belong to high-security tasks, and may include at least one of payment, order placement, contract signing, account management, configuration change, sensitive data export, device control, and permission granting.

[0071] For example, the preset authorization policy on the client side may include an access control policy based on task identifiers. The trusted authorization component 102 can match the task identifier carried in the task request initiated by the intelligent agent 101 with a preset list of tasks requiring authorization. When a match is found, it is determined that the current task belongs to the scope of trusted authorization.

[0072] In another possible implementation, the authorization trigger determination can be completed by server 200, or jointly by terminal 100 and server 200. Trusted authorization component 102 can send information about the task to be executed on behalf of the client, as indicated by the authorization intent, to server 200, enabling server 200 to make a determination based on the cloud-side authorization policy and receive the cloud-side authorization trigger determination result returned by server 200. After receiving the task information, server 200 can invoke trusted verification component 201 or an independent policy decision component to make a comprehensive determination based on the cloud-side authorization policy.

[0073] Cloud-side authorization policies can include authorization triggering strategies based on at least one of the following: risk level, amount threshold, sensitive data range, device control object, or permission change type. For example, for payment tasks, the cloud-side authorization policy can set an amount threshold; if the payment amount is below the threshold, authorization is not required; if the payment amount reaches or exceeds the threshold, authorization is required. For data export tasks, the cloud-side authorization policy can set a sensitive data range; if the exported data involves preset sensitive fields, authorization is required. For permission change tasks, the cloud-side authorization policy can determine whether authorization is required based on whether the permission change involves the granting or revocation of core permissions. The cloud-side authorization policy can be combined with the risk control results from the server 200 side, allowing the server 200 to make dynamic decisions based on a comprehensive consideration of risk level, contextual information, and historical behavioral characteristics.

[0074] In another possible implementation, the trusted authorization component 102 can employ both edge-side and cloud-side determination methods simultaneously. After obtaining the edge-side authorization trigger determination result and the cloud-side authorization trigger determination result, the trusted authorization component 102 determines whether trusted authorization needs to be enabled based on the combined result of the two. The combination method can be: authorization is triggered when either determination result indicates that authorization is required; authorization is triggered only when both determination results indicate that authorization is required; or a weighted decision can be made based on the weights corresponding to the edge-side determination result and the cloud-side determination result. The specific combination strategy can be configured according to the security requirements of the application scenario.

[0075] When the trusted authorization component 102 determines that trusted authorization needs to be activated based on the terminal-side authorization trigger determination result and / or the cloud-side authorization trigger determination result, it triggers the trusted authorization component 102 to generate registration materials in the trusted execution environment 103 based on the binding context, i.e., it enters the registration material generation process in S303 above. When the determination result is that trusted authorization does not need to be activated, the trusted authorization component 102 can return a response indicating that binding is not required to the intelligent agent 101, or generate a simplified authorization credential for regular task execution, without entering the complete binding relationship establishment process based on the trusted execution environment 103.

[0076] Through the above-mentioned authorization triggering determination mechanism, this embodiment can apply the trusted authorization capability of the terminal side to high-security tasks that meet preset conditions. Low-risk or ordinary tasks can be executed directly by the intelligent agent 101 without triggering the trusted authorization component 102, thereby ensuring the reliability of authorization for high-security tasks while reducing the overall authorization overhead of the system and the frequency of disturbance to users.

[0077] In S304, the trusted authorization component 102 sends the registration materials to the trusted verification component 201 in the server 200.

[0078] The transmission process can be performed via network 300. Network 300 can be a wired network, a wireless network, or a combination thereof, and can employ a secure transmission protocol to encrypt and protect the communication content to prevent the registration materials from being eavesdropped on or tampered with during transmission. For example, a terminal identifier can be included when sending the registration materials.

[0079] In some embodiments, a user confirmation step may be introduced before the trusted authorization component 102 sends the registration materials to the server 200, in order to further enhance the security proof strength of the binding relationship establishment phase.

[0080] The condition for determining whether personal confirmation is required is whether the task to be performed on behalf of the authorized party falls within the preset scope of tasks requiring enhanced confirmation. The scope of tasks requiring enhanced confirmation can be pre-configured within the trusted authorization component 102 or in the secure storage area of ​​the terminal 100, and may include at least one of high-security tasks such as payment, contract signing, and permission granting. The scope of tasks requiring enhanced confirmation may be the same as or different from the aforementioned scope of trusted authorization; strategically, a subset of tasks with higher security levels can be included in the scope of tasks requiring enhanced confirmation.

[0081] When the current task is determined to fall within the scope requiring enhanced verification, the trusted authorization component 102 can trigger the terminal 100 to obtain the user's on-device identity verification information. The on-device identity verification information may include at least one of biometric verification information, personal identification number (PIN) verification information, or device unlock status verification information. Biometric verification information may be the result of biometric identification such as fingerprint, face, or iris scan; personal identification number (PIN) verification information is a pre-set numeric or character password by the user; device unlock status verification information refers to system-level proof that the terminal 100 is currently in an unlocked state, such as an unlock status token generated by the operating system after the user passes screen lock verification.

[0082] The process of obtaining the identity verification information on the client side can be completed within the trusted execution environment 103 by the trusted authorization component 102 calling the trusted user interface of the terminal 100, ensuring that the verification process itself is not interfered with by the ordinary operating system level. If the client-side identity verification is successful, the trusted authorization component 102 is triggered to send the registration materials to the server 200, thus entering... Figure 3 The sending process is shown in S304. If the identity verification on the terminal fails, such as due to biometric mismatch, incorrect personal identification code, or the device not being unlocked, the trusted authorization component 102 can terminate the binding process, not send registration materials to the server 200, and return a binding failure result to the agent 101.

[0083] Through the above mechanism, the establishment of the binding relationship not only relies on the binding request of the intelligent agent 101 and the registration materials generated by the trusted authorization component 102 in the trusted execution environment 103, but can also bind the user's own biometrics or device unlock status and other strong identity proofs when necessary, thereby forming stronger non-repudiation in the key link of "who initiated the binding" and reducing the risk of unauthorized binding.

[0084] In S305, the trusted verification component 201 in server 200 establishes a binding relationship based on the registration materials.

[0085] Upon receiving the registration materials, the trusted verification component 201 can first verify the registration materials. If the verification is successful, the trusted verification component 201 records the association between the terminal identifier, the user identifier in the registration materials, the agent identifier, and the task as a binding relationship, and stores it in a binding database or trusted storage area. This binding relationship represents the trusted association between the terminal 100, the user, the agent 101, and the task being executed.

[0086] For example, after receiving the registration materials, the trusted verification component 201 retrieves the binding relationship index and certificate materials containing the public key from the registration materials. The binding relationship index is generated by the trusted authorization component 102 on the terminal 100 side in the trusted execution environment 103 based on various binding element identifiers in the binding context information. Its generation algorithm is consistent with that on the server 200 side to ensure that the cloud can correctly retrieve the binding relationship based on the index. The certificate materials can be a public key carrier encapsulated in the form of a certificate chain.

[0087] The trusted verification component 201 can verify the validity of certificate materials, including: verifying the integrity of the certificate chain, verifying the signature of each certificate in the certificate chain level by level, up to the root certificate; checking whether each certificate is within its validity period; checking whether the certificate has been revoked; and verifying whether the proof information of the trusted execution environment 103 of the terminal 100 is valid. If any level of verification in the certificate chain fails, the certificate has expired or been revoked, or the proof information is invalid, the verification fails, the registration process terminates, and a registration failure result is returned.

[0088] If the verification passes, the trusted verification component 201 extracts the public key from the certificate materials. This public key, together with the private key stored in the trusted execution environment 103 on the terminal 100 side, forms an asymmetric key pair, which will be used to verify the authorized signature in subsequent task execution phases.

[0089] Subsequently, the trusted verification component 201 uses the binding relationship index as the retrieval primary key to associate and store binding relationships. A binding relationship may include at least one of the following: binding relationship index, public key, user identifier, agent identifier, task identifier, terminal identifier, binding status, binding time, and binding validity period. The binding relationship index uniquely identifies a binding relationship as the retrieval primary key; the public key is used for signature verification; the user identifier indicates the authorized user; the agent identifier indicates the authorized agent instance; the task identifier defines the authorized operation scope; and the terminal identifier indicates the device carrying the trusted root. When the registration materials include an access party identifier, the binding relationship may also include an access party identifier, indicating the end-side application or access channel that initiated the binding. The binding time records the timestamp of the binding relationship establishment, and the binding validity period limits the valid time range of the binding.

[0090] After completing the aforementioned information storage, the trusted verification component 201 sets the binding status of the binding relationship to a valid state, indicating that the binding relationship has been activated and can serve as the basis for authorization verification in subsequent task execution phases. The binding status can be defined using enumerated values, such as valid, frozen, unbound, and expired. By setting different states for the binding relationship and associating them with expiration dates, the server 200 can achieve full lifecycle management of the binding relationship, providing a basis for determining whether the binding relationship is in a valid state when verifying the authorization results later.

[0091] In S306, the trusted verification component 201 returns the binding result to the trusted authorization component 102 of the terminal 100.

[0092] The binding result is used to notify terminal 100 that the binding relationship has been successfully established. The binding result includes at least one of the following: binding relationship index, binding status, and validity period or usage policy information generated by server 200 for the binding relationship.

[0093] In S307, the trusted authorization component 102 of terminal 100 returns the binding result to agent 101.

[0094] After receiving the binding result returned by the server 200, the trusted authorization component 102 forwards the binding result to the intelligent agent 101. Upon receiving the successful binding result, the intelligent agent 101 can confirm that it has been authorized to perform a specific task, and the binding relationship establishment phase is completed. The pre-establishment of the binding relationship provides a trusted association basis for the server 200 to perform independent authorization verification for each task request in the subsequent task execution phase.

[0095] Successful execution of the binding relationship establishment phase can demonstrate the user's consent to the binding process in the following ways: (1) At the behavioral level, the binding activation is initiated by the user. The user enters the binding activation process by expressing the intention to activate the service or the intention to perform the task on behalf of the user, and completes the activation confirmation at the access point of the terminal he holds, which shows the user's consent to the binding in terms of behavior.

[0096] (2) At the holding level, the binding depends on the generation device key pair of the trusted execution environment within the user's terminal. The user's holding of the terminal itself constitutes an implicit constraint on the establishment of the binding relationship.

[0097] (3) In the optional enhanced confirmation level, users may be required to make an explicit personal confirmation on the terminal side when binding is activated, including at least one of biometric verification, personal identification code verification or device unlock status verification, thereby providing stronger proof for users to agree to establish binding.

[0098] In some embodiments, the binding result will be ultimately transmitted to the agent 101 via the trusted authorization component 102 of the terminal 100, and persistently stored by the terminal 100 to serve the subsequent task execution phase.

[0099] The trusted authorization component 102 receives and stores the binding result returned by the server 200 after establishing the corresponding binding relationship. The binding result includes at least the binding status of the binding relationship on the server 200. The binding status indicates the current lifecycle stage of the binding relationship on the server 200 side. For example, the binding result may also include at least one of the following: a binding relationship identifier assigned by the server 200 to the binding relationship, a binding establishment timestamp, a binding validity period, and the scope of authorized tasks confirmed by the server 200. The storage of the binding result on the terminal 100 side allows the intelligent agent 101 or the trusted authorization component 102 to quickly query the status of the binding relationship locally in subsequent processes without having to initiate a status query request to the server 200 each time.

[0100] The binding status of the binding relationship is uniformly maintained by the trusted verification component 201 in server 200. By placing the maintenance of the binding status on the cloud side, centralized management and dynamic control of the binding relationship can be achieved, with terminal 100 acting as both the receiver and responder of status information. When terminal 100 is lost, user identity changes, business permissions are adjusted, or a security risk event occurs, the cloud can promptly modify the binding status and make it effective in subsequent task authorization verifications, avoiding inconsistencies or delays that might arise from state management being decentralized on terminal 100.

[0101] The binding status maintained by the trusted verification component 201 can include at least one of the following: valid, frozen, unbound, expired, and pending rebinding. A valid status indicates that the binding relationship is in a normal and usable state. A frozen status indicates that the binding relationship has been temporarily suspended due to a risk event or management policy. An unbound status indicates that the binding relationship has been permanently terminated. An expired status indicates that the binding relationship has automatically expired. A pending rebinding status indicates that the binding process needs to be re-executed due to agent 101 migration or other changes.

[0102] When the trusted verification component 201 detects a change in the binding status of a certain binding relationship, it can send the binding status change information for that binding relationship to the corresponding trusted authorization component 102. The binding status change information is used to indicate the current status of the binding relationship. This status change push mechanism can be implemented by the server actively pushing or by the terminal side periodically polling.

[0103] Changes in binding status can be triggered by various management operations. When terminal 100 is reported as lost, the cloud can freeze or unbind the binding relationship index corresponding to terminal 100, causing subsequent signature verification to fail. When the identifier of agent 101 changes, such as when agent 101 migrates from one terminal to another or switches from one running instance to another, since the binding relationship index is generated jointly by various binding element identifiers, the identifier change will cause the binding relationship index to change, and the original binding will naturally become invalid, requiring rebinding under the new identifier. When a user cancels their account, all binding records associated with that user identifier can be unbound or set to invalid. When business permissions change, the binding at the corresponding business subject identifier dimension can be set to invalid or frozen.

[0104] Upon receiving information about a change in binding status, the trusted authorization component 102 updates the locally stored binding status accordingly. If the locally stored binding status is invalid (e.g., frozen, unbound, expired, or awaiting rebinding), the trusted authorization component 102 can restrict the agent 101 from initiating task authorization requests based on that binding relationship. This linkage mechanism ensures that cloud-based status changes are promptly applied to the terminal side, guaranteeing that the agent 101 cannot continue to initiate high-security task authorizations if the binding relationship has expired.

[0105] It is understandable that the above binding relationships support many-to-many association structures. The binding relationship uses a binding relationship index as its unique key, which is generated by binding element identifiers such as user identifier, agent identifier, task identifier, and terminal identifier according to preset rules. Different combinations of identifiers can generate different binding relationship indexes, each corresponding to an independent binding record, isolated from each other.

[0106] In one scenario, a user can bind to multiple trusted terminals. When the same user initiates binding requests on different terminals 100, the trusted authorization component 102 of each terminal 100 independently generates device key pairs and certificate materials in their respective trusted execution environments 103. Because the terminal identifiers are different, the binding relationship indexes generated by each terminal are also different. The trusted verification component 201 in the server 200 can use these different binding relationship indices as the retrieval primary key to create multiple independent binding records for the user. The public key in each binding record corresponds one-to-one with the private key of the corresponding terminal, achieving one key per device.

[0107] In another scenario, a terminal can be bound to multiple agents or multiple tasks. When multiple agent instances are deployed on the same terminal 100, or when the same agent 101 needs to perform different tasks, different agent identifiers or different task identifier combinations can generate different binding relationship indexes, forming different binding records on the server 200 side, which do not conflict with each other.

[0108] Under the above mechanism, a many-to-many mapping relationship can be formed between users, terminals, intelligent agents and access parties. Different binding relationship indexes can be used to distinguish and isolate them. While ensuring the independence and security of each binding relationship, it provides flexible authorization management capabilities for diverse deployment scenarios.

[0109] exist Figure 1 and Figure 2 Please refer to the system architecture shown. Figure 4 It provides a timing interaction diagram between terminal 100 and server 200 during the task execution phase. This task execution phase occurs after the successful completion of the binding relationship establishment phase and is used to implement a closed-loop mechanism of successive authorization signature on the terminal side and verification on the server side when the intelligent agent 101 performs specific high-security tasks on behalf of the user.

[0110] In S401, agent 101 generates a task authorization request.

[0111] For example, when agent 101 triggers a task to be executed based on the user's task execution intention or an automated task chain, it can first determine whether the task to be executed belongs to the task to be executed on behalf of someone else as indicated by an established binding relationship. This determination can be made by querying the authorized task range in the binding results stored locally on terminal 100. After confirming that the task to be executed belongs to an already bound task, agent 101 generates a task authorization request. The task authorization request includes task content and a binding context for establishing the binding relationship. The task content may include the task's operation type, operation object, operation parameters, amount information, and timestamp, etc. The binding context includes binding element identifiers such as user identifier, agent identifier, task identifier, optional terminal identifier, and optional access party identifier.

[0112] In S402, agent 101 sends a task authorization request to trusted authorization component 102. This sending process can be implemented through inter-process communication mechanisms within terminal 100 or application plugins / access layers 105.

[0113] In S403, the trusted authorization component 102 generates an authorization result in the trusted execution environment 103 based on the task authorization request.

[0114] In some embodiments, after receiving a task authorization request, the trusted authorization component 102 introduces a multi-verification mechanism to ensure that only legitimate, valid requests with established binding relationships are signed, rather than unconditionally signing arbitrary inputs.

[0115] After receiving a task authorization request sent by agent 101 via S402, the trusted authorization component 102 can first perform validity checks on the binding context information and task content in the task authorization request. Validity checks may include: checking whether the binding element identifiers such as user identifier, agent identifier, and task identifier in the binding context information conform to preset format specifications, and whether they are null or out-of-bounds values; checking whether the data structure of the task content is complete, whether the operation type is within a preset range, and whether the operation parameters are valid. When the binding context contains an access party identifier, it can also parse the identifier to confirm that the caller's application package name or access channel identifier matches the system's preset list of valid access parties; if they do not match, subsequent signature operations are rejected.

[0116] During or after validity verification, the trusted authorization component 102 can generate a key index in the trusted execution environment 103 based on a pre-set key and at least some binding element identifiers in the binding context information. The pre-set key is a security key generated by the trusted execution environment 103 during the initialization phase of the trusted authorization component 102, and it has application-dimensional uniqueness. The key index can be generated by using the pre-set key as the root key and a combination of the user identifier and the agent identifier as the derivation factor, calculated through a key derivation function. Based on this key index, the trusted authorization component 102 can determine whether a corresponding key pair exists in the secure storage area of ​​the trusted execution environment 103. If a corresponding key pair exists, it indicates that the current user has established a binding relationship for this type of task through the agent 101; if no corresponding key pair exists, it indicates that a binding relationship has not yet been established, and the trusted authorization component 102 can reject the signature request and return an unbound status message to the agent 101.

[0117] If the validity verification passes and a corresponding key pair exists, the trusted authorization component 102 is triggered to generate an authorization result in the trusted execution environment 103 based on the task authorization request, thus entering the signature generation process.

[0118] The above combination of verifications restricts signature triggering conditions from multiple dimensions: business entity identifier verification ensures that only legitimate applications or business types can trigger signatures; binding status verification ensures that only entities that have completed binding can obtain authorization; parameter validity verification excludes abnormal or maliciously constructed inputs. The verification logic is executed within the trusted execution environment 103, and the verification results are not affected by ordinary operating systems.

[0119] For example, in high-risk scenarios, users can be required to make an explicit confirmation on the terminal side, such as biometric verification, personal identification code verification, or device unlocking verification, to further prevent malicious plugins from inducing authorization without the user's knowledge.

[0120] In some embodiments, the generation of the authorization result involves cryptographically binding the task content with the binding context indivisibly and signing it with a private key within the trusted execution environment 103 to form an authorization credential that can be verified by the server 200.

[0121] The trusted authorization component 102 passes the task content and binding context to the trusted execution environment 103. The input data may include the task content and various binding element identifiers in the binding context.

[0122] Within the Trusted Execution Environment 103, the process of generating the authorization result can include two stages: data preprocessing and trusted signing.

[0123] In the data preprocessing stage, a task content summary is first generated based on the task content. This summary can be generated using a hash algorithm, which maps task content of arbitrary length to a fixed-length summary value and has collision resistance, ensuring that any change in the task content will result in a different summary value. Commonly used hash algorithms include SHA-256 or SM3, but are not limited to these.

[0124] Subsequently, the task content summary and various binding element identifiers in the binding context information are mixed according to preset preprocessing rules to obtain the data to be signed. The preset preprocessing rules may include at least one of the following: encoding, bitwise operations, and hashing of the task content summary and various binding element identifiers. Encoding can convert each field into a fixed-length byte sequence; bitwise operations may include at least one of byte-by-byte XOR operations and byte-level circular shift operations. By performing bitwise operations such as byte-by-byte XOR and circular shifts with multiple identifiers in the binding context and the task content summary, deep mixing of context and business data can be achieved, making the signature result dependent on both the task content and the complete binding context.

[0125] Based on the above hybrid processing, a hash calculation can be performed on the hybrid result to obtain a deterministic preprocessed result. This preprocessed result serves as the data to be signed. Its determinism means that for the same input, the endpoint and cloud sides can obtain consistent results by calculating according to the same rules. This allows the server 200 side to reproduce the calculation process and perform comparison during verification.

[0126] During the trusted signature phase, the trusted authorization component 102 invokes the private key corresponding to the binding relationship in the trusted execution environment 103 to sign the data to be signed, obtaining the signed data. The private key is the private key portion of the key pair generated or invoked by the trusted execution environment 103 during the binding relationship establishment phase, and it is always retained within the trusted execution environment 103 and set to be non-exportable. Because the private key is hardware-bound to the trusted execution environment 103 of the terminal 100 and is non-exportable, even if the operating environment of the intelligent agent 101 is completely controlled by an attacker, the attacker cannot obtain the private key to forge the authorization result.

[0127] After signing, the trusted authorization component 102 encapsulates and outputs the authorization result. The authorization result can be encapsulated in a common format, such as a standardized secure message format like SD-JWT. SD-JWT is a secure credential format based on JSON Web Token that supports selective disclosure. Its payload can include fields such as issuer identifier, issuance timestamp, expiration timestamp, globally unique identifier, and preprocessing result hash. The issuer identifier indicates the key index that generated the signature, the issuance timestamp records the time the signature was generated, the expiration timestamp limits the valid usage period of the signature, the globally unique identifier is used for replay verification, and the preprocessing result hash is used for data consistency verification on the server side. The authorization result may also include information such as the signature timestamp and error codes.

[0128] By combining the above-mentioned data preprocessing with trusted signatures, this embodiment binds the task content and the binding context together inseparably, preventing attackers from recombining the valid signature with the replaced task content or binding context for replay or cross-scenario reuse attacks.

[0129] In S404, the trusted authorization component 102 returns the authorization result to the agent 101.

[0130] In S405, agent 101 sends an authorization result and a task execution request containing task content to server 200. After receiving the request, task execution component 202 in server 200 hands it over to trusted verification component 201 for processing.

[0131] In S406, the trusted verification component 201 verifies the authorization result based on the binding relationship.

[0132] In some embodiments, after receiving a task execution request sent by agent 101 via S405, trusted verification component 201 may perform the following verification steps: Step 1: Parse the task execution request. The trusted verification component 201 extracts the task content and binding context from the task execution request. The task content includes business data such as operation type, operation object, and operation parameters, while the binding context contains various binding element identifiers.

[0133] Step 2: Generate a binding relationship index and retrieve binding relationships. The trusted verification component 201 calculates the binding relationship index based on the binding element identifiers in the binding context, using the same generation algorithm as the terminal 100. This algorithm may include concatenating the binding element identifiers in a preset order, encoding them with a fixed length, and then performing a hash calculation. After obtaining the binding relationship index, the trusted verification component 201 uses this index as the retrieval primary key to query the binding database. If no corresponding binding relationship is found, or if the binding status of the retrieved binding relationship is invalid, the trusted verification component 201 directly determines that the verification fails and rejects the task execution request. Invalid statuses may include frozen status, unbound status, or expired status.

[0134] Step 3: If the binding relationship is found and is valid, obtain the public key corresponding to the binding relationship. During the binding relationship establishment phase, the public key is provided by the trusted authorization component 102 on the terminal 100 side in the form of a certificate chain and stored in the binding relationship. The trusted verification component 201 can verify the validity of the certificate chain, including verifying the signature of each certificate in the certificate chain level by level, checking the certificate validity period and certificate revocation status. After successful verification, the public key is extracted from the certificate chain.

[0135] Step 4: Verify the signature data in the authorization result based on the obtained public key. The verification process uses the same verification algorithm as the signature algorithm on the terminal 100 side. The public key decrypts the signature data to obtain a digest value, and at the same time, the trusted verification component 201 recalculates the digest of the original data to be signed. The two are compared to determine whether the signature is valid. If the verification fails, it indicates that the signature data has been tampered with or was not generated by the corresponding private key, and the trusted verification component 201 determines that the verification fails.

[0136] Step 5, Data Consistency Verification. The trusted verification component 201 generates verification data based on the task content and binding context, following the same preset preprocessing rules as the terminal 100. Specifically, this may include: hashing the task content to obtain a task content digest; encoding, bitwise operations, and hashing the task content digest and various binding element identifiers in the binding context to obtain the verification data. The verification data is then compared for consistency with the data to be verified carried in the authorization result. If the comparison is inconsistent, it indicates that the task content or binding context has been tampered with during transmission, and the trusted verification component 201 determines that the verification fails.

[0137] Step 6: If the signature verification and data consistency comparison pass, optionally, the trusted verification component 201 can further perform timestamp verification and anti-replay verification. Timestamp verification includes checking whether the deviation between the issuance timestamp and expiration timestamp in the authorization result and the current server time is within an allowed window; if it exceeds the window, the request is rejected. Anti-replay verification includes extracting the globally unique identifier from the authorization result and querying whether the identifier already exists in the anti-replay cache; if it already exists, the request is rejected; if it does not exist, the identifier is written to the cache and an expiration time is set.

[0138] If all the above verifications pass, the trusted verification component 201 determines that the authorization result has been verified and proceeds to S407. The above verification process uses the binding relationship index as the entry point, public key signature verification and data consistency comparison as the core, supplemented by timestamp and anti-replay verification, to form a complete verification closed loop. The authorized task content and the final executed task content must be consistent byte by byte; otherwise, the verification will fail, thus preventing tampering and execution after authorization from the mechanism.

[0139] In S407, if the authorization result is verified, the trusted verification component 201 sends the verification result to the task execution component 202.

[0140] In S408, upon receiving a successful verification result, the task execution component 202 executes the high-security operation indicated by the task execution request. After task execution is complete, it can return the execution result to the intelligent agent 101.

[0141] In the event of a verification failure, the task execution component 202 may refuse to execute the task and return a failure result and the corresponding error code to the agent 101. The error code can be used to indicate the specific reason for the failure, such as the binding relationship not existing, the binding state being abnormal, the signature verification failing, the data consistency verification failing, the timestamp deviation exceeding the limit, or a replay attack being detected.

[0142] Meanwhile, the trusted verification component 201 can record an audit log for this failed request, retaining relevant information for traceability and risk analysis. The audit log content may include the access party identifier, user identifier, agent identifier, task identifier, globally unique identifier, reason for failure, and request timestamp, etc.

[0143] In some embodiments, when verification fails, server 200 may send a notification message to terminal 100 to inform the user that the authorization verification has failed and guide the user to re-initiate the signature authorization process, or trigger a rebinding process if the binding relationship has expired.

[0144] In addition, the trusted verification component 201 can count the frequency of authorization verification failures. When the number of failures of a certain intelligent agent 101, terminal 100, or binding relationship within a preset time window reaches an abnormal threshold, the trusted verification component 201 can set the corresponding binding status to a frozen state, blocking subsequent task execution requests until it is restored after security review or user reconfirmation.

[0145] The embodiments in this specification adopt a hierarchical authorization mechanism of "one-time explicit activation and seamless execution within the scope", which divides user participation into the binding activation stage and the task execution stage.

[0146] During the binding and activation phase, the user participates explicitly. After expressing their intention to activate the service or install the application to the intelligent agent 101, the user enters the binding and activation process. An explicit activation confirmation is completed on the access point 104's interactive interface on the terminal 100, establishing a binding relationship between the terminal 100, the user, the intelligent agent 101, and the business scenario. This binding relationship constitutes the user's pre-authorization for the intelligent agent 101 to perform actions on their behalf within a specific business scenario.

[0147] During the task execution phase, seamless execution within the authorized scope is achieved. When a binding relationship has been established and the task to be executed falls within the authorized business scenario and task scope, the trusted authorization component 102 on the terminal 100 side automatically signs and authorizes the specific task request one by one in the trusted execution environment 103, without requiring the user to manually confirm each time, thereby ensuring security while reducing interference with the user's normal usage process.

[0148] In some embodiments, please refer to Figure 5 This specification also provides a trusted authorization method for an intelligent agent, applied to a terminal with a trusted execution environment. The terminal includes a trusted authorization component and an intelligent agent. The method includes: In S500, the agent sends a binding request carrying a binding context to the trusted authorization component based on the user's authorization intent. The binding context is used to characterize the association between the user, the agent, and the task to be performed on behalf of the user as indicated by the authorization intent.

[0149] In S502, the trusted authorization component generates registration materials in a trusted execution environment based on the binding context and sends them to the server so that the server can establish the corresponding binding relationship.

[0150] In S504, the agent sends a task authorization request to the trusted authorization component, which includes the task content and binding context.

[0151] In S506, the trusted authorization component generates authorization results in a trusted execution environment based on the task authorization request and returns them to the agent.

[0152] In S508, the agent sends an authorization result and a task execution request containing task content to the server, so that the server can verify the authorization result based on the binding relationship and execute the task execution request after the verification is successful.

[0153] In one implementation, the trusted authorization component generates registration materials in a trusted execution environment based on the binding context, including: the trusted authorization component passing the binding context information into the trusted execution environment to perform the following steps in the trusted execution environment: after verifying the validity of various binding element identifiers in the binding context information, generating a binding relationship index based on the various binding element identifiers in the binding context information; generating or calling a key pair associated with the binding relationship index based on a preset key, the key pair including a public key and a private key; generating and outputting registration materials, the registration materials including at least: certificate materials containing the public key and the binding relationship index.

[0154] In one implementation, generating or invoking a key pair associated with a binding relationship index based on a preset key includes: in a trusted execution environment, generating a key index based on a preset key and at least some binding element identifiers in the binding context information; determining whether a corresponding key pair already exists in the trusted execution environment based on the key index; if no corresponding key pair exists, generating a new key pair in the trusted execution environment and storing the private key in the new key pair in the trusted execution environment; if a corresponding key pair exists, invoking the existing key pair in the trusted execution environment.

[0155] In one implementation, before the trusted authorization component sends the registration materials to the server, the method further includes: if the task to be performed on behalf of the user as indicated by the authorization intent falls within a preset scope requiring enhanced verification, obtaining the user's end-user identity verification information, which includes at least one of biometric verification information, personal identification code verification information, or device unlock status verification information; and if the end-user identity verification information is verified successfully, triggering the trusted authorization component to send the registration materials to the server.

[0156] In one implementation, the method further includes: after receiving a binding request, the trusted authorization component determines whether the task to be executed on behalf of the client falls within the preset trusted authorization scope according to the client-side preset authorization policy, and obtains the client-side authorization trigger determination result; and / or, sends the relevant information of the task to be executed on behalf of the client according to the authorization intention to the server, so that the server can make a determination according to the cloud-side authorization policy and receive the cloud-side authorization trigger determination result returned by the server; if it is determined that trusted authorization needs to be enabled based on the client-side authorization trigger determination result and / or the cloud-side authorization trigger determination result, the trusted authorization component is triggered to generate registration materials in the trusted execution environment based on the binding context.

[0157] In one implementation, the trusted authorization component generates an authorization result in a trusted execution environment based on a task authorization request, including: generating a task content digest based on the task content within the trusted execution environment; mixing the task content digest with binding context information according to preset preprocessing rules to obtain data to be signed; wherein the preset preprocessing rules include at least one of encoding, bitwise operation, and hashing of various binding element identifiers in the task content digest and binding context information; and signing the data to be signed using a private key in the trusted execution environment to obtain the authorization result.

[0158] In one implementation, before the trusted authorization component generates an authorization result in the trusted execution environment based on the task authorization request, it further includes: validating the binding context information and task content in the task authorization request; generating a key index in the trusted execution environment based on a preset key and at least some binding element identifiers in the binding context information, and determining whether a corresponding key pair exists in the trusted execution environment based on the key index; and triggering the trusted authorization component to generate an authorization result in the trusted execution environment based on the task authorization request if the validity verification passes and a corresponding key pair exists.

[0159] In one implementation, the method further includes: a trusted authorization component receiving and storing the binding result returned by the server after establishing the corresponding binding relationship; wherein the binding result includes at least the binding status of the binding relationship in the server; the trusted authorization component receiving binding status change information for the binding relationship sent by the server, the binding status change information indicating the current status of the binding relationship, the current status including at least one of valid status, frozen status, unbound status, expired status, and pending rebinding status; updating the locally stored binding status according to the binding status change information; and restricting the agent from initiating task authorization requests based on the binding relationship when the locally stored binding status is invalid.

[0160] In one implementation, the various binding element identifiers in the binding context information include basic binding element identifiers, or include basic binding element identifiers and extended binding element identifiers; wherein, the basic binding element identifiers include user identifiers, agent identifiers, and task identifiers; the extended binding element identifiers include at least one of terminal identifiers and access party identifiers, wherein the access party identifier is used to characterize the end-side application, client, or access channel that invokes the trusted authorization component.

[0161] In some embodiments, please refer to Figure 6 This specification also provides a trusted authorization method for intelligent agents, applied to a server, the server including a trusted verification component and a task execution component, the method including: In S600, the trusted verification component receives registration materials sent by the terminal. These registration materials are used to establish a binding relationship between the terminal, the user, the intelligent agent, and the task to be executed.

[0162] In S602, the trusted verification component establishes a binding relationship based on the registration materials.

[0163] In S604, the server receives a task execution request and authorization result sent by the agent. The task execution request includes the task content to be executed, and the authorization result is generated by the terminal based on the task content and the binding context. The binding context is used to represent the association between the user, the agent and the task.

[0164] In S606, the trusted verification component verifies the authorization result based on the binding relationship.

[0165] In S608, if the authorization result verification is successful, the trusted verification component sends the verification result to the task execution component.

[0166] In S610, the task execution component executes the task execution request upon receiving a successful verification result.

[0167] In one implementation, the trusted verification component establishes a binding relationship based on the registration materials, including: obtaining a binding relationship index and certificate materials containing a public key from the registration materials; verifying the validity of the certificate materials, and extracting the public key from the certificate materials if the verification passes; storing the binding relationship using the binding relationship index as the retrieval primary key, wherein the binding relationship includes at least one of the following: binding relationship index, public key, user identifier, agent identifier, task identifier executed on behalf of, terminal identifier, binding status, binding time, and binding validity period; and setting the binding status of the binding relationship to a valid state.

[0168] In one implementation, the method further includes: returning a binding result to the terminal, which includes a binding relationship index and / or binding status.

[0169] In one implementation, the trusted verification component verifies the authorization result based on the binding relationship, including: parsing the task execution request to obtain the task content and binding context; generating a binding relationship index based on the binding context and retrieving pre-stored binding relationships according to the binding relationship index; if a binding relationship is found and is in a valid state, obtaining the public key corresponding to the binding relationship; verifying the signature data in the authorization result based on the public key; generating verification data based on the task content and binding context, and comparing the verification data with the data to be verified carried in the authorization result; if the signature verification and the consistency comparison pass, determining that the authorization result has been verified successfully.

[0170] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0171] Figure 7 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 7 As shown, device 700 mainly consists of a communication interface 702, a user interface 704, a processor 706, and a data storage 708. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 710. The communication interface 702 enables device 700 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 702 may include an antenna and related processing devices for wireless communication with a radio access network or access point. Furthermore, the communication interface 702 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 702 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 702 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0172] User interface 704 includes receiving user input and providing output to the user. Therefore, user interface 704 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 704 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 704 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 700 may support remote access from other devices via communication interface 702 or another physical interface (not shown). User interface 704 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 704 may also be configured as a display device for rendering or displaying text fragments.

[0173] Processor 706 may contain one or more general-purpose processors and / or special-purpose processors.

[0174] Data storage 708 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 706. Data storage 708 may include removable and non-removable components.

[0175] Processor 706 is capable of executing program instructions 718 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 708 to perform the various functions described herein. Data storage 708 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 700, enable device 700 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 706 executing program instructions 718 may result in processor 706 using data 712.

[0176] For example, program instructions 718 may include an operating system 722 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 700 and one or more applications 720 (e.g., a browser, social application, or game application). Similarly, data 712 may include operating system data 716 and application data 714. Operating system data 716 is primarily accessible to the operating system 722, while application data 714 is primarily accessible to one or more applications 720. Application data 714 may reside in a file system visible or hidden from the user of device 700.

[0177] Application 720 can communicate with operating system 722 through one or more application programming interfaces (APIs). These APIs help application 720 read and / or write application data 714, transmit or receive information via communication interface 702, receive or display information on user interface 704, etc.

[0178] In some terminology, application 720 may be simply referred to as "app". Furthermore, application 720 can be downloaded to device 700 through one or more online app stores or app markets. However, applications can also be installed on device 700 in other ways, such as through a web browser or a physical interface on device 700 (e.g., a USB port).

[0179] In some embodiments, the trusted authorization method apparatus for intelligent agents, applied to a terminal or applied to a server, can be applied to, for example... Figure 7 The device shown is used to implement the technical solution of this specification. The specific implementation of the device can be found in the above description, and will not be repeated here.

[0180] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0181] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0182] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0183] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0184] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0185] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0186] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0187] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0188] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0189] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A trusted authorization method for an intelligent agent, applied to a terminal with a trusted execution environment, the terminal including a trusted authorization component and an intelligent agent, the method comprising: The intelligent agent sends a binding request carrying a binding context to the trusted authorization component according to the user's authorization intent. The binding context is used to characterize the association between the user, the intelligent agent, and the task to be executed on behalf of the user as indicated by the authorization intent. Based on the binding context, the trusted authorization component generates registration materials in the trusted execution environment and sends them to the server, so that the server establishes a corresponding binding relationship. The agent sends a task authorization request to the trusted authorization component, the task authorization request including task content and the binding context; Based on the task authorization request, the trusted authorization component generates an authorization result in the trusted execution environment and returns it to the agent; The agent sends the authorization result and a task execution request containing the task content to the server, so that the server can verify the authorization result based on the binding relationship and execute the task execution request after the verification is successful.

2. The method according to claim 1, wherein the trusted authorization component generates registration materials in the trusted execution environment based on the binding context, comprising: The trusted authorization component passes the binding context information to the trusted execution environment to perform the following steps in the trusted execution environment: After verifying the validity of various binding element identifiers in the binding context information, a binding relationship index is generated based on the various binding element identifiers in the binding context information; Generate or invoke a key pair associated with the binding relationship index based on a preset key, wherein the key pair includes a public key and a private key; Generate and output registration materials, which include at least: certificate materials containing the public key and the binding relationship index.

3. The method according to claim 2, wherein generating or invoking a key pair associated with the binding relationship index based on a preset key comprises: In the trusted execution environment, a key index is generated based on the preset key and at least some of the binding element identifiers in the binding context information; Determine whether a corresponding key pair already exists in the trusted execution environment based on the key index; If no corresponding key pair exists, a new key pair is generated in the trusted execution environment, and the private key in the new key pair is stored in the trusted execution environment. If a corresponding key pair exists, the existing key pair is invoked in the trusted execution environment.

4. The method according to claim 1, further comprising, before the trusted authorization component sends the registration materials to the server: If the task to be performed on behalf of the user as indicated by the authorized intent falls within the preset scope of enhanced verification, the user's terminal-side identity verification information is obtained. The terminal-side identity verification information includes at least one of biometric verification information, personal identification code verification information, or device unlock status verification information. If the identity verification on the client side is successful, the trusted authorization component is triggered to send the registration materials to the server.

5. The method according to claim 1, further comprising: After receiving the binding request, the trusted authorization component determines whether the task to be executed on behalf of the client falls within the preset trusted authorization scope according to the client-side preset authorization policy, and obtains the client-side authorization trigger determination result; and / or sends the relevant information of the task to be executed on behalf of the client according to the authorization intention to the server, so that the server can make a determination according to the cloud-side authorization policy and receive the cloud-side authorization trigger determination result returned by the server. If, based on the terminal-side authorization trigger determination result and / or the cloud-side authorization trigger determination result, it is determined that trusted authorization needs to be enabled, the trusted authorization component is triggered to generate registration materials in the trusted execution environment based on the binding context.

6. The method according to claim 1, wherein the trusted authorization component generates an authorization result in the trusted execution environment based on the task authorization request, comprising: Within a trusted execution environment, a task content summary is generated based on the task content; The task content summary and the binding context information are mixed according to a preset preprocessing rule to obtain data to be signed; wherein, the preset preprocessing rule includes at least one of encoding, bitwise operation and hashing of various binding element identifiers in the task content summary and the binding context information; The data to be signed is signed using the private key in the trusted execution environment to obtain the authorization result.

7. The method according to claim 1 or 6, wherein before the trusted authorization component generates an authorization result in the trusted execution environment based on the task authorization request, it further comprises: The binding context information and task content in the task authorization request are validated for validity. In the trusted execution environment, a key index is generated based on a preset key and at least some of the binding element identifiers in the binding context information, and it is determined whether a corresponding key pair exists in the trusted execution environment based on the key index; If the validity verification passes and a corresponding key pair exists, the trusted authorization component is triggered to generate an authorization result in the trusted execution environment based on the task authorization request.

8. The method according to claim 1, further comprising: The trusted authorization component receives and stores the binding result returned by the server after establishing the corresponding binding relationship; wherein the binding result includes at least the binding status of the binding relationship in the server; The trusted authorization component receives binding status change information for the binding relationship sent by the server. The binding status change information is used to indicate the current status of the binding relationship. The current status includes at least one of the following: valid status, frozen status, unbound status, expired status, and pending rebinding status. Update the locally stored binding status according to the binding status change information; If the locally saved binding state is invalid, the agent is restricted from initiating task authorization requests based on the binding relationship.

9. The method according to any one of claims 1 to 6 and 8, wherein the various binding element identifiers in the binding context information include basic binding element identifiers, or include basic binding element identifiers and extended binding element identifiers; in, The basic binding element identifiers include user identifier, agent identifier, and task identifier; The extended binding element identifier includes at least one of a terminal identifier and an access party identifier, wherein the access party identifier is used to characterize the end-side application, client, or access channel that invokes the trusted authorization component.

10. A trusted authorization method for an intelligent agent, applied to a server, the server including a trusted verification component and a task execution component, the method comprising: The trusted verification component receives registration materials sent by the terminal, and the registration materials are used to establish a binding relationship between the terminal, the user, the intelligent agent and the task executed on behalf of the user; The trusted verification component establishes the binding relationship based on the registration materials; The server receives a task execution request and authorization result sent by the intelligent agent. The task execution request includes the task content of the task to be executed. The authorization result is generated by the terminal based on the task content and the binding context. The binding context is used to characterize the association between the user, the intelligent agent and the task. The trusted verification component verifies the authorization result based on the binding relationship; If the authorization result is verified successfully, the trusted verification component sends the verification result to the task execution component; Upon receiving the verification result, the task execution component executes the task execution request.

11. The method according to claim 10, wherein the trusted verification component establishes the binding relationship based on the registration materials, comprising: Obtain the binding relationship index and certificate materials containing the public key from the registration materials; The certificate materials are validated for validity, and if the certificate materials pass the validation, the public key is extracted from the certificate materials. The binding relationship is stored in association using the binding relationship index as the primary key for retrieval. The binding relationship includes at least one of the following: the binding relationship index, the public key, the user identifier, the smart agent identifier, the task identifier, the terminal identifier, the binding status, the binding time, and the binding validity period. Set the binding status of the aforementioned binding relationship to a valid state; The method further includes: Return a binding result to the terminal, which includes the binding relationship index and / or the binding status.

12. The method according to claim 10, wherein the trusted verification component verifies the authorization result based on the binding relationship, comprising: Parse the task execution request to obtain the task content and the binding context; A binding relationship index is generated based on the binding context, and pre-stored binding relationships are retrieved according to the binding relationship index; If the binding relationship is found and is in a valid state, obtain the public key corresponding to the binding relationship; Verify the signature data in the authorization result based on the public key; Verification data is generated based on the task content and the binding context, and the verification data is compared with the data to be verified carried in the authorization result for consistency. If the signature verification and consistency comparison pass, the authorization result is deemed to have passed verification.

13. A trusted authorization system for intelligent agents, comprising a server and a terminal with a trusted execution environment, wherein the terminal includes a trusted authorization component and an intelligent agent, and the server includes a trusted verification component and a task execution component; The terminal is used to execute the trusted authorization method for intelligent agents as described in any one of claims 1 to 9; The server is used to execute the trusted authorization method for intelligent agents as described in any one of claims 10 to 12.

14. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-12 by executing the executable instructions.

15. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-12.

16. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-12.

Images