Tool calling method and device, equipment, medium and program product

Abstract

The embodiment of the invention provides a tool calling method and device, equipment, a medium and a program product. The method comprises the following steps: receiving a tool calling request sent by a target model; verifying whether the tool calling request is a malicious calling request or not; and when the tool calling request is the malicious calling request, intercepting the tool calling request. The method is used for protecting user privacy data in the use process of the MCP.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of artificial intelligence, and in particular to a tool calling method and device, equipment, medium and program product. BACKGROUND

[0002] The MCP (Model Context Protocol) defines the way of exchanging context information between large models and tools, so that developers can connect various tools to large models in a way, and let large models use different tools in a more standard way.

[0003] In the prior art, the context information of the MCP protocol can make the large model more easily understand the problems in the real scene, so that the large model can perform more outstandingly, but in the actual use process, the MCP protocol is vulnerable to attacks due to its shared memory, variable tool definition, and automatic tool calling, thereby leaking user privacy data.

[0004] Therefore, how to protect user privacy data in the use process of the MCP protocol has become a problem to be solved. SUMMARY

[0005] The embodiments of the present application provide a tool calling method, device, equipment, medium and program product to protect user privacy data in the use process of the MCP protocol.

[0006] In a first aspect, the embodiments of the present application provide a tool calling method, comprising:

[0007] receiving a tool calling request sent by a target model;

[0008] verifying whether the tool calling request is a malicious calling request;

[0009] In the case where the tool calling request is a malicious calling request, intercepting the tool calling request.

[0010] In a possible implementation, the tool calling request includes a calling message and a signature generated based on the calling message;

[0011] The verification of whether the tool calling request is a malicious calling request includes:

[0012] based on the signature, verifying whether the calling message is tampered with;

[0013] based on the result of whether the calling message is tampered with, determining whether the tool calling request is a malicious calling request.

[0014] In a possible implementation, the signature is obtained by encrypting the first hash value using a private key, and the first hash value is obtained by hashing the original call message;

[0015] The verifying whether the call message is tampered with based on the signature comprises:

[0016] decrypting the signature using a public key corresponding to the private key to obtain the first hash value;

[0017] hashing the call message to obtain a second hash value;

[0018] determining whether the call message is tampered with based on the first hash value and the second hash value.

[0019] In a possible implementation, the method further comprises:

[0020] receiving the public key sent by the target model.

[0021] In a possible implementation, the determining whether the tool call request is a malicious call request based on the result of whether the call message is tampered with comprises:

[0022] if the call message is tampered with, determining that the tool call request is a malicious call request;

[0023] if the call message is not tampered with, determining that the tool call request is not a malicious call request.

[0024] In a possible implementation, the call message comprises proof information of a target tool to be called.

[0025] The determining whether the tool call request is a malicious call request based on the result of whether the call message is tampered with comprises:

[0026] if the call message is tampered with, determining that the tool call request is a malicious call request;

[0027] if the call message is not tampered with, verifying whether the proof information is valid, and determining that the tool call request is not a malicious call request based on the result of whether the proof information is valid.

[0028] In a possible implementation, the tool call request further comprises input information of a model, and the proof information is proof information generated by taking the input information as public input and taking verification information of a tool description as secret input.

[0029] The verifying whether the proof information is valid comprises:

[0030] verify whether a usage relationship between the proof information and a public parameter is established based on the input information, the public parameter being generated based on the tool description information;

[0031] in a case where the usage relationship is established, determine that the proof information is valid;

[0032] in a case where the usage relationship is not established, determine that the proof information is invalid.

[0033] In a possible implementation, the method further includes:

[0034] receiving the public parameter sent through the target model.

[0035] In a possible implementation, determining, based on the result of whether the proof information is valid, that the tool calling request is a non-malicious calling request includes:

[0036] in a case where the proof information is valid, determining that the tool calling request is a non-malicious calling request;

[0037] in a case where the proof information is invalid, determining that the tool calling request is a malicious calling request.

[0038] In a possible implementation, the tool calling request includes proof information of a target tool to be called.

[0039] verifying whether the tool calling request is a malicious calling request includes:

[0040] verifying whether the proof information is valid;

[0041] in a case where the proof information is valid, determining that the tool calling request is a non-malicious calling request;

[0042] in a case where the proof information is invalid, determining that the tool calling request is a malicious calling request.

[0043] In a possible implementation, the method further includes:

[0044] in a case where the tool calling request is a non-malicious calling request, sending the tool calling request to a target tool server corresponding to the tool calling request.

[0045] In a second aspect, an embodiment of the present application provides a tool calling apparatus, including:

[0046] a receiving module configured to receive a tool calling request sent through a target model;

[0047] The verification module is configured to verify whether the tool invocation request is a malicious invocation request.

[0048] The interception module is configured to intercept the tool invocation request if the tool invocation request is a malicious invocation request.

[0049] In a third aspect, an electronic device is provided, comprising a memory and a processor.

[0050] The memory stores computer-executable instructions.

[0051] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the method according to any one of the first aspect.

[0052] In a fourth aspect, a computer-readable storage medium is provided, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, the computer-executable instructions are configured to implement the method according to any one of the first aspect.

[0053] In a fifth aspect, a computer program product is provided, which comprises a computer program. When the computer program is executed by a processor, the computer program implements the method according to any one of the first aspect.

[0054] The tool invocation method, device, equipment, medium and program product provided by the embodiments of the present application add a trusted proxy mechanism between the MCP client and the tool, receive and verify whether the tool invocation request is malicious through the trusted proxy mechanism, and intercept if the tool invocation request is a malicious invocation request. Compared with the method in the prior art that lacks an authentication mechanism for MCP invocation requests and thus leaks user privacy data, the present application can reduce the risk of malicious invocation requests leaking user privacy data. BRIEF DESCRIPTION OF DRAWINGS

[0055] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0056] Figure 1 FIG. 1 is a schematic diagram of a network architecture applying an MCP protocol;

[0057] Figure 2 FIG. 2 is a schematic diagram of a tool invocation method applying an MCP protocol in the prior art;

[0058] Figure 3 FIG. 3 is a schematic diagram of a network architecture applying an MCP protocol with a trusted proxy mechanism provided by the present application;

[0059] Figure 4 FIG. 4 is a schematic diagram of a tool invocation method provided by the embodiments of the present application.

[0060] Figure 5 A flowchart of a specific tool calling method provided for an embodiment of the present application is shown in the figure;

[0061] Figure 6 A structural diagram of a tool calling device provided for the present application is shown in the figure;

[0062] Figure 7 A structural diagram of an electronic device provided for the present application is shown in the figure.

[0063] The above figures have shown the specific embodiments of the present application, which will be described in more detail hereinafter. These figures and the written description are not intended to limit the scope of the present application concept in any way, but to illustrate the present application concept to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0064] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The following description is made with reference to the accompanying drawings in which like reference numerals refer to like elements, and the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Unless otherwise noted, the description of an embodiment below is not meant to limit the scope of the application concept to that embodiment. Additionally, the description of an embodiment is not meant to limit the scope of the application concept to that embodiment. Rather, the description of an embodiment is meant to provide a description of one embodiment of the application concept, which can be embodied in many different forms.

[0065] In the present application, the term "comprising" and its variants are used to mean that the composition includes the recited elements, but not excluding others. The term "or" and its variants are used to mean "and / or" unless otherwise noted. The term "first", "second", and the like are used to describe similar objects, not necessarily in a particular order or sequence. In the present application, "multiple" means two or more. "And / or", describes the relationship between the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist together, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects.

[0066] The following introduces the professional terms involved in the present application.

[0067] Digital signature technology: a means of identity authentication realized through the principle of cryptography, which uses the public-private key encryption system to ensure that the identity of the information sender cannot be forged. The digital signature identity authentication process includes:

[0068] (1) Key generation and distribution: using a signature algorithm, such as the Rivest-Shamir-Adleman (RSA) algorithm, Elliptic Curve Digital Signature Algorithm (ECDSA), to generate a unique public-private key pair, and the public key is disclosed to all objects that need to verify identity.

[0069] (2) Signature creation: the sender uses a hash function to generate a hash value for the message, encrypts the hash value with the private key to generate a digital signature, and sends the original message and the signature to the receiver.

[0070] (3) Signature verification: after receiving the message and the signature, the receiver uses the sender's public key to decrypt the signature and obtain the message hash value. The receiver recalculates the hash value of the received message and compares it. If the hash values are consistent, the message has not been tampered with.

[0071] Zero-knowledge proof: a cryptographic technique whose core value is to allow the prover to prove the truth of a statement to the verifier without revealing the original data content. It is mainly based on cryptographic problems (such as discrete logarithm problem, elliptic curve discrete logarithm problem). The original data D generates a proof P through a specific algorithm. If D is tampered with, the new proof will be completely different from the original proof P. The verification process is similar to digital fingerprint comparison. The verifier only needs to confirm whether P is generated from the original D, without knowing the specific content of D.

[0072] For example, the specific calculation process of Groth 16 zero-knowledge proof scheme is as follows:

[0073] (1) Setup phase: generate a public reference string, select random numbers ɑ, β, γ, δ, calculate and generate τ and σ, where σ is public and τ is secret.

[0074] (2) Proof phase: the prover generates a linear relationship matrix Л according to the given relationship R, public input φ and secret input ω, through a polynomial algorithm (ProofMatrix); randomly selects two parameters r and s, and calculates the proof π = Лσ by combining σ and the linear relationship matrix.

[0075] (3) Verification phase: the verifier generates a verification circuit t using the relationship R and the public input φ. The verifier judges the validity of the proof by verifying whether t(σ, π) is true. If the result is true, the proof is accepted, otherwise the proof is rejected.

[0076] The characteristics of this zero-knowledge proof scheme include:

[0077] (1) Lightweight: the generated proof is very small and can be quickly stored and transmitted;

[0078] (2) High efficiency: the prover only needs to send one proof without multiple rounds of interaction with the verifier;

[0079] (3) High performance: the verification process has small computational complexity and is fast, which can quickly determine whether the input and output of the given point are legal.

[0080] MCP (Model Context Protocol) defines the way of exchanging context information between large models and tools, enabling developers to connect various tools to large models in a way that allows large models to use different tools in a more standardized manner.

[0081] Figure 1 For a network architecture applying the MCP protocol, as shown in Figure 1 , the architecture includes a host (Host)-MCP client (Client)-tool server (Server), wherein the host is responsible for receiving the user's question and interacting with the model, when the model decides to call a specified MCP service, it establishes a connection with the tool server through the built-in MCP client, after the tool server is called, it returns the query result, and the model generates an answer. It should be noted that the model here is a Figure 1 large language model (LLM), Figure 1 and Server 1-Server n in the figure are different tool servers.

[0082] Tool poisoning attack: a common attack method in MCP, which embeds malicious instructions in the tool description that are invisible to users but visible to AI models. Attackers take advantage of the characteristics of AI models that can analyze complete tool descriptions to plant hidden instructions in tool functions, inducing models to perform unauthorized operations, such as accessing private keys, configuration files, etc. For example, to steal private keys, attackers plant malicious code as tool descriptions in a normal MCP client disguised as a tool description, when the AI analyzes the tool description, it will prioritize processing the content of the tag field, execute malicious instructions, and send the stolen private information to the backend called server.

[0083] Since in the original host-MCP client-tool server architecture, the tool server can directly access the MCP client, malicious attackers can come from malicious tool providers and from malicious servers. When coming from malicious attackers, the attacker pre-registers a normal MCP tool, and then maliciously tampers with the tool description through version control. This attack can be detected through the version control of the MCP client or the LLM. A malicious server can pollute the tool description through a shadow attack (when multiple servers are connected to the same MCP client, the MCP client will open the tool permissions to all connected tool servers, including accessing the tool description file and stealing the tool description content). In the original architecture, the tool server often does not pay attention to the description of the tool (the tool description usually appears in the form of comments), and when the polluted tool calls other tool servers or other tool servers call the polluted tool, the attacker will steal the private data of the normal tool server and send it to the malicious server.

[0084] In the prior art, the context information of the MCP structure can make the large model more easily understand the problems in the real scene, so that the large model performs more outstandingly, but in actual use, the architecture lacks an authentication mechanism for MCP call requests, and can be attacked due to its shared memory, variable tool definition, and automatic tool calling, thereby leaking user private data, which is specifically explained as follows:

[0085] 1. Shared memory: The MCP persistent context is shared, and the large model can read and write the shared memory space to ensure that the information is retained and the environment changes are flexibly adapted. In this shared memory mode, the MCP can quickly connect multiple tool servers, but due to the lack of an authentication mechanism for MCP call requests, if any tool server in the network is attacked, other tool servers will trust the malicious tool server without a verification mechanism, which can cause user private data leakage.

[0086] 2. Variable tool definition: The MCP client currently lacks a version management mechanism, and developers can arbitrarily modify their tool descriptions to flexibly implement different functions. However, the tool is registered by default and is trusted by the MCP client for a long time. Due to the lack of an authentication mechanism for MCP call requests, if a tool changes its behavior after initial audit, it can cause user private data leakage.

[0087] 3. Automatic tool calling: The MCP client can call tools, initiate API requests, process data, and run user-oriented workflows through structured definitions and tool descriptions. However, due to the lack of an authentication mechanism for MCP call requests, the MCP client does not verify or clean up tool description information, and attackers can hide malicious instructions or inducement parameters in the tool definition, causing user private data leakage.

[0088] Take the user request to call the file system as an example, Figure 2 The schematic diagram of calling tools by MCP protocol in the prior art is shown in Figure 2 The process includes:

[0089] 1. The user requests to call the file system through the MCP client.

[0090] 2. The MCP client requests the file system.

[0091] 3. The malicious server (i.e., the malicious Server in Figure 2 intercepts the request in step 2.

[0092] 4. The malicious server (i.e., the malicious Server in Figure 2 modifies the request in step 2 to reinitiate the call.

[0093] The malicious server can implement attacks by tampering with tool descriptions. When multiple tool servers are connected to the same MCP client, the malicious server can intercept requests that should be sent to a trusted tool server, modify the tool or service to be called, and pollute the tool description, thereby stealing data of other tool servers and implementing identity authentication hijacking to obtain access to other servers (such as local file systems and mail systems).

[0094] In summary, the privacy security threat existing in the host-MCP client-tool server architecture mainly comes from the lack of authentication mechanism for MCP call requests. In this case, the tool server will default to trust the requests from the MCP client, and the attacker can steal the host's private data by means such as disguising as a legitimate call request and injecting instructions in the tool.

[0095] Therefore, the present application proposes a tool calling method, device, equipment, medium and program product. A trusted proxy server is added between the MCP client and the tool. The trusted proxy server receives and verifies whether the tool calling request is malicious. In the case of malicious calling request, the interception is performed. Compared with the prior art method of leaking user private data due to the lack of authentication mechanism for MCP calling requests, the present application can reduce the risk of leaking user private data by malicious calling request through the processing of the trusted proxy server.

[0096] A trusted proxy server is added between the MCP client and the tool server to prevent the malicious server from stealing user private data,

[0097] The technical solutions of the present application and how the technical solutions of the present application solve the above technical problems will be described in detail below with specific examples. The following specific examples can be combined with each other, and the same or similar concepts or processes can not be described again in some examples. The embodiments of the present application will be described below with reference to the accompanying drawings.

[0098] Figure 3 A network architecture with an MCP protocol and a trusted proxy mechanism is provided in the present application, as shown in Figure 3 A trusted proxy server mechanism is added between the MCP client and the tool server, i.e. Proxy shown in Figure 3 The trusted proxy server can be a plug-in or a server, which is not limited in the present application. The trusted proxy server is taken as an example in the present application.

[0099] Optionally, the MCP client and the trusted proxy server can be connected through an invocation interface, and the trusted proxy server and the tool server can be connected through an invocation interface, which is not limited in the present application.

[0100] It should be noted that the execution subject of the present application is the trusted proxy server.

[0101] Figure 4 A flowchart of a tool invocation method is provided in the embodiments of the present application. As shown in Figure 4 The method comprises:

[0102] S101, receiving a tool invocation request sent by a target model.

[0103] Optionally, the target model can be a large language model with tool invocation capability. The tool invocation request can be a structured instruction generated by the MCP client and conforming to the trusted proxy server specification, which is used to trigger tool execution.

[0104] Optionally, the trusted proxy server can receive the tool invocation request through an invocation interface.

[0105] S102, verifying whether the tool invocation request is a malicious invocation request.

[0106] Optionally, the malicious invocation request can be a tool invocation request that does not conform to normal business logic and has bad intentions. This request can be initiated for malicious purposes such as destroying the system, stealing data, and interfering with the normal operation of the service, for example, sending a large number of invalid requests frequently to try to crash the system, or requesting to invoke tools that are not allowed by the system. This malicious invocation request can usually be achieved by tampering with the invocation message sent by the MCP client.

[0107] The non-malicious calling request is initiated by a user based on normal business requirements, and the MCP client reasonably calls corresponding tools according to the calling message to complete a specific task. Therefore, the embodiment verifies the tool calling request to determine whether the request is malicious.

[0108] Optionally, the trusted proxy server can verify the tool calling request through any one or more of signature, request source analysis, request content verification, request behavior pattern verification, and the like, which are not limited in the application.

[0109] S103, in the case of the tool calling request being a malicious calling request, intercepting the tool calling request.

[0110] Optionally, the trusted proxy server can use existing technologies to intercept the malicious calling request, for example, a firewall can be configured with corresponding interception rules, and addresses considered as malicious calling requests can be added to the firewall for interception.

[0111] The embodiment of the application adds a trusted proxy mechanism between the MCP client and the tool, receives and verifies whether the tool calling request is malicious through the trusted proxy mechanism, and intercepts in the case of the tool calling request being a malicious calling request. Compared with the method of leaking user privacy data due to the lack of authentication mechanism for MCP calling requests in the prior art, the application can reduce the risk of leaking user privacy data by malicious calling requests.

[0112] The above describes how the trusted proxy server verifies whether the tool calling request is a malicious calling request. In the case of the tool calling request being a non-malicious calling request, the trusted proxy server of the embodiment of the application can also send the tool calling request to the target tool server corresponding to the tool calling request.

[0113] Optionally, the trusted proxy server can send the tool calling request to the corresponding target tool server through the calling interface, which is not limited in the application.

[0114] In the case of the tool calling request being a non-malicious calling request, the embodiment of the application can send the tool calling request to the target tool server corresponding to the tool calling request, thereby reducing the risk of user privacy data being stolen by malicious servers in the use process of the MCP protocol.

[0115] The following illustrates how to verify whether the tool calling request is a malicious calling request:

[0116] The first way: the tool calling request includes a calling message. The calling message may include, for example, the tool name called, parameters, and the like. Malicious calling requests can usually be achieved by tampering with the calling message, so the embodiment verifies whether the tool calling request is a malicious calling request by verifying whether the calling message carried by the tool calling request is tampered with.

[0117] For example, the application adjusts the information carried by the tool invocation request, and the tool invocation request carries a signature generated based on the invocation message in addition to the invocation message included in the tool invocation request, and the signature can uniquely bind the invocation message.

[0118] Therefore, the trusted proxy server can verify the tool invocation request through the signature to verify whether the invocation message is tampered.

[0119] Optionally, the signature generated based on the invocation message can be generated by using a cryptographic algorithm in the prior art, for example, any one or more of a digital signature algorithm, a hash algorithm, etc., and the application does not limit this.

[0120] The trusted proxy server can verify whether the invocation message is tampered based on the signature. Optionally, the tampering can be one or more of malicious code execution, remote access control, etc. The trusted proxy server can compare whether the signature is changed to verify whether the invocation message is tampered. If the signature is not changed, it is determined that the invocation message is not tampered. If the signature is changed, it is determined that the invocation message is tampered.

[0121] The trusted proxy server can determine whether the tool invocation request is a malicious invocation request based on the result of whether the invocation message is tampered. Optionally, the result of whether the invocation message is tampered can be used as an index reflecting whether the tool invocation request is malicious. In an embodiment, if the invocation message is not tampered, it is determined that the tool invocation request is a non-malicious invocation request. If the invocation message is tampered, it is determined that the tool invocation request is a malicious invocation request.

[0122] The application takes whether the invocation message is tampered as the basis for judgment, and when it is detected that the invocation message is tampered, it is quickly determined to be a malicious invocation request, which can timely block potential security threats and prevent attackers from implementing malicious behaviors such as data theft and system destruction by using the tampered message, thereby effectively improving the security and stability.

[0123] The application verifies the invocation message based on the signature, which can detect whether the message is maliciously modified in transmission, determine whether the request is malicious according to the verification result, effectively intercept the tampered illegal invocation, prevent malicious attackers from implementing malicious behaviors such as data theft and system destruction by forging or tampering the request, and improve the security of tool invocation.

[0124] Taking the signature of the invocation message generated by using a digital signature algorithm as an example, the following describes in detail how the trusted proxy server determines whether the invocation message is tampered.

[0125] In the embodiments of the present application, the public-private key pair can be issued by a certificate authority (CA). Alternatively, the MCP client can generate the public-private key pair using a signature algorithm (e.g., RSA, ECDSA) for the original invocation message. The MCP client can disclose the public key to the trusted proxy server through the target model. The MCP client can generate a first hash value for the original invocation message using a hash function, and encrypt the first hash value using the private key to obtain a signature.

[0126] The MCP client sends the original invocation message and the signature to the trusted proxy server. In an embodiment, the trusted proxy server receives the public key sent through the target model. Alternatively, the trusted proxy server can receive the public key through the invocation interface provided by the target model, which is not limited in the present application.

[0127] The embodiments of the present application can encrypt the original invocation message using the private key and decrypt the original invocation message using the public key. The uniqueness of the public-private key pair can reduce the risk of tampering with the original invocation message by a third party.

[0128] The trusted proxy server receives the invocation message and the signature simultaneously, and performs a hash operation on the invocation message to obtain a second hash value. Alternatively, the process of performing the hash operation on the invocation message can be consistent with the process of generating the first hash value for the original invocation message using the hash function by the MCP client, which is not limited in the present application.

[0129] Based on the first message hash value and the second message hash value, it is determined whether the invocation message is tampered with. Alternatively, the first message hash value and the second message hash value can be compared to determine whether they are consistent. If they are consistent, it can be indicated that the invocation message received by the trusted proxy server is consistent with the original invocation message, and the original invocation message has not been tampered with in the transmission process. If they are not consistent, it can be indicated that the invocation message received by the trusted proxy server is inconsistent with the original invocation message, and the original invocation message has been tampered with in the transmission process.

[0130] The embodiments of the present application use the combination of the public-private key and the hash function to determine whether the original invocation message is generated by the MCP client, and to confirm whether the invocation message is tampered with based on the first message hash value and the second message hash value, thereby achieving double verification of the credibility and accuracy of the original invocation message.

[0131] The second mode: the calling message of the embodiment of the application includes the proof information of the target tool to be called. As described above, the calling message in the prior art can include the tool name, parameters and other related content, and in the application, the calling message can only carry the proof information of the target tool to be called, and the calling of the tool can be realized without revealing the tool name, parameters and other related content. Under the premise that it is confirmed that the calling message is not tampered with, it is verified whether the proof information is valid. The proof information can be used to verify the security of the target tool. Exemplarily, the proof information of the target tool can include any one or more of digital certificate, access token and the like, and the application does not limit this.

[0132] The trusted proxy server can determine whether the tool calling request is a malicious calling request based on the result of whether the calling message is tampered with. If the calling message is tampered with, it is determined that the tool calling request is a malicious calling request. If the calling message is not tampered with, it is verified whether the proof information is valid, and based on the result of whether the proof information is valid, it is determined that the tool calling request is a non-malicious calling request.

[0133] In an embodiment, in the case that the proof information is valid, it is determined that the tool calling request is a non-malicious calling request. In the case that the proof information is invalid, it is determined that the tool calling request is a malicious calling request.

[0134] Optionally, the validity of the proof information can represent that the called tool is safe, i.e., it can be determined that the tool calling request is a non-malicious calling request. The invalidity of the proof information can represent that the called tool has an unsafe factor, i.e., it can be determined that the tool calling request is a malicious calling request.

[0135] The embodiment of the application determines whether the tool calling request is malicious by whether the proof information is valid, ensures that the source of the tool is trusted, and improves the security of the tool calling.

[0136] The embodiment of the application can verify the security of the calling message and the validity of the proof information, and double-verify the calling message. If the calling message is tampered with, it is directly determined that the tool calling request is a malicious calling request. If the calling message is not tampered with, it is further verified whether the proof information is valid, so as to determine that the tool calling request is a non-malicious calling request, and the security of the tool calling is improved.

[0137] In an embodiment, the trusted proxy server can also verify whether the tool calling request is a malicious calling request only according to the proof information of the target tool to be called. The trusted proxy server can verify whether the proof information is valid. In the case that the proof information is valid, it is determined that the tool calling request is a non-malicious calling request. In the case that the proof information is invalid, it is determined that the tool calling request is a malicious calling request.

[0138] The process of verifying whether the tool invocation request is a malicious invocation request according to the attestation information of the target tool to be invoked is consistent with the above, and will not be repeated here.

[0139] The third mode: the tool invocation request further includes input information of the model; the attestation information is attestation information generated by the verification information of the tool description with the input information as a public input. The attestation information integrates the input information and the verification information of the tool description, and can be used as a basis for judging whether the invocation request meets the preset security rules and business logic, effectively resisting security threats such as malicious invocation and fake requests.

[0140] It should be noted that in this implementation mode, the tool invocation request includes an invocation message and a signature, and the invocation message includes attestation information. In the process of invoking the tool, the signature is verified first, and then the attestation information is verified.

[0141] Optionally, the input information of the model can include user input text information, which can be directly input by the user or converted from audio information input by the user, and the present application does not limit it. The verification information of the tool description can be the description information of the tool, and the present application does not limit it.

[0142] The trusted proxy server can verify whether the attestation information is valid, which can include: based on the input information, verifying whether the use relationship between the attestation information and the public parameter is established; the public parameter is generated based on the tool description information.

[0143] Optionally, the public parameter can be randomly generated based on the tool description information, and the present application does not limit it. In an embodiment, the trusted proxy server can receive the public parameter sent through the target model.

[0144] The use relationship between the attestation information and the public parameter can be determined according to the characteristics of the tool, and the present application does not limit it. Optionally, the process of verifying whether the use relationship between the attestation information and the public parameter is established by the trusted proxy server is consistent with the verification process of the above zero-knowledge proof method, and will not be repeated here.

[0145] In the case where the use relationship is established, the trusted proxy server determines that the attestation information is valid. In the case where the use relationship is not established, it is determined that the attestation information is invalid. Optionally, the establishment of the use relationship can represent that the description information of the tool has not been tampered with in the invocation process, i.e., the attestation information is valid. The use relationship is not established, which can represent that the description information of the tool has been tampered with in the invocation process, i.e., the attestation information is invalid.

[0146] The embodiment of the application can verify the security of the proof information through zero-knowledge proof, without contacting the specific information of the tool description, thereby ensuring the authenticity of the tool calling request while strictly protecting the privacy and security of the tool description, determining the effectiveness of the proof information by judging whether the use relationship is established or not, and improving the security of the tool calling.

[0147] Taking a file system tool as an example, Figure 5 A specific tool calling method flowchart provided by the embodiment of the application is shown in FIG. 1. Figure 5 As shown in the figure, the flowchart includes:

[0148] 1. A user requests to call a file system through an MCP client (i.e., a client shown in FIG. 1). Figure 5 2. A trusted proxy server requests the file system to verify the signature, that is, based on the signature, verifies whether the calling message is tampered with. Based on the result of whether the calling message is tampered with, it is determined whether the tool calling request is a malicious calling request. If not, step 3 is performed. If yes, step 4 is performed.

[0149] 3. The trusted proxy server requests the file system.

[0150] 4. The trusted proxy server intercepts the request.

[0151] It should be noted that Step 5 in the above is performed by a malicious server, which modifies the request to reinitiate the calling signature failure. At this time, the trusted proxy server rejects the request and records the malicious server.

[0152] Figure 5 The embodiment of the application also provides an MCP architecture, which includes:

[0153] A host end for calling a target model based on the dialogue data of a user to obtain a dialogue response of the user;

[0154] A target model deployed with an MCP client, for sending a tool calling request to a proxy server based on the MCP client in the process of obtaining the dialogue response in the case of needing to call a target tool;

[0155] A proxy server for verifying whether the tool calling request is a malicious calling request by using the method of the trusted proxy server, and intercepting the tool calling request in the case of the tool calling request being a malicious calling request, and sending the tool calling request to a corresponding target tool server end in the case of the tool calling request being a non-malicious calling request;

[0156] A target tool server end for obtaining a tool calling result by running a target tool and returning to the target model.

[0157] A target tool server end for obtaining a tool calling result by running a target tool and returning to the target model.

[0158] The above is the method embodiment provided by the present application, and the device provided by the present application is described below.

[0159] Figure 6 The structure diagram of a tool calling device provided by the present application is shown in FIG. 2, which comprises a receiving module 201, a verifying module 202 and an intercepting module 203. Figure 6 Optionally, the tool calling device 200 can further comprise a processing module 204.

[0160] The receiving module 201 is configured to receive a tool calling request sent by a target model.

[0161] The verifying module 202 is configured to verify whether the tool calling request is a malicious calling request.

[0162] The intercepting module 203 is configured to intercept the tool calling request if the tool calling request is a malicious calling request.

[0163] Optionally, the tool calling request comprises a calling message and a signature generated based on the calling message. The verifying module 202 is specifically configured to verify whether the calling message is tampered based on the signature. Based on the result of whether the calling message is tampered, it is determined whether the tool calling request is a malicious calling request.

[0164] For example, the signature is obtained by encrypting a first hash value using a private key, and the first hash value is obtained by hashing an original calling message. The verifying module 202 is specifically configured to decrypt the signature using a public key corresponding to the private key to obtain the first hash value. The calling message is hashed to obtain a second hash value. Based on the first hash value and the second hash value, it is determined whether the calling message is tampered.

[0165] In an implementation, the processing module 204 is configured to receive a public key sent by the target model.

[0166] For example, the verifying module 202 is specifically configured to determine that the tool calling request is a malicious calling request if the calling message is tampered. If the calling message is not tampered, it is determined that the tool calling request is not a malicious calling request.

[0167] For example, the calling message comprises proof information of a target tool to be called. The verifying module 202 is specifically configured to determine that the tool calling request is a malicious calling request if the calling message is tampered. If the calling message is not tampered, it is verified whether the proof information is valid, and based on the result of whether the proof information is valid, it is determined that the tool calling request is not a malicious calling request.

[0168] The tool invocation request further includes, for example, input information of the model. The proof information is proof information generated by the tool description as secret input based on the input information. The verification module 202 is specifically configured to verify whether a use relationship between the proof information and the public parameter based on the input information is established. The public parameter is generated based on the tool description information. In the case where the use relationship is established, it is determined that the proof information is valid. In the case where the use relationship is not established, it is determined that the proof information is invalid.

[0169] In an embodiment, the processing module 204 is further configured to receive the public parameter sent by the target model.

[0170] The verification module 202 is specifically configured to determine that the tool invocation request is a non-malicious invocation request in the case where the proof information is valid, and determine that the tool invocation request is a malicious invocation request in the case where the proof information is invalid.

[0171] Optionally, the tool invocation request includes proof information of a target tool to be invoked. The verification module 202 is specifically configured to verify whether the proof information is valid. In the case where the proof information is valid, it is determined that the tool invocation request is a non-malicious invocation request. In the case where the proof information is invalid, it is determined that the tool invocation request is a malicious invocation request.

[0172] In an embodiment, the processing module 204 is further configured to send the tool invocation request to a target tool server corresponding to the tool invocation request in the case where the tool invocation request is a non-malicious invocation request.

[0173] The tool invocation apparatus provided in the embodiment can perform the method provided in any of the above method embodiments, and has similar implementation principles and technical effects. Details are not described herein again.

[0174] Figure 7 A structural schematic diagram of an electronic device provided in the present application is shown in FIG. 5. Figure 7 As shown in FIG. 5, the electronic device 500 provided in the embodiment includes at least one processor 501 and a memory 502. Optionally, the device 500 further includes a communication component 503. The processor 501, the memory 502 and the communication component 503 are connected through a bus 504.

[0175] In the specific implementation process, the at least one processor 501 executes the computer execution instructions stored in the memory 502, so that the at least one processor 501 performs the above method.

[0176] The specific implementation process of the processor 501 can refer to the above method embodiments, and has similar implementation principles and technical effects. Details are not described herein again.

[0177] In the above embodiments, it should be understood that the processor can be a central processing unit (CPU) and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or can also be any conventional processor. The steps of the method disclosed in combination with the application can be directly embodied as hardware processor execution or combined with hardware and software modules in the processor for execution.

[0178] The memory can include a random access memory (RAM) and can also include a non-volatile memory (NVM), such as at least one disk memory.

[0179] The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application does not limit to only one bus or one type of bus.

[0180] The present application also provides a computer program product comprising a computer program which, when executed by a processor, implements the above method.

[0181] The present application also provides a computer readable storage medium having computer execution instructions stored therein, wherein when a processor executes the computer execution instructions, the above method is implemented.

[0182] The above readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0183] An example readable storage medium is coupled to the processor such that the processor can read information from the readable storage medium and can write information to the readable storage medium. Of course, the readable storage medium can also be a part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in the device.

[0184] The division of units is only a logical functional division, and in actual implementation, there can be another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0185] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0186] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0187] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the part of the present application that essentially contributes to the prior art or the part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The foregoing storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

[0188] Those skilled in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction related hardware. The foregoing program can be stored in a computer readable storage medium. The program executes to perform the steps of the above-mentioned method embodiments; and the foregoing storage medium includes various media capable of storing program codes, such as ROM, RAM, magnetic disk, or optical disk.

[0189] Finally, it should be noted that other embodiments of the present application will readily occur to those skilled in the art upon consideration of the specification and practice of the present application disclosed herein. The present application is intended to include all such variations as fall within the general scope of the application, and includes the generic principles disclosed and the best mode known to the inventors to be currently practiced as well as variations thereof, without departing from the scope of the present application as defined by the claims. The specification and examples give the best application of the present application as known to at least one of the inventors at the time of the filing of this application. It is to be understood that since numerous modifications and changes will readily occur to those skilled in the art, the application is not to be limited to the exact construction and operation as illustrated and described. Accordingly, all such variations are intended to be included within the scope of the present application as defined in the claims. The application is to be limited only by the claims.

Claims

1. A tool invocation method, characterized by, The method comprises: receiving a tool invocation request sent by a target model; verifying whether the tool invocation request is a malicious invocation request; intercepting the tool invocation request if the tool invocation request is a malicious invocation request.

2. The method of claim 1, wherein, The tool invocation request comprises an invocation message and a signature generated based on the invocation message; The verification of whether the tool invocation request is a malicious invocation request comprises: verifying whether the invocation message is tampered with based on the signature; determining whether the tool invocation request is a malicious invocation request based on the result of whether the invocation message is tampered with.

3. The method of claim 2, wherein, The signature is obtained by encrypting a first hash value using a private key, and the first hash value is obtained by hashing an original invocation message; The verification of whether the invocation message is tampered with based on the signature comprises: decrypting the signature using a public key corresponding to the private key to obtain the first hash value; hashing the invocation message to obtain a second hash value; determining whether the invocation message is tampered with based on the first hash value and the second hash value.

4. The method of claim 3, wherein, The method further comprises: receiving the public key sent by the target model.

5. The method of claim 2, wherein, The determination of whether the tool invocation request is a malicious invocation request based on the result of whether the invocation message is tampered with comprises: if the invocation message is tampered with, determining that the tool invocation request is a malicious invocation request; if the invocation message is not tampered with, determining that the tool invocation request is a non-malicious invocation request.

6. The method of claim 2, wherein, The invocation message comprises proof information of a target tool to be invoked; The determination of whether the tool invocation request is a malicious invocation request based on the result of whether the invocation message is tampered with comprises: if the invocation message is tampered with, determining that the tool invocation request is a malicious invocation request; if the invocation message is not tampered with, verifying whether the proof information is valid, and determining that the tool invocation request is a non-malicious invocation request based on the result of whether the proof information is valid.

7. The method of claim 6, wherein, The tool invocation request further comprises input information of a model; the proof information is proof information generated by taking the input information as public input and taking verification information of a tool description as secret input; The verification of whether the proof information is valid comprises: verifying whether a use relationship between the proof information and a public parameter is established based on the input information; the public parameter is generated based on the tool description information; if the use relationship is established, determining that the proof information is valid; if the use relationship is not established, determining that the proof information is invalid.

8. The method of claim 7, wherein, The method further comprises: receiving the public parameter sent by the target model.

9. The method of claim 6, wherein, The determination of the tool invocation request as a non-malicious invocation request based on the result of whether the proof information is valid comprises: if the proof information is valid, determining that the tool invocation request is a non-malicious invocation request; if the proof information is invalid, determining that the tool invocation request is a malicious invocation request.

10. The method of claim 1, wherein, The tool invocation request comprises proof information of a target tool to be invoked; The method further comprises: In the case that the tool calling request is a non-malicious calling request, sending the tool calling request to a target tool server corresponding to the tool calling request. Comprise: A receiving module, configured to receive a tool calling request sent through a target model; 11. The method according to any one of claims 1 to 10, characterized in that, A verifying module, configured to verify whether the tool calling request is a malicious calling request; An intercepting module, configured to intercept the tool calling request in the case that the tool calling request is a malicious calling request.

12. A tool invocation apparatus, characterized by Comprise: A memory and a processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the processor executes the method according to any one of claims 1-11.

13. An electronic device, comprising: The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method according to any one of claims 1-11. The computer program is executed by the processor to implement the method according to any one of claims 1-11. The architecture comprises: A host end, configured to call a target model to obtain a conversation response of a user based on conversation data of the user; 14. A computer-readable storage medium, characterized in that, The target model is deployed with an MCP client, and is configured to send a tool calling request to a proxy server based on the MCP client in the case that a target tool needs to be called in the process of obtaining the conversation response; 15. A computer program product, characterised in that, The proxy server is configured to verify whether the tool calling request is a malicious calling request by using the method according to any one of claims 1-11, intercept the tool calling request in the case that the tool calling request is a malicious calling request, and send the tool calling request to a corresponding target tool server in the case that the tool calling request is a non-malicious calling request; 16. An MCP architecture, characterized by, The target tool server is configured to obtain a tool calling result by running the target tool and return to the target model. ​ ​ ​ ​

Images