Tool operating method and apparatus

Abstract

This application provides a tool execution method and apparatus. The tool execution method includes: in a first case, obtaining the context of a first task, where the first task is a task to be completed by a target tool, and the target tool or a Model Context Protocol (MCP) tool called by the target tool corresponds to a first risk level, which is obtained in an initial authorization of the target tool or the MCP tool called by the target tool; performing a second authorization on the first task based on the context of the first task to obtain a first permission set, where the first permission set satisfies the condition that a second risk level is lower than or equal to the first risk level, and the second risk level is the highest risk level among the risk levels corresponding to the permissions in the first permission set; constructing a first sandbox execution environment based on the first permission set; and running the target tool in the first sandbox execution environment to execute the first task. This application can improve security and further narrow the scope of permission usage, thereby improving the authorization experience and efficiency.

Description

[0001] This application is a divisional application. The original application has the application number 202511724909.6 and the original application date is November 21, 2025. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to artificial intelligence (AI) technology, and more particularly to a method and apparatus for operating a tool. Background Technology

[0003] The Model Context Protocol (MCP), as an open and standardized protocol, enables Large Language Models (LLMs) to communicate with dedicated tool servers via clients, thereby securely and structurally invoking external tools, data sources, and Application Programming Interfaces (APIs). The core value of MCP lies in combining the cognitive capabilities of LLMs with the execution capabilities of external tools, significantly enhancing the practicality and scope of AI applications. However, this "empowerment" process also introduces unprecedented security risks, expanding the capabilities of LLMs from information processing to the actual manipulation of real-world systems and data.

[0004] Therefore, there is an urgent need for a security protection technology for invoking external tools. Summary of the Invention

[0005] This application provides a tool operation method and apparatus to improve security and further narrow the scope of permission use, thereby improving the authorization experience and efficiency.

[0006] In a first aspect, this application provides a tool operation method, comprising: in a first case, obtaining the context of a first task, wherein the first task is a task to be completed by a target tool, the target tool or a Model Context Protocol (MCP) tool invoked by the target tool corresponds to a first risk level, the first risk level being obtained in a first authorization of the target tool or the MCP tool invoked by the target tool; performing a second authorization on the first task based on the context of the first task to obtain a first permission set, wherein the first permission set satisfies the condition that a second risk level is lower than or equal to the first risk level, the second risk level being the highest risk level among the risk levels corresponding to the permissions in the first permission set; constructing a first sandbox execution environment based on the first permission set; and running the target tool in the first sandbox execution environment to execute the first task.

[0007] This application assesses the permissions available to the target tool in real time based on the context of the task to be executed, and judges the rationality of the permissions available to the target tool based on the risk level. On the one hand, it can improve security, and on the other hand, it can further narrow the scope of permission usage, limiting the target tool to execute the first task with "least privileges" (first set of privileges) in each task, reducing the attack surface, and improving the authorization experience and efficiency.

[0008] The first task is a task that the target tool is meant to accomplish.

[0009] Optionally, the target tool may include an MCP tool. In this case, the first task can be a task that the MCP tool needs to complete. For example, if the target tool (MCP tool) is the Ctrip application, the first task could be purchasing tickets through the Ctrip application. This scenario corresponds to a locally deployed MCP tool, where the system can directly interact with the MCP tool.

[0010] Optionally, the target tool may include a proxy. In this case, the first task can be a task that the proxy needs to complete when calling the MCP tool. For example, if the target tool (proxy) is Doubao, the first task could be Doubao reading the local image library in order to remotely call the image editing application (MCP tool) to complete the image editing of the local image. This scenario corresponds to remotely calling the MCP tool, where the system needs to interact with the MCP tool through the proxy.

[0011] The aforementioned target tool or the MCP tool invoked by the target tool corresponds to a first risk level, which is obtained during a single authorization process. That is, when the target tool or the MCP tool invoked by the target tool registers with the registry center, the system can authorize the target tool or the MCP tool invoked by the target tool once, during which the target tool or the MCP tool invoked by the target tool is matched with a risk level (first risk level). For example, this application can configure three risk levels (high / medium / low). For the target tool or the MCP tool remotely invoked by the target tool, content security checks can be performed on it through tool access control, and then risk classification can be performed based on the check results, matching it to a high / medium / low risk level. Optionally, a risk level label (high / medium / low risk level label) can be applied to the target tool or the MCP tool remotely invoked by the target tool.

[0012] In this application, the first case can include a first risk level higher than a level threshold. For example, with the aforementioned three risk levels of high / medium / low, if the level threshold is set to low risk, then the first case can include the target tool or the MCP tool called by the target tool corresponding to a high / medium risk level. More generally, N (N>1) risk levels can be divided, and the level threshold can be set to n1 (n1<N) risk levels. The first case can include risk levels higher than n1.

[0013] In one possible implementation, the first scenario may include a high-risk level or a medium-risk level where the first task has not been authorized. This application can grant permissions (secondary authorization) to the first task to be completed by the target tool during runtime, based on the risk level of the target tool or the MCP tool it calls. For example, if the target tool or the MCP tool it calls has a high risk level during runtime (e.g., operating the kernel, involving monetary transactions), secondary authorization is required each time the first task is executed. If the target tool or the MCP tool it calls has a medium risk level during runtime, and the first task has not been authorized, secondary authorization can be performed, and the authorization result is valid for the lifecycle of the target tool. These two scenarios constitute the first scenario.

[0014] When the target tool is running, if the risk level of the target tool or the MCP tool it calls is low (e.g., it does not operate on the system), or if the risk level of the target tool or the MCP tool it calls is medium and the first task has already been authorized, then secondary authorization is not required. This situation can be referred to as the second situation below.

[0015] In this application, the system can grant or deny secondary authorization to the target tool or the MCP tool called by the target tool based on risk level. Low-risk levels do not require secondary authorization, medium-risk levels allow a single secondary authorization to remain valid indefinitely, and high-risk levels require secondary authorization for each task execution. This enables fine-grained authorization at the task level, and by determining the frequency of secondary authorization according to risk level, it improves the efficiency of authorization for different tasks.

[0016] The context of the first task includes at least one of the following: user-inputted intent information via the interactive interface, current environment information, or target tool's functional information. During the aforementioned primary or secondary authorization process, the user can input intent information via the interactive interface. For example, when the system installs or runs the target tool, a pop-up window prompts the user about the permissions the target tool needs / may use (e.g., microphone, speaker, camera, read / write gallery, location, etc.). The user can then select the permissions they wish to grant (e.g., location, camera, read / write gallery). These selected permissions express the user's intent and constitute intent information. Another example is when the system installs or runs the target tool, a pop-up window prompts the user whether they agree to the target tool running automatically. The user can then choose to agree to the target tool running automatically, and the system can automatically assess the risk level of the target tool and grant it the corresponding system permissions. Current environment information may include the system's security status, whether it has been intruded upon, whether it has been maliciously attacked, etc. Furthermore, current environment information may also include the system's resource consumption and computing environment information. The target tool's functional information may include the target tool's name, function description, attributes, permission requirements, and resource requirements. The context of the first task described above is merely an example and does not constitute a limitation on the context of the first task. This application does not impose any specific limitations on it.

[0017] In a single authorization, a fourth set of permissions can be granted to the target tool based on the user's authorization actions on the interactive interface. This fourth set of permissions includes one or more permissions from the system permission set. The user can input their desired information through the interactive interface. This authorization can be considered a permission declaration for the target tool during its registration process (granting one or more permissions from the system permission set), and the resulting permission set (the fourth set of permissions) limits the maximum scope of permissions for subsequent secondary authorizations. Therefore, the first set of permissions mentioned below is a subset of the fourth set of permissions; that is, any permission in the first set is also a permission in the fourth set of permissions.

[0018] In this application, the system can first obtain a second permission set based on the context of the first task, which includes one or more permissions in the system permission set; then obtain a third permission set, which is the permission set that the target tool will use during the execution of the first task, and includes one or more permissions in the system permission set; and then obtain the first permission set based on the second permission set and the third permission set.

[0019] The system assesses the set of permissions required by the target tool to perform its first task (the first permission set, i.e., the set of permissions the target tool can use to perform the first task) based on multi-dimensional contextual information such as the user's intentions input through the interactive interface, current environment information, and tool functionality information. It determines whether system permissions are needed based on user intent, whether the current environment is secure based on collected environmental information, and whether system permissions are required to complete the corresponding function based on tool functionality. If the user intent is met and the environment is secure, permissions are granted; if the user intent is deviated from or the environment is risky, permissions are denied; if permissions are not required to complete the function, permissions are denied.

[0020] The system can obtain a third set of permissions based on the permission requests made by the target tool during the execution of the first task. During the execution of the first task, the target tool requests system permissions from the system via API; this third set of permissions represents the set of permissions that the target tool expects or wants to use when executing the first task.

[0021] The system can obtain the first permission set based on the second and third permission sets using the following two methods: Method 1: Obtain the intersection of the second and third permission sets; obtain the first permission set based on the intersection.

[0022] As mentioned above, the second permission set represents the set of permissions that the target tool can use when performing the first task, and the third permission set represents the set of permissions that the target tool expects or wants to use when performing the first task. If there are permissions in the third permission set that do not belong to the second permission set, it means that the target tool has requested permissions that it cannot use, and these permissions cannot be granted to the target tool. Therefore, we can first take the intersection of the second and third permission sets, exclude the permissions in the third permission set that do not belong to the second permission set, and then obtain the first permission set based on the intersection of the permissions.

[0023] Method 2: If there are permissions in the third permission set that do not belong to the second permission set, then the first permission set is determined to be empty; if there are no permissions in the third permission set that do not belong to the second permission set, then the intersection of the permissions of the second and third permission sets is obtained, and the first permission set is obtained based on the intersection of the permissions.

[0024] Similarly, the second permission set represents the set of permissions the target tool can use when performing the first task, and the third permission set represents the set of permissions the target tool expects or wants to use when performing the first task. If the third permission set contains permissions that do not belong to the second permission set, it means that the target tool has requested permissions that it cannot use. These permissions cannot be granted to the target tool, and in this case, it can be considered that the target tool has been compromised or tampered with. Therefore, no permissions should be granted to it, i.e., the first permission set is determined to be empty. Conversely, if the third permission set does not contain permissions that do not belong to the second permission set, it means that the target tool is trustworthy. In this case, the intersection of the permissions in the second and third permission sets can be taken first, and then the first permission set can be obtained based on the intersection.

[0025] In this application, in addition to the condition that the first permission set is a subset of the fourth permission set, the first permission set must also satisfy the condition that the second risk level is lower than or equal to the first risk level, and the second risk level is the highest risk level among the risk levels corresponding to the permissions in the first permission set.

[0026] The system can pre-classify system permissions, corresponding to the aforementioned risk levels. For example, permissions such as memory access, payment, and location services are classified as high-risk; microphone, speaker, camera, and calendar permissions are classified as medium-risk; and floating window and notification permissions are classified as low-risk. Optionally, the system can group / set system permissions according to risk levels, with each group / set corresponding to a risk level. Based on this, target tools with different risk levels can use different permission sets. High-risk target tools can use low-risk permission sets, while low-risk target tools cannot use high-risk permission sets, thus ensuring minimal system exposure.

[0027] One or more permissions in the first permission set each correspond to a risk level, while the second risk level is the highest among the risk levels corresponding to the one or more permissions in the first permission set. If the second risk level is lower than or equal to the first risk level, it means that the risk level of all permissions in the first permission set is lower than or equal to the first risk level. In other words, a high-risk target tool can use a set of permissions with lower risk levels that have been declared in a single authorization. For example, the first task could be purchasing tickets through the Ctrip app (the target tool). Based on this, the first permission set includes payment and camera access (both declared in an initial authorization), both of which are at a high-risk level (second risk level). The risk level of the Ctrip app (first risk level) is high, so the second risk level equals the first risk level. The first permission set meets the conditions, therefore the first permission set can be granted to the target tool. Alternatively, the first task could be that Doubao (the target tool) reads the local image library in order to remotely call a photo editing app (the MCP tool called by the target tool) to complete the photo editing of local images. Based on this, the first permission set includes reading the image library and communication (both declared in an initial authorization), both of which are at a medium-risk level (second risk level). The risk level of the photo editing app (first risk level) is medium, so the second risk level equals the first risk level. The first permission set meets the conditions, therefore the first permission set can be granted to the target tool.

[0028] To ensure that the first permission set satisfies the condition that the second risk level is lower than or equal to the first risk level, obtaining the first permission set based on the permission intersection as described above may include: obtaining the risk levels corresponding to the permissions in the permission intersection; if there is a risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permissions corresponding to the risk levels higher than the first risk level are deleted from the permission intersection to obtain the first permission set; if there is no risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permission intersection is determined as the first permission set. That is, further judgment is made on the permission intersection obtained from the second and third permission sets using one of the above two methods. If there is a risk level higher than the first risk level (a risk level that does not meet the condition) among the risk levels corresponding to all permissions in the permission intersection, then the permissions corresponding to the risk levels that do not meet the condition are deleted from the permission intersection to obtain the first permission set; if there is no risk level higher than the first risk level among the risk levels corresponding to all permissions in the permission intersection, then the permission intersection is directly determined as the first permission set. The final first permission set obtained in this way is not only the permission set that the target tool can use when performing the first task (in accordance with user wishes, current environment, and tool functions), but also the permission set that the target tool expects or wants to use when performing the first task (in accordance with the target tool's request), or the permission set that meets the condition that the second risk level is lower than or equal to the first risk level (in accordance with the risk level of granting permissions for the first task not exceeding the risk level of the target tool or the MCP tool called by the target tool).

[0029] This application adopts a "sandbox isolation" mechanism, which limits the tool to execute each task with "least privileges and least resource scope" to prevent the tool from accessing system resources without authorization.

[0030] In one possible implementation, the method further includes: in the second case, obtaining the historical permission set of the second task; constructing a second sandbox execution environment for the second task based on the historical permission set; and running the second task in the second sandbox execution environment.

[0031] Corresponding to the first scenario above, the second scenario can include a first risk level that is lower than or equal to the risk level threshold. For example, with the three risk levels of high / medium / low mentioned above, the risk level threshold can be set to low risk level, then the second scenario can include the target tool or the MCP tool called by the target tool corresponding to a low risk level. More generally, N (N>1) risk levels can be divided, and the risk level threshold can be set to n1 (n1<N) risk levels, then the second scenario can include risk levels that are lower than or equal to n1.

[0032] In one possible implementation, the second scenario includes either a low-risk level first, or a medium-risk level first and the second task already authorized. A low-risk level may not require secondary authorization, while a medium-risk level allows for long-term validity of any previously granted secondary authorization. Therefore, if a medium-risk level task has already been authorized, secondary authorization may not be necessary.

[0033] Therefore, in the second scenario, the historical permission set of the second task can be obtained. This historical permission set can be obtained from a single authorization or from a previous instance when the target tool executed the second task. For the second task in this scenario, the historical permission set of the second task can be directly granted to the target tool, thereby creating a sandbox execution environment for it. This reduces the frequency of authorization and improves authorization efficiency for target tools with lower risk levels.

[0034] Secondly, this application provides a tool running apparatus, comprising: an acquisition module, configured to, in a first case, acquire the context of a first task, wherein the first task is a task to be completed by a target tool, the target tool or a Model Context Protocol (MCP) tool invoked by the target tool corresponds to a first risk level, the first risk level being obtained in a first authorization of the target tool or the MCP tool invoked by the target tool; an authorization module, configured to, based on the context of the first task, perform a second authorization on the first task to obtain a first permission set, wherein the first permission set satisfies the condition that a second risk level is lower than or equal to the first risk level, the second risk level being the highest risk level among the risk levels corresponding to the permissions in the first permission set; and a running module, configured to, based on the first permission set, construct a first sandbox execution environment; and run the target tool in the first sandbox execution environment to execute the first task.

[0035] In one possible implementation, the first case includes the first risk level being higher than the level threshold.

[0036] In one possible implementation, the first situation includes either the first risk level being high-risk, or the first risk level being medium-risk and the first task not being authorized.

[0037] In one possible implementation, the authorization module is specifically configured to: evaluate a second permission set based on the context of the first task, the second permission set including one or more permissions in the system permission set; obtain a third permission set, the third permission set being the permission set to be used by the target tool during the execution of the first task, the third permission set including one or more permissions in the system permission set; and obtain the first permission set based on the second permission set and the third permission set.

[0038] In one possible implementation, the authorization module is specifically used to obtain the third permission set based on the permission request during the execution of the first task by the target tool.

[0039] In one possible implementation, the authorization module is specifically used to obtain the intersection of the permissions of the second permission set and the third permission set; and to obtain the first permission set based on the permission intersection.

[0040] In one possible implementation, the authorization module is specifically configured to determine that the first permission set is empty if there are permissions in the third permission set that do not belong to the second permission set; and if there are no permissions in the third permission set that do not belong to the second permission set, obtain the intersection of the permissions of the second permission set and the third permission set, and obtain the first permission set based on the intersection of the permissions.

[0041] In one possible implementation, the authorization module is specifically used to obtain the risk level corresponding to the permissions in the permission intersection; if there is a risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permissions corresponding to the risk levels higher than the first risk level are deleted from the permission intersection to obtain the first permission set; if there is no risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permission intersection is determined as the first permission set.

[0042] In one possible implementation, the context of the first task includes at least one of the following: user intent information input through an interactive interface, current environment information, or functional information of the target tool.

[0043] In one possible implementation, the target tool includes an MCP tool, and the first task is a task that the MCP tool is to perform; or, the target tool includes an agent, and the first task is a task that the agent is to perform when it invokes the MCP tool.

[0044] In one possible implementation, the acquisition module is further configured to, in a second case, acquire a historical permission set for a second task, wherein the second task is a task to be completed by the target tool; the running module is further configured to, based on the historical permission set, construct a second sandbox execution environment for the second task to run; and run the second task in the second sandbox execution environment.

[0045] In one possible implementation, the second case includes the first risk level being lower than the level threshold.

[0046] In one possible implementation, the second situation includes either the first risk level being low-risk, or the first risk level being medium-risk and the second task having been authorized.

[0047] In one possible implementation, the authorization module is further configured to match the first risk level to the target tool or the MCP tool called by the target tool during the registration phase based on tool access control.

[0048] In one possible implementation, the authorization module is further configured to obtain a fourth set of permissions authorized to the target tool based on the user's authorization operation on the interactive interface, the fourth set of permissions including one or more permissions in the system permission set.

[0049] In one possible implementation, the first permission set is a subset of the fourth permission set.

[0050] Thirdly, this application provides an electronic device, comprising: one or more processors; a memory for storing one or more programs; and when the one or more programs are executed by the one or more processors, causing the one or more processors to perform the method as described in any one of the first aspects above.

[0051] Fourthly, this application provides a computer-readable storage medium including a computer program that, when executed on a computer, causes the computer to perform the method described in any one of the first aspects above.

[0052] Fifthly, this application provides a computer program product comprising computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects above. Attached Figure Description

[0053] Figure 1 This is a schematic block diagram of the device 100 of this application.

[0054] Figure 2 This is a diagram illustrating the security protection mechanism architecture of this application.

[0055] Figure 3 A flowchart of the process 300 for the tool operation method provided in this application.

[0056] Figure 4 This is a flowchart of the tool operation method of this application.

[0057] Figure 5 This is another flowchart of the tool operation method of this application.

[0058] Figure 6 The flowchart shows the target tool as the local MCP tool.

[0059] Figure 7 A flowchart for using a target tool as a proxy (remotely calling an MCP tool).

[0060] Figure 8 This is a schematic diagram of the structure of the tool operating device 800 of this application. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0062] The terms "first," "second," etc., used in the specification, embodiments, claims, and drawings of this application are for distinguishing purposes only and should not be construed as indicating or implying relative importance or order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, such as including a series of steps or units. A method, system, product, or apparatus is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0063] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0064] To facilitate understanding, some nouns or terms used in this application will be explained below, and these nouns or terms are also part of the content of the invention.

[0065] 1. Model Context Protocol (MCP) MCP aims to integrate Large Language Models (LLMs) with external resources and tools, establishing a secure, bidirectional connection between the large model and data sources. MCP is an open protocol that standardizes how applications provide context to the LLM, defining a set of common communication protocols, data formats, and rules. It offers features such as simplified development, flexibility, real-time response, security and compliance, and scalability.

[0066] 2. Large Language Model (LLM) LLM (Local Language Processing) is an artificial intelligence technique based on deep learning and a core research area in natural language processing. Its core principle is to train models using large-scale datasets, enabling them to generate natural language text or understand the meaning of spoken text. LLM performs exceptionally well in a variety of applications, capable of performing not only simple language tasks such as spell checking and grammar correction, but also complex tasks like text summarization, machine translation, sentiment analysis, dialogue generation, and content recommendation.

[0067] Figure 1 This is a schematic block diagram of the device 100 of this application, as shown below. Figure 1 As shown, the device 100 may include a processor 101 and a transceiver / transceiver pin 102, and optionally, a memory 103.

[0068] The various components of device 100 are coupled together via bus 104, which includes a data bus, a power bus, a control bus, and a status signal bus. For clarity, all buses are referred to as bus 104 in the figure.

[0069] Optionally, the memory 103 can be used to store instructions in the embodiments of this application. The processor 101 can be used to execute the instructions in the memory 103, control the receive pin to receive signals, and control the transmit pin to transmit signals.

[0070] Device 100 may be an electronic device or a chip of an electronic device in the embodiments of this application. The electronic device may include a computer, a terminal device, a tablet computer, etc.

[0071] It should be understood that, Figure 1 The components included in the illustrated structure do not constitute a specific limitation on device 100. In other embodiments of this application, device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements, etc.

[0072] Figure 2 This is an architecture diagram of the security protection mechanism of this application, such as Figure 2 As shown, this security mechanism can be deployed in device 100 and includes the following modules: 1. MCP tool, which includes the following functions: (1) Developer signature: Verify the identity of the tool developer and ensure that the tool source is trustworthy.

[0073] (2) Functional declaration / permission declaration: Clearly define the functional scope and required permissions of the tool to provide a basis for subsequent permission control.

[0074] 2. The tool gateway is the "central hub" ensuring secure calls to MCP tools, and includes the following security verification and access control sub-modules: (1) Tool Agent: Responsible for user authorization, identity authentication, input validation, permission application and evaluation, and serves as a "secure bridge" for interaction between users / intelligent agents and the system.

[0075] "User Authorization": Receives user instructions on granting permissions to the tool.

[0076] "Identity Authentication": Verifies the legitimacy of a user's or agent's identity.

[0077] "Input Validation": Checks the compliance of the tool's input parameters to prevent malicious input.

[0078] "Permission assessment": Evaluate the permissions (e.g., file, network, application call, system call, hardware call permissions) and resource / task strength requested by the tool to assess whether they comply with user intent and security rules.

[0079] (2) Tool Access Control: This involves security checks on MCP tools, assessing their security, and providing a basis for risk level labeling for tool agents. It may include the following functions: "Signature Verification": This feature verifies the developer's signature of the MCP tool to ensure that the tool has not been tampered with during installation and that its source is absolutely trustworthy.

[0080] "Permission check": Verify whether the permissions declared by the tool match the actual functions (for example, if the tool declares "only read file permissions are required", but the actual code contains logic to modify system configuration, it will be judged as a permission abnormality).

[0081] "Malicious Server Detection": Checks whether the tool contains malicious code, is associated with malicious services, phishing interfaces, or illegal data transmission links, ensuring that the tool's content is not malicious.

[0082] "External Interface Security Testing": Verify the security of the interfaces exposed by the tool, including whether the interfaces have vulnerabilities and whether they comply with secure communication specifications.

[0083] (3) Tool isolation: The "sandbox isolation" mechanism is adopted to limit the tools to execute with "minimum privileges and minimum resource scope" in each task, so as to prevent the tools from accessing system resources without authorization.

[0084] (5) Log recording: Record the "Installation and Update Record", "Execution Process Record" and "Sensitive Operation Record" throughout the process to provide a basis for auditing and tracing.

[0085] 3. Agent and MCP Client: MCP Client: As the interaction entry point between the Agent and the tool gateway, it is responsible for initiating tool call requests.

[0086] Agent: Can be understood as an intelligent task executor that collaborates with the tool gateway through the MCP Client to complete tool selection / invocation.

[0087] 4. System Layer (MCP Server): MCP Server: The final execution environment of the tool, which can access resources such as the system's "public directory", "system directory", "applications", "hardware", and "system calls" to complete the tool's functional logic.

[0088] Based on the above modules, the security protection mechanism of this application is divided into two stages: tool installation and tool operation.

[0089] During the tool installation (registration) phase, a content security check is performed on the MCP tool before installation via tool access control, and the check results are sent to the registration center. When the registration center registers the MCP tool, a risk level label is assigned to the MCP tool based on the aforementioned check results. Furthermore, at this stage, a declaration of permissions for the MCP tool can be made based on the user's choice (granting one or more permissions from the system permission set). In this application, this stage can also be referred to as an authorization stage, including the registration classification (risk level labeling) and permission declaration of the MCP tool.

[0090] During the tool execution phase, the MCP Client collaborates with the tool gateway to complete tool selection / invocation. Users can input authorization permissions through the interactive interface, then the user / Agent is authenticated, and the user / Agent input is validated. Based on this, permission assessment is performed and the authorization result is returned. Based on the authorization result, a "sandbox isolation" mechanism is adopted to limit the tool to execute with "least privileges and least resource scope" in each task, preventing the tool from accessing system resources without authorization.

[0091] Based on the above content, the technical solution of the tool operation method provided in this application will be described below.

[0092] Figure 3 A flowchart of process 300 for the tool operation method provided in this application. Process 300 can be executed by the aforementioned device 100. Process 300 is described as a series of steps or operations, and it should be understood that process 300 can be executed in various orders and / or occur simultaneously, and is not limited to... Figure 3 The execution order is shown. Process 300 may include: Step 301: In the first case, obtain the context of the first task.

[0093] The first task is a task that the target tool is meant to accomplish.

[0094] Optionally, the target tool may include an MCP tool. In this case, the first task can be a task that the MCP tool needs to complete. For example, if the target tool (MCP tool) is the Ctrip application, the first task could be purchasing tickets through the Ctrip application. This scenario corresponds to a locally deployed MCP tool, where the system can directly interact with the MCP tool.

[0095] Optionally, the target tool may include a proxy. In this case, the first task can be a task that the proxy needs to complete when calling the MCP tool. For example, if the target tool (proxy) is Doubao, the first task could be Doubao reading the local image library in order to remotely call the image editing application (MCP tool) to complete the image editing of the local image. This scenario corresponds to remotely calling the MCP tool, where the system needs to interact with the MCP tool through the proxy.

[0096] The aforementioned target tool or the MCP tool invoked by the target tool corresponds to a first risk level, which is obtained during a single authorization process. That is, when the target tool or the MCP tool invoked by the target tool registers with the registry center, the system can authorize the target tool or the MCP tool invoked by the target tool once, during which the target tool or the MCP tool invoked by the target tool is matched with a risk level (first risk level). For example, this application can configure three risk levels (high / medium / low). For the target tool or the MCP tool remotely invoked by the target tool, content security checks can be performed on it through tool access control, and then risk classification can be performed based on the check results, matching it to a high / medium / low risk level. Optionally, a risk level label (high / medium / low risk level label) can be applied to the target tool or the MCP tool remotely invoked by the target tool.

[0097] In this application, the first case can include a first risk level higher than a level threshold. For example, with the aforementioned three risk levels of high / medium / low, if the level threshold is set to low risk, then the first case can include the target tool or the MCP tool called by the target tool corresponding to a high / medium risk level. More generally, N (N>1) risk levels can be divided, and the level threshold can be set to n1 (n1<N) risk levels. The first case can include risk levels higher than n1.

[0098] In one possible implementation, the first scenario may include a high-risk level or a medium-risk level where the first task has not been authorized. This application can grant permissions (secondary authorization) to the first task to be completed by the target tool during runtime, based on the risk level of the target tool or the MCP tool it calls. For example, if the target tool or the MCP tool it calls has a high risk level during runtime (e.g., operating the kernel, involving monetary transactions), secondary authorization is required each time the first task is executed. If the target tool or the MCP tool it calls has a medium risk level during runtime, and the first task has not been authorized, secondary authorization can be performed, and the authorization result is valid for the lifecycle of the target tool. These two scenarios constitute the first scenario.

[0099] When the target tool is running, if the risk level of the target tool or the MCP tool it calls is low (e.g., it does not operate on the system), or if the risk level of the target tool or the MCP tool it calls is medium and the first task has already been authorized, then secondary authorization is not required. This situation can be referred to as the second situation below.

[0100] In this application, the system can grant or deny secondary authorization to the target tool or the MCP tool called by the target tool based on risk level. Low-risk levels do not require secondary authorization, medium-risk levels allow a single secondary authorization to remain valid indefinitely, and high-risk levels require secondary authorization for each task execution. This enables fine-grained authorization at the task level, and by determining the frequency of secondary authorization according to risk level, it improves the efficiency of authorization for different tasks.

[0101] The context of the first task includes at least one of the following: user-inputted intent information via the interactive interface, current environment information, or target tool's functional information. During the aforementioned primary or secondary authorization process, the user can input intent information via the interactive interface. For example, when the system installs or runs the target tool, a pop-up window prompts the user about the permissions the target tool needs / may use (e.g., microphone, speaker, camera, read / write gallery, location, etc.). The user can then select the permissions they wish to grant (e.g., location, camera, read / write gallery). These selected permissions express the user's intent and constitute intent information. Another example is when the system installs or runs the target tool, a pop-up window prompts the user whether they agree to the target tool running automatically. The user can then choose to agree to the target tool running automatically, and the system can automatically assess the risk level of the target tool and grant it the corresponding system permissions. Current environment information may include the system's security status, whether it has been intruded upon, whether it has been maliciously attacked, etc. Furthermore, current environment information may also include the system's resource consumption and computing environment information. The target tool's functional information may include the target tool's name, function description, attributes, permission requirements, and resource requirements. The context of the first task described above is merely an example and does not constitute a limitation on the context of the first task. This application does not impose any specific limitations on it.

[0102] In a single authorization, a fourth set of permissions can be granted to the target tool based on the user's authorization actions on the interactive interface. This fourth set of permissions includes one or more permissions from the system permission set. The user can input their desired information through the interactive interface. This authorization can be considered a permission declaration for the target tool during its registration process (granting one or more permissions from the system permission set), and the resulting permission set (the fourth set of permissions) limits the maximum scope of permissions for subsequent secondary authorizations. Therefore, the first set of permissions mentioned below is a subset of the fourth set of permissions; that is, any permission in the first set is also a permission in the fourth set of permissions.

[0103] Step 302: Grant secondary authorization to the first task based on the context of the first task to obtain the first permission set.

[0104] In this application, the system can first obtain a second permission set based on the context of the first task, which includes one or more permissions in the system permission set; then obtain a third permission set, which is the permission set that the target tool will use during the execution of the first task, and includes one or more permissions in the system permission set; and then obtain the first permission set based on the second permission set and the third permission set.

[0105] The system assesses the set of permissions required by the target tool to perform its first task (the first permission set, i.e., the set of permissions the target tool can use to perform the first task) based on multi-dimensional contextual information such as the user's intentions input through the interactive interface, current environment information, and tool functionality information. It determines whether system permissions are needed based on user intent, whether the current environment is secure based on collected environmental information, and whether system permissions are required to complete the corresponding function based on tool functionality. If the user intent is met and the environment is secure, permissions are granted; if the user intent is deviated from or the environment is risky, permissions are denied; if permissions are not required to complete the function, permissions are denied.

[0106] The system can obtain a third set of permissions based on the permission requests made by the target tool during the execution of the first task. During the execution of the first task, the target tool requests system permissions from the system via API; this third set of permissions represents the set of permissions that the target tool expects or wants to use when executing the first task.

[0107] The system can obtain the first permission set based on the second and third permission sets using the following two methods: Method 1: Obtain the intersection of the second and third permission sets; obtain the first permission set based on the intersection.

[0108] As mentioned above, the second permission set represents the set of permissions that the target tool can use when performing the first task, and the third permission set represents the set of permissions that the target tool expects or wants to use when performing the first task. If there are permissions in the third permission set that do not belong to the second permission set, it means that the target tool has requested permissions that it cannot use, and these permissions cannot be granted to the target tool. Therefore, we can first take the intersection of the second and third permission sets, exclude the permissions in the third permission set that do not belong to the second permission set, and then obtain the first permission set based on the intersection of the permissions.

[0109] Method 2: If there are permissions in the third permission set that do not belong to the second permission set, then the first permission set is determined to be empty; if there are no permissions in the third permission set that do not belong to the second permission set, then the intersection of the permissions of the second and third permission sets is obtained, and the first permission set is obtained based on the intersection of the permissions.

[0110] Similarly, the second permission set represents the set of permissions the target tool can use when performing the first task, and the third permission set represents the set of permissions the target tool expects or wants to use when performing the first task. If the third permission set contains permissions that do not belong to the second permission set, it means that the target tool has requested permissions that it cannot use. These permissions cannot be granted to the target tool, and in this case, it can be considered that the target tool has been compromised or tampered with. Therefore, no permissions should be granted to it, i.e., the first permission set is determined to be empty. Conversely, if the third permission set does not contain permissions that do not belong to the second permission set, it means that the target tool is trustworthy. In this case, the intersection of the permissions in the second and third permission sets can be taken first, and then the first permission set can be obtained based on the intersection.

[0111] In this application, in addition to the condition that the first permission set is a subset of the fourth permission set, the first permission set must also satisfy the condition that the second risk level is lower than or equal to the first risk level, and the second risk level is the highest risk level among the risk levels corresponding to the permissions in the first permission set.

[0112] The system can pre-classify system permissions, corresponding to the aforementioned risk levels. For example, permissions such as memory access, payment, and location services are classified as high-risk; microphone, speaker, camera, and calendar permissions are classified as medium-risk; and floating window and notification permissions are classified as low-risk. Optionally, the system can group / set system permissions according to risk levels, with each group / set corresponding to a risk level. Based on this, target tools with different risk levels can use different permission sets. High-risk target tools can use low-risk permission sets, while low-risk target tools cannot use high-risk permission sets, thus ensuring minimal system exposure.

[0113] One or more permissions in the first permission set each correspond to a risk level, while the second risk level is the highest among the risk levels corresponding to the one or more permissions in the first permission set. If the second risk level is lower than or equal to the first risk level, it means that the risk level of all permissions in the first permission set is lower than or equal to the first risk level. In other words, a high-risk target tool can use a set of permissions with lower risk levels that have been declared in a single authorization. For example, the first task could be purchasing tickets through the Ctrip app (the target tool). Based on this, the first permission set includes payment and camera access (both declared in an initial authorization), both of which are at a high-risk level (second risk level). The risk level of the Ctrip app (first risk level) is high, so the second risk level equals the first risk level. The first permission set meets the conditions, therefore the first permission set can be granted to the target tool. Alternatively, the first task could be that Doubao (the target tool) reads the local image library in order to remotely call a photo editing app (the MCP tool called by the target tool) to complete the photo editing of local images. Based on this, the first permission set includes reading the image library and communication (both declared in an initial authorization), both of which are at a medium-risk level (second risk level). The risk level of the photo editing app (first risk level) is medium, so the second risk level equals the first risk level. The first permission set meets the conditions, therefore the first permission set can be granted to the target tool.

[0114] To ensure that the first permission set satisfies the condition that the second risk level is lower than or equal to the first risk level, obtaining the first permission set based on the permission intersection as described above may include: obtaining the risk levels corresponding to the permissions in the permission intersection; if there is a risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permissions corresponding to the risk levels higher than the first risk level are deleted from the permission intersection to obtain the first permission set; if there is no risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permission intersection is determined as the first permission set. That is, further judgment is made on the permission intersection obtained from the second and third permission sets using one of the above two methods. If there is a risk level higher than the first risk level (a risk level that does not meet the condition) among the risk levels corresponding to all permissions in the permission intersection, then the permissions corresponding to the risk levels that do not meet the condition are deleted from the permission intersection to obtain the first permission set; if there is no risk level higher than the first risk level among the risk levels corresponding to all permissions in the permission intersection, then the permission intersection is directly determined as the first permission set. The final first permission set obtained in this way is not only the permission set that the target tool can use when performing the first task (in accordance with user wishes, current environment, and tool functions), but also the permission set that the target tool expects or wants to use when performing the first task (in accordance with the target tool's request), or the permission set that meets the condition that the second risk level is lower than or equal to the first risk level (in accordance with the risk level of granting permissions for the first task not exceeding the risk level of the target tool or the MCP tool called by the target tool).

[0115] Step 303: Construct the first sandbox execution environment based on the first permission set.

[0116] Step 304: Run the target tool in the first sandbox execution environment to perform the first task.

[0117] This application adopts a "sandbox isolation" mechanism, which limits the tool to execute each task with "least privileges and least resource scope" to prevent the tool from accessing system resources without authorization.

[0118] In one possible implementation, the method further includes: in the second case, obtaining the historical permission set of the second task; constructing a second sandbox execution environment for the second task based on the historical permission set; and running the second task in the second sandbox execution environment.

[0119] Corresponding to the first scenario above, the second scenario can include a first risk level that is lower than or equal to the risk level threshold. For example, with the three risk levels of high / medium / low mentioned above, the risk level threshold can be set to low risk level, then the second scenario can include the target tool or the MCP tool called by the target tool corresponding to a low risk level. More generally, N (N>1) risk levels can be divided, and the risk level threshold can be set to n1 (n1<N) risk levels, then the second scenario can include risk levels that are lower than or equal to n1.

[0120] In one possible implementation, the second scenario includes either a low-risk level first, or a medium-risk level first and the second task already authorized. A low-risk level may not require secondary authorization, while a medium-risk level allows for long-term validity of any previously granted secondary authorization. Therefore, if a medium-risk level task has already been authorized, secondary authorization may not be necessary.

[0121] Therefore, in the second scenario, the historical permission set of the second task can be obtained. This historical permission set can be obtained from a single authorization or from a previous instance when the target tool executed the second task. For the second task in this scenario, the historical permission set of the second task can be directly granted to the target tool, thereby creating a sandbox execution environment for it. This reduces the frequency of authorization and improves authorization efficiency for target tools with lower risk levels.

[0122] This application assesses the permissions available to the target tool in real time based on the context of the task to be executed, and judges the rationality of the permissions available to the target tool based on the risk level. On the one hand, it can improve security, and on the other hand, it can further narrow the scope of permission usage, limiting the target tool to execute the first task with "least privileges" (first set of privileges) in each task, reducing the attack surface, and improving the authorization experience and efficiency.

[0123] The following are several specific embodiments to illustrate... Figure 3 The technical solutions of the illustrated method embodiments will be described in detail.

[0124] Figure 4 A flowchart of the tool operation method of this application is shown below. Figure 4 As shown, it includes the following 4 steps: 1. Registration and Tiering: When an MCP tool (target tool) is installed locally or remotely accessed via a proxy (target tool) on the Internet, the MCP tool registers with the registration center. Simultaneously, the system performs risk tiering on the MCP tool based on tool access control (i.e., it performs content security checks on the MCP tool through tool access control, and then tiers the MCP tool based on the check results), matching it to high / medium / low risk levels and assigning a risk level label (high / medium / low risk label) to the MCP tool.

[0125] 2. One-time authorization: During the registration of an MCP tool, users can grant one-time authorization to the tool through an interactive interface. For example, when the system installs the target tool, a pop-up window will prompt the user which permissions the target tool needs / may use (e.g., microphone, speaker, camera, read / write gallery, location, etc.). At this time, the user can select the permissions they wish to grant (e.g., location, camera, read / write gallery).

[0126] 3. Secondary Authorization: When the target tool executes a task, secondary authorization can be applied, based on the risk level of the MCP tool. For example, if the MCP tool is low-risk, secondary authorization may not be required; if it's medium-risk, a single secondary authorization can be valid indefinitely; and if it's high-risk, secondary authorization must be applied every time the task is executed. Authorization can be done manually, with the user inputting or selecting permissions through an interactive interface; or automatically by the system, which determines the permissions available for the task based on its context and the permissions the target tool needs to execute the task, then grants the appropriate secondary authorization.

[0127] 4. Tool Operation: Based on the assessment results and the permissions that meet the risk level conditions, the final permissions granted to the target tool are determined, and a sandbox running environment is built based on this. The "sandbox isolation" mechanism is adopted to restrict the target tool to execute the first task with "least privileges" (first set of permissions) in each task, dynamically isolating the execution environment and preventing the target tool from accessing system resources without authorization.

[0128] Figure 5 Another flowchart of the tool operation method of this application is as follows: Figure 5 As shown, it includes the following 4 steps: 1. Registration and risk classification: During tool installation, the risk of the tool is classified based on the tool access control (i.e., the tool is checked for content security through the tool access control, and then the risk of the tool is classified based on the check results). It can be divided into three levels (high / medium / low risk level). Tool 3, which can be executed with only ordinary permissions, can be classified as low risk level; Tool 2, which requires higher permissions (e.g., low-risk kernel permissions), can be classified as medium risk level; Tool 1, which performs sensitive and high-risk operations (e.g., deletion, payment, etc.), can be classified as high risk level.

[0129] 2. One-time authorization: Users can enter or select the permissions to be granted through the interactive interface; alternatively, users can authorize the system to grant permissions automatically.

[0130] 3. Secondary Authorization: When Tool 2 executes a task, secondary authorization can be granted according to the risk level (medium) of Tool 2. The permissions (permission 1, permission 2, permission 3) available for Tool 2 to execute the task are identified based on multi-dimensional information such as user intent, environmental information, and details of Tool 2 (including functions, attributes, name, etc.).

[0131] 4. Tool Operation: Based on the evaluation results (permission 1, permission 2, permission 3), the risk level of the permissions in the evaluation results is obtained (permission 1 (high), permission 2 (medium), permission 3 (low)). Then, the legality of the permissions is judged in combination with the risk level conditions (medium risk level and low risk level) to determine the final permissions granted to the target tool (permission 2 (medium), permission 3 (low)). Based on this, a sandbox running environment is built, and a "sandbox isolation" mechanism is adopted to limit the target tool to execute the first task with "least privileges" (first permission set) in each task, dynamically isolating the execution environment and preventing the target tool from accessing system resources without authorization.

[0132] Figure 6 A flowchart for a local MCP tool as the target tool, such as... Figure 6 As shown, by deploying the MCP tool locally, users can access the tool's source code and perform risk detection locally. Furthermore, the system can directly interact with the MCP tool to achieve real-time control. That is, Users download and install MCP tools from MCP marketplaces and open-source communities via the internet, and register them with a registry center. The local risk detection module matches the MCP tools to risk levels; for example, among three MCP tools, MCP1 is classified as high-risk, MCP2 as medium-risk, and MCP3 as low-risk. The user authorizes the tool once during registration.

[0133] During the operation of the MCP tool, either user-based secondary authorization or automatic system-based secondary authorization can be used. Automatic authorization determines whether system permissions are required based on user intent, assesses the security of the current environment by collecting environmental information, and determines whether system permissions are needed to complete the corresponding function based on the tool's functionality. Authorization is granted if the user intent is met and the environment is secure; otherwise, it is denied if the user intent is deviated from or the environment is risky; or if the function does not require permission. Categorized authorization allows for no secondary authorization for low-risk tasks, maintains long-term secondary authorization for medium-risk tasks, and requires secondary authorization for each task execution for high-risk tasks.

[0134] Based on risk level criteria, tasks executed by MCP1 can select permissions from high / medium / low risk level permission sets for authorization; tasks executed by MCP2 can select permissions from medium / low risk level permission sets for authorization; and tasks executed by MCP3 can select permissions from low risk level permission sets for authorization. This results in the minimum permission set for MCP1 / MCP2 / MCP3, and a sandbox execution environment for MCP1 / MCP2 / MCP3 is built based on this minimum permission set to run tasks executed by MCP1 / MCP2 / MCP3. The automatic construction of the minimum permission set sandbox can use a third-party proxy to automatically determine the legality of permissions and generate sandbox execution environments with corresponding permissions, ensuring minimal permissions are granted.

[0135] Figure 7 A flowchart for a target tool acting as a proxy (remotely calling an MCP tool), such as... Figure 7 As shown, when remotely invoking the MCP tool via a proxy, the registry only stores a list of risk levels for the MCP tool, not the tool itself. Risk detection relies more heavily on intelligence or the tool marketplace. Interaction with the MCP tool via a proxy is required to complete installation and authorization. That is, The registry center remotely invokes MCP tools from the MCP marketplace and open-source community via a proxy. It stores a risk level list of these tools; for example, the list might include three MCP tools: MCP1 (high risk), MCP2 (medium risk), and MCP3 (low risk). Users authorize these tools only once during the registration process.

[0136] During agent operation, either user-based secondary authorization or automatic system secondary authorization can be used. Automatic authorization determines whether system permissions are required by user intent, assesses the security of the current environment by collecting environmental information, and determines whether system permissions are needed to complete the corresponding function based on tool functionality. Authorization is granted if the user intent is met and the environment is secure; otherwise, it is denied if the user intent is deviated from or the environment is risky; or if the function does not require permissions. Categorized authorization allows for no secondary authorization for low-risk tasks, maintains long-term validity for medium-risk tasks with one-time secondary authorization, and requires secondary authorization for each high-risk task execution.

[0137] Based on risk level criteria, tasks executed by proxy calling MCP1 can select permissions from high / medium / low risk level permission sets for authorization; tasks executed by proxy calling MCP2 can select permissions from medium / low risk level permission sets for authorization; and tasks executed by proxy calling MCP3 can select permissions from low risk level permission sets for authorization. This ultimately yields the minimum permission set for proxy calls to MCP1 / MCP2 / MCP3, and a sandbox execution environment is built based on this minimum permission set to run tasks executed by proxy calling MCP1 / MCP2 / MCP3. The automatic construction of the minimum permission set sandbox allows third-party proxies to automatically determine the legality of permissions and generate sandbox execution environments with corresponding permissions, ensuring minimal permissions are granted.

[0138] Figure 8 This is a schematic diagram of the structure of the tool operating device 800 of this application, as shown below. Figure 8 As shown, the tool running device 800 of this embodiment can be applied to the aforementioned electronic device. The tool running device 800 may include: an acquisition module 801, an authorization module 802, and a running module 803. Wherein, The acquisition module 801 is used to acquire the context of a first task in a first case. The first task is a task that the target tool needs to complete. The target tool or the Model Context Protocol (MCP) tool called by the target tool corresponds to a first risk level, which is obtained in an initial authorization of the target tool or the MCP tool called by the target tool. The authorization module 802 is used to perform a second authorization on the first task based on the context of the first task to obtain a first permission set. The first permission set satisfies the condition that a second risk level is lower than or equal to the first risk level. The second risk level is the highest risk level among the risk levels corresponding to the permissions in the first permission set. The running module 803 is used to construct a first sandbox execution environment based on the first permission set and run the target tool in the first sandbox execution environment to execute the first task.

[0139] In one possible implementation, the first case includes the first risk level being higher than the level threshold.

[0140] In one possible implementation, the first situation includes either the first risk level being high-risk, or the first risk level being medium-risk and the first task not being authorized.

[0141] In one possible implementation, the authorization module 802 is specifically configured to: evaluate a second permission set based on the context of the first task, the second permission set including one or more permissions in the system permission set; obtain a third permission set, the third permission set being the permission set to be used by the target tool during the execution of the first task, the third permission set including one or more permissions in the system permission set; and obtain the first permission set based on the second permission set and the third permission set.

[0142] In one possible implementation, the authorization module 802 is specifically used to obtain the third permission set based on the permission request during the execution of the first task by the target tool.

[0143] In one possible implementation, the authorization module 802 is specifically used to obtain the intersection of the permissions of the second permission set and the third permission set; and to obtain the first permission set based on the permission intersection.

[0144] In one possible implementation, the authorization module 802 is specifically configured to determine that the first permission set is empty if there is a permission in the third permission set that does not belong to the second permission set; if there is no permission in the third permission set that does not belong to the second permission set, obtain the intersection of the permissions of the second permission set and the third permission set, and obtain the first permission set based on the permission intersection.

[0145] In one possible implementation, the authorization module 802 is specifically used to obtain the risk level corresponding to the permissions in the permission intersection; if there is a risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permissions corresponding to the risk levels higher than the first risk level are deleted from the permission intersection to obtain the first permission set; if there is no risk level higher than the first risk level among the risk levels corresponding to the permissions in the permission intersection, then the permission intersection is determined as the first permission set.

[0146] In one possible implementation, the context of the first task includes at least one of the following: user intent information input through an interactive interface, current environment information, or functional information of the target tool.

[0147] In one possible implementation, the target tool includes an MCP tool, and the first task is a task that the MCP tool is to perform; or, the target tool includes an agent, and the first task is a task that the agent is to perform when it invokes the MCP tool.

[0148] In one possible implementation, the acquisition module 801 is further configured to acquire a historical permission set for a second task in a second case, wherein the second task is a task to be completed by the target tool; the running module 803 is further configured to construct a second sandbox execution environment for the second task based on the historical permission set; and run the second task in the second sandbox execution environment.

[0149] In one possible implementation, the second case includes the first risk level being lower than the level threshold.

[0150] In one possible implementation, the second situation includes either the first risk level being low-risk, or the first risk level being medium-risk and the second task having been authorized.

[0151] In one possible implementation, the authorization module 802 is further configured to match the first risk level to the target tool or the MCP tool called by the target tool during the registration phase of the target tool or the MCP tool called by the target tool based on the tool access control.

[0152] In one possible implementation, the authorization module 802 is further configured to obtain a fourth set of permissions authorized to the target tool based on the authorization operation performed by the user on the interactive interface, the fourth set of permissions including one or more permissions in the system permission set.

[0153] In one possible implementation, the first permission set is a subset of the fourth permission set.

[0154] The apparatus of this embodiment can be used to perform Figure 3 The technical solutions of the method embodiments shown are similar in principle and in effect, and will not be described again here.

[0155] In implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly implemented by a hardware encoding processor, or by a combination of hardware and software modules in the encoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0156] The memory mentioned in the above embodiments can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0157] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0158] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0159] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and 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; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0160] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0161] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0162] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0163] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A tool run method, characterized by, include: Obtain the context and first risk level of the first task, where the first task is a task that the target tool needs to complete, and the first risk level corresponds to the target tool; Based on the context of the first task and the first risk level, determine the first set of permissions; Construct a first sandbox execution environment based on the first permission set; The target tool is run in the first sandbox execution environment to perform the first task.

2. The method according to claim 1, characterized in that, The first risk level is either high risk, medium risk, or low risk.

3. The method according to claim 1 or 2, characterized in that, Determining the first permission set based on the context of the first task and the first risk level includes: Based on the context of the first task, the intersection of the second permission set and the third permission set is determined, wherein the second permission set includes one or more permissions from the system permission set, and the third permission set is the permission set to be used by the target tool during the execution of the first task; Obtain the risk level corresponding to the permissions in the intersection of the permissions; The first set of permissions is determined based on the intersection of the permissions, the risk level, and the first risk level, wherein the risk level of the permissions in the first set of permissions is not higher than the first risk level.

4. The method according to claim 3, characterized in that, The step of determining the first permission set based on the permission intersection, the risk level, and the first risk level includes: If the risk level is higher than the first risk level, the permissions corresponding to the risk level that is higher than the first risk level are deleted from the intersection of permissions to obtain the first permission set.

5. The method according to claim 3, characterized in that, The step of determining the first permission set based on the permission intersection, the risk level, and the first risk level includes: If the risk level is not higher than the first risk level, the intersection of permissions is determined to be the first permission set.

6. The method according to claim 3, characterized in that, Determining the intersection of the second and third permission sets based on the context of the first task includes: The second set of permissions is obtained based on the context evaluation of the first task; Obtain the third set of permissions; If the permissions of the second permission set exist in the third permission set, obtain the intersection of the permissions of the second permission set and the third permission set.

7. The method according to any one of claims 1 to 6, characterized in that, The context of the first task includes at least one of the following: user intention information input through the interactive interface, current environment information, or functional information of the target tool.

8. A tool operating device, characterized in that, include: The acquisition module is used to acquire the context and first risk level of the first task, where the first task is a task that the target tool needs to complete, and the first risk level corresponds to the target tool. The authorization module is used to determine a first set of permissions based on the context of the first task and the first risk level; The execution module is used to construct a first sandbox execution environment based on the first permission set; and to run the target tool in the first sandbox execution environment to perform the first task.

9. The apparatus according to claim 8, characterized in that, The first risk level is either high risk, medium risk, or low risk.

10. The apparatus according to claim 8 or 9, characterized in that, The authorization module is used to determine, based on the context of the first task and the first risk level, the first set of permissions, including: The authorization module is used to determine the intersection of the second permission set and the third permission set according to the context of the first task, wherein the second permission set includes one or more permissions in the system permission set, and the third permission set is the permission set to be used by the target tool in the process of executing the first task; The authorization module is used to obtain the risk level corresponding to the permissions in the permission intersection; The authorization module is used to determine the first permission set based on the intersection of permissions, the risk level, and the first risk level, wherein the risk level of the permissions in the first permission set is not higher than the first risk level.

11. The apparatus according to claim 10, characterized in that, The authorization module is used to determine, based on the intersection of permissions, the risk level, and the first risk level, that the first permission set includes: If the risk level is higher than the first risk level, the authorization module is used to delete the permissions corresponding to the risk level that is higher than the first risk level from the permission intersection to obtain the first permission set.

12. The apparatus according to claim 10, characterized in that, The authorization module is used to determine, based on the intersection of permissions, the risk level, and the first risk level, that the first permission set includes: If the risk level is not higher than the first risk level, the intersection of permissions is determined to be the first permission set.

13. The apparatus according to claim 10, characterized in that, The authorization module is configured to determine the intersection of the second and third permission sets based on the context of the first task, including: The authorization module is used to obtain a second set of permissions based on the context of the first task; The authorization module is used to obtain the third permission set; If the permissions of the second permission set exist in the third permission set, the authorization module is used to obtain the intersection of the permissions of the second permission set and the third permission set.

14. The apparatus according to any one of claims 8 to 13, characterized in that, The context of the first task includes at least one of the following: user intention information input through the interactive interface, current environment information, or functional information of the target tool.

15. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that, It includes a computer program that, when executed on a computer, causes the computer to perform the method of any one of claims 1 to 7.

17. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes the computer to perform the method of any one of claims 1 to 7.

Images