A tool invocation method, system, and computing device for large language models

Abstract

A tool calling method, system and computing device for a large language model, receiving a tool calling request generated according to a user question submitted by an MCP client, wherein a target function of a target application is indicated; transmitting the tool calling request to the target application; receiving an encrypted execution result returned by the target application, the encrypted execution result being encrypted for a plaintext execution result according to a preset accessible attribute group for the target function using an attribute-based encryption algorithm; decrypting the encrypted execution result according to an attribute key of a target user to determine a decrypted result, wherein the attribute key is generated according to a user attribute of the target user using the attribute-based encryption algorithm; and transmitting the decrypted result to the MCP client, the data returned by the target application being transmitted in an encrypted form, the decryption operation relying on a pre-distributed attribute key rather than an original identity credential of the user, when the attribute key is leaked, an attacker can only decrypt the encrypted execution result satisfying the corresponding attribute, and cannot access other services in the MCP architecture.

Description

Technical Field

[0001] The embodiments in this specification pertain to the field of large language model applications, and particularly relate to a tool invocation method, system, and computing device for large language models. Background Technology

[0002] The Model Context Protocol (MCP) is a communication protocol used to integrate Large Language Models (LLMs) with external data sources and tools. Through this protocol, the LLM can dynamically invoke external tools to obtain data or perform operations during inference. In the MCP architecture, a secure and trusted communication connection needs to be established between the LLM and the MCP server to ensure that data transmitted in the call chain is not accessed by unauthorized parties.

[0003] In existing MCP architecture authentication schemes, OAuth 2.0 protocol or API key mechanism are typically used for user authentication. Taking OAuth 2.0 authentication as an example, before calling the tools provided by the MCP server, users must first request an identity token from the authorization server, and then include this token in the tool call request. After verifying the token's validity, the MCP server determines whether the user has the permission to call the corresponding tool, and returns the requested data upon successful verification. API key authentication uses a similar mechanism; users directly include the API key in the request, and the server completes authentication by verifying the key.

[0004] When an MCP server calls multiple external tools, the user's identity credentials need to be transmitted along the call chain. If any tool in the chain has a security flaw or is maliciously tampered with, it can intercept and extract the user's identity credentials, leading to the leakage of the user's real identity information. Furthermore, the same identity credential is often used to authorize calls to multiple tools. When the credentials of one tool are leaked, all services in the entire MCP architecture that rely on that credential face the risk of being accessed and traversed.

[0005] Therefore, how to prevent the exposure of user identity credentials in the call chain while ensuring that data is not accessed by unauthorized parties remains a problem that needs to be solved in the security design of the MCP architecture. Summary of the Invention

[0006] This specification provides embodiments that aim to offer a method, system, and computing device for invoking tools for large language models, including:

[0007] This specification provides a method for invoking tools for large language models, the method being applied to an MCP server, the method comprising:

[0008] Receive a tool call request submitted by the MCP client, the tool call request being generated based on a user query sent by the target user, which indicates the target function of the target application;

[0009] The tool invocation request is transmitted to the target application;

[0010] The encrypted execution result returned by the target application is received, and the encrypted execution result is obtained by encrypting the plaintext execution result using an attribute-based encryption algorithm based on a combination of accessible attributes preset for the target function;

[0011] The encryption execution result is decrypted based on the attribute key of the target user, and the decryption result is determined. The attribute key is generated using the attribute base encryption algorithm based on several user attributes of the target user.

[0012] The decryption result is transmitted to the MCP client.

[0013] The second aspect of this specification provides a tool invocation system for large language models, the system including an MCP client, an MCP server, and a target application;

[0014] The MCP client is used to respond to user queries sent by the target user, generate a tool call request instructing the target function of the target application, and submit the tool call request to the MCP server.

[0015] The MCP server is used to receive tool call requests submitted by MCP clients and transmit the tool call requests to the target application.

[0016] The target application is used to determine the plaintext execution result according to the tool call request; and to encrypt the plaintext execution result using an attribute-based encryption algorithm based on a preset combination of accessible attributes for the target function to obtain an encrypted execution result; and to return the encrypted execution result to the MCP server.

[0017] The MCP server is used to decrypt the encryption execution result based on the attribute key of the target user, determine the decryption result, wherein the attribute key is generated using the attribute base encryption algorithm based on several user attributes of the target user; and transmit the decryption result to the MCP client.

[0018] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0019] A fourth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the first aspect.

[0020] The tool invocation scheme for large language models provided in this embodiment transmits data returned by the target application in encrypted form. The decryption operation relies on the pre-distributed attribute key rather than the user's original identity credentials. When the attribute key is leaked, the attacker can only decrypt the encrypted execution result that satisfies the corresponding attribute and cannot traverse and access other services in the MCP architecture. Attached Figure Description

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

[0022] Figure 1 This is a system architecture diagram of a tool invocation system for a large language model in one embodiment of this specification;

[0023] Figure 2 This is an overall flowchart of a tool invocation method for a large language model in one embodiment of this specification;

[0024] Figure 3 This is a schematic diagram illustrating the determination of LSSP for the combination of accessible attributes in one embodiment of this specification;

[0025] Figure 4 This is a timing diagram illustrating the challenge value verification and mask execution results in one embodiment of this specification;

[0026] Figure 5 This is an interaction sequence diagram of a tool call system for a large language model in one embodiment of this specification. Detailed Implementation

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

[0028] Figure 1A system architecture diagram of a tool invocation system for a large language model is shown in one embodiment of this application. For example... Figure 1 As shown, the system comprises four components: the target user terminal, the MCP client, the MCP server, and the target application. The target user submits user queries to the MCP client through the target user terminal. The MCP client, deployed on the target user terminal, includes a large language model calling interface and a request generation component. The MCP server, deployed in the cloud or on-premises server cluster, includes a request processing component, an attribute key storage component, and a decryption operation component. The target application is an external service node independent of the MCP server, containing a business logic execution component and an attribute base encryption component. The MCP client and the MCP server are connected via an encrypted communication link, while the MCP server and the target application are connected via an application-layer communication protocol.

[0029] The MCP client is deployed on the end-user side and is used to respond to user queries sent by the target user, generate a tool call request that instructs the target function of the target application, and submit the tool call request to the MCP server.

[0030] The MCP server is deployed on the server side to receive tool call requests submitted by MCP clients and transmit the tool call requests to the target application.

[0031] The target application is a service node in the MCP architecture that provides specific external functions. It is used to determine the plaintext execution result based on the received tool call request, and to encrypt the plaintext execution result using an attribute-based encryption algorithm to obtain the encrypted execution result.

[0032] It should be noted that the tool invocation method for large language models in this embodiment relies on an attribute-based encryption system. This attribute-based encryption system can separate the generation process of attribute keys from the implementation process of MCP, and have it uniformly executed by a dedicated key generation center, thereby utilizing a trusted third party (key generation center) to provide security for the MCP process.

[0033] The following section first introduces the attribute-based encryption system. This system includes a key generation phase and an encryption / decryption phase. The encryption / decryption phase is used during the execution of the tool invocation method in this embodiment; therefore, the key generation phase will be described first.

[0034] The key generation phase includes the system initialization phase and the user registration phase.

[0035] During the system initialization phase, the key generation center executes an initialization algorithm to generate system-level parameters. The key generation center selects a security parameter. As input, construct the group parameter system required for the attribute-based cryptographic algorithm.

[0036] One embodiment of this application relates to a key generation and distribution mechanism in an attribute-based cryptography system. This embodiment separates the attribute key generation process from the MCP server, allowing it to be executed centrally by a dedicated key generation center.

[0037] During the system initialization phase, the key generation center executes an initialization algorithm to generate system-level parameters. The key generation center selects a security parameter. As input, construct the group parameter system required for the attribute-based cryptographic algorithm.

[0038] The key generation center defines two prime order numbers. Multiplication cyclic group and and a target group .exist and Establish a bilinear mapping between them Bilinear mappings satisfy the following property: For any element in , any element in and any integer and ,satisfy:

[0039]

[0040] Key generation center from Select generators ,from Select generators At the same time, define a collision-resistant hash function. Used to map binary strings of arbitrary length to groups The element space.

[0041] Group parameters are represented as:

[0042]

[0043] The key generation center randomly selects an integer. As a system private key, based on the system private key And bilinear mapping to calculate paired values This allows us to obtain the system's public key.

[0044]

[0045] The system private key is represented as:

[0046]

[0047] The key generation center will use the system public key Broadcast to all participating entities, including the MCP client, MCP server, and target application. System private key. The key is securely stored by the key generation center and is not disclosed to external parties.

[0048] In one different embodiment, the construction of the multiplicative cyclic group in the group parameters is based on elliptic curves. The choice of elliptic curve directly affects the efficiency of the pairing operation. Choosing a curve parameter with higher security will increase the time overhead of the pairing operation, and the decryption latency on the MCP server side will increase accordingly. For tool invocation scenarios with high real-time requirements, a trade-off is made between security level and computational efficiency, and a curve with a smaller parameter size is selected.

[0049] During the user registration phase, the target user submits their set of user attributes to the key generation center to complete identity registration. The target user's set of attributes is represented as follows:

[0050]

[0051] in For the number of attributes, Indicates the first User attributes.

[0052] The key generation center verifies the user's identity. Once verification is successful, the system public key is used. System private key and user attribute set The input is used to execute the key generation algorithm.

[0053] The key generation center randomly selects an integer. ,based on Generate attribute keys.

[0054] Attribute keys are based on user attribute sets Each attribute component in the set is calculated separately. Attributes The key generation center calculates the corresponding attribute key components:

[0055]

[0056] Simultaneously calculate:

[0057]

[0058]

[0059] The attribute key is represented as follows:

[0060]

[0061] Attribute Key It is sent to the MCP server for storage, and is used for subsequent decryption operations on the encryption results.

[0062] In some implementations, the execution of the key generation algorithm can also simultaneously generate the user's private key, specifically:

[0063] The key generation center randomly selects an integer. and .based on and Generate the attribute key and user private key. User private key Directly from random numbers Sure:

[0064]

[0065] Attribute keys are based on user attribute sets Each attribute component in the set is calculated separately. Attributes The key generation center calculates the corresponding attribute key components:

[0066]

[0067] Simultaneously calculate:

[0068]

[0069]

[0070] The attribute key is represented as follows:

[0071]

[0072] If only use If an attribute key is generated, then the encrypted execution result can be completely decrypted using only the attribute key, yielding the plaintext execution result. If the user's private key is used... Since the generation process of the attribute key is incorporated, the attribute key alone cannot completely decrypt the encrypted execution result. Further decryption using the user's private key is still required to obtain the correct plaintext execution result.

[0073] This further ensures that the plaintext execution results will not be leaked at the MCP server stage.

[0074] The specific representation of user attributes depends on the business scenario in which the MCP architecture is deployed. In an enterprise data security management scenario, user attributes may include the user's department, job level, role, and date of employment. For example, a user's user attributes might be represented as follows:

[0075]

[0076] Accessibility attribute combinations define access conditions based on these specific attribute values. For example, if the accessibility attribute combination for a tool's call result is set to "department is data security or network security, job level is senior or expert, and years of service are greater than 2," then the above attribute set is... Users who meet the required combination of accessibility attributes have the right to decrypt and obtain the results of the tool call.

[0077] It should be noted that, as described above regarding user attributes, obtaining only one set of user attributes is insufficient to accurately locate the specific user corresponding to that set of user attributes. This ensures the privacy and security of users in the tool invocation method for large language models provided in this embodiment.

[0078] In some implementations, the attribute key is generated using an attribute encryption algorithm based on several user attributes of the target user and the user's private key. The user's private key is held by the target user, and the decryption result is the intermediate ciphertext encrypted using the user's private key. This mechanism introduces the user's own private key component into the attribute key generation process. The generation of the attribute key no longer relies entirely on the key generation center; instead, the key generation center generates the main part based on system parameters and user attributes, and the user's private key, as the final link in the decryption chain, is kept by the user.

[0079] After generating keys, the key generation center maintains a user attribute registry, recording each user's registered attribute set and its corresponding attribute key version identifier. When a user's attributes change, the key generation center executes an attribute key update algorithm to recalculate the affected attribute key components. The updated attribute key is then incrementally pushed to the MCP server. This incremental update mechanism avoids the overhead of regenerating all keys.

[0080] After the attribute keys are generated and distributed, the MCP server has the ability to decrypt the encrypted execution result based on attribute combinations, and the target user holds the user's private key. Used for final decryption of intermediate ciphertext. In the tool call chain, the encryption of the plaintext execution result is completed by the target application, while decryption can be completed collaboratively by the MCP server and the target user (this discussion is based on the user's private key). (This is based on the premise of incorporating the generation process of attribute keys). Throughout the entire process, the user's real identity credentials will not be exposed in plaintext at any node in the call chain.

[0081] One embodiment of this application relates to the process by which an MCP server receives and processes tool invocation requests.

[0082] After receiving a question submitted by a target user through a natural language interface, the MCP client first analyzes the question content using its local large language model. The large language model uses intent recognition and semantic parsing to determine whether the question requires the use of external tools or data sources. When the large language model determines that external tools are needed, it generates the corresponding tool invocation request.

[0083] The tool invocation request contains the function identifier of the target application. The target application refers to an external service within the MCP architecture that provides specific functions, including but not limited to database query services, API interface call services, file read / write services, and remote computing services. The tool invocation request is encapsulated in a structured protocol message format, conforming to the message specifications defined by the MCP protocol.

[0084] The MCP server receives tool invocation requests submitted by MCP clients. These requests are generated based on user queries sent by the target user, specifying the target application's intended function. Upon receiving the request, the MCP server performs request format validation and protocol parsing, extracting the target application identifier and the target function identifier.

[0085] Figure 2 This is an overall flowchart of a tool invocation method for a large language model, provided as an embodiment of this application. Figure 2 As shown, the method includes:

[0086] Step S200: The MCP server receives a tool call request submitted by the MCP client. The tool call request is generated based on a user question sent by the target user, which indicates the target function of the target application.

[0087] After receiving a tool invocation request, the MCP server performs necessary pre-processing. The MCP server extracts the target application's network address or service endpoint identifier from the tool invocation request and determines the access path of the target application based on the endpoint identifier.

[0088] In some implementations, the target application and target function are determined by the MCP client calling the large language model based on the user's query. The large language model performs natural language understanding on the user's query to identify the user's intent. When the user's query involves data querying, the large language model determines that the target application is a database service and the target function is to execute an SQL query. When the user's query involves file operations, the large language model determines that the target application is a file management service and the target function is to read or write files.

[0089] The process of determining the target application and target function using the large language model is based on cue word templates and model inference. The cue word templates contain a list of tools accessible to the MCP client and their functional descriptions. The large language model semantically matches the user's query with the tool list, selecting the most matching tool as the target application and its specific operation as the target function. When the user's query involves multiple tools, the large language model can generate multiple tool invocation requests.

[0090] In one different implementation, the target application and target function can be determined using rule matching. The MCP client maintains a mapping table from intent to tool, and determines the target application and target function through keyword matching or regular expression matching. The advantage of rule matching is its speed and low computational cost, making it suitable for scenarios with a small number of tools and well-defined functional boundaries. Rule matching can be combined with large language model inference, with rule matching serving as the first layer of rapid filtering and large language model inference supplementing the handling of complex queries that cannot be covered by the rules.

[0091] For example, a target user might submit a question like, "Please analyze our department's project investment last month, including the work hour percentages and cost distribution for each team." After semantic analysis, the large language model identifies two levels of data acquisition needs. The first level is basic data querying, corresponding to the project management system, with the target function being data export service. This specifically includes outputting the personnel name, detailed job description, minute-accurate work hour data, and associated contract unit price information for each work hour record. The second level is post-processing data querying, still corresponding to the project management system, with the target function being data aggregation service. This specifically includes performing grouping and aggregation operations on the raw work hour data, outputting the work hour percentage distribution for each team and the total cost summary.

[0092] In step S202, the MCP server transmits the tool invocation request to the target application.

[0093] The MCP server transmits tool call requests to the target application. The transmission process follows the communication protocol used by the target application. When the target application is an HTTP service, the MCP server encapsulates the tool call request into an HTTP request message and sends it to the target application's server endpoint via HTTPS. When the target application is a gRPC service, the MCP server transmits the serialized tool call request through a gRPC channel.

[0094] Before transmitting a tool invocation request, the MCP server performs necessary format conversions on the request content. The target application may use an interface specification different from the MCP protocol. The MCP server, acting as an intermediary layer for protocol conversion, maps the MCP-formatted tool invocation request to an interface invocation format that the target application can recognize. This format mapping process includes parameter name conversion, data type adaptation, and the addition of authentication information.

[0095] In some implementations, receiving tool invocation requests submitted by the MCP client specifically includes receiving the tool invocation request and the attribute key. In this case, the attribute key is transmitted along with the tool invocation request, rather than being pre-distributed through a separate key distribution channel. When generating the tool invocation request, the MCP client embeds the attribute key corresponding to the target user into the authentication header or extended field of the request message. After receiving the tool invocation request carrying the attribute key, the MCP server temporarily stores the attribute key in the context memory of the current session for subsequent decryption operations. This on-the-fly method is suitable for scenarios where user attributes change frequently, ensuring that the attribute key in each tool invocation request is the latest version.

[0096] In one different embodiment, the attribute key can be carried using a reference identifier. The MCP client does not directly transmit the complete content of the attribute key, but instead transmits a version identifier or hash value of the attribute key. The MCP server uses this identifier to look up the corresponding attribute key in its local key cache. If the corresponding version of the attribute key is not found in the local cache, the MCP server initiates a key retrieval request to the key generation center to obtain the latest version of the attribute key.

[0097] In other implementations, the MCP server supports concurrent transmission of tool invocation requests to multiple target applications. When the large language model determines that multiple independent tools need to be invoked, the MCP server establishes connections with each target application in parallel and sends the corresponding tool invocation requests simultaneously.

[0098] In step S204, the MCP server receives the encrypted execution result returned by the target application.

[0099] Upon receiving a tool invocation request, the target application executes the corresponding business logic and generates a plaintext execution result. The plaintext execution result is the raw data generated by the target application after executing the tool invocation request. Instead of directly returning the plaintext execution result to the MCP server, the target application uses an attribute-based encryption algorithm to encrypt the plaintext execution result, obtaining an encrypted execution result.

[0100] For example, continuing from the previous example, the target function "Data Export Service" needs to perform the following: output the personnel name, detailed job description, minute-accurate work hour data, and associated contract unit price information for each work hour record. This type of data directly identifies individuals, therefore requiring a higher level of access. In the corresponding accessibility attribute combination for "Data Export Service," the "Data Permission" attribute is set to "Detail Level," meaning only users with "Detail Level" data permissions are allowed access. The target function "Data Aggregation Service" needs to perform grouped aggregation operations on the raw work hour data, outputting the work hour distribution and cost summary results for each team. The summary results have relatively lower privacy, allowing access at a lower permission level. In the corresponding accessibility attribute combination for "Data Aggregation Service," the "Data Permission" attribute is set to "Aggregation Level" (Detail Level permissions are higher than Aggregation Level permissions), meaning users with "Aggregation Level" and higher data permissions are allowed access.

[0101] It should be noted that in this embodiment, the target application does not need to verify the user's identity before executing the tool call request. It only needs to perform attribute-based encryption on the plaintext execution result after execution is complete, thus preventing users without viewing permissions from obtaining the correct plaintext execution result. In other words, this solution achieves restricted use of the target function without exposing the user's true identity or unique identity credentials.

[0102] Specifically, when the target application performs attribute-based encryption, it uses the system public key. Preset combinations of accessible attributes and plaintext execution results For input. The accessibility attribute combination defines the user attribute conditions that grant the user the right to decrypt the result of the encryption. The target application randomly selects a secret value. Based on the system public key and secret value Calculate the ciphertext components.

[0103] The process of generating the encryption execution result is as follows. Target application computation:

[0104]

[0105]

[0106]

[0107]

[0108] in, For the pairing parameters in the system public key, and is a generator in the group parameters. For each user attribute condition in the accessible attribute combination. These are several randomly generated numbers. The secret value is obtained by combining the valid shares of each user attribute condition belonging to the same set of accessible attribute combinations. .

[0109] The overall result of the encryption execution is represented as follows:

[0110]

[0111] in A plaintext description of the combination of accessible attributes.

[0112] Once the encryption execution result is determined, the target application can send the encryption execution result to the MCP server so that the MCP server can receive the encryption execution result returned by the target application.

[0113] In step S206, the MCP server decrypts the encryption execution result based on the target user's attribute key.

[0114] It should be noted that, compared to the target user terminal, the MCP server typically has more abundant computing resources and can handle the complex group element operations involved in the attribute key. Therefore, in this embodiment, all or part of the encryption process is arranged to be performed on the MCP server.

[0115] Specifically, if the user's private key is not... Integrating the attribute key generation process, the MCP server's decryption process includes:

[0116] First, calculate:

[0117]

[0118] in For the target user attribute set The combination of accessible attributes is satisfied A collection of attribute indexes. The encryption result is determined synchronously when the target application calculates it, provided that the target user attributes meet the required combination of accessible attributes. , specific Available As shown in the diagram. However, if the target user's attributes do not satisfy any of the accessible attribute combinations, no matter how the corresponding target user's attribute keys are combined, the encryption will not yield the correct decryption result.

[0119] Then calculate:

[0120]

[0121] Therefore, the decryption result obtained by the MCP server is as follows. That is the result of the explicit execution.

[0122] If the user's private key Integrating the generation process of the attribute key, the decryption process of the MCP server also begins with calculating:

[0123]

[0124] However, because the user's private key is incorporated into each attribute key... The MCP server was unaware of this. Decryption cannot be completed directly.

[0125] In this embodiment as well as Also known as intermediate ciphertext. This intermediate ciphertext is the user's private key. The decryption result corresponding to the MCP server after incorporating the attribute key generation process.

[0126] In some implementations, the accessible attribute combination is represented as a linear secret sharing matrix consisting of several attribute vectors; that is, the plaintext description of the accessible attribute combination is a linear secret sharing matrix. Each attribute vector corresponds to one attribute in the accessible attribute combination.

[0127] Determining whether several user attributes of a target user satisfy the combination of accessible attributes specifically includes determining several attribute vectors corresponding to several user attributes in a linear secret sharing matrix, obtaining a preset target vector based on whether the corresponding attribute vectors can be combined, and determining whether several user attributes satisfy the combination of accessible attributes.

[0128] The linear secret sharing matrix is ​​constructed as follows. Before encryption, the target application encodes the accessibility attributes into a linear secret sharing matrix. .matrix The number of rows equals the total number of attributes in the accessible attribute combination, and the number of columns is determined by the complexity of the access structure. Matrix Each row corresponds to one attribute in the accessible attribute combination, and the row vector is denoted as . .

[0129] The target application simultaneously selects a target column to determine whether the attribute vectors can be linearly combined to form the target vector.

[0130] Figure 3 This is a schematic diagram illustrating the LSSP determination of accessible attribute combinations according to an embodiment of this application. Figure 3 As shown, the LSSP determination process consists of three steps: the target application transforms the combination of accessible attributes into a linear secret sharing matrix. Each row of the matrix corresponds to an attribute vector; the MCP server uses the attribute set of the target user. Filter out Attributes in the matrix The corresponding subset of attribute vectors; Gaussian elimination is performed on this subset of attribute vectors to determine whether there exists a set of constants such that a linear combination of the subset of attribute vectors equals the target vector. In this context, the position of the 1 element in the target vector represents the position of the target column. If the target column exists, it is considered satisfied; otherwise, it is considered not satisfied.

[0131] When the MCP server performs the decision-making operation, it first starts from the target user's attribute set. Selecting from linear secret sharing matrices If there are attributes corresponding to a row, retrieve the corresponding attribute vector subset. Then, Gaussian elimination is performed to determine if a set of constants exists. Make:

[0132]

[0133] If a set of constants satisfying the above equation exists, the target user attributes are determined to meet the accessibility attribute combination. If no set of constants satisfying the equation exists, the target user attributes are determined not to meet the accessibility attribute combination, and the MCP server returns a decryption failure message to the MCP client.

[0134] In some implementations, the tool invocation request includes at least several user attributes of the target user. The process involves receiving the encrypted execution result returned by the target application, specifically including the encrypted execution result and the combination of accessible attributes. Before decrypting the encrypted execution result, it is determined whether the target user's several user attributes satisfy the combination of accessible attributes. If not, a decryption failure message is returned to the MCP client.

[0135] When the target user attributes do not meet the requirements for the accessible attribute combination, the MCP server directly returns a decryption failure message without performing subsequent bilinear pairing operations. This mechanism avoids unnecessary decryption computation overhead.

[0136] In step S208, the MCP server transmits the decryption result back to the MCP client.

[0137] After decryption is complete, the MCP server can transmit the decryption result back to the MCP client.

[0138] If the MCP client receives the decryption result Then you can directly obtain the plaintext execution result.

[0139] If the MCP client receives the intermediate ciphertext as well as Then the MCP client can use its own user private key Decryption complete, plaintext execution result obtained:

[0140]

[0141] Then, the MCP client uses the plaintext execution result as the context input of the large language model, which generates a response to the target user's question based on the execution result.

[0142] like Figure 2 This paper presents a tool invocation method for large language models. It encrypts the execution results of the target application using an attribute-based encryption mechanism, allowing only users meeting specific attribute conditions to decrypt and retrieve the results. Throughout the tool invocation chain, the data returned by the target application is transmitted in encrypted form. The decryption operation on the MCP server side relies on pre-distributed attribute keys, not the user's original identity credentials. When a target application in the invocation chain has a security flaw, that application can only obtain its own encrypted execution results and cannot access the user identity credentials of other nodes in the chain. The same attribute key is only valid for the current tool invocation result. When the attribute key is leaked, attackers can only decrypt the encrypted execution results that meet the attribute conditions corresponding to that component and cannot access other services in the MCP architecture.

[0143] On the other hand, the combination of attribute-based encryption and the MCP protocol enables access control at the tool invocation level. The combination of accessible attributes for each tool invocation result is independently set by the target application, with different tool invocation results corresponding to different combinations of accessible attributes. Users can only decrypt tool invocation results whose attribute sets satisfy the accessible attribute combinations; they cannot obtain other data with mismatched attributes. This fine-grained access control avoids the risk of a single identity credential being used for traversal access authorization across multiple tool invocations.

[0144] One embodiment of this application provides a tool invocation method that encrypts the execution result of the target application using an attribute-based encryption mechanism, enabling only users meeting specific attribute conditions to decrypt and obtain the execution result. Throughout the tool invocation chain, the data returned by the target application is transmitted in encrypted form. The decryption operation on the MCP server side relies on pre-distributed attribute keys, rather than the user's original identity credentials. When a target application in the invocation chain has a security flaw, that target application can only obtain its own encrypted execution result and cannot obtain the user identity credential information of other nodes in the chain. The same attribute key is only valid for the current tool invocation result. When a component of the attribute key is leaked, an attacker can only decrypt the encrypted execution result that meets the attribute conditions corresponding to that component and cannot traverse and access other services in the MCP architecture.

[0145] The combination of attribute-based encryption and the MCP protocol enables access control at the tool invocation level. The combination of accessible attributes for each tool invocation result is independently set by the target application, with different tool invocation results corresponding to different combinations of accessible attributes. Users can only decrypt tool invocation results whose attribute sets satisfy the accessible attribute combinations; they cannot obtain other data with mismatched attributes. This fine-grained access control avoids the risk of a single identity credential being used for traversal access authorization across multiple tool invocations.

[0146] In some implementations, the tool invocation request also includes a challenge value. The encrypted execution result is obtained by encrypting the masked execution result using an attribute encryption algorithm based on a preset combination of accessible attributes. The masked execution result is then processed from the plaintext execution result using the challenge value. This challenge value can be randomly generated by the MCP client when generating the tool invocation request and transmitted to the target application along with the request. Correspondingly, before generating the encrypted execution result, the target application first applies a mask transformation based on the challenge value to the plaintext execution result to obtain the masked execution result.

[0147] In some implementations, the challenge value is generated as follows:

[0148] After receiving a question from the target user, the MCP client randomly selects a non-zero integer as the challenge value. Challenge value Bind to the current session identifier to ensure that a different challenge value is used for each tool call request.

[0149] The target application received the challenge value. Then, the challenge value is used to execute the plaintext result. Perform masking. The specific method for masking is as follows:

[0150]

[0151] in This is a hash function. The result of the masking process is shown below. Instead of plaintext execution result As input for attribute-based encryption.

[0152] The target application executes the mask result. Attribute-based encryption is performed to obtain the encrypted result. After the MCP server and MCP client perform the aforementioned decryption process, the masked result is recovered. The MCP client utilizes challenge values. Demask the execution result to restore the plaintext execution result:

[0153]

[0154] Figure 4 This is a timing diagram illustrating the challenge value verification and mask execution results provided in one embodiment of this application. Figure 4 As shown, the challenge value verification and masking process consists of four stages: the MCP client randomly generates the challenge value. The challenge value is then embedded into the tool invocation request; the target application receives the challenge value and calculates the mask value. The mask value is compared with the plaintext execution result. Multiplying to obtain the mask result ;Target application Attribute-based encryption is performed to obtain the encrypted execution result and return it; the MCP client then obtains the decrypted mask execution result. Then, use the locally saved challenge values. Calculate the inverse mask ,and Multiplication to restore plaintext .

[0155] The challenge value mechanism serves to prevent replay attacks. When an attacker intercepts the encrypted execution result returned by the target application, even if they are able to resend the encrypted result to the MCP server, the challenge value used in the demasking operation must match the challenge value used during encryption because each tool call request carries a different challenge value. If the challenge values ​​do not match, the demasking operation cannot recover the correct plaintext execution result.

[0156] In a different embodiment, the combination of the challenge value and the plaintext execution result can be achieved using an XOR operation instead of group element multiplication. In this case, the target application's calculated mask execution result is:

[0157]

[0158] The overall interactive process of tool invocation by the system is as follows: The target user inputs a user question in natural language on their terminal device. The MCP client receives the user question, calls the large language model for semantic parsing, and determines the target application and function to be invoked. The MCP client generates a tool invocation request containing the target application identifier and the target function identifier, and sends it to the MCP server via an encrypted communication link. The MCP server's request routing module parses the tool invocation request, determines the network endpoint of the target application, and forwards the tool invocation request to the target application. The target application's business execution module executes the corresponding business logic according to the tool invocation request, generating a plaintext execution result. The target application's encryption module encrypts the plaintext execution result using a combination of the system public key and accessibility attributes, generating an encrypted execution result, which is returned to the MCP server. The MCP server's attribute verification module uses the target user's attribute key to decrypt the encrypted execution result. If the attributes are satisfied, the first stage of decryption is performed to obtain intermediate ciphertext. The MCP server transmits the intermediate ciphertext back to the MCP client. The MCP client forwards the intermediate ciphertext to the target user terminal, and the target user terminal uses its held user private key to perform the final decryption of the intermediate ciphertext, restoring the plaintext execution result. The large language model generates responses to the target user's questions based on the plaintext execution results.

[0159] Figure 5 This is an interaction timing diagram of a tool invocation system for a large language model provided in one embodiment of this application. Figure 5 As shown, the tool calls the system including the MCP client, the MCP server, and the target application.

[0160] The system interaction comprises seven phases: Phase 1, the target user sends a user query to the MCP client; Phase 2, the MCP client submits a tool invocation request to the MCP server; Phase 3, the MCP server forwards the tool invocation request to the target application; Phase 4, the target application executes business logic to generate a plaintext execution result; Phase 5, the target application encrypts the plaintext execution result using an attribute-based encryption algorithm and returns the encrypted execution result to the MCP server; Phase 6, the MCP server decrypts the encrypted execution result using an attribute key to obtain intermediate ciphertext and transmits it back to the MCP client; Phase 7, the target user uses their private key to perform the final decryption of the intermediate ciphertext to obtain the plaintext execution result.

[0161] One embodiment of this application provides a computing device. The computing device includes a memory and a processor. The memory stores executable code that can run on the processor. When the processor executes the executable code, it implements the various steps of the aforementioned tool invocation method for large language models.

[0162] The memory of the computing device includes at least one of random access memory (RAM) and read-only memory (ROM). RAM is used to cache temporary data such as tool invocation requests, encrypted execution results, and intermediate ciphertext during tool invocation method execution. ROM stores the system public key and fixed parameters of the attribute-based encryption algorithm. The executable code contains a sequence of instructions for a request receiving module, a request forwarding module, an encrypted receiving module, a decryption processing module, and a decryption result transmission module.

[0163] When executing executable code, the processor first calls the instruction of the request receiving module to receive the tool call request submitted by the MCP client. Then, it calls the instruction of the request forwarding module to transmit the tool call request to the target application. The processor calls the instruction of the encryption receiving module to receive the encrypted execution result returned by the target application. The processor calls the instruction of the decryption processing module to decrypt the encrypted execution result according to the target user's attribute key and determine the decryption result. Finally, the processor calls the instruction of the decryption result transmission module to transmit the decryption result to the MCP client.

[0164] In one different embodiment, the computing device is a cloud server instance, the storage adopts a distributed storage architecture, and the processor is a multi-core processor. Different cores of the multi-core processor are responsible for request forwarding, encrypted reception, and decryption processing, respectively. In the distributed storage architecture, attribute keys are stored on independent key storage nodes, physically isolated from the computing nodes that execute the processing logic, reducing the risk of attribute key leakage.

[0165] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0166] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0167] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0168] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0169] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0170] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0171] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0172] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0173] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0174] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0175] Computer-readable media includes 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 disk storage, graphene 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.

[0176] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0177] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0178] The various embodiments in this specification 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, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0179] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for invoking tools for large language models, the method being applied to an MCP server, the method comprising: Receive a tool call request submitted by the MCP client, the tool call request being generated based on a user query sent by the target user, which indicates the target function of the target application; The tool invocation request is transmitted to the target application; The encrypted execution result returned by the target application is received, and the encrypted execution result is obtained by encrypting the plaintext execution result using an attribute-based encryption algorithm based on a combination of accessible attributes preset for the target function; The encryption execution result is decrypted based on the attribute key of the target user, and the decryption result is determined. The attribute key is generated using the attribute base encryption algorithm based on several user attributes of the target user. The decryption result is transmitted to the MCP client.

2. The method as described in claim 1, wherein, The attribute key is generated using the attribute encryption algorithm based on the target user's user attributes and the user's private key; the user's private key is held by the target user. The decryption result is the intermediate ciphertext encrypted using the user's private key.

3. The method as described in claim 1, wherein, Receive tool invocation requests submitted by the MCP client, specifically including: Receive tool call requests and attribute keys submitted by the MCP client.

4. The method of claim 1, wherein, The tool invocation request includes at least several user attributes of the target user; Receiving the encrypted execution result returned by the target application specifically includes: Receive the encrypted execution result and the combination of accessible attributes returned by the target application; Before decrypting the encryption result, the method further includes: Determine whether the aforementioned user attributes satisfy the accessible attribute combination; if not, return a decryption failure message to the MCP client.

5. The method of claim 4, wherein, The accessible attribute combination is represented as a linear secret sharing matrix composed of several attribute vectors, where each attribute vector corresponds to one attribute in the accessible attribute combination. Determining whether the aforementioned user attributes satisfy the accessible attribute combination specifically includes: Determine several attribute vectors corresponding to the several user attributes in the linear secret sharing matrix, and determine whether the several user attributes satisfy the accessible attribute combination based on whether the corresponding several attribute vectors can be combined to obtain a preset target vector.

6. The tool invocation method for large language models as described in claim 1, wherein, The tool invocation request also includes a challenge value; The encrypted execution result is obtained by encrypting the masked execution result using an attribute encryption algorithm based on a preset accessibility attribute. The masked execution result is obtained by processing the plaintext execution result using the challenge value.

7. The method of claim 1, wherein, The attribute key is generated by the key generation center using the system public key, the system private key, and the user private key, based on several user attributes of the target user. The encrypted execution result is obtained by encrypting the plaintext execution result using the system public key and a preset accessibility attribute combination.

8. The method of claim 1, wherein, The target application and the target function are determined by the MCP client calling the large language model based on the user's question.

9. A tool invocation system for large language models, the system comprising an MCP client, an MCP server, and a target application; The MCP client is used to respond to user queries sent by the target user and generate tool call requests that instruct the target application on the target function. And submit the tool invocation request to the MCP server; The MCP server is used to receive tool call requests submitted by MCP clients and transmit the tool call requests to the target application. The target application is used to determine the plaintext execution result according to the tool call request; and to encrypt the plaintext execution result using an attribute-based encryption algorithm based on a preset combination of accessible attributes for the target function to obtain an encrypted execution result; and to return the encrypted execution result to the MCP server. The MCP server is used to decrypt the encryption execution result based on the attribute key of the target user, determine the decryption result, wherein the attribute key is generated using the attribute base encryption algorithm based on several user attributes of the target user; and transmit the decryption result to the MCP client.

10. A computing device comprising a memory and a processor, the memory storing executable code, wherein the processor, when executing the executable code, implements the method as claimed in any one of claims 1-8.

Images