Tool invocation, tool invocation response methods, systems and electronic devices

Abstract

This application provides a tool invocation method, a tool invocation response method, a system, and an electronic device. The tool invocation method includes: a trusted invocation wrapper receiving a first invocation request output by a large model, the request including the identifier of a candidate tool, a candidate invocation operation, and candidate invocation parameters; upon successful verification of the first invocation request, determining first information, the information including the identifier of a target tool, the identifier of a target invocation operation, and target invocation parameters; encrypting the second information and generating a second invocation request, the request including a visible header and ciphertext, the visible header including the identifier of the target tool, the identifier of the target invocation operation, and information required for decryption, the second information including the target invocation parameters; and sending the second invocation request to a trusted invocation entry point corresponding to the target tool, the trusted invocation entry point decrypting the ciphertext in a trusted environment and sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool. This improves the security of the external tool invocation process.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a tool invocation, a tool invocation response method, a system, and an electronic device. Background Technology

[0002] With the deep application of Large Language Models (LLMs), LLMs (hereinafter referred to as large models) or AI agents based on large models have the technical foundation to extend their capabilities by calling external tools. Currently, large models or agents can call various external tools, such as database query interfaces, code execution environments, or Application Programming Interfaces (APIs), to complete complex tasks such as information retrieval, business operations, and decision execution, based on user tasks. In a typical system architecture, the large model or agent is responsible for understanding the user task and generating candidate tool call requests. These candidate requests are processed and sent to the corresponding tool for execution, and the execution result is then returned to the large model for the next round of inference.

[0003] However, the aforementioned tool invocation process faces a series of security challenges, preventing candidate invocations from the output of large models or agents from being directly executed as authorization requests. For example, the output of large models is nondeterministic and may be affected by factors such as hint injection, context pollution, or random sampling, making it difficult to guarantee the trustworthiness of the generated target tools, operations, and parameters. Furthermore, the various components of the invocation request lack unified integrity protection during transmission, making it difficult to guarantee that the request content will not be tampered with or replaced during transmission. Moreover, even with encrypted transmission, existing solutions struggle to effectively control the access and reading of decrypted plaintext parameters before execution, failing to ensure that plaintext parameters are only delivered to the executor after necessary verification. Furthermore, after tool execution, the returned results may not be effectively verified for their correspondence and integrity with the original request; unverified results, once entering the model context, will affect the reliability of subsequent inference.

[0004] It is evident that existing technical solutions are insufficient to provide adequate security guarantees for the process from model-side output to tool-side execution when large models call external tools. Summary of the Invention

[0005] This application provides a tool invocation, a tool invocation response method, a system, and an electronic device to improve the security of large models invoking external tools.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: Firstly, a tool invocation method is provided, applied to a trusted invocation wrapper, wherein the trusted invocation wrapper is the sole exit point for a large model to initiate invocation requests to external tools, and the method includes: Receive the first invocation request output by the large model, wherein the first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters; The first call request is verified, and if the verification is successful, the first information is determined, wherein the first information includes the identifier of the target tool that the first call request can call, the identifier of the target call operation, and the target call parameters; The second information is encrypted, and a second call request is generated. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and the information required to decrypt the ciphertext. The second information includes the target call parameters. The second call request is sent to the trusted call entry corresponding to the target tool, wherein the trusted call entry is used to decrypt the ciphertext in a trusted environment and send the identifier of the target call operation obtained from the visible header and the decrypted target call parameters to the executor of the target tool.

[0007] Secondly, a tool invocation response method is provided, applied to the trusted invocation entry point of the target tool, the method comprising: Receive a second call request sent by the trusted call encapsulator of the large model. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and the information required to decrypt the ciphertext. The second information includes the target call parameters. In a trusted environment, the ciphertext is decrypted according to the information required to decrypt it, to obtain the second information; The identifier of the target invocation operation and the target invocation parameters are sent to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target invocation operation.

[0008] Thirdly, a tool invocation device is provided, applied to a trusted invocation wrapper, wherein the trusted invocation wrapper is the sole outlet for a large model to initiate invocation requests to external tools, and the device includes: The first receiving module is used to receive the first invocation request output by the large model, wherein the first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters; The first determining module is used to verify the first call request and determine the first information if the verification is successful. The first information includes the identifier of the target tool that the first call request can call, the identifier of the target call operation, and the target call parameters. The first encapsulation module is used to encrypt the second information and generate a second call request, wherein the second call request includes a visible header and ciphertext corresponding to the second information, the visible header includes the identifier of the target tool, the identifier of the target call operation and the information required to decrypt the ciphertext, and the second information includes the target call parameters; The first sending module is used to send the second call request to the trusted call entry corresponding to the target tool, wherein the trusted call entry is used to decrypt the ciphertext in a trusted environment and send the identifier of the target call operation obtained from the visible header and the decrypted target call parameters to the executor of the target tool.

[0009] Fourthly, a tool invocation response device is provided, applied to a trusted invocation entry point of a target tool, the device comprising: The first receiving module is used to receive a second call request sent by the trusted call encapsulator of the large model. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and the information required to decrypt the ciphertext. The second information includes the target call parameters. The first decryption module is used to decrypt the ciphertext in a trusted environment according to the information required to decrypt the ciphertext, and obtain the second information; The first sending module is used to send the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target invocation operation.

[0010] Fifthly, a tool invocation system is provided, the system comprising a trusted invocation encapsulator and a trusted invocation entry point corresponding to the target tool, wherein the trusted invocation encapsulator is the sole exit point for the large model to initiate invocation requests to external tools, wherein: The trusted invocation encapsulator is configured to receive a first invocation request output by the large model, wherein the first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters; verify the first invocation request, and if the verification is successful, determine first information, wherein the first information includes the identifier of the target tool that the first invocation request can invoke, the identifier of the target invocation operation, and the target invocation parameters; encrypt the second information and generate a second invocation request, wherein the second invocation request includes a visible header and ciphertext corresponding to the second information, the visible header including the identifier of the target tool, the identifier of the target invocation operation, and information required to decrypt the ciphertext, and the second information including the target invocation parameters; and send the second invocation request to the trusted invocation entry point corresponding to the target tool. The trusted invocation entry point is used to receive the second invocation request; decrypt the ciphertext in a trusted environment according to the information required to decrypt the ciphertext to obtain the second information; and send the identifier of the target invocation operation in the visible header and the target invocation parameters in the second information to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target invocation operation.

[0011] Sixthly, an electronic device is provided, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in the first or second aspect.

[0012] A seventh aspect provides a computer-readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method as described in the first or second aspect.

[0013] Eighthly, a computer program product is provided, which is stored in a storage medium and is executed by at least one processor to implement the method as described in the first or second aspect.

[0014] The technical solution provided in this application, because the trusted call encapsulator serves as the sole exit point for the large model to initiate call requests to external tools, verifies the first call request output by the large model and, upon successful verification, determines the first information including the target tool identifier, the target call operation identifier, and the target call parameters. Therefore, it avoids the impact of the non-determinism of the large model's output on the trustworthiness of the tool call. Simultaneously, because the second information is encrypted and a second call request including a visible header and ciphertext is generated, the business parameters are transmitted in ciphertext form, and the visible header carries the information required for decryption. This ensures the integrity of the call request during transmission and prevents the request content from being tampered with or replaced. Furthermore, because the trusted call entry point decrypts the ciphertext in a trusted environment and sends the target call operation identifier and target call parameters to the executor, it effectively controls the access behavior of the decrypted plaintext parameters, ensuring that the plaintext parameters can only be delivered to the executor for execution after decryption in a trusted environment. Thus, the security of the large model calling external tools is improved. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a tool invocation method provided in an embodiment of this application.

[0017] Figure 2 This is a schematic diagram of the authentication and encryption process provided in an embodiment of this application.

[0018] Figure 3 This is a schematic diagram of the dual cryptographic binding of the calling intent provided in an embodiment of this application.

[0019] Figure 4 This is a flowchart illustrating a tool invocation method provided in another embodiment of this application.

[0020] Figure 5 This is a flowchart illustrating a tool invocation response method provided in an embodiment of this application.

[0021] Figure 6 This is a schematic diagram of a plaintext controlled release state machine for a trusted call entry point provided in an embodiment of this application.

[0022] Figure 7 This is a schematic diagram of the interaction timing of a tool invocation method provided in an embodiment of this application.

[0023] Figure 8 This is a schematic diagram of the structure of a tool calling system provided in an embodiment of this application.

[0024] Figure 9 This is a schematic diagram of the structure of a tool calling system provided in another embodiment of this application.

[0025] Figure 10 This is a schematic diagram of the structure of a tool calling device provided in an embodiment of this application.

[0026] Figure 11 This is a schematic diagram of a tool calling device provided in another embodiment of this application.

[0027] Figure 12 This is a schematic diagram of the structure of a tool call response device provided in an embodiment of this application.

[0028] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0030] The terms "first," "second," etc., used in this application and the claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that this application can be implemented in orders other than those illustrated or described herein. Furthermore, in this application and the claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0031] Existing technical solutions typically only improve one aspect of transmission encryption, tool authentication, or result signing, making it difficult to simultaneously ensure security throughout the entire invocation process. For example, the tool name, operations, and parameters output by a large model may be affected by factors such as hint injection, context pollution, or sampling, and cannot be directly executed as an authorized invocation request; the lack of a unified signature object binding between the external tool's signature capability list, public key, parameter specifications, key generation, and actual execution instance may lead to the risk of misusing tools, incorrect versions, or downgraded invocations; ordinary encryption schemes may immediately deliver the plaintext to the external tool's executor after decryption, failing to guarantee that the plaintext was not read before execution; the execution results of unverified external tools may enter the model context, affecting subsequent inference and decision-making, and so on.

[0032] Therefore, how to transform the candidate tool calls generated by the large model into deterministic and verifiable protocol objects, and how to prevent external tools from releasing plaintext to ordinary executors before the "isolation decryption - joint verification - atomic consumption" process is completed, thus ensuring the security of the entire process of the large model calling external tools, are the technical problems that urgently need to be solved.

[0033] To address at least one of the aforementioned problems and improve the security and reliability of large-scale models calling external tools throughout the entire process, embodiments of this application provide a tool invocation method, a tool invocation response method, a system, and an electronic device. In this method, after the large-scale model generates candidate tool invocations through inference, it does not directly send an invocation request to the executor of the target tool. Instead, the large-scale model's trusted invocation encapsulator converts the candidate invocation into a sealed object bound to at least one of the following security information: the target tool's signature capability list, normalized parameters, minimum privilege credential, and the large-scale model's key-holding proof. This sealed object is then sent to the target tool's trusted invocation entry point. After joint verification, the trusted invocation entry point establishes a one-time plaintext channel and sends the relevant parameters to the target tool's execution through this one-time plaintext channel to execute the invocation. This improves the security of the entire process of the large-scale model calling the target tool.

[0034] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0035] Figure 1 The diagram illustrates a flowchart of a tool invocation method according to an embodiment of this application. This method can be applied to a trusted invocation wrapper for a large model, which serves as the sole exit point for the large model to initiate invocation requests to external tools, and the two can communicate with each other. In other words, the large model's runtime environment cannot directly access external network exits; the only exit point is the trusted invocation wrapper.

[0036] In some embodiments, the aforementioned "single exit" architectural constraint can be achieved through process isolation and network access control. Specifically, the inference process of a large model can be deployed in a separate container, virtual machine, network namespace, or restricted subnet, with its access to external networks prohibited by default, and the client certificates, tokens, and original network connection permissions required to access external tools removed. This inference process is only allowed to send candidate call requests to the trusted call wrapper via local inter-process communication (IPC) or controlled remote procedure call (RPC).

[0037] In some embodiments, the trusted invocation wrapper can use independent service identities and network permissions. Its network egress can be restricted by firewalls, access control lists (ACLs), egress proxies, or service meshes, allowing it to access only trusted invocation entries of external tools registered in the tool trust registry. The Uniform Resource Locator (URL), candidate tool name, or routing information output by the large model cannot directly trigger a network connection; the target address can only be determined by the trusted invocation wrapper based on a verified list of signature capabilities.

[0038] like Figure 1 As shown, an embodiment of this application provides a tool invocation method, which may include: Step 101: Receive the first invocation request output by the large model, wherein the first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters.

[0039] In some embodiments, the large model can be a standalone AI model or a large model embedded in an AI agent as the core of inference. The large model is responsible for understanding the user task, reasoning in conjunction with the context, and generating candidate tool invocation requests, i.e., the first invocation request.

[0040] In some embodiments, a candidate tool refers to an external tool initially proposed by the large model based on the user task. Its identifier can be information that uniquely identifies the tool, such as its name, ID, or Uniform Resource Locator (URL). A candidate invocation operation refers to the specific operation proposed by the large model to be performed on the candidate tool, such as querying, refunding, or code execution. Candidate invocation parameters refer to the parameter content used by the large model when proposing to execute the candidate invocation operation, such as query conditions, refund amount, and code to be executed. It should be noted that the term "candidate" only indicates the state of the invocation request before verification by the trusted invocation wrapper, and does not imply that the invocation request itself is uncertain.

[0041] Step 102: Verify the first call request, and if the verification is successful, determine the first information, wherein the first information includes the identifier of the target tool that the first call request can call, the identifier of the target call operation, and the target call parameters.

[0042] In some embodiments, the first invocation request output by the large model may include multiple candidate tools, multiple candidate invocation operations, and / or corresponding candidate invocation parameters. The trusted invocation wrapper does not reinterpret the business intent, but instead verifies the candidate tools and candidate invocation operations. Only candidate tools that pass all verifications can be selected as the target tool and target invocation operation; if no candidate tool passes verification, the trusted invocation wrapper refuses to generate a second invocation request. When multiple candidate invocations are equivalent instances of the same operation, the trusted invocation wrapper may select according to preset rules, such as sequentially comparing data residency requirements, trust metrics, health status, business priority, and stability indicators, and the same input, the same manifest version, and the same policy version should yield the same result. Optionally, if the business meanings or external side effects of multiple candidate invocations differ, the trusted invocation wrapper does not replace the large model in selection, but instead requires the large model to re-plan, or requests user confirmation if the scope exceeds the pre-authorized range.

[0043] In some embodiments, verifying the first invocation request and determining first information if the verification passes may include: verifying the first invocation request based on a task boundary generated by a trusted task boundary generator and a signature capability list of at least one external tool, and determining first information if the verification passes, wherein the signature capability list of the external tool includes the identifier of the external tool, the identifier of at least one invocation operation allowed by the external tool, the parameter specification of the external tool, and related security information.

[0044] In some embodiments, the signature capability list is a verifiable security object of an external tool, provided by the external tool and registered in a tool trust registry. An external tool's signature capability list includes at least the external tool's unique identifier, the identifier of at least one allowed invocation operation of the external tool, a summary of the external tool's input / output parameter specifications, and related security information. This related security information may include at least one of the following: a request decryption public key, a receipt verification public key, an identifier of the cryptographic algorithm suite, key generation, effective time and expiration time, revocation status, and optional trusted invocation entry metric values, etc.

[0045] In some embodiments, the task boundary is generated by a trusted task boundary generator based on at least one of the following: the user's current task, system security policy, tenant and data access scope, and the scope of allowed and prohibited tools, operations, and resources. For example, if a user requests "query order 123", the task boundary can be limited to: only allowing the order query operation, only allowing access to order 123, and not allowing refunds or modifications to the order.

[0046] In some embodiments, verifying the first invocation request based on a task boundary generated by a trusted task boundary generator and a signature capability list of at least one external tool may include: Based on the task boundary, determine whether the identifier of the candidate tool and the candidate invocation operation are within the allowed task boundary range; The identifiers of the candidate tools are matched with the identifiers of the external tools in the signature capability list of each external tool to obtain a target signature capability list that matches the identifiers of the candidate tools. Based on the relevant security information in the target signature capability list, the signature, validity period, revocation status, and key generation of the target signature capability list are verified; Determine whether the candidate invocation operation falls within the scope of at least one invocation operation permitted by the target signature capability list; Based on the parameter specifications in the target signature capability list, the candidate call parameters are normalized to obtain normalized parameters; If the candidate tool's identifier and the candidate invocation operation are within the allowed task boundary, the candidate invocation operation is within the allowed invocation operation range of the target signature capability list, the signature, validity period, revocation status, and key generation of the target signature capability list are verified, and the normalized parameters are obtained, then the verification is deemed successful.

[0047] In some embodiments, the target signature capability list is the signature capability list of the target tool. The normalization process for the candidate call parameters according to the parameter specifications in the target signature capability list may include: rejecting at least one of the following from the candidate call parameters: unknown fields, duplicate keys, out-of-bounds values, and disallowed sensitivity levels; and deterministically encoding the retained fields according to the parameter specifications to obtain normalized parameters. Since the normalization result is consistent for the same call at any time and on any device, the normalized parameters can be recalculated and compared.

[0048] In some embodiments, if there is no list of target signature capabilities that match the identifier of the candidate tool, or if the candidate invocation operation is not within the scope of allowed invocation operations, the verification is determined to fail.

[0049] In some embodiments, determining the first information upon successful verification includes: upon successful verification, identifying the external tool corresponding to the target signature capability list as the target tool, identifying the candidate invocation operation as the target invocation operation, and identifying the normalized parameter as the target invocation parameter.

[0050] Step 103: Encrypt the second information and generate a second call request. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool (tool_id), the identifier of the target call operation (operation_id), and information required to decrypt the ciphertext. The second information includes the target call parameters.

[0051] In some embodiments, prior to step 103 Figure 1 The method shown may further include: generating a call intent based on the target signature capability list and the first information.

[0052] In some embodiments, generating a call intent based on the target signature capability list and the first information includes: generating a parameter digest based on the parameter specifications in the target signature capability list and the target call parameters; generating the call intent based on the identifier of the target tool, the identifier of the target call operation, the digest of the target signature capability list, the parameter digest, and third information, wherein the third information includes: the hash value of the minimum permission credential for this call, the key digest of the large model, the identifier of the first call request, the request random number for this call, the validity period of this call, and the key generation.

[0053] In some embodiments, the trusted invocation wrapper may obtain the minimum authorization credentials for this invocation from the authorization service after receiving the first invocation request.

[0054] For example, the above parameter summary can be calculated by the following formula: args_digest=H("AI-TOOL-ARGS-v1"||LP(schema_digest)||LP(canonical_args_bytes)) Where H() represents a hash function, LP() represents a length prefix, and || represents concatenation; "AI-TOOL-ARGS-v1" is a fixed label, schema_digest is a digest of the parameter specifications in the target signature capability list, and canonical_args_bytes is the byte string corresponding to the canonical parameters. It can be understood that by incorporating the parameter specification digest into the parameter digest calculation, even if the parameter bytes are the same, if the parameter specification interpreting the parameter is replaced, the parameter digest will change, thereby preventing privilege expansion due to parameter specification substitution.

[0055] The hash function H() can employ hash algorithms such as SHA-256, and its output is a fixed-length hash value. Any change in the input will change the output hash value, and this is irreversible. The length prefix LP() is used to record the length of each data segment before concatenation to avoid ambiguity caused by concatenating different data segments. For example, without the length prefix, the result of concatenating "AB" and "C" is the same as the result of concatenating "A" and "BC". Adding the length prefix avoids this ambiguity. The fixed labels "AI-TOOL-MANIFEST-v1" and "AI-TOOL-ARGS-v1" are used for domain separation, that is, to indicate the object type to which the hash value belongs, preventing hash values ​​of different objects from being confused.

[0056] For example, a summary of the signature capability list can be calculated using the following formula: manifest_digest=H("AI-TOOL-MANIFEST-v1"||LP(manifest_bytes)) Here, "AI-TOOL-MANIFEST-v1" is a fixed tag, and manifest_bytes is the raw bytes of the signature capability manifest. Using the above formula, any change to the content of the signature capability manifest will result in a change to its digest, allowing the version of the signature capability manifest used to be determined in subsequent stages by comparing the digests.

[0057] For example, the invocation intent I does not contain the model's hidden thought chain, but instead includes the task boundary, the identifier of the target tool, the identifier of the target invocation operation, a digest of the target signature capability list (manifest_digest), a digest of the parameter specification (schema_digest), a digest of the parameter specifications (args_digest), a digest of the minimum privilege credentials for this invocation, a key digest of the large model, the first invocation request identifier, the request random number, the validity period of this invocation, and the key generation. In this case, the invocation intent can be calculated using the following formula: I=H(domain||LP(tool_id)||LP(manifest_digest)||LP(operation_id)||LP(args_digest)||LP(H(permission_token))||LP(agent_key_digest)||LP(request_id)||LP(nonce)||LP(expiry)||LP(key_epoch)) Where I represents the invocation intent, domain represents the task boundary, tool_id represents the identifier of the target tool, manifest_digest represents the digest of the target signature capability list, operation_id represents the identifier of the target invocation operation, args_digest represents the parameter digest, H(permission_token) represents the hash value of the minimum permission credential for this invocation, permission_token represents the minimum permission credential, agent_key_digest represents the key digest of the large model, request_id represents the identifier of the first invocation request, nonce represents the request random number for this invocation, expiry represents the expiry date of this invocation, and key_epoch represents the key generation.

[0058] In some embodiments, the invocation intent I does not contain the hidden thought process of the large model, but only the objectively verifiable elements mentioned above. In this way, the irreproducible reasoning process of the large model can be avoided as the basis for security judgment, ensuring that the invocation intent can be transmitted, compared and stored among multiple parties.

[0059] In some embodiments, the hash value of the least privilege credential is used in the calculation of Invocation Intent I, instead of the least privilege credential itself. In this way, Invocation Intent I can bind the credential to the current invocation without exposing the credential content.

[0060] In some embodiments, the invocation intent I is generated after parameter normalization and before the second information is encrypted, and is used to bind all constraints of this invocation at once. In subsequent steps, the invocation intent I also participates in the derivation of the request key and the generation of authentication association data, so that any change in any of the following: target tool, target invocation operation, parameter specification, parameter digest, least privilege credential, key digest of the large model, identifier of the first invocation request, request random number, validity period, and key generation will result in failure of the request key or authentication verification.

[0061] In some embodiments, encrypting the second information and generating a second invocation request may include: encrypting the second information according to the invocation intent and the relevant security information corresponding to the target tool, and generating a second invocation request.

[0062] In some specific embodiments, encrypting the second information and generating a second invocation request based on the invocation intent and the relevant security information corresponding to the target tool may include: 1) Generate a shared key based on the request encryption public key in the relevant security information of the target signature capability list. In some embodiments, the trusted invocation wrapper can use the request encryption public key to obtain the shared key (shared_secret) through a key encapsulation mechanism (KEM) or hybrid public key encryption (HPKE). The shared key is calculated independently by both the trusted invocation wrapper and the trusted invocation entry point of the target tool. Only the key encapsulation value is transmitted during the transmission process; the shared key itself is not transmitted with the request.

[0063] 2) Derive a request key based on the shared key and the fourth information, wherein the fourth information includes the invocation intent, the communication protocol version of the trusted invocation wrapper and the trusted invocation entry, the identifier of the cryptographic algorithm suite supported by the target tool, and the request direction.

[0064] In some embodiments, derivation can be performed using a key derivation function (KDF), as shown in the following formula: request_key=KDF(shared_secret,"AI-TOOL-SEAL-v1"||suite_id||I||"request") In this context, `request_key` represents the request key, `KDF` represents the key derivation function, `shared_secret` represents the shared key, `"AI-TOOL-SEAL-v1"` is a fixed label, `suite_id` represents the identifier of the encryption algorithm suite, `I` represents the invocation intent, and `request` represents the request direction label. In some embodiments, the plaintext of the request key is not sent with the second invocation request; it is re-derived for each invocation and cleared after the invocation ends. Because the invocation intent `I` participates in the derivation of the request key, any change in any of the following—target tool, target invocation operation, parameter specification, parameter digest, least privilege credential, key digest of the large model, identifier of the first invocation request, request random number, validity period, or key generation—will result in a different derived request key, preventing the target tool from correctly decrypting it.

[0065] 3) Using the request key and the first associated authenticating data (AAD), perform authenticating encryption with associated data (AEAD) on the second information to obtain the ciphertext. The first AAD is generated based on the fifth information, which includes a digest of the target signature capability list, a digest of the parameter specification, and the invocation intent. Specifically, the authentication encryption can be represented as: ciphertext=AEAD.Seal(request_key,request_nonce,plaintext,AAD) Wherein, ciphertext represents ciphertext, AEAD.Seal represents the authentication encryption operation, request_key represents the request key, request_nonce represents the request random number for this call, plaintext represents plaintext, and AAD represents authentication associated data. The plaintext includes at least the second information, i.e., the target call parameters, and may also include the minimum privilege credential and the key-holding proof of the large model. Optionally, the authentication encryption outputs ciphertext and an AEAD authentication tag. The AEAD authentication tag is an integrity check value calculated together with the ciphertext and AAD, and is included in the ciphertext.

[0066] Figure 2 This illustration shows an authentication encryption process provided by an embodiment of this application. In this embodiment, specified fields in the visible header are digested to generate first authentication associated data (AAD). The first AAD may include a digest of the target signature capability list, a digest of the parameter specification, and a call intent I. Then, the second information is authenticated and encrypted using the request key and the first AAD to obtain ciphertext. The ciphertext may include the target call parameters, the minimum privilege credential, and the key holding proof of the large model. The first AAD is generated based on the specified fields in the visible header and is not sent independently with the second call request.

[0067] In addition, such as Figure 3As shown, in some embodiments, when generating the second invocation request, the invocation intent I is subjected to dual cryptographic binding. In this embodiment, invocation intent I participates in both the derivation of the request key and the authentication encryption, forming a dual binding. Specifically, invocation intent I enters the derivation of the request key (binding 1), i.e., request_key=KDF(shared_secret,"AI-TOOL-SEAL-v1"||suite_id||I||"request"); and enters the authentication encryption AAD (binding 2), i.e., ciphertext=AEAD.Seal(request_key,request_nonce,plaintext,AAD). Thus, any change in any of the following—target tool, target invocation operation, parameter specification, parameter digest, least privilege credential, key digest of the large model, identifier of the first invocation request, request random number, validity period, and key generation—will result in a different request key or authentication verification failure.

[0068] It should be noted that the second AAD does not need to be sent as an independent field with the second call request. Instead, it is generated by deterministically encoding a specified field in the visible header according to pre-agreed rules. The trusted call wrapper and the trusted call entry point can obtain identical second AADs based on the same visible header and the same encoding rules. It can be understood that the second AAD is not encrypted, but participates in the calculation of the AEAD authentication tag, its role being to bind the visible header to the ciphertext. For example, even if an attacker cannot decrypt the ciphertext, if they modify fields such as the target tool identifier, the digest of the signature capability list, the key generation, the identifier of the second call request, or the request random number in the visible header, the AAD calculated by the trusted call entry point will change, and the AEAD verification will fail.

[0069] It should also be noted that, in addition to AEAD, those skilled in the art can also use other encryption algorithms to encrypt the second information to obtain ciphertext, and the embodiments of this application do not limit this.

[0070] In some embodiments, the identifier (operation_id) of the target invocation operation may also be carried in the ciphertext and sent to the trusted invocation entry point corresponding to the target tool. The visible header only retains the routing and key selection fields and does not contain the business plaintext.

[0071] In some embodiments, the second information further includes the least privilege credential for this call and the key holding proof of the large model. The least privilege credential is associated with seventh information, which includes the identifier of the target tool, the identifier of the target call operation, and the target call parameters. The key holding proof is associated with eighth information, which includes the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key code. The key holding proof is used to bind the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key code to prevent the least privilege credential from being copied or abused across instances.

[0072] 4) Encapsulate the fifth and sixth information to obtain the visible header, wherein the sixth information includes the communication protocol version, the identifier of the encryption algorithm suite, the identifier of the target tool, the identifier of the target call operation, the key generation, the key encapsulation value, the request random number of this call, the identifier of the second call request, the validity period of this call, the temporary public key of the large model, etc.

[0073] 5) Encapsulate the visible header and the ciphertext to obtain the second invocation request.

[0074] In some embodiments, the second invocation request may be represented as: sealed_request=protected_header+ciphertext Here, `sealed_request` represents the second request, `protected_header` represents the visible header, and `ciphertext` represents the ciphertext. From the overall structure, the second request consists of two parts: a visible header and ciphertext. The key encapsulation value and the request random number are already included in the visible header and do not need to be treated as a separate third part.

[0075] It is understandable that by generating a call intent, elements such as the identifier of the target tool, the identifier of the target call operation, the digest of the signature capability list, the parameter digest, and the hash value of the least privilege credential are bound to the same call intent. This ensures that any change in any element can be detected through comparison of the call intent. At the same time, the second information is encrypted to generate a second call request, so that the target call parameters are transmitted in ciphertext. It is evident that the header only carries the information required for routing and decryption without exposing the plaintext of the business. This ensures that the call request can be correctly routed and decrypted, while improving the integrity and confidentiality of the call request during transmission.

[0076] Step 104: Send the second call request to the trusted call entry corresponding to the target tool, wherein the trusted call entry is used to decrypt the ciphertext in a trusted environment and send the identifier of the target call operation obtained from the visible header and the decrypted target call parameters to the executor of the target tool.

[0077] In some embodiments, the trusted invocation wrapper can send a second invocation request to the trusted invocation entry point corresponding to the target tool through an untrusted transport layer. During transmission, intermediate nodes can only obtain the visible header and ciphertext, but cannot know the business plaintext in the ciphertext, nor can they tamper with the visible header or ciphertext without being detected.

[0078] In some embodiments, after receiving the second call request, the trusted call entry point can decrypt the ciphertext in a trusted environment (such as a trusted execution environment or an isolated component) based on the decryption information in the visible header to obtain the target call parameters. It then sends the identifier of the target call operation obtained from the visible header and the decrypted target call parameters to the executor of the target tool. The operations performed by the trusted call entry point, including decryption of the ciphertext, joint verification of the second call request, atomic consumption of the least privilege credential, and establishment of a one-time plaintext channel, will be discussed below. Figure 5 The embodiments shown are described in detail, and will not be repeated here.

[0079] Figure 1 The tool invocation method proposed in the illustrated embodiment, since the trusted invocation encapsulator serves as the sole outlet for the large model to initiate invocation requests to external tools, verifies the first invocation request output by the large model and, upon successful verification, determines the first information including the target tool identifier, the target invocation operation identifier, and the target invocation parameters. Therefore, it avoids the impact of the non-determinism of the large model's output on the trustworthiness of the tool invocation. Simultaneously, by encrypting the second information and generating a second invocation request including a visible header and ciphertext, the business parameters are transmitted in ciphertext form, and the visible header carries the information required for decryption. This ensures the integrity of the invocation request during transmission and prevents the request content from being tampered with or replaced. Furthermore, since the trusted invocation entry point decrypts the ciphertext in a trusted environment and sends the target invocation operation identifier and the target invocation parameters to the executor, it can effectively control the access behavior of the decrypted plaintext parameters, ensuring that the plaintext parameters can only be delivered to the executor for execution after decryption in a trusted environment. Thus, the security of the large model invoking external tools is improved.

[0080] In some embodiments, such as Figure 4 As shown, after step 104, the tool invocation method proposed in this application may further include: Step 105: Receive the sealed response returned by the trusted call entry point. The sealed response includes the encrypted execution result and the signed receipt.

[0081] The signature receipt is associated with the tenth information, which includes: a digest of the ciphertext, the invocation intent, an actual instance of the target tool, a list of the target signature capabilities, an identifier of the target invocation operation, the execution status of the target invocation operation, and a digest of the execution result.

[0082] In some embodiments, since the trusted invocation wrapper can also derive response material from the key negotiation context, the authentication encryption verification of the response ciphertext can only prove that the content has not been tampered with, and cannot independently prove that the execution result was indeed generated by the target tool. Therefore, the trusted invocation entry point of the target tool should also generate a signed receipt for the request ciphertext digest, response ciphertext or result digest, invocation intent, actual instance, actual signature capability list, operation, and status. Accordingly, the trusted invocation wrapper only accepts the execution result after all response decryption, authentication encryption verification, signed receipt verification, request association verification, and output parameter specification verification have passed.

[0083] Step 106: Decrypt the sealing response to obtain the execution result.

[0084] In some embodiments, step 106 may specifically include: 1) Based on the key negotiation context between the trusted call encapsulator and the trusted call entry point, a response key is derived using a first purpose label and a response base random number is derived using a second purpose label through the key export interface, wherein the response key and the response base random number are both bound to the digest of the ciphertext of the call intent and the second call request.

[0085] Specifically, the response key and the response base random number use keys and random numbers independent of the request direction, and cannot directly reuse the request key or request random number to prevent direction confusion attacks. For example, the key negotiation context can be an HPKE context, the key export interface can be the SecretExport interface of the HPKE context, the primary purpose tag can be "response-key", and the secondary purpose tag can be "response-nonce".

[0086] 2) Determine the response random number based on the response base random number.

[0087] In some embodiments, in the case of non-streaming response, the base random number of the response can be used directly as the response random number, or the response random number can be derived after being derived according to a preset derivation rule. In the case of streaming response, a unique response random number can be generated for each fragment of the execution result based on the base random number of the response and the incrementing fragment number, and the fragment number and the termination flag are added to the second AAD.

[0088] 3) Generate a second AAD based on the ninth information, wherein the ninth information includes the request identifier of the second call request, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status, a summary of the response parameter specification, and a summary of the execution result.

[0089] 4) Use the response key, the response random number, and the second AAD to authenticate and decrypt the encrypted execution result to obtain the execution result.

[0090] Step 107: Verify the execution result and the signature receipt.

[0091] In some embodiments, step 107 may specifically include, but is not limited to, at least one of the following: 1) Verify the signature receipt based on the signature verification public key of the target tool; 2) Verify whether the digest of the ciphertext in the signature receipt matches the digest of the ciphertext in the second call request; 3) Verify whether the invocation intent in the signature receipt is consistent with the invocation intent in the second invocation request; 4) Verify that the actual instance of the target tool in the signature receipt matches the target tool; 5) Verify that the digest of the target signature capability list in the signature receipt is consistent with the digest of the target signature capability list in the second call request; 6) Verify whether the identifier of the target invocation operation in the signature receipt is consistent with the identifier of the target invocation operation in the second invocation request; 7) Verify whether the execution result conforms to the response parameter specification corresponding to the target call operation; 8) If the signature verification of the signature receipt passes and all the above verifications pass, the verification of the execution result and the signature receipt is confirmed to be successful.

[0092] Step 108: If the execution result and the signature receipt are verified to be valid, write the execution result into the model context of the large model.

[0093] In some embodiments, in step 108, the execution result is written to the model context of the large model only if all verifications—response decryption, authentication encryption verification, signature receipt verification, request association verification, and output parameter specification verification—pass. If any verification fails, the execution result is refused to be written to the model context to avoid unverified results contaminating subsequent reasoning and decision-making.

[0094] It is understandable that by receiving the sealed response and decrypting the encrypted execution result, as well as performing multi-dimensional verification of the signed receipt, it can be ensured that the execution result does indeed originate from the actual instance of the target tool specified in this call and has not been tampered with. Since the response key and the response base random number are independent of the key and random number of the request direction, direction confusion attacks can be prevented. Since the signed receipt is bound to the request ciphertext digest, execution result digest, call intent, actual instance, actual signature capability list, operation identifier, and execution status, it can prevent forged results from entering the model context, thereby further improving the security of large models calling external tools.

[0095] Figure 5 The illustration shows a flowchart of a tool invocation response method according to an embodiment of this application. This method can be applied to a trusted invocation entry point (hereinafter referred to as the trusted invocation entry point) corresponding to a target tool. The trusted invocation entry point is a trusted component of the target tool that receives external invocation requests. The trusted invocation entry point can communicate with the executor of the target tool, and the trusted invocation entry point operates in a trusted environment.

[0096] like Figure 5 As shown, an embodiment of this application provides a tool invocation response method, which may include: Step 501: Receive a second call request sent by the trusted call wrapper of the large model. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and the information required to decrypt the ciphertext. The second information includes the target call parameters.

[0097] In some embodiments, the second invocation request may be sent from the trusted invocation wrapper to the trusted invocation entry point via an untrusted transport layer. During transmission, intermediate nodes can only obtain the visible header and ciphertext, but cannot know the business plaintext in the ciphertext, nor can they tamper with the visible header or ciphertext without being detected. The visible header only retains the routing and key selection fields and does not contain the business plaintext.

[0098] In some embodiments, the visible header includes fifth and sixth information. The fifth information includes a summary of the target signature capability list, a summary of the parameter specifications, and the intent of this call. The sixth information includes the communication protocol version, the identifier of the cryptographic algorithm suite, the identifier of the target tool, the identifier of the target call operation, the key generation, the key encapsulation value, the request random number for this call, the identifier of the second call request, and the validity period of this call. In some embodiments, the sixth information may also include a temporary public key for the large model.

[0099] Step 502: In a trusted environment, the ciphertext is decrypted according to the information required to decrypt it, to obtain the second information.

[0100] In some embodiments, the trusted invocation entry point first selects the corresponding signature capability list based on the manifest digest in the visible header, selects the corresponding private key based on the key generation, and decrypts it into a protected buffer in a Trusted Execution Environment (TEE) or isolated component. Ordinary executors do not have the address, handle, shared memory mapping, or serialization reference of this buffer at this stage.

[0101] In some embodiments, the trusted call entry point first verifies the second call request based on the fifth information and the sixth information; if the verification is successful, the ciphertext is then decrypted in a trusted environment based on the information required to decrypt the ciphertext to obtain the second information.

[0102] In some embodiments, verifying the second call request based on the fifth information and the sixth information may include: 1) Obtain the target signature capability list based on the digest of the target signature capability list contained in the fifth information.

[0103] 2) Verify whether the target signature capability list is valid and obtain the first verification result; specifically, the signature, validity period, revocation status and key generation of the target signature capability list can be verified to confirm whether the target signature capability list is valid.

[0104] 3) Verify whether the target signature capability list contains the identifier of the target tool and the identifier of the target invocation operation to obtain the second verification result.

[0105] 4) Verify whether the digest of the parameter specification in the target signature capability list is consistent with the digest of the parameter specification in the fifth information, and obtain the third verification result.

[0106] 5) Verify whether the second call request is within the validity period to obtain the fourth verification result.

[0107] 6) If the first verification result, the second verification result, the third verification result, and the fourth verification result are all yes, then the verification of the second call request is determined to be successful.

[0108] In some embodiments, if at least one of the first verification result, the second verification result, the third verification result, and the fourth verification result is negative, it is determined that the verification of the second call request has failed. In the event of verification failure, the trusted call entry point destroys the decrypted content and performs no further operation.

[0109] In some embodiments, decrypting the ciphertext in a trusted environment based on information required to decrypt the ciphertext to obtain the second information may include: 1) Obtain the private key corresponding to the key generation in the sixth information; specifically, the trusted call entry point searches for the corresponding private key in its own secure storage (such as TEE) according to the key generation.

[0110] 2) The private key is used to decapsulate the key encapsulation value in the sixth information to obtain the shared key. Specifically, this step is the receiver's operation in key encapsulation mechanism (KEM) or hybrid public key encryption (HPKE) key negotiation: the trusted call encapsulator encapsulates the key encapsulation value using the target tool's public key on the sending side, and the trusted call entry decapsulates the key encapsulation value using the corresponding private key on the receiving side. Both parties independently calculate the same shared key. Neither the shared key nor the private key is transmitted with the request.

[0111] 3) Derivate the request key based on the shared key and the fourth information, wherein the fourth information includes the invocation intent, the communication protocol version between the trusted invocation wrapper and the trusted invocation entry point, the identifier of the cryptographic algorithm suite supported by the target tool, and the request direction. Specifically, the derivation can be performed using a key derivation function, as shown in the following formula: request_key=KDF(shared_secret,"AI-TOOL-SEAL-v1"||suite_id||I||"request") In this context, `request_key` represents the request key, `shared_secret` represents the shared key, `"AI-TOOL-SEAL-v1"` is a fixed label, `suite_id` represents the identifier of the encryption algorithm suite, `I` represents the invocation intent, and `"request"` represents the request direction label. The request key is independently derived from the trusted invocation entry point and is used to decrypt ciphertext; it is not passed to ordinary executors.

[0112] 4) Generate first authentication association data (AAD) based on the fifth information. Specifically, the first AAD is generated by the specified fields in the fifth information according to the same deterministic encoding rules as the trusted invocation wrapper, and does not need to be sent as an independent field with the second invocation request. The first AAD includes a digest of the target signature capability list, a digest of the parameter specification, and the invocation intent.

[0113] 5) Authenticate and decrypt the ciphertext using the request key and the first AAD to obtain the second information. Specifically, the authentication and decryption can be expressed as: plaintext=AEAD.Open(request_key,request_nonce,ciphertext,AAD) Here, plaintext represents plaintext, AEAD.Open indicates the authentication / decryption operation, request_key represents the request key, request_nonce represents the random number for this request, ciphertext represents ciphertext, and AAD represents authentication-related data. Decryption verification will fail if the visible header, invocation intent I, ciphertext, or AEAD authentication tag is modified.

[0114] Step 503: Send the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target invocation operation.

[0115] In some embodiments, the second information may further include the least privilege credential for this call and the key-holding proof of the large model. The least privilege credential is associated with seventh information, which includes the identifier of the target tool, the identifier of the target call operation, and the target call parameters. The key-holding proof is associated with eighth information, which includes the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key code. The binding of the key-holding proof with the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key code prevents the least privilege credential from being copied or abused across instances.

[0116] Before sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool, Figure 5 The method shown may further include: saving the decrypted second information to a protected buffer, wherein the protected buffer is located in the trusted environment. In this case, a normal executor does not have the address, handle, shared memory mapping, or serialization reference to the buffer, and cannot access it even if the plaintext exists in memory in plaintext form.

[0117] In some embodiments, sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool may include: performing joint verification on the second information; and if the joint verification passes, sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool.

[0118] In some embodiments, if the joint verification fails, the second information stored in the buffer is destroyed and the executor is not invoked.

[0119] In some embodiments, the joint verification of the second information includes at least one of the following: 1) Verify whether the target call parameters conform to the parameter specifications corresponding to the target call operation; 2) Based on the target invocation parameters and the parameter specification, recalculate the parameter digest and verify whether the recalculated parameter digest is consistent with the parameter digest used when generating the invocation intent; 3) Verify that the signature, validity period, and authorization scope of the minimum privilege credential are valid; 4) Verify whether the minimum permission credential is associated with the seventh piece of information; 5) Verify whether the key-holding proof of the large model is valid; 6) Based on the identifier of the target tool, the identifier of the target invocation operation, the digest of the target signature capability list, the parameter digest, and the third information, regenerate the invocation intent, and verify whether the recalculated invocation intent is consistent with the invocation intent in the fifth information, wherein the third information includes: the hash value of the minimum privilege credential, the key digest of the large model, the identifier of the second invocation request, the request random number of this invocation, the validity period of this invocation, and the key generation; 7) Verify whether the request identifier and request random number of the second call request have been used.

[0120] In some embodiments, Figure 5The tool call response method shown may further include: if all joint verifications pass, atomically recording and occupying the request identifier and request random number of the second call request; optionally, if the minimum privilege credential is a one-time or limited-use credential, atomically consuming the minimum privilege credential; and refusing execution if a subsequent call request carrying the same request identifier or the same request random number is received. Here, "atomic" means that the recording and occupation of the request identifier and request random number are indivisible; when two requests simultaneously compete for the same request identifier or request random number, only one can successfully occupy it, and the other will be rejected, thereby preventing concurrent replay attacks.

[0121] In some embodiments, if all joint verifications pass, sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool includes: creating a one-time invocation channel, wherein the one-time invocation channel is bound to the request identifier of the second invocation request, the identifier of the target invocation operation, the identifier of the executor, the number of uses, and the validity period; and sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool through the one-time invocation channel, wherein the one-time invocation channel is destroyed after being successfully used once.

[0122] It is understandable that by creating a one-time call channel and binding the one-time call channel to the request identifier of the second call request, the identifier of the target call operation, the identifier of the executor, the number of uses, and the validity period, the executor can only obtain the verified target call parameters through this channel, and cannot read the protected buffer before verification. Since the one-time call channel is destroyed after successful use, repeated use, timeout use, or use by an incorrect executor will all be rejected. Therefore, even if the executor itself runs untrusted logic, it can only access the plaintext parameters corresponding to this call and this operation, and cannot obtain the global key, the plaintext of other requests, or other credentials. This ensures the controlled release of plaintext parameters while preventing the out-of-bounds reuse of plaintext parameters.

[0123] In some embodiments, a one-time call channel can be implemented using a local remote procedure call (RPC) token, a Unix domain socket, a one-time pipe, an access-controlled shared memory handle, or a trusted execution environment call gate. The executor can only obtain the validated target call parameters through this channel and cannot read the protected buffer before validation. Once the channel's call permission is successfully used once, it is marked as consumed; repeated use, timeout use, or use by an erroneous executor will all be rejected. The original protected buffer is cleared after parameter handover, and the channel is revoked after the call ends. For streaming input, multiple numbered fragments can be transmitted after a successful connection establishment, but these fragments still belong to the same request identifier and the same restricted session.

[0124] It is understandable that by clearing the original protected buffer after parameter handover and revoking the channel after the call ends, it can be ensured that plaintext parameters will not reside in the trusted environment for a long time, further reducing the risk of plaintext parameters being leaked.

[0125] It is also understandable that for streaming input, since multiple numbered fragments can be transmitted after a successful connection is established, and each fragment still belongs to the same request identifier and the same restricted session, the same security constraints as for a single call can be maintained while meeting the requirements of streaming transmission.

[0126] In some embodiments, Figure 5 The tool invocation response method shown may further include: after the executor performs the corresponding operation according to the identifier of the target invocation operation and the target invocation parameters, generating a signature receipt, wherein the signature receipt is associated with tenth information, the tenth information including: a digest of the ciphertext, the invocation intent, the actual instance of the target tool, the target signature capability list, the identifier of the target invocation operation, the execution status of the target invocation operation, and a digest of the execution result; returning a sealed response to the trusted invocation encapsulator, the sealed response including the encrypted execution result and the signature receipt.

[0127] It is understood that by generating a signed receipt after the executor performs an operation, and associating the signed receipt with the digest of the ciphertext, the invocation intent, the actual instance of the target tool, the target signature capability list, the identifier of the target invocation operation, the execution status, and the digest of the execution result, the trusted invocation wrapper can verify that the execution result does indeed originate from the actual instance of the target tool specified in this invocation and has not been tampered with, thereby preventing forged or tampered execution results from polluting the subsequent reasoning and decision-making of the large model.

[0128] In some embodiments, the encrypted execution result is obtained in the following way: Based on the key negotiation context between the trusted call wrapper and the trusted call entry point, a response key is derived using a first purpose label and a second purpose label is derived using a key export interface. The response key and the response base random number are both bound to the call intent and the digest of the ciphertext. The response random number is determined based on the response base random number; The execution result is authenticated and encrypted using the response key, the response random number, and the second AAD to obtain the encrypted execution result. The second AAD is generated based on the ninth information, which includes the request identifier of the second call request, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status, a summary of the response parameter specifications, and a summary of the execution result.

[0129] For example, the key negotiation context can be an HPKE context, the key export interface can be the SecretExport interface of the HPKE context, the first purpose tag can be "response-key", and the second purpose tag can be "response-nonce".

[0130] It is understood that since the response side uses a response key and a response base random number that are independent of the request direction, and both the response key and the response base random number are bound to the call intent and the digest of the ciphertext, it can prevent direction confusion attacks between the request direction and the response direction, and ensure that the response key cannot be reused in the request direction, and the request key cannot be reused in the response direction.

[0131] In the case of non-streaming response, the base random number of the response can be used directly as the response random number, or the response random number can be derived after using a preset derivation rule. In the case of streaming response, a unique response random number can be generated for each fragment of the execution result based on the base random number of the response and an incrementing fragment number, and the fragment number and a termination flag are added to the second AAD.

[0132] It is understandable that, in the case of non-streaming responses, the response base random number can be directly used as the response random number, or the response random number can be derived after being derived through a preset derivation rule. Therefore, the response random number can be flexibly determined according to the actual response type. In the case of streaming responses, since a unique response random number is generated for each fragment based on the response base random number and the incrementing fragment number, and the fragment number and the termination flag are added to the second AAD, it can be ensured that the authentication encryption of each fragment is different, preventing fragments from being rearranged, replaced, or truncated.

[0133] In some embodiments, since the trusted invocation wrapper can also derive response material from the key negotiation context, the authentication encryption verification of the response ciphertext can only prove that the content has not been tampered with, but cannot prove that the result was indeed generated by the target tool. Therefore, the trusted invocation entry point of the target tool should also generate a signed receipt for the request ciphertext digest, response ciphertext or result digest, invocation intent, actual instance, actual signature capability list, operation and status, so that the trusted invocation wrapper will only accept the execution result after the response decryption, authentication encryption verification, signed receipt verification, request association verification and output parameter specification verification have all passed. Therefore, it can make up for the shortcomings of simply relying on authentication encryption to prove the source of the result, and further improve the security of large models calling external tools.

[0134] Figure 5 The tool invocation response method proposed in the illustrated embodiment decrypts the ciphertext in a trusted environment and saves the decrypted second information to a protected buffer, preventing ordinary executors from accessing plaintext parameters before verification is complete. This effectively controls access to and reading of the decrypted plaintext parameters. Furthermore, by performing joint verification on the second information before sending the target invocation operation identifier and target invocation parameters to the executor, and then sending it through a one-time invocation channel after successful joint verification, the method ensures that plaintext parameters are only delivered to the executor after necessary verification, preventing unverified results from contaminating subsequent reasoning and decision-making. In addition, by generating a signed receipt and returning the encrypted execution result through a sealed response, the method ensures that the execution result truly originates from the actual instance of the target tool specified in this invocation and has not been tampered with, thereby improving the security of large models invoking external tools.

[0135] As an example, Figure 6 The plaintext controlled release state machine of the target tool's trusted invocation entry point is shown. For example... Figure 6 As shown, the state machine may include the following stages: Phase R0: Receiving Ciphertext. After receiving the second call request, the trusted invocation entry point only parses the visible header, without performing any business operations or displaying the plaintext business data. At this point, the target tool's executor cannot obtain any business parameters.

[0136] Phase R1: Isolation and Decryption. The trusted entry point decrypts the ciphertext within a trusted environment. The decrypted plaintext is only placed in a protected buffer. Ordinary executors cannot read the handle to this buffer, nor can they access the plaintext content within it.

[0137] Phase R2: Joint Verification. The trusted call entry point performs joint verification on the decrypted second information. The verification content includes at least one of the following: target signature capability list, parameter specifications, call intent, minimum privilege credential, key holding proof of the large model, and validity period.

[0138] Phase R3: Atomic Consumption. After all joint verifications pass, the trusted call entry point atomically acquires the identifier and request random number of the target call operation, and consumes the single-use credential or decrements the count to prevent concurrent replay.

[0139] Phase R4: One-time Release. The trusted invocation entry point creates a one-time restricted channel through which the identifier and parameters of the target invocation operation are transmitted to the executor. The one-time restricted channel is bound to the request identifier, the identifier of the target invocation operation, the executor identifier, the number of uses, and the validity period, and is destroyed after one successful use.

[0140] like Figure 6 As shown, in any of the above stages, if verification fails, fields are inconsistent, privileges are exceeded, or the process expires or is replayed, the process enters the rejection path: the protected buffer is overwritten, the same error code is returned, and the executor of the target tool is not invoked. Specifically, if the joint verification fails, the second information stored in the protected buffer is destroyed, and the executor is not invoked. After the executor completes execution according to the identifier and parameters of the target call operation, the process enters the completion path: the execution result is returned to the trusted call entry point, which encapsulates and seals the response and issues a signature receipt bound to the actual instance. Specifically, the trusted call entry point generates a signature receipt, which is associated with tenth information, including the digest of the ciphertext, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status of the target call operation, and the digest of the call result; and returns a sealed response to the trusted call encapsulator, which includes the encrypted call result and the signature receipt.

[0141] from Figure 6 As can be seen, compared with related technologies, the tool call response method proposed in some embodiments of this application does not involve "decryption first, followed by verification by a normal service," but rather "isolated decryption, full verification, and atomic consumption before establishing a plaintext reachable path." This effectively controls the access and reading of decrypted plaintext parameters, ensuring that plaintext parameters are only delivered to the executor after necessary verification is completed, thereby improving the security of large models calling external tools.

[0142] Figure 7 This diagram illustrates the end-to-end timing flow from the large model to the target tool. (For example...) Figure 7 As shown, the interaction sequence may include the following steps: S701, the large model 83 performs inference, generates and outputs a first invocation request to the trusted invocation wrapper 81. The first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters.

[0143] S702, after receiving the first call request, the trusted call encapsulator 81 verifies the first call request and determines the first information, and then requests the minimum permission credential for this call from the authorization service 85.

[0144] S703, the authorization service 85 issues a minimum privilege credential based on the identity of the large model 83, the task boundary, and the current candidate call, and returns the minimum privilege credential to the trusted call wrapper 81. The minimum privilege credential may be bound to at least one of the following: a summary of the task boundary, an identifier of the target tool, an identifier of the target call operation, a summary of the target call parameters, and a validity period.

[0145] S704, the trusted invocation encapsulator 81 encrypts the second information according to the invocation intent and related security information, generates a second invocation request, and sends the sealed second invocation request to the trusted invocation entry point 82 of the target tool. The second invocation request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target invocation operation, and information required to decrypt the ciphertext.

[0146] S705, the trusted call entry point 82 of the target tool isolates and decrypts the ciphertext in a trusted environment to obtain the second information, and saves the decrypted second information to a protected buffer.

[0147] S706, the trusted invocation entry point 82 of the target tool performs joint verification on the second information. The joint verification includes verifying at least one of the following: the target signature capability list, parameter specifications, invocation intent, minimum privilege credential, key holding proof of the large model, and validity period.

[0148] S707 After the joint verification is passed, the trusted call entry point 82 of the target tool sends the identifier of the target call operation and the target call parameters to the executor 87 of the target tool through the one-time call channel.

[0149] S708, executor 87 performs the corresponding operation according to the identifier of the target call operation, and returns the execution result to the trusted call entry point 82 of the target tool.

[0150] S709, the trusted invocation entry point 82 of the target tool generates a signed receipt and encrypts the execution result to obtain a sealed response, which is then returned to the trusted invocation wrapper 81. The sealed response includes the encrypted execution result and the signed receipt.

[0151] S710, the trusted call encapsulator 81 decrypts and verifies the sealed response. If the verification is successful, the execution result is injected into the model context of the large model 83 for the large model 83 to perform the next round of inference.

[0152] from Figure 7 As can be seen, the end-to-end tool invocation method provided in this application embodiment realizes a complete trusted invocation chain from the inference output of the large model to the injection of the execution result into the model context through the interaction between the large model 83, the trusted invocation encapsulator 81, the authorization service 85, the trusted invocation entry point 82 of the target tool, and the executor 87. Specifically, the trusted invocation encapsulator, as the sole exit point for the large model to initiate invocation requests to external tools, verifies the first invocation request and generates a second invocation request; the authorization service issues a minimum-privilege credential; the trusted invocation entry point, after being isolated, decrypted, and jointly verified in a trusted environment, releases plaintext parameters to the executor through a one-time invocation channel; and the execution result, after being returned with a signed receipt and a sealed response, is verified before being injected into the model context. This enhances the security of the entire process of the large model invoking external tools.

[0153] The following examples illustrate a tool invocation method proposed in this application.

[0154] 1) Customer data inquiry In some embodiments, a user submits a task to the large model to "query customer information for order 123". After performing inference, the large model generates a first invocation request, which includes the identifier of the candidate tool "customer.lookup", the candidate invocation operation "query", and the candidate invocation parameters, which include the fields "name" and "order_status".

[0155] After receiving the first call request, the trusted call wrapper verifies the request based on the task boundary and signature capability list generated by the trusted task boundary generator. The task boundary is limited according to the user's current task: only order query operations are allowed, only order 123 is allowed, and refunds or order modifications are not permitted. The signature capability list only allows the "customer.lookup" tool to perform "query" operations, and only allows the input fields "name" and "order_status".

[0156] The trusted invocation wrapper determines, based on the task boundaries, that the candidate tool "customer.lookup" and the candidate invocation operation "query" are within the allowed task boundary range; it matches the candidate tool "customer.lookup" with the identifiers of external tools in each signature capability list to obtain the target signature capability list; it verifies the signature, validity period, revocation status, and key generation of the target signature capability list; it determines that the candidate invocation operation "query" is within the allowed invocation operation range of the target signature capability list; and it normalizes the candidate invocation parameters according to the parameter specifications in the target signature capability list to obtain normalized parameters, and identifies the external tool corresponding to the target signature capability list as the target tool, the candidate invocation operation as the target invocation operation, and the normalized parameters as the target invocation parameters.

[0157] The trusted invocation wrapper generates an invocation intent based on the target signature capability list and the target invocation parameters. It generates a shared key based on the request encryption public key in the invocation intent and the target signature capability list. It derives a request key based on the shared key and the fourth information. It uses the request key and the first authentication association data to authenticate and encrypt the second information to obtain ciphertext. It generates a second invocation request based on the visible header and the ciphertext and sends the second invocation request to the trusted invocation entry of the target tool.

[0158] If an intermediate node tampers with the second call request, for example, by rewriting the identifier "query" of the target call operation in the visible header to "delete", or rewriting a field in the visible header to "all_fields", or replacing the summary of the signature capability list in the visible header with another version, then the first authentication association data generated by the trusted call entry point of the target tool based on the visible header will change after receiving the second call request. Alternatively, the call intent recalculated based on the call intent in the visible header will be inconsistent with the call intent in the visible header. AEAD authentication decryption or call intent recalculation will fail, and the trusted call entry point of the target tool will not release plaintext, thereby ensuring the security of customer data query.

[0159] 2) Refund tools In some embodiments, a user submits a task to the large model to "refund 100 yuan for order 456". After performing inference, the large model generates a first invocation request, which includes the identifier of the candidate tool "payment.refund", the candidate invocation operation "refund", and the candidate invocation parameters, including the order identifier "456", the refund amount "100", and the currency "CNY".

[0160] The trusted invocation wrapper verifies the first invocation request based on the task boundaries and signature capability list. Upon successful verification, it determines the target tool "payment.refund", the target invocation operation "refund", and the target invocation parameters, and generates an invocation intent, requesting the minimum permission credential for this invocation from the authorization service. The authorization service issues the minimum permission credential based on the identity of the overall model, the task boundaries, and this candidate invocation. This minimum permission credential is bound to the order summary, the maximum refund amount, the currency, the tenant, and the operation identifier "refund".

[0161] The trusted invocation wrapper encrypts the second information, generates a second invocation request, and sends the second invocation request to the trusted invocation entry point of the target tool. The second information includes the target invocation parameters, the minimum privilege credential, and the key holding proof of the large model.

[0162] If the large model is flagged for an injection attack during subsequent inference, such as rewriting the candidate call operation from "refund" to "transfer" or increasing the refund amount in the candidate call parameters from "100" to "10000", the trusted call wrapper will detect during the verification phase that the candidate call operation "transfer" is not within the range of call operations allowed by the signature capability list, or that the normalized target call parameters are inconsistent with the maximum refund amount bound to the minimum privilege credential. The joint verification will fail, the minimum privilege credential will not be consumed, the refund operation will not be executed, and the refund result will not enter the model context of the large model.

[0163] 3) Code execution tools In some embodiments, the user submits a task to the large model to "execute a test on code repository 789". After the large model performs inference, it generates a first invocation request, which includes the identifier of the candidate tool "code.execute", the candidate invocation operation "test", and the candidate invocation parameters, including the code repository identifier "789" and the command "run_test".

[0164] The trusted invocation wrapper verifies the first invocation request based on the task boundary and the signature capability list. Upon successful verification, it determines the target tool "code.execute", the target invocation operation "test", and the target invocation parameters, generates an invocation intent, encrypts the second information, generates a second invocation request, and sends the second invocation request to the trusted invocation entry point of the target tool. The signature capability list is bound to a read-only repository, command template, runtime image, and resource limits.

[0165] The trusted entry point of the target tool isolates and decrypts the ciphertext in a trusted environment, and saves the decrypted second information to a protected buffer. After joint verification passes, the trusted entry point creates a one-time call channel, releasing the normalized command "run_test" only to the restricted executor. The executor executes the corresponding operation according to the identifier "test" of the target call operation and returns the execution result to the trusted entry point. The trusted entry point generates a signed receipt, which is associated with the digest of the ciphertext, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status, and the digest of the execution result, and returns a sealed response to the trusted call wrapper.

[0166] If the executor forges a "test successful" execution result, since the signature receipt is bound to the actual execution instance, and the trusted call encapsulator decrypts and verifies the sealed response, it will verify whether the actual instance in the signature receipt is consistent with the target tool and whether the execution result conforms to the response parameter specification. The forged execution result will fail the verification and thus cannot enter the model context of the large model.

[0167] The above describes a tool invocation method proposed in this application. Corresponding to the above-described tool invocation method, embodiments of this application also propose a tool invocation device, which will be briefly described below.

[0168] like Figure 8 As shown in the embodiment of this application, a tool invocation system 800 is also proposed. The system 800 may include: a trusted invocation encapsulator 81 and a trusted invocation entry point 82 for the target tool, wherein the trusted invocation encapsulator 81 is the only exit point for the large model to initiate an invocation request to an external tool.

[0169] A trusted invocation encapsulator 81 is configured to receive a first invocation request output by the large model, wherein the first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters; verify the first invocation request, and determine first information if the verification is successful, wherein the first information includes the identifier of the target tool invoked by the first invocation request, the identifier of the target invocation operation, and the target invocation parameters; encrypt the second information and generate a second invocation request, wherein the second invocation request includes a visible header and ciphertext corresponding to the second information, the visible header including the identifier of the target tool, the identifier of the target invocation operation, and information required to decrypt the ciphertext, and the second information including the target invocation parameters; and send the second invocation request to the trusted invocation entry point corresponding to the target tool.

[0170] The trusted invocation entry 82 of the target tool is used to receive the second invocation request; decrypt the ciphertext in a trusted environment according to the information required to decrypt the ciphertext to obtain the second information; and send the identifier of the target invocation operation in the visible header and the target invocation parameters in the second information to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target invocation operation.

[0171] In some embodiments, the trusted invocation wrapper 81 can be used to execute a tool invocation method proposed in the embodiments of this application, such as... Figure 1 or Figure 4 The method shown; the trusted invocation entry point 82 of the target tool can be used to execute a tool invocation response method proposed in the embodiments of this application, such as Figure 5 The method shown achieves the same technical effect, and will not be elaborated further.

[0172] In some embodiments, such as Figure 9 As shown, the tool invocation system 800 proposed in this application embodiment includes, in addition to a trusted invocation encapsulator 81 and a trusted invocation entry point 82 for the target tool, a large model 83, a trusted registry for external tools 84, an authorization service 85, an untrusted intermediate node 86, an executor for the target tool 87, and a result acceptance module 811.

[0173] Large model 83 is used to generate the first call request and output the first call request to the trusted call wrapper 81.

[0174] The trust registry 84 for external tools is used to store and manage a list of signature capabilities of external tools. The list of signature capabilities includes the identifier of the external tool, the identifier of at least one call operation allowed by the external tool, the parameter specifications of the external tool, and related security information.

[0175] Authorization service 85 is used to issue a minimum permission credential based on the identity, task boundary and current candidate call of large model 83, and provide the minimum permission credential to trusted call wrapper 81.

[0176] An untrusted intermediate node 86 is used to forward a second call request between the trusted call encapsulator 81 and the trusted call entry point 82 of the target tool. The untrusted intermediate node 86 can only obtain the visible header and ciphertext in the second call request, but cannot obtain the business plaintext.

[0177] The executor 87 of the target tool is used to receive the identifier of the target call operation and the target call parameters sent by the trusted call entry 82 of the target tool through a one-time call channel, execute the corresponding operation according to the identifier of the target call operation, and return the execution result to the trusted call entry 82 of the target tool.

[0178] The result acceptance module 811 is used to receive the sealed response returned by the trusted call entry 82 of the target tool, decrypt and verify the sealed response, and write the call result in the sealed response into the model context of the large model 83 if the verification is successful.

[0179] In some embodiments, the trusted invocation entry 82 of the target tool is further configured to generate a signature receipt 88 after the executor 87 of the target tool has finished executing, and return a sealed response including the encrypted execution result and the signature receipt 88 to the trusted invocation encapsulator 81.

[0180] In some embodiments, the trusted invocation wrapper 81 can be used to execute a tool invocation method proposed in the embodiments of this application, such as... Figure 1 or Figure 4 The method shown; the trusted invocation entry point 82 of the target tool can be used to execute a tool invocation response method proposed in the embodiments of this application, such as Figure 5 The method shown; the large model 83, the trust registry of external tools 84, the authorization service 85, the untrusted intermediate node 86, the executor of the target tool 87, and the result acceptance module 811 can be used to execute the corresponding steps in the embodiments of this application and achieve the same technical effect, which will not be described in detail here.

[0181] Corresponding to the method embodiments described above, this application also proposes a corresponding virtual device, which will be briefly described below.

[0182] Figure 10 This is a schematic diagram of a tool invocation device 1000 according to an embodiment of this application. The tool invocation device 1000 can be applied to a trusted invocation wrapper for large models. Please refer to... Figure 10 In one software implementation, the tool invocation device 1000 may include: a first receiving module 1001, a first determining module 1002, a first encapsulation module 1003, and a first sending module 1004.

[0183] The first receiving module 1001 is used to receive the first call request output by the large model, wherein the first call request includes the identifier of the candidate tool to be called, the candidate call operation, and the candidate call parameters.

[0184] In some embodiments, the large model can be a standalone AI large model or a large model embedded in an intelligent agent as the core of inference. A candidate tool refers to an external tool that the large model initially proposes to invoke based on the user task; a candidate invocation operation refers to the specific operation that the large model proposes to perform on the candidate tool; and candidate invocation parameters refer to the parameter content used by the large model when proposing to execute the candidate invocation operation.

[0185] In some embodiments, the first invocation request may include multiple candidate tools, multiple candidate invocation operations, and / or corresponding candidate invocation parameters.

[0186] The first determining module 1002 is used to verify the first call request and determine first information if the verification is successful. The first information includes the identifier of the target tool that the first call request can call, the identifier of the target call operation, and the target call parameters.

[0187] In some embodiments, the first determining module 1002 may be specifically used to: verify the first invocation request based on the task boundary generated by the trusted task boundary generator and the signature capability list of at least one external tool, and determine first information if the verification is successful, wherein the signature capability list of the external tool includes the identifier of the external tool, the identifier of at least one invocation operation allowed by the external tool, the parameter specification of the external tool, and related security information.

[0188] In some embodiments, the first determining module 1002 may specifically be used to: determine whether the identifier of the candidate tool and the candidate invocation operation are within the allowed task boundary range based on the task boundary; match the identifier of the candidate tool with the identifiers of external tools in the signature capability list of each external tool to obtain a target signature capability list that matches the identifier of the candidate tool; verify the signature, validity period, revocation status, and key generation of the target signature capability list based on the relevant security information in the target signature capability list; determine whether the candidate invocation operation is within the range of at least one invocation operation allowed by the target signature capability list; normalize the candidate invocation parameters according to the parameter specifications in the target signature capability list to obtain normalized parameters; and determine that the verification is successful when the identifier of the candidate tool and the candidate invocation operation are within the allowed task boundary range, the candidate invocation operation is within the range of invocation operations allowed by the target signature capability list, the signature, validity period, revocation status, and key generation of the target signature capability list are verified, and the normalized parameters are obtained.

[0189] In some embodiments, the first determining module 1002 may be specifically used to: determine the external tool corresponding to the target signature capability list as the target tool, determine the candidate invocation operation as the target invocation operation, and determine the normalized parameter as the target invocation parameter, if the verification is successful.

[0190] The first encapsulation module 1003 is used to encrypt the second information and generate a second call request. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and information required to decrypt the ciphertext. The second information includes the target call parameters.

[0191] In some embodiments, the first encapsulation module 1003 can also be used to: generate a call intent based on the target signature capability list and the first information before encrypting the second information. Specifically, a parameter digest is generated based on the parameter specifications in the target signature capability list and the target call parameters; the call intent is generated based on the identifier of the target tool, the identifier of the target call operation, the digest of the target signature capability list, the parameter digest, and third information, wherein the third information includes: the hash value of the minimum permission credential for this call, the key digest of the large model, the identifier of the first call request, the request random number for this call, the validity period of this call, and the key generation.

[0192] In some embodiments, the first encapsulation module 1003 can be specifically used to: generate a shared key based on the request encryption public key in the relevant security information of the target signature capability list; derive a request key based on the shared key and fourth information, wherein the fourth information includes the call intent, the communication protocol version between the trusted call encapsulator and the trusted call entry, the identifier of the encryption algorithm suite supported by the target tool, and the request direction; use the request key and first authentication association data (AAD) to perform authentication encryption with association data on the second information to obtain the ciphertext, wherein the first AAD is generated based on fifth information, the fifth information including the digest of the target signature capability list, the digest of the parameter specification, and the call intent; encapsulate the fifth information and the sixth information to obtain the visible header, wherein the sixth information includes the communication protocol version, the identifier of the encryption algorithm suite, the identifier of the target tool, the identifier of the target call operation, the key generation, the key encapsulation value, the request random number of this call, the identifier of the second call request, and the validity period of this call; encapsulate the visible header and the ciphertext to obtain the second call request.

[0193] In some embodiments, the second information further includes the least privilege credential for this call and the key holding proof of the large model. The least privilege credential is associated with seventh information, which includes the identifier of the target tool, the identifier of the target call operation, and the target call parameters. The key holding proof is associated with eighth information, which includes the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key code. The key holding proof is used to bind the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key code to prevent the least privilege credential from being copied or abused across instances.

[0194] In some embodiments, the second information further includes the minimum privilege credential for this call and the key holding proof of the large model, wherein the minimum privilege credential is associated with seventh information, the seventh information including the identifier of the target tool, the identifier of the target call operation, and the target call parameters, and the key holding proof is associated with eighth information, the eighth information including the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key generation.

[0195] The first sending module 1004 is used to send the second call request to the trusted call entry corresponding to the target tool, wherein the trusted call entry is used to decrypt the ciphertext in a trusted environment and send the identifier of the target call operation obtained from the visible header and the decrypted target call parameters to the executor of the target tool.

[0196] Figure 10 The tool calling device 1000 shown can realize Figure 1 This demonstrates a tool invocation method that achieves the same technical effect; related aspects can be referenced from each other.

[0197] like Figure 11 As shown, the tool calling device 1000 proposed in this application may further include a second receiving module 1005, a first decryption module 1006, a first verification module 1007, and a first writing module 1008.

[0198] The second receiving module 1005 is used to receive the sealed response returned by the trusted call entry point. The sealed response includes the encrypted execution result and the signature receipt. The signature receipt is associated with the tenth information, which includes: the digest of the ciphertext, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status of the target call operation, and the digest of the execution result.

[0199] The first decryption module 1006 is used to decrypt the sealing response to obtain the execution result.

[0200] In some embodiments, the first decryption module 1006 may specifically be used to: derive a response key using a first purpose tag and a response base random number using a second purpose tag, based on the key negotiation context between the trusted call encapsulator and the trusted call entry point, through a key export interface; determine a response random number based on the response base random number; generate second authentication association data (AAD) based on ninth information, wherein the ninth information includes the request identifier of the second call request, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status, a summary of the response parameter specification, and a summary of the execution result; and authenticate and decrypt the encrypted execution result using the response key, the response random number, and the second AAD to obtain the execution result.

[0201] The first verification module 1007 is used to verify the execution result and the signature receipt.

[0202] In some embodiments, the first verification module 1007 may be specifically used to perform at least one of the following: 1) Verify the signature receipt based on the signature verification public key of the target tool; 2) Verify whether the digest of the ciphertext in the signature receipt matches the digest of the ciphertext in the second call request; 3) Verify whether the invocation intent in the signature receipt is consistent with the invocation intent in the second invocation request; 4) Verify that the actual instance of the target tool in the signature receipt matches the target tool; 5) Verify that the digest of the target signature capability list in the signature receipt is consistent with the digest of the target signature capability list in the second call request; 6) Verify whether the identifier of the target invocation operation in the signature receipt is consistent with the identifier of the target invocation operation in the second invocation request; 7) Verify whether the execution result conforms to the response parameter specification corresponding to the target call operation; 8) If the signature verification of the signature receipt passes and all the above verifications pass, the verification of the execution result and the signature receipt is confirmed to be successful.

[0203] The first writing module 1008 is used to write the execution result into the model context of the large model if the execution result and the signature receipt are verified to be valid.

[0204] In some embodiments, the first writing module 1008 only writes the execution result to the model context of the large model if all verifications—response decryption, authentication encryption verification, signature receipt verification, request association verification, and output parameter specification verification—pass. If any verification fails, the execution result is refused to be written to the model context to avoid unverified results contaminating subsequent reasoning and decision-making.

[0205] Figure 11 The tool calling device 1000 shown can realize Figure 4 This demonstrates a tool invocation method that achieves the same technical effect; related aspects can be referenced from each other.

[0206] Figure 12 This is a schematic diagram of a tool invocation response device 1200 provided in one embodiment of this application. The tool invocation response device 1200 can be applied to a trusted invocation entry point for a target tool. Please refer to... Figure 12 In one software implementation, the tool call response device 1200 may include: a third receiving module 1201, a second decryption module 1202, and a second sending module 1203.

[0207] The third receiving module 1201 is used to receive a second call request sent by the trusted call encapsulator of the large model. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and the information required to decrypt the ciphertext. The second information includes the target call parameters.

[0208] In some embodiments, the visible header includes fifth information and sixth information. The fifth information includes a summary of the target signature capability list, a summary of the parameter specification, and the call intent of this call. The sixth information includes the communication protocol version, the identifier of the encryption algorithm suite, the identifier of the target tool, the identifier of the target call operation, the key generation, the key encapsulation value, the request random number of this call, the identifier of the second call request, and the validity period of this call.

[0209] The second decryption module 1202 is used to decrypt the ciphertext in a trusted environment according to the information required to decrypt the ciphertext, and obtain the second information.

[0210] In some embodiments, the second decryption module 1202 may be specifically used to: verify the second call request according to the fifth information and the sixth information; and if the verification is successful, decrypt the ciphertext in a trusted environment according to the information required to decrypt the ciphertext to obtain the second information.

[0211] In some embodiments, the second decryption module 1202 may specifically be used to: obtain the target signature capability list based on the digest of the target signature capability list contained in the fifth information; verify whether the target signature capability list is valid to obtain a first verification result; verify whether the target signature capability list contains the identifier of the target tool and the identifier of the target invocation operation to obtain a second verification result; verify whether the digest of the parameter specification in the target signature capability list is consistent with the digest of the parameter specification in the fifth information to obtain a third verification result; verify whether the second invocation request is within the validity period to obtain a fourth verification result; and determine that the verification of the second invocation request is passed if the first verification result, the second verification result, the third verification result, and the fourth verification result are all yes.

[0212] In some embodiments, the second decryption module 1202 may specifically be used to: obtain a private key corresponding to the key generation in the sixth information; decapsulate the key encapsulation value in the sixth information using the private key to obtain a shared key; perform key derivation based on the shared key and the fourth information to obtain a request key, wherein the fourth information includes the invocation intent, the communication protocol version between the trusted invocation encapsulator and the trusted invocation entry point, the identifier of the encryption algorithm suite supported by the target tool, and the request direction; generate first authentication association data (AAD) based on the fifth information; and authenticate and decrypt the ciphertext using the request key and the first AAD to obtain the second information.

[0213] In some embodiments, the second decryption module 1202 may also be used to: save the decrypted second information to a protected buffer, wherein the protected buffer is located in the trusted environment.

[0214] The second sending module 1203 is used to send the identifier of the target call operation and the target call parameters to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target call operation.

[0215] In some embodiments, the second sending module 1203 may be specifically used to: perform joint verification on the second information; and if the joint verification passes, send the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool.

[0216] In some embodiments, the second sending module 1203 may specifically be used to perform at least one of the following joint verifications: verifying whether the target invocation parameters conform to the parameter specification corresponding to the target invocation operation; recalculating the parameter digest according to the target invocation parameters and the parameter specification, and verifying whether the recalculated parameter digest is consistent with the parameter digest used when generating the invocation intent; verifying whether the signature, validity period, and authorization scope of the least privilege credential are valid; verifying whether the least privilege credential is associated with the seventh information; verifying whether the key holding proof of the large model is valid; regenerating the invocation intent according to the identifier of the target tool, the identifier of the target invocation operation, the digest of the target signature capability list, the parameter digest, and the third information, and verifying whether the recalculated invocation intent is consistent with the invocation intent in the fifth information; verifying whether the request identifier and request random number of the second invocation request have been used.

[0217] In some embodiments, the second sending module 1203 may also be used to: atomically record and occupy the request identifier and request random number of the second call request if all the joint verifications pass; and refuse to execute if a call request carrying the same request identifier or the same request random number is subsequently received.

[0218] In some embodiments, the second sending module 1203 may be specifically used to: create a one-time call channel, wherein the one-time call channel is bound to the request identifier of the second call request, the identifier of the target call operation, the identifier of the executor, the number of uses, and the validity period; and send the identifier of the target call operation and the target call parameters to the executor of the target tool through the one-time call channel, wherein the one-time call channel is destroyed after being successfully used once.

[0219] In some embodiments, the tool invocation response device 1200 may further include: a signature receipt generation module, configured to generate a signature receipt after the executor performs the corresponding operation according to the identifier of the target invocation operation and the target invocation parameters, wherein the signature receipt is associated with tenth information, the tenth information including: a digest of the ciphertext, the invocation intent, the actual instance of the target tool, the target signature capability list, the identifier of the target invocation operation, the execution status of the target invocation operation, and a digest of the execution result; and a sealed response sending module, configured to return a sealed response to the trusted invocation encapsulator, the sealed response including the encrypted execution result and the signature receipt.

[0220] In some embodiments, the encrypted execution result is obtained as follows: based on the key negotiation context between the trusted call wrapper and the trusted call entry point, a response key is derived using a first purpose tag and a response base random number is derived using a second purpose tag through the key export interface, wherein both the response key and the response base random number are bound to the call intent and the digest of the ciphertext; a response random number is determined based on the response base random number; the execution result is authenticated and encrypted using the response key, the response random number, and the second AAD to obtain the encrypted execution result, wherein the second AAD is generated based on the ninth information, the ninth information including the request identifier of the second call request, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status, the digest of the response parameter specification, and the digest of the execution result.

[0221] Figure 12 The tool call response device 1200 shown can realize Figure 5 The tool shown calls a response method and achieves the same technical effect; related aspects can be referenced from each other.

[0222] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0223] Figure 13 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 13 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0224] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 13 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0225] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0226] The processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming a tool invocation device at the logical level. The processor executes the program stored in memory and specifically performs a tool invocation method or a tool invocation response method proposed in the embodiments of this application, achieving the same technical effect.

[0227] The above is as stated in this application. Figure 13The method executed by the tool invocation device or a tool invocation response device disclosed in the illustrated embodiments can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0228] The electronic device can also perform Figure 1 , Figure 4 or Figure 5 The method, and implement the tool calling device in Figure 1 , Figure 4 or Figure 5 The functions described in the illustrated embodiments will not be repeated here.

[0229] Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0230] This application also proposes a computer-readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform actions such as... Figure 1 , Figure 4 or Figure 5 The method described.

[0231] This application also proposes a computer program product, characterized in that the program product is stored in a storage medium and is executed by at least one processor to achieve the following: Figure 1 , Figure 4 or Figure 5 The method described.

[0232] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0233] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0234] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0235] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0236] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

Claims

1. A method for invoking a tool, characterized in that, Applied to a trusted invocation wrapper, which is the sole exit point for a large model to initiate invocation requests to external tools, the method includes: Receive the first invocation request output by the large model, wherein the first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters; The first call request is verified, and if the verification is successful, the first information is determined, wherein the first information includes the identifier of the target tool that the first call request can call, the identifier of the target call operation, and the target call parameters; The second information is encrypted, and a second call request is generated. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and the information required to decrypt the ciphertext. The second information includes the target call parameters. The second call request is sent to the trusted call entry corresponding to the target tool, wherein the trusted call entry is used to decrypt the ciphertext in a trusted environment and send the identifier of the target call operation obtained from the visible header and the decrypted target call parameters to the executor of the target tool.

2. The method as described in claim 1, characterized in that, The step of verifying the first call request and determining the first information if the verification is successful includes: The first invocation request is verified based on the task boundary generated by the trusted task boundary generator and the signature capability list of at least one external tool. If the verification is successful, first information is determined. The signature capability list of the external tool includes the identifier of the external tool, the identifier of at least one invocation operation allowed by the external tool, the parameter specification of the external tool, and related security information.

3. The method according to claim 2, characterized in that, The verification of the first invocation request based on the task boundary generated by the trusted task boundary generator and the signature capability list of at least one external tool includes: Based on the task boundary, determine whether the identifier of the candidate tool and the candidate invocation operation are within the allowed task boundary range; The identifiers of the candidate tools are matched with the identifiers of the external tools in the signature capability list of each external tool to obtain a target signature capability list that matches the identifiers of the candidate tools. Based on the relevant security information in the target signature capability list, the signature, validity period, revocation status, and key generation of the target signature capability list are verified; Determine whether the candidate invocation operation falls within the scope of at least one invocation operation permitted by the target signature capability list; Based on the parameter specifications in the target signature capability list, the candidate call parameters are normalized to obtain normalized parameters; If the candidate tool's identifier and the candidate invocation operation are within the allowed task boundary, the candidate invocation operation is within the allowed invocation operation range of the target signature capability list, the signature, validity period, revocation status, and key generation of the target signature capability list are verified, and the normalized parameters are obtained, then the verification is deemed successful.

4. The method according to claim 3, characterized in that, The determination of the first information upon successful verification includes: If the verification is successful, the external tool corresponding to the target signature capability list is identified as the target tool, the candidate invocation operation is identified as the target invocation operation, and the normalized parameter is identified as the target invocation parameter.

5. The method according to claim 4, characterized in that, Before encrypting the second information and generating the second call request, the method further includes: Based on the target signature capability list and the first information, a call intent is generated.

6. The method according to claim 5, characterized in that, The step of generating a call intent based on the target signature capability list and the first information includes: Generate a parameter digest based on the parameter specifications in the target signature capability list and the target call parameters; The invocation intent is generated based on the identifier of the target tool, the identifier of the target invocation operation, the digest of the target signature capability list, the parameter digest, and the third information. The third information includes: the hash value of the minimum permission credential for this invocation, the key digest of the large model, the identifier of the first invocation request, the request random number for this invocation, the validity period of this invocation, and the key generation.

7. The method according to claim 5, characterized in that, The step of encrypting the second information and generating a second call request includes: Based on the invocation intent and the relevant security information corresponding to the target tool, the second information is encrypted, and a second invocation request is generated.

8. The method according to claim 7, characterized in that, The step of encrypting the second information and generating a second invocation request based on the invocation intent and the relevant security information corresponding to the target tool includes: Generate a shared key based on the requested encryption public key in the relevant security information of the target signature capability list; The request key is derived based on the shared key and the fourth information, wherein the fourth information includes the invocation intent, the communication protocol version between the trusted invocation wrapper and the trusted invocation entry, the identifier of the cryptographic algorithm suite supported by the target tool, and the request direction; Using the request key and the first authentication association data AAD, the second information is encrypted with authentication data to obtain the ciphertext. The first authentication association data AAD is generated based on the fifth information, which includes a digest of the target signature capability list, a digest of the parameter specification, and the invocation intent. The fifth and sixth information are encapsulated to obtain the visible header, wherein the sixth information includes the communication protocol version, the identifier of the encryption algorithm suite, the identifier of the target tool, the identifier of the target call operation, the key generation, the key encapsulation value, the request random number of this call, the identifier of the second call request, and the validity period of this call; The visible header and the ciphertext are encapsulated to obtain the second invocation request.

9. The method according to any one of claims 5-8, characterized in that, The second information also includes the minimum privilege credential for this call and the key holding proof of the large model. The minimum privilege credential is associated with the seventh information, which includes the identifier of the target tool, the identifier of the target call operation, and the target call parameters. The key holding proof is associated with the eighth information, which includes the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key generation.

10. The method according to any one of claims 5-8, characterized in that, The method further includes: The system receives a sealed response returned by the trusted invocation entry point. The sealed response includes an encrypted execution result and a signature receipt. The signature receipt is associated with tenth information, which includes: a digest of the ciphertext, the invocation intent, the actual instance of the target tool, a list of the target signature capabilities, an identifier of the target invocation operation, the execution status of the target invocation operation, and a digest of the execution result. The sealing response is decrypted to obtain the execution result; Verify the execution result and the signature receipt; If the execution result and the signature receipt are verified to be valid, the execution result is written into the model context of the large model.

11. The method according to claim 10, characterized in that, The process of decrypting the sealing response to obtain the execution result includes: Based on the key negotiation context between the trusted call encapsulator and the trusted call entry point, a response key is derived using a first purpose label and a response base random number is derived using a second purpose label through the key export interface. Both the response key and the response base random number are bound to the digest of the ciphertext of the call intent and the second call request. The response random number is determined based on the response base random number; The second authentication association data (AAD) is generated based on the ninth information, wherein the ninth information includes the request identifier of the second invocation request, the invocation intent, the actual instance of the target tool, the target signature capability list, the identifier of the target invocation operation, the execution status, a summary of the response parameter specifications, and a summary of the execution result; The encrypted execution result is authenticated and decrypted using the response key, the response random number, and the second authentication association data (AAD) to obtain the execution result.

12. A tool call response method, characterized in that, The method, which applies to a trusted invocation entry point for the target tool, includes: Receive a second call request sent by the trusted call encapsulator of the large model. The second call request includes a visible header and ciphertext corresponding to the second information. The visible header includes the identifier of the target tool, the identifier of the target call operation, and the information required to decrypt the ciphertext. The second information includes the target call parameters. In a trusted environment, the ciphertext is decrypted according to the information required to decrypt it, to obtain the second information; The identifier of the target invocation operation and the target invocation parameters are sent to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target invocation operation.

13. The method according to claim 12, characterized in that, The visible header includes a fifth piece of information and a sixth piece of information. The fifth piece of information includes a summary of the target signature capability list, a summary of the parameter specifications, and the intent of this call. The sixth piece of information includes the communication protocol version, the identifier of the encryption algorithm suite, the identifier of the target tool, the identifier of the target call operation, the key generation, the key encapsulation value, the request random number of this call, the identifier of the second call request, and the validity period of this call. The step of decrypting the ciphertext in a trusted environment based on the information required to decrypt the ciphertext, to obtain the second information, includes: Based on the fifth and sixth information, the second call request is verified. If the verification is successful, the ciphertext is decrypted in a trusted environment according to the information required to decrypt the ciphertext, and the second information is obtained.

14. The method according to claim 13, characterized in that, The step of verifying the second call request based on the fifth and sixth information includes: The target signature capability list is obtained based on the digest of the target signature capability list contained in the fifth information; Verify the validity of the target signature capability list to obtain the first verification result; Verify whether the target signature capability list contains the identifier of the target tool and the identifier of the target invocation operation to obtain a second verification result; The third verification result is obtained by verifying whether the digest of the parameter specification in the target signature capability list is consistent with the digest of the parameter specification in the fifth information. Verify whether the second call request is within its validity period to obtain the fourth verification result; If the first verification result, the second verification result, the third verification result, and the fourth verification result are all yes, then the verification of the second call request is determined to be successful.

15. The method according to claim 13, characterized in that, The step of decrypting the ciphertext in a trusted environment based on the information required to decrypt the ciphertext, to obtain the second information, includes: Based on the key generation in the sixth information, obtain the private key corresponding to the key generation; The shared key is obtained by decapsulating the key encapsulation value in the sixth information using the private key. Based on the shared key and the fourth information, a key is derived to obtain the request key, wherein the fourth information includes the invocation intent, the communication protocol version between the trusted invocation wrapper and the trusted invocation entry, the identifier of the cryptographic algorithm suite supported by the target tool, and the request direction; Generate first authentication association data AAD based on the fifth information; The ciphertext is authenticated and decrypted using the request key and the first authentication association data (AAD) to obtain the second information.

16. The method according to claim 13, characterized in that, The second information also includes the minimum privilege credential for this call and the key holding proof of the large model. The minimum privilege credential is associated with the seventh information, which includes the identifier of the target tool, the identifier of the target call operation, and the target call parameters. The key holding proof is associated with the eighth information, which includes the request identifier of the second call request, the call intent, the digest of the ciphertext, and the key generation.

17. The method according to claim 16, characterized in that, Before sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool, the method further includes: The decrypted second information is saved to a protected buffer, wherein the protected buffer is located in the trusted environment.

18. The method according to claim 17, characterized in that, The step of sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool includes: Perform joint verification on the second information; If the joint verification passes, the identifier of the target invocation operation and the target invocation parameters are sent to the executor of the target tool.

19. The method according to claim 18, characterized in that, The joint verification of the second information includes at least one of the following: Verify whether the target call parameters conform to the parameter specification corresponding to the target call operation; Based on the target invocation parameters and the parameter specification, recalculate the parameter digest and verify whether the recalculated parameter digest is consistent with the parameter digest used when generating the invocation intent; Verify the validity of the signature, validity period, and authorization scope of the minimum privilege credential; Verify whether the minimum permission credential is associated with the seventh information; Verify whether the key-holding proof of the large model is valid; Based on the identifier of the target tool, the identifier of the target invocation operation, the digest of the target signature capability list, the parameter digest, and the third information, the invocation intent is regenerated, and it is verified whether the recalculated invocation intent is consistent with the invocation intent in the fifth information. The third information includes: the hash value of the minimum privilege credential, the key digest of the large model, the identifier of the second invocation request, the request random number of this invocation, the validity period of this invocation, and the key generation. Verify whether the request identifier and request random number of the second call request have been used.

20. The method according to claim 18, characterized in that, The method further includes: If all joint verifications pass, the request identifier and request random number of the second call request are recorded and occupied atomically; If a subsequent call request carrying the same request identifier or the same request random number is received, execution will be refused.

21. The method according to claim 18, characterized in that, The step of sending the identifier of the target invocation operation and the target invocation parameters to the executor of the target tool, provided that all joint verifications pass, includes: Create a one-time call channel, which is bound to the request identifier of the second call request, the identifier of the target call operation, the identifier of the executor, the number of uses, and the validity period; The one-time call channel sends the identifier of the target call operation and the target call parameters to the executor of the target tool. The one-time call channel is destroyed after being successfully used once.

22. The method according to any one of claims 13-21, characterized in that, The method further includes: After the executor performs the corresponding operation according to the identifier of the target invocation operation and the target invocation parameters, a signature receipt is generated. The signature receipt is associated with tenth information, which includes: a digest of the ciphertext, the invocation intent, the actual instance of the target tool, the target signature capability list, the identifier of the target invocation operation, the execution status of the target invocation operation, and a digest of the execution result. A sealed response is returned to the trusted caller, the sealed response including the encrypted execution result and the signed receipt.

23. The method according to claim 22, characterized in that, The encrypted execution result is obtained in the following way: Based on the key negotiation context between the trusted call wrapper and the trusted call entry point, a response key is derived using a first purpose label and a second purpose label is derived using a key export interface. The response key and the response base random number are both bound to the call intent and the digest of the ciphertext. The response random number is determined based on the response base random number; The execution result is authenticated and encrypted using the response key, the response random number, and the second authentication association data (AAD) to obtain the encrypted execution result. The second authentication association data (AAD) is generated based on the ninth information, which includes the request identifier of the second call request, the call intent, the actual instance of the target tool, the target signature capability list, the identifier of the target call operation, the execution status, a summary of the response parameter specifications, and a summary of the execution result.

24. A tool invocation system, characterized in that, The system includes a trusted invocation wrapper and a trusted invocation entry point corresponding to the target tool. The trusted invocation wrapper is the sole exit point for the large model to initiate invocation requests to external tools, wherein: The trusted invocation encapsulator is configured to receive a first invocation request output by the large model, wherein the first invocation request includes the identifier of the candidate tool to be invoked, the candidate invocation operation, and the candidate invocation parameters; verify the first invocation request, and if the verification is successful, determine first information, wherein the first information includes the identifier of the target tool that the first invocation request can invoke, the identifier of the target invocation operation, and the target invocation parameters; encrypt the second information and generate a second invocation request, wherein the second invocation request includes a visible header and ciphertext corresponding to the second information, the visible header including the identifier of the target tool, the identifier of the target invocation operation, and information required to decrypt the ciphertext, and the second information including the target invocation parameters; and send the second invocation request to the trusted invocation entry point corresponding to the target tool. The trusted invocation entry point is used to receive the second invocation request; decrypt the ciphertext in a trusted environment according to the information required to decrypt the ciphertext to obtain the second information; and send the identifier of the target invocation operation in the visible header and the target invocation parameters in the second information to the executor of the target tool, wherein the executor is used to perform the corresponding operation according to the identifier of the target invocation operation.

25. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as claimed in any one of claims 1 to 11, or to implement the method as claimed in any one of claims 12 to 23.

26. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as claimed in any one of claims 1 to 11, or the method as claimed in any one of claims 12 to 23.

27. A computer program product, characterized in that, The program product is stored in a storage medium and is executed by at least one processor to implement the method as claimed in any one of claims 1 to 11, or to implement the method as claimed in any one of claims 12 to 23.

Images