Dynamic authority-based MCP plug-in execution method and device, equipment and storage medium

Abstract

The invention discloses an MCP plug-in execution method, device and equipment based on dynamic permission and a storage medium, and relates to the technical field of plug-in control, the method comprises the following steps: when a plug-in calling request is received, obtaining context plug-in sensing information corresponding to the plug-in calling request; dynamically generating a minimum permission strategy corresponding to the target MCP plug-in based on the context plug-in sensing information; and determining a target plug-in running sandbox according to the minimum permission strategy, and executing the target MCP plug-in in the target plug-in running sandbox. According to the method, firstly, the context plug-in sensing information related to the plug-in calling request is collected to dynamically generate the minimum permission strategy, it is ensured that the plug-in only obtains the permission necessary for completing the current task, and the permission abuse risk is reduced from the source; meanwhile, by means of the sandbox isolation environment, even if the plug-in is abnormal, system core resources cannot be affected, plug-in operation is limited in an independent space, the overall safety is improved, and therefore the running safety of the MCP plug-in is improved.

Description

Technical Field

[0001] This application relates to the field of plug-in control technology, and in particular to a method, apparatus, device and storage medium for executing MCP plug-ins based on dynamic permissions. Background Technology

[0002] With the development of large language models (LLMs), their ability to extend functionality by calling external tools has been increasingly enhanced. MCP (Model Context Protocol), as a new standardized interface protocol, allows LLMs to call local or remote services to complete operational tasks beyond the scope of their training knowledge, such as reading and writing files, accessing databases, and executing commands.

[0003] However, because the MCP plugin has strong local operation privileges and its background operations are difficult to detect, malicious behavior is not easily exposed, and potential vulnerabilities may be difficult to discover in a timely manner. Without effective control over the plugin's execution process, there are security risks of unauthorized remote login and malicious code execution.

[0004] Therefore, improving the operational security of MCP plugins has become an urgent problem to be solved. Summary of the Invention

[0005] The main purpose of this application is to provide a method, apparatus, device and storage medium for executing MCP plugins based on dynamic permissions, aiming to solve the technical problem of how to improve the operational security of MCP plugins.

[0006] To achieve the above objectives, this application proposes an MCP plugin execution method based on dynamic permissions, the method comprising:

[0007] When a plugin call request is received, obtain the context plugin awareness information corresponding to the plugin call request;

[0008] Based on the context plugin awareness information, the minimum permission policy corresponding to the target MCP plugin is dynamically generated.

[0009] The target plugin execution sandbox is determined according to the least privilege policy, and the target MCP plugin is executed in the target plugin execution sandbox.

[0010] In one embodiment, the step of obtaining the context plugin-aware information corresponding to the plugin invocation request includes:

[0011] The context plugin awareness information includes, but is not limited to: user natural language, user identity information, plugin historical behavior information, plugin historical call records, and resource context information.

[0012] In one embodiment, the step of dynamically generating the least privilege policy corresponding to the target MCP plugin based on the context plugin awareness information includes:

[0013] The context plugin awareness information is feature-encoded to obtain a plugin awareness vector;

[0014] Intent recognition is performed based on the plugin perception vector to obtain the operation intent structure;

[0015] The permission items corresponding to the operation task of the operation intent structure are selected from the preset permission library, and the minimum permission policy corresponding to the target MCP plugin is generated.

[0016] In one embodiment, the step of determining the target plugin's execution sandbox according to the least privilege policy includes:

[0017] The least privilege policy is converted into a multi-dimensional permission feature vector. The vector dimensions of the multi-dimensional permission feature vector include, but are not limited to: API interface whitelist, parameter whitelist, file path access permission, network connection permission, script execution permission, and optional parameters.

[0018] Based on the multi-dimensional permission feature vector, determine whether there is a matching sandbox call identifier in the sandbox identifier vector library;

[0019] If a matching sandbox call identifier exists, the target plugin's execution sandbox is determined based on the matching sandbox call identifier.

[0020] In one embodiment, the step of determining the target plugin runtime sandbox according to the least privilege policy and executing the target MCP plugin in the target plugin runtime sandbox includes:

[0021] Obtain the real-time behavior sequence corresponding to the target plugin's running sandbox;

[0022] Behavioral anomaly monitoring is performed based on a preset security policy set and the real-time behavior sequence.

[0023] In one embodiment, the step of monitoring abnormal behavior based on a preset security policy set and the real-time behavior sequence includes:

[0024] The real-time behavior sequence is finely matched according to a preset set of security policies to obtain a matching security policy;

[0025] Based on the policy weights and scoring functions corresponding to the matching security policy, a policy weighting operation is performed to obtain the overall risk score corresponding to the target MCP plugin.

[0026] If the overall risk score exceeds the sandbox operation warning threshold, the sandbox security response mechanism will be triggered.

[0027] In one embodiment, the step of determining the target plugin runtime sandbox according to the least privilege policy and executing the target MCP plugin in the target plugin runtime sandbox includes:

[0028] Set the effective runtime of the target plugin's runtime sandbox, which is determined based on the expected execution time of the target MCP plugin;

[0029] If the execution time of the target MCP plugin exceeds the effective runtime, the target plugin's runtime sandbox is destroyed, and the permission scope of the target MCP plugin is automatically reduced to basic operation permissions.

[0030] Furthermore, to achieve the above objectives, this application also proposes an MCP plugin execution device based on dynamic permissions, which includes:

[0031] Set the effective runtime of the target plugin's runtime sandbox, which is determined based on the expected execution time of the target MCP plugin;

[0032] If the execution time of the target MCP plugin exceeds the effective runtime, the target plugin's runtime sandbox is destroyed, and the permission scope of the target MCP plugin is automatically reduced to basic operation permissions.

[0033] In addition, to achieve the above objectives, this application also proposes a dynamic permission-based MCP plugin execution device, the device including: a memory, a processor, and a dynamic permission-based MCP plugin execution program stored in the memory and executable on the processor, the dynamic permission-based MCP plugin execution program being configured to implement the steps of the dynamic permission-based MCP plugin execution method described above.

[0034] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, storing a dynamic permission-based MCP plugin executor. When the dynamic permission-based MCP plugin executor is executed by a processor, it implements the steps of the dynamic permission-based MCP plugin execution method described above.

[0035] This application discloses a method, apparatus, device, and storage medium for executing MCP plugins based on dynamic permissions. The method includes: when a plugin invocation request is received, obtaining context plugin awareness information corresponding to the plugin invocation request; dynamically generating a minimum permission policy corresponding to the target MCP plugin based on the context plugin awareness information; determining the target plugin runtime sandbox according to the minimum permission policy; and executing the target MCP plugin in the target plugin runtime sandbox. This application first collects context plugin awareness information related to the plugin invocation request and dynamically generates a minimum permission policy to ensure that the plugin only obtains the permissions necessary to complete the current task, reducing the risk of permission abuse from the source. Simultaneously, by utilizing the sandbox isolation environment, plugin operations are restricted to an independent space, ensuring that even if the plugin malfunctions, it will not affect the core resources of the system, improving overall security. Furthermore, the dynamic adaptation of permissions and the sandbox allows the same plugin to have matching permissions in different scenarios (such as different users or different tasks), balancing flexibility and security. Therefore, this application dynamically restricts the permission scope of MCP plugins through dynamic permission policies and sandbox isolation, and executes them in an isolated environment, improving the operational security of MCP plugins. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0038] Figure 1 This is a first flowchart illustrating the first embodiment of the MCP plugin execution method based on dynamic permissions of this application.

[0039] Figure 2 This is a second flowchart illustrating the first embodiment of the MCP plugin execution method based on dynamic permissions in this application.

[0040] Figure 3 This is a schematic diagram of the first process of the second embodiment of the MCP plugin execution method based on dynamic permissions of this application;

[0041] Figure 4 This is a second flowchart illustrating the second embodiment of the MCP plugin execution method based on dynamic permissions in this application;

[0042] Figure 5 This is a simplified flowchart illustrating the MCP plugin execution method based on dynamic permissions in this application.

[0043] Figure 6 This is a schematic diagram of the module structure of the MCP plugin execution device based on dynamic permissions according to an embodiment of this application;

[0044] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the MCP plugin execution method based on dynamic permissions in the embodiments of this application.

[0045] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0046] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0047] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0048] The main solution of this application is: when a plugin call request is received, obtain the context plugin awareness information corresponding to the plugin call request; dynamically generate the least privilege policy corresponding to the target MCP plugin based on the context plugin awareness information; determine the target plugin running sandbox according to the least privilege policy, and execute the target MCP plugin in the target plugin running sandbox.

[0049] Currently, MCP plugins have strong local operation permissions, while traditional MCP plugin execution methods typically use fixed permission configurations (such as granting administrator privileges by default or uniform basic permissions). This presents two major drawbacks: first, over-granting permissions can lead to abuse when plugins are tampered with (e.g., stealing sensitive data); second, insufficient permissions prevent plugins from completing normal tasks. Furthermore, plugins run directly in the system environment without isolation, and any anomalies can directly impact system stability. Therefore, without effective control, there are security risks of unauthorized remote login and malicious code execution.

[0050] To improve the security of MCP plugin operation, this application proposes a sandbox execution environment construction and dynamic permission control method for MCP plugin calls. By dynamically generating a least privilege policy, it ensures that plugins only obtain the permissions necessary to complete the current task, reducing the risk of permission abuse from the source and resolving the contradiction between "over-authorization" and "under-authorization." Furthermore, by utilizing a sandbox isolation environment, plugin operations are restricted to an independent space, ensuring that even if a plugin malfunctions, it will not affect core system resources, thus improving overall security. Simultaneously, the dynamic adaptation of permissions and the sandbox allows the same plugin to have matching permissions in different scenarios (such as different users and different tasks), balancing flexibility and security. Therefore, this application can significantly improve the security of MCP plugin operation.

[0051] It should be noted that the execution entity in this embodiment can be an MCP plugin execution system based on dynamic permissions, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an MCP plugin execution device based on dynamic permissions capable of performing the above functions. This embodiment does not specifically limit this. For example, a built-in call controller module integrated in an MCP client or server module; an independent security gateway that centrally manages the operation of multiple MCP plugins; an integrated module of an LLM inference engine, etc. The following uses an MCP plugin execution device based on dynamic permissions (hereinafter referred to as the execution device) as the execution entity to describe this embodiment and the following embodiments.

[0052] Based on this, the embodiments of this application provide an MCP plugin execution method based on dynamic permissions, referring to... Figure 1 , Figure 1 This is a first flowchart illustrating the first embodiment of the MCP plugin execution method based on dynamic permissions of this application.

[0053] In this embodiment, the MCP plugin execution method based on dynamic permissions includes steps S10 to S30:

[0054] Step S10: When a plugin call request is received, obtain the context plugin awareness information corresponding to the plugin call request;

[0055] Step S20: Dynamically generate the minimum permission policy corresponding to the target MCP plugin based on the context plugin awareness information;

[0056] It is easy to understand that the above-mentioned plugin invocation request can be an instruction initiated by a user, application, or LLM to request the execution of the target MCP plugin (i.e., the software module developed based on the Model Context Protocol to be invoked, used by the LLM to call external services). The execution device can receive the plugin invocation request through a preset interface (such as an API (Application Programming Interface) interface or a message queue), parse the unique plugin identifier (such as plugin ID), invocation parameters (such as the operation object and execution instructions) and triggering scenario (such as "the user requests to parse an Excel file") contained in the request, and determine the plugin to be executed (i.e., the target MCP plugin) and the task.

[0057] The aforementioned context plugin awareness information can be a collection of historical information and dynamic environment data corresponding to the target MCP plugin, used to evaluate the execution context corresponding to the target MCP plugin, including user identity, session intent, historical behavior, etc., which can be obtained through system logs or API.

[0058] In one feasible implementation, the context plugin awareness information in this embodiment includes, but is not limited to: user natural language, user identity information, plugin historical behavior information, plugin historical call records, and resource context information.

[0059] It is easy to understand that the aforementioned user natural language can be the plugin invocation text input by the LLM and its implicit intent scope (such as "read the report from drive D and send it to Zhang San", which includes information such as file path, operation type, and target object), which can be represented as L input ∈L, L input It can be stored as a string variable in the natural language input space L.

[0060] The aforementioned user identity information can be obtained by querying a user database, and can be represented as U = (u r ,u d ,u p ,…), where u r Indicates role, u d Indicates department, u p The first line represents the permission level, and the second line represents other identity dimensions. User identity information can be used for permission assessment (such as administrator or ordinary user) and can be obtained through authentication systems such as OAuth (OpenAuthorization).

[0061] The aforementioned plugin historical behavior information can be obtained from the system log system, retrieving past operation records (such as file access history) of the target MCP plugin. The format can be a time-series log. This can be represented as... Where t i Indicates timestamp, a i Indicates historical operation actions.

[0062] The aforementioned plugin historical call records and resource context information can be obtained through system monitoring tools (such as Prometheus). The plugin historical call records can include the plugin call frequency and parameter history (such as the number of exec and shell calls) corresponding to the target MCP plugin, used for behavioral analysis to assess the plugin's stability and necessity. This can be represented as... Where m j Indicates the plugin name, p j ... represents the call parameters, ... represents other call information dimensions.

[0063] The aforementioned resource context information can be the system resource status involved in the plugin call (such as the target file path, network environment, and hardware resource utilization), for example, "the file to be accessed is located in an encrypted partition, and the current network is an internal LAN," which can be obtained through the system API. This can be represented as R = (r t ,r s,r p ,…), where r t Indicates resource type, r s Indicates sensitivity score, r p ... indicates path information, ... indicates other context information.

[0064] It's important to understand that the aforementioned least privilege policy can be a policy file defining the minimum access permissions for a plugin (e.g., allowing only reading of a specific directory). It only includes permissions necessary for the plugin to perform its tasks (e.g., "Allow only reading of Excel files in a specified path, prohibit access to the system registry"), without any redundant permissions. This ensures that the target MCP plugin only operates on necessary resources. The policy format can be JSON or a policy language (e.g., OPA). The granularity of permission control corresponding to this least privilege policy can be refined to specific APIs, parameter ranges, and target objects (e.g., allowing only reading of files in a specific directory). This embodiment can calculate and adjust the least privilege policy corresponding to the target MCP plugin in real time based on contextual plugin awareness information, rather than pre-configuring it.

[0065] Therefore, in one feasible implementation, refer to Figure 2 , Figure 2 This is a second flowchart illustrating the first embodiment of the MCP plugin execution method based on dynamic permissions of this application. In this embodiment, step S20 includes steps S21 to S23:

[0066] Step S21: Encode the context plugin awareness information using features to obtain the plugin awareness vector;

[0067] Step S22: Based on the plug-in perception vector, perform intent recognition to obtain the operation intent structure;

[0068] Step S23: Select the permission items of the operation task corresponding to the operation intent structure from the preset permission library, and generate the minimum permission policy corresponding to the target MCP plugin.

[0069] It should be noted that in this embodiment, the user identity information, plugin historical behavior information, plugin historical call records, and resource context information in the context plugin awareness information can be combined into a context information vector (U,H,R,M). Then, the context information vector (U,H,R,M) is combined with the natural language input L. inputThe input is fed into a unified intent recognition module T, which is a large model or Transformer architecture network with multimodal understanding capabilities. This module can jointly model natural language commands and contextual information vectors through workflows or prompts, analyze the target MCP plugin's operational intent and task requirements, and filter out the necessary permissions from a pre-defined permission library, combining them into a least-permission policy. For example, if the plugin needs to "read a user-uploaded Excel file," the permission policy will only include the permission to "read the directory where the file is located," excluding irrelevant permissions such as "write to the system directory" and "execute system commands."

[0070] For example, the workflow of the intent recognition module T can be as follows:

[0071] First, the context plugin-aware information is fused and structured feature-encoded using a context encoder. This transforms unstructured context plugin-aware information (such as text and logs) into a structured multidimensional numerical vector, yielding the plugin-aware vector E, which can be represented as follows:

[0072] E = ContextEncoder(L input ,U,H,R,M); (1)

[0073] Then, the intent recognition module T can perform intent recognition based on the plugin perception vector E, determine the core intent of the user calling the plugin, and convert E into a structured operation intent structure I, where I = Adapt Intent Parser(E). I can be in JSON format and can contain the intent type and parameters corresponding to the operation task. It can be represented as I = {"action":"read","target_type":"file","target_path":" / etc / passwd",...}.

[0074] Finally, the aforementioned preset permission library can be a database pre-stored for all available permission items and their associated operation tasks on the execution device, such as permission item P001 corresponding to "read / tmp directory" and permission item P002 corresponding to "call sendmail interface". Each permission item can be the smallest unit constituting a permission policy, representing a specific operation that is allowed to be executed, such as "allow access to port 8080" or "prohibit modification of the system registry". Therefore, the intent recognition module T can also be used to match the operation intent structure I with the permission item entries in the preset permission library, and convert the filtered permission items into a policy file, thereby converting the operation intent structure I into a minimum permission set P, P = PermissionGenerator(I), and the structure of P can be represented as {"allowed_apis":["read_file"], "allowed_paths":[" / etc / "], ...}.

[0075] The minimum permission set P can include dimensions such as API interface whitelist, parameter whitelist, file path whitelist, network connection permissions, and script execution permissions. The minimum permission set P satisfies the following formal definition:

[0076]

[0077] That is: any set of permissions p smaller than P ′ Neither of them can complete the current task.

[0078] Therefore, the aforementioned minimum permission set P ensures that the target MCP plugin can only access the resources necessary to complete the current task, thereby preventing unauthorized operations and the risk of misauthorization.

[0079] In this embodiment, addressing the problem that traditional permission policies rely on manual templates and cannot adapt to dynamic contexts, leading to excessive or insufficient permissions, this implementation assembles an intent recognition module into a large model to perform structured feature encoding of information and dynamically generate a precisely matching least privilege policy based on intent recognition. This ensures that the least privilege policy perfectly matches the actual task requirements, guaranteeing minimal permissions. This not only improves the precision of permission control but also reduces the risk of unauthorized operations by plugins.

[0080] Step S30: Determine the target plugin execution sandbox according to the least privilege policy, and execute the target MCP plugin in the target plugin execution sandbox.

[0081] It is easy to understand that the aforementioned target plugin runtime sandbox can be an independent, isolated environment specifically allocated for the target MCP plugin, with resource access restrictions (such as access to the file system, network, and memory) that strictly match the least privilege policy, preventing plugins from exceeding their privileges and affecting core system resources. This embodiment can use containerization technology (such as Docker or Linux namespaces) to restrict plugin resource access. The sandbox may include namespaces, resource quotas (cgroups), and security policies. For example, in this embodiment, the sandbox allocates an independent namespace, resource quota, and security policy to each MCP plugin that needs to be prepared for execution, ensuring that it executes in a restricted environment; the sandbox prohibits access to sensitive resources (such as the system root directory, network interfaces, user key files, etc.) by default, and disables unnecessary system calls and kernel functions; it supports mounting temporary access paths (such as / tmp / task_123) on demand and automatically cleans them up after the task ends. Subsequently, the execution device can execute the plugin code corresponding to the target MCP plugin in the target plugin runtime sandbox, which can be triggered by system calls.

[0082] It is important to understand that the execution device can determine a target plugin execution sandbox with a completely compatible permission range based on the content of the least privilege policy. The configuration of the target plugin execution sandbox (such as allowed file paths and callable API interfaces) strictly corresponds to the least privilege policy.

[0083] In one feasible implementation, step S30 includes steps S31 to S33:

[0084] Step S31: Convert the least privilege policy into a multi-dimensional permission feature vector. The vector dimensions of the multi-dimensional permission feature vector include, but are not limited to: API interface whitelist, parameter whitelist, file path access permission, network connection permission, script execution permission, and optional parameters.

[0085] Step S32: Determine whether a matching sandbox call identifier exists in the sandbox identifier vector library based on the multi-dimensional permission feature vector;

[0086] Step S33: If a matching sandbox call identifier exists, determine the target plugin running sandbox based on the matching sandbox call identifier.

[0087] It is important to understand that, in order to improve plugin execution efficiency and reduce sandbox creation overhead, this embodiment can further introduce a fingerprint recognition control mechanism in the sandbox environment. By using a vectorization method, the above-mentioned least privilege policy vector is mapped into a multi-dimensional permission feature vector representing the sandbox fingerprint. Based on a pre-built vector database (i.e., the above-mentioned sandbox identifier vector library, where each vector in the library corresponds to a sandbox instance in a pre-created sandbox pool, and the vector dimension is consistent with the permission feature vector for fast matching), it can be used to determine whether the current permission set already has a reusable sandbox.

[0088] For example, in this embodiment, the minimum permission set P can be encoded into a permission feature vector with fixed dimensions and field order. It consists of multiple permission control dimensions, each representing a type of access permission or resource restriction. The dimension structure can be flexibly adjusted according to policies and user scenarios, and this embodiment does not impose any restrictions on it.

[0089] For example, in this embodiment, the dimensions include, but are not limited to: API whitelist (representing a list of allowed API calls, such as create, read, write, delete, etc., with allowed APIs represented by 1 and prohibited by 0); parameter whitelist (representing field names that are allowed to be called or modified by APIs, such as max_depth = 2); file path access permissions (representing accessible file paths, such as / etc / config); network connection permissions (representing allowed network IPs and ports or whether outbound communication is allowed, 1 for communication and 0 for no communication); script execution permissions (whether shell or JS scripts are allowed to be executed, 1 for execution and 0 for no execution); and call frequency limits (representing the maximum number of calls per second (e.g., 10 times)) and optional parameters (representing personalized additional parameters corresponding to the target MCP plugin, such as maximum script length or call frequency limits). The optional parameter dimension needs to be filled with default values ​​(e.g., set to 0 if not defined) to ensure uniform vector length and avoid matching failures.

[0090] Therefore, assuming the target MCP plugin's minimum permission set P = {"allowed_apis":["create_file","read_file","update_file","delete_file"],"allowed_paths":[" / etc / passwd"," / home / user / data"],"network":false,"script_exec":true,"max_script_size":1024}, that is, the minimum permission set can include operation permissions corresponding to dimensions such as API interface whitelist, file path access permissions, network connection permissions, and optional parameters (such as maximum script length), and in constructing the feature vector... A set of predefined field order templates can be used to ensure that the vector dimensions are consistent across different tasks, which facilitates subsequent matching and reuse.

[0091] At this point, the corresponding multidimensional permission feature vector of the target MCP plugin Example as follows:

[0092] 1) API interface whitelist dimension:

[0093] definition The API whitelist is defined by the following dimensions and field order: ["create_file", "read_file", "update_file", "delete_file"]. Then, based on the allowed_apis field in P, each field is mapped using a boolean. If the corresponding API permission is in the allowed permissions of the API whitelist, the corresponding position is 1; otherwise, it is 0. The default delete_file permission is 0.

[0094] Therefore, P["allowed_apis"] = ["create_file", "read_file", "update_file", "delete_file"] can be mapped to [1,1,1,0]. [1,1,1,0]

[0095] 2) File path access permission dimension:

[0096] definition The API file path access permissions and path field prefix order are: [ / etc / , / home / , / tmp / ]. Then, based on the allowed_paths field in the minimum permission set P, a boolean mapping is performed on each field. Notably, / etc / appears... Add 1 to the allowed_paths list; / home / will appear. Add 1 to the allowed_paths list; / tmp / does not appear. The allowed_paths field allows paths to be appended with 0. Therefore, This is further mapped to [1,1,1,0,1,1,0]

[0097] 3) Network connection permission dimension:

[0098] If the `network` field of the least privilege set `P` is false, then add 0 accordingly. This is further mapped to [1,1,1,0,1,1,0,0].

[0099] 4) Optional parameter dimensions:

[0100] Assume that the optional parameter in the minimum permission set P is the maximum script length, and max_script_size is 1024 bytes. Here's an example of the final permission vector.

[0101] It is easy to understand that the system can further generate multi-dimensional permission vectors based on the mapping. Generate a sandbox fingerprint identifier corresponding to the target MCP plugin and insert it into the sandbox identifier vector library for unified management, which will be used for subsequent matching and reuse in the sandbox environment.

[0102] At this point, the execution device can calculate the matching degree between the permission feature vector and the sandbox fingerprint vector corresponding to the existing sandbox stored in the sandbox identifier vector library. If the matching degree is greater than a preset similarity threshold (e.g., 0.9), and the sandbox is greater than or equal to the permission feature vector, it indicates that there is a matching sandbox call identifier in the sandbox identifier vector library, that is, the target MCP plugin has a corresponding existing sandbox instance. At this time, the target plugin running sandbox can be determined directly based on the matching sandbox call identifier, such as the Docker container ID.

[0103] Furthermore, this embodiment can also perform precise matching based on the scope of permissions, that is, the execution device can be based on a multi-dimensional permission vector. Perform a range search operation to return all sandbox fingerprints in the sandbox identifier vector library that meet the following conditions. The matching logic is as follows:

[0104]

[0105] Formula (2) indicates that if the current sandbox corresponding to the target MCP plugin does not exceed the permissions of the existing sandbox i in any dimension j, then the permissions of sandbox i are determined to meet the current task requirements, and the fingerprint vector corresponding to sandbox i can be the matching sandbox call identifier.

[0106] For example, suppose The call identifier of sandbox A in the sandbox identifier vector library

[0107] Sandbox B's call identifier because middle In the middle, write_file = 1.

[0108] Understandably, if multiple matching sandboxes exist, the execution device can prioritize and reuse the most recently used sandbox instance with the lowest memory usage or fastest response to improve system efficiency and reduce resource waste; if none exist, the target plugin running sandbox can be dynamically created in the sandbox pool (multiple pre-created sandbox instances) according to the least privilege policy.

[0109] This embodiment proposes an MCP tool execution environment system based on sandboxes and dynamic permission control. The permissions of each sandbox are abstracted into a fixed-dimensional feature vector, establishing a high-efficiency sandbox fingerprint database. When a new task arrives, its permission vector can be submitted to the database, quickly finding the "sufficient and optimal" sandbox instance for reuse, thereby reducing sandbox creation overhead and improving plugin startup speed. Furthermore, this embodiment restricts the plugin's permission scope (only the minimum necessary permissions) through dynamic permission policies and sandbox isolation, and executes it in an isolated environment, ensuring plugin operational security.

[0110] In summary, this embodiment generates context-aware plugin information by combining request environment data and request-related historical data queried from the system log database when receiving a plugin call request (such as an API request sent by an LLM). Then, based on this context-aware plugin information, an intent recognition algorithm (such as an NLP model) is applied to generate a corresponding least privilege policy. This policy only includes the permissions necessary to complete the current task of the target MCP plugin (e.g., only allowing reading the / tmp directory). The least privilege policy is then mapped to a sandbox environment. First, existing sandboxes are matched in the sandbox database based on the multi-dimensional permission feature vector corresponding to the least privilege policy; if no matching sandbox call identifier is found, a new sandbox is created. Finally, the target MCP plugin code is executed in the target plugin runtime sandbox, ensuring all operations are restricted. Therefore, this embodiment effectively defends against tool poisoning and command injection attacks, solves the security risks caused by excessive permissions and lack of isolation in MCP plugins, and achieves secure execution through dynamic permissions and sandbox isolation; simultaneously, resource overhead can be reduced and plugin execution efficiency improved through sandbox reuse.

[0111] This embodiment provides a method for executing an MCP plugin based on dynamic permissions. The method includes: upon receiving a plugin invocation request, obtaining contextual plugin awareness information corresponding to the request; the contextual plugin awareness information includes, but is not limited to, user natural language, user identity information, plugin historical behavior information, plugin historical invocation records, and resource context information. Feature encoding is performed on the contextual plugin awareness information to obtain a plugin awareness vector; intent recognition is performed based on the plugin awareness vector to obtain an operation intent structure; permission items corresponding to the operation task in the operation intent structure are selected from a preset permission library to generate a minimum permission policy corresponding to the target MCP plugin. The minimum permission policy is converted into a multi-dimensional permission feature vector, the vector dimensions of which include, but are not limited to, API interface whitelist, parameter whitelist, file path access permissions, network connection permissions, script execution permissions, and optional parameters; based on the multi-dimensional permission feature vector, it is determined whether a matching sandbox invocation identifier exists in the sandbox identifier vector library; if a matching sandbox invocation identifier exists, the target plugin running sandbox is determined according to the matching sandbox invocation identifier, and the target MCP plugin is executed in the target plugin running sandbox. This embodiment can effectively defend against tool poisoning and command injection attacks, and solve the security risks caused by excessive permissions and lack of isolation in MCP plugins. It achieves secure execution through dynamic permissions and sandbox isolation; at the same time, it reduces resource overhead and improves plugin execution efficiency through sandbox reuse.

[0112] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0113] It is easy to understand that the above-mentioned preset classification model needs to be iteratively trained before classifying the processed experimental data. Therefore, based on the first embodiment, please refer to... Figure 3 , Figure 3 This is a first flowchart illustrating the second embodiment of the MCP plugin execution method based on dynamic permissions of this application. In this embodiment, steps S40 to S50 are included after step S30:

[0114] Step S40: Obtain the real-time behavior sequence corresponding to the target plugin running sandbox;

[0115] Step S50: Detect abnormal behavior based on the preset security policy set and the real-time behavior sequence.

[0116] It should be understood that, in order to further enhance the security and controllability of the system, this embodiment can further collect fine-grained behavior data of the target MCP sandbox runtime through probe mechanisms (such as eBPF (Extended Berkeley Packet Filter), libseccomp (Seccomp Library), etc.) to obtain the operation log sequence recorded in chronological order during the runtime of the target MCP plugin within the target plugin runtime sandbox. This includes, but is not limited to, key indicators such as system call sequences, file access paths, network connection requests, and resource usage, for real-time behavior monitoring and analysis.

[0117] Then, this embodiment can combine the collected behavioral data with a predefined set of security rules, i.e. a set of preset security policies, to perform pattern matching and risk assessment in order to monitor whether the plugin running behavior in the target plugin running sandbox deviates from the normal mode.

[0118] This preset security policy set can be represented as S = {s1, s2, ..., s} m This can be used to address abnormal behavior such as "prohibiting access to system directories", "prohibiting the use of delete commands", or "network request frequency must not exceed 10 times / second".

[0119] In one feasible implementation, step S50 includes steps A1 to A3:

[0120] Step A1: Perform fine-grained matching on the real-time behavior sequence according to the preset security policy set to obtain the matching security policy;

[0121] Step A2: Perform a policy weighting operation based on the policy weight and scoring function corresponding to the matching security policy to obtain the overall risk score corresponding to the target MCP plugin;

[0122] Step A3: If the overall risk score is greater than the sandbox operation warning threshold, trigger the sandbox security response mechanism.

[0123] At this point, assume the real-time behavior sequence is B = {b1, b2, ..., b} m}, where each action item b i It includes type (such as syscall, network, file, resource), timestamp, operation object (such as file path, IP address, system call number) and parameter information;

[0124] The preset security policy set S serves as the rule foundation for behavior assessment. It can be used to match the collected real-time behavior sequence B item by item according to the built-in specific security behaviors and policy rules (such as matching "prohibited operation" using a rule engine), i.e., the aforementioned fine-grained matching, and to perform an overall risk score based on the matching results. The policy weight is the importance coefficient of each rule in the preset security policy set. For example, "delete system files" has a weight of 0.8, and "exceeding the network request frequency limit" has a weight of 0.2. The higher the weight, the greater the impact on the final overall risk score. The scoring function is a function that determines the degree of matching between each rule in the preset security policy set and the real-time behavior sequence.

[0125] For example, the execution device can perform actions on each item b. i With each strategy in the strategy set i The conditional expression is compared, and if the matching condition is met, the weight w is specified in advance according to the strategy. i and scoring function f(b) i ) Calculate its contribution value and summarize it into the quantitative indicator obtained through strategy weighting, namely the overall risk score mentioned above.

[0126] At this point, the calculation process for the overall risk score RiskScore(B) can be defined as follows:

[0127]

[0128] Among them, w i ∈R + This indicates the configurable weighting coefficients; the higher the overall risk score, the more suspicious the behavior or the more it deviates from normal operating patterns.

[0129] And f(b) i f(b) ∈ [0,1] is a configurable scoring rule engine, which is essentially a lightweight rule evaluator. It can represent the basic overall risk score of item bi by the degree of matching between behavior item bi and the security policy. In this embodiment, multiple evaluation model configurations f(b) are supported. i Examples include static rule models, which directly score based on rules such as regular expressions, blacklists / whitelists, and fixed thresholds; dynamic statistical models, which calculate the degree of deviation based on the distribution of historical behaviors; and lightweight machine learning models, which integrate decision trees, random forests, or small neural networks to identify complex attack patterns.

[0130] Therefore, this embodiment can use a "policy matching + weighted scoring" approach to score each behavior, and use this overall risk scoring function to comprehensively score the real-time behavior sequence. When the score exceeds the pre-set sandbox operation warning threshold, the executing device can determine that the execution of the target MCP plugin is a high-risk behavior and can automatically trigger corresponding security responses, including but not limited to increasing the logging level of sensitive operations, interrupting suspicious processes, updating sandbox permission configurations, or issuing alarm notifications, and even preventing the continued execution of specific behaviors, etc., to achieve adaptive security protection.

[0131] For example, the above scoring process is illustrated. Suppose that a policy s1 = {"type":"syscall","condition":"name=='execve'ANDargs[0]=~' / etc / .*'","weight":5.0,"evaluator":"static"} in the preset security policy set S indicates that "execute any script under / etc / " is a high-risk behavior with a weight of 5.

[0132] The real-time behavior sequence B corresponding to the target MCP plugin contains a behavior b1 = {"type":"syscal l","object":"execve","parameters":{"filename":" / etc / exploit.sh"}}

[0133] The matching result at this point is as follows:

[0134] The type of b1 is syscall, which is the same as the type of s1; the filename matches / etc / .*; therefore, the behavior item b1 matches security policy s1 in the preset security policy set, and the matching score determined by its corresponding scoring function is: f(b1) = 1.0 (complete match). Therefore, the final overall risk score calculated based on the weight of 5.0 corresponding to the matching security policy s1 can be RiskScore(B) = 5.0 × 1.0 = 5.0.

[0135] In this embodiment, the activity of the MCP sandbox can be captured through the MCP probe mechanism, collecting all system calls, file operations, network requests, and other behaviors of the plugin in real time. A weighted risk score is then performed based on the captured data to achieve accurate anomaly detection. Furthermore, this embodiment can dynamically adjust security policies based on the analysis results, further improving the security of plugin operation.

[0136] In one feasible implementation, refer to Figure 4 , Figure 4This is a second flowchart illustrating the first embodiment of the MCP plugin execution method based on dynamic permissions of this application. In this embodiment, after step S30, steps S60 to S70 are also included:

[0137] Step S60: Set the effective runtime of the target plugin's runtime sandbox, the effective runtime being determined based on the expected execution time of the target MCP plugin;

[0138] Step S70: If the execution time of the target MCP plugin exceeds the effective runtime, destroy the target plugin's runtime sandbox and automatically reduce the target MCP plugin's permission scope to basic operation permissions.

[0139] Understandably, the aforementioned effective runtime can be the maximum lifespan allowed for the target plugin's execution sandbox. It can be set based on the target MCP plugin's expected execution time, which can be determined through historical data or model prediction. The effective runtime can be determined by adding buffer times corresponding to different plugin types to the preset execution time.

[0140] It should be noted that, to avoid security risks caused by prolonged validity of permissions leading to timeouts, this embodiment reduces permission exposure through time-limit control. Specifically, if the execution time of the target MCP plugin exceeds the effective runtime, the target plugin's runtime sandbox is destroyed. This involves forcibly terminating the sandbox process, releasing system resources such as memory occupied by the sandbox, and clearing temporary data within the sandbox to prevent residual risks. Simultaneously, the execution device can reduce the target MCP plugin's permissions to pre-set basic operation permissions, allowing only access to public directories to prevent unauthorized access.

[0141] In summary, this embodiment utilizes runtime behavior monitoring to promptly detect and intercept abnormal operations outside of permission policies, forming a dual security mechanism of "access control + behavior auditing" to enhance the security of plugin execution. Simultaneously, risk scoring enables refined security responses, providing only warnings for low-risk behaviors and immediate interception for high-risk behaviors, balancing security and availability; furthermore, quantifying risks facilitates traceability and optimization of security policies.

[0142] In addition, this embodiment uses timeout control to forcibly reclaim resources and avoid resource abuse; at the same time, it reduces permissions to prevent dangerous operations from continuing after timeout, further improving system security.

[0143] This embodiment discloses a method for obtaining the real-time behavior sequence corresponding to the target plugin's runtime sandbox; performing fine-grained matching of the real-time behavior sequence according to a preset security policy set to obtain a matching security policy; performing a policy weighted calculation based on the policy weight and scoring function corresponding to the matching security policy to obtain the overall risk score corresponding to the target MCP plugin; and triggering the sandbox security response mechanism when the overall risk score exceeds the sandbox runtime warning threshold. This embodiment provides a quantitative risk assessment through a weighted risk scoring mechanism, thereby not only reducing false alarms but also achieving adaptive protection, further improving the security of plugin operation.

[0144] Furthermore, this embodiment also discloses setting an effective runtime for the target plugin's runtime sandbox. The effective runtime is determined based on the expected execution time of the target MCP plugin. If the execution time of the target MCP plugin exceeds the effective runtime, the target plugin's runtime sandbox is destroyed, and the target MCP plugin's permission scope is automatically reduced to basic operation permissions. Therefore, this embodiment can reduce permission exposure and resolve the risk of sandbox timeout execution through time limit control.

[0145] For example, to help understand the technical concept or principle of the MCP plugin execution method based on dynamic permissions after combining this embodiment with the above-described Embodiments 1 and 2, please refer to Figure 5 , Figure 5 The following is a simplified flowchart illustrating the execution method of the MCP plugin based on dynamic permissions in this application:

[0146] 1) Information Acquisition:

[0147] First, during the dynamic access control phase, if a request to invoke the MCP tool is detected in the natural language statement currently input by the user into the Large Language Model (LLM), i.e., a plugin invocation request exists, the context plugin information corresponding to the plugin invocation request can be obtained through the intent recognition module T pre-configured in the large model. This information includes the user's natural language, user identity information, plugin historical behavior information, plugin historical invocation records, and resource context information. Based on the obtained information, the minimum permission policy corresponding to the target MCP plugin is determined.

[0148] This application proposes a context-aware, minimum dynamic permission control method in the field of MCP. Instead of relying on traditional manually configured permission policy templates, it uses a unified intent recognition module to dynamically generate the minimum permission set required for the current task, starting from the user's natural language input and combining their identity information, historical information and behavior, MCP plugin call records and resource context.

[0149] 2) Sandbox creation or sandbox reuse:

[0150] Then, the execution device can convert the context plugin information into a multi-dimensional permission vector that can perform sandbox fingerprint recognition. If a matching sandbox call identifier is detected in the sandbox identifier vector library, it is determined that there is an execution sandbox environment that meets the requirements. At this time, the existing MCP sandbox status can be directly synchronized and used as the target plugin to run the sandbox, thereby realizing sandbox reuse.

[0151] If no matching sandbox call identifier exists, the multidimensional permission vector is saved to the sandbox identifier vector library, and the execution sandbox environment with the least privilege is created directly based on the multidimensional permission vector determined by the intent recognition module, which is then used as the target plugin to run the sandbox.

[0152] Then, in the MCP execution sandbox environment, the MCP service (or MCP Server) corresponding to the target MCP plugin is executed in isolation based on the sandbox configuration of the target plugin, such as opening local files, calling APIs, obtaining permissions, etc.

[0153] This application introduces a sandbox fingerprinting mechanism based on permission vector space to determine whether the current minimum permission set already has a matching sandbox environment. Unlike the traditional hash matching method (which requires an exact match), this application uses a permission vectorization representation method to encode the minimum permission set into a multi-dimensional feature vector, and calculates and judges based on this vector and the existing sandbox fingerprint.

[0154] Furthermore, the sandbox and dynamic permission control provided in this application do not depend on specific programming languages ​​or platforms, and can be adapted to various MCP clients, improving the system's compatibility and scalability, and providing technical support for building secure, controllable, and stable AI intelligent agent applications.

[0155] 3) Behavioral monitoring and analysis

[0156] The execution device can monitor the running process of the target plugin sandbox in real time, filter sensitive data, determine whether there are high-risk behaviors, and if so, send alarm information or directly block the running of the MCP plugin.

[0157] During this process, the execution device can perform fine-grained matching between the real-time behavior sequence B corresponding to the target MCP plugin and the preset security policy set S to determine the specific rules that are violated; perform weighted calculations based on the policy weight and degree of violation of the rules to obtain the risk score RiskScore(B); and determine whether there is a high-risk behavior based on the risk score.

[0158] If the risk score exceeds the sandbox operation warning threshold, the sandbox security response mechanism will be triggered (such as sending alarm information or blocking behavior, or directly destroying the sandbox).

[0159] This application achieves risk grading from qualitative judgment to quantitative assessment through quantitative scoring and weighting mechanisms, avoiding over-response or under-response; and achieves refined security response through risk scoring in real-time monitoring of high-risk behaviors, issuing warnings only for low-risk behaviors and immediately intercepting high-risk behaviors, thus balancing security and availability.

[0160] 4) Sandbox is destroyed periodically.

[0161] After the execution device starts the target plugin's runtime sandbox, it can create a sandbox lifespan timer. Before the effective runtime (or timeout) is reached, the sandbox environment of the target plugin's runtime sandbox can be maintained and its state synchronized; if the effective runtime is reached, the sandbox environment can be destroyed and a corresponding command can be sent to the sandbox runtime environment for state synchronization.

[0162] This application can prevent plugins from occupying resources indefinitely or performing malicious operations through time-limited control and timeout handling; at the same time, it can reduce permissions to prevent dangerous operations from continuing after the timeout, thereby further improving system security.

[0163] In summary, this application proposes a sandbox execution environment construction and dynamic permission control method for MCP plugin calls. By introducing a containerized isolation environment and a context-aware minimum dynamic permission control mechanism during plugin execution, and vectorizing permission configuration, it achieves efficient matching and reuse of sandbox fingerprints by combining a vector database. Furthermore, it incorporates output filtering, runtime behavior collection, and anomaly detection mechanisms to effectively defend against various security threats, including tool poisoning, data leakage, command injection, unauthorized remote access, and malicious code execution.

[0164] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the MCP plugin execution method based on dynamic permissions in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0165] This application also provides an MCP plugin execution device based on dynamic permissions, please refer to... Figure 6 , Figure 6 This is a schematic diagram of the module structure of the MCP plugin execution device based on dynamic permissions according to an embodiment of this application. In this embodiment, the MCP plugin execution device based on dynamic permissions includes:

[0166] The information acquisition module 601 is used to acquire the context plugin awareness information corresponding to the plugin invocation request when a plugin invocation request is received.

[0167] The permission determination module 602 is used to dynamically generate the minimum permission policy corresponding to the target MCP plugin based on the context plugin awareness information.

[0168] The plugin invocation module 603 is used to determine the target plugin execution sandbox according to the least privilege policy, and execute the target MCP plugin in the target plugin execution sandbox.

[0169] As one possible implementation, in this embodiment, the information acquisition module 601 is further configured to acquire context plugin awareness information corresponding to the plugin call request when a plugin call request is received; dynamically generate a minimum permission policy corresponding to the target MCP plugin based on the context plugin awareness information; determine the target plugin running sandbox according to the minimum permission policy; and execute the target MCP plugin in the target plugin running sandbox.

[0170] As one possible implementation, in this embodiment, the context plugin awareness information acquired by the information acquisition module 601 includes, but is not limited to: user natural language, user identity information, plugin historical behavior information, plugin historical call records, and resource context information.

[0171] As one possible implementation, in this embodiment, the permission determination module 602 is further configured to perform feature encoding on the context plugin perception information to obtain a plugin perception vector; perform intent recognition based on the plugin perception vector to obtain an operation intent structure; filter out the permission items of the operation task corresponding to the operation intent structure from the preset permission library, and generate the minimum permission policy corresponding to the target MCP plugin.

[0172] As one possible implementation, in this embodiment, the plugin invocation module 603 is further configured to convert the least privilege policy into a multi-dimensional permission feature vector. The vector dimensions of the multi-dimensional permission feature vector include, but are not limited to: API interface whitelist, parameter whitelist, file path access permission, network connection permission, script execution permission, and optional parameters; determine whether a matching sandbox invocation identifier exists in the sandbox identifier vector library based on the multi-dimensional permission feature vector; if a matching sandbox invocation identifier exists, determine the target plugin running sandbox based on the matching sandbox invocation identifier.

[0173] As one possible implementation, in this embodiment, the plugin invocation module 603 is further used to obtain the real-time behavior sequence corresponding to the target plugin running sandbox; and to perform behavior anomaly monitoring based on the preset security policy set and the real-time behavior sequence.

[0174] As one possible implementation, in this embodiment, the plugin invocation module 603 is further configured to perform fine-grained matching on the real-time behavior sequence according to a preset security policy set to obtain a matching security policy; perform policy weighting calculation based on the policy weight and scoring function corresponding to the matching security policy to obtain the overall risk score corresponding to the target MCP plugin; and trigger the sandbox security response mechanism if the overall risk score is greater than the sandbox operation warning threshold.

[0175] As one possible implementation, in this embodiment, the plugin invocation module 603 is further configured to set the effective runtime of the target plugin running sandbox, the effective runtime being determined based on the expected execution time of the target MCP plugin; if the execution time of the target MCP plugin exceeds the effective runtime, the target plugin running sandbox is destroyed, and the permission scope of the target MCP plugin is automatically reduced to basic operation permissions.

[0176] The MCP plugin execution device based on dynamic permissions provided in this application, employing the MCP plugin execution method based on dynamic permissions in the above embodiments, can solve the technical problems of over-authorization or under-authorization and lack of isolation affecting system stability caused by fixed permissions in traditional MCP plugin execution. Compared with the prior art, the beneficial effects of the MCP plugin execution device based on dynamic permissions provided in this application are the same as those of the MCP plugin execution method based on dynamic permissions provided in the above embodiments, and other technical features in the MCP plugin execution device based on dynamic permissions are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0177] This application provides a dynamic permission-based MCP plugin execution device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the dynamic permission-based MCP plugin execution method in the first embodiment described above.

[0178] The following is for reference. Figure 7 This document illustrates a structural diagram of a dynamic permission-based MCP plugin execution device suitable for implementing embodiments of this application. The dynamic permission-based MCP plugin execution device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The MCP plugin execution device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0179] like Figure 7As shown, the MCP plug-in execution device based on dynamic permissions may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the MCP plug-in execution device based on dynamic permissions. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the dynamic access-based MCP plug-in execution device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows dynamic access-based MCP plug-in execution devices with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0180] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in this application include a dynamic permission-based MCP plug-in executor product, which includes a dynamic permission-based MCP plug-in executor carried on a computer-readable medium, the dynamic permission-based MCP plug-in executor containing program code for performing the methods shown in the flowcharts. In such embodiments, the dynamic permission-based MCP plug-in executor can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the dynamic permission-based MCP plug-in executor is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0181] The MCP plugin execution device based on dynamic permissions provided in this application, employing the MCP plugin execution method based on dynamic permissions in the above embodiments, can solve the technical problems of over-authorization or under-authorization and lack of isolation affecting system stability caused by fixed permissions in traditional MCP plugin execution. Compared with the prior art, the beneficial effects of the MCP plugin execution device based on dynamic permissions provided in this application are the same as those of the MCP plugin execution method based on dynamic permissions provided in the above embodiments, and other technical features in this MCP plugin execution device based on dynamic permissions are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0182] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0183] The above are merely specific embodiments 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.

[0184] This application provides a storage medium having computer-readable program instructions (i.e., a dynamic permission-based MCP plugin executor) stored thereon, the computer-readable program instructions being used to execute the dynamic permission-based MCP plugin execution method in the above embodiments.

[0185] The storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0186] The aforementioned storage medium may be included in a dynamic permission-based MCP plugin execution device; or it may exist independently and not be assembled into a dynamic permission-based MCP plugin execution device.

[0187] The aforementioned storage medium carries one or more programs. When these programs are executed by the MCP plugin execution device based on dynamic permissions, the MCP plugin execution device based on dynamic permissions improves the security of MCP plugin operation.

[0188] The dynamic permissions-based MCP plugin executable code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as C or similar languages. The program code can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0189] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and dynamic permission-based MCP plug-in executor products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0190] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0191] The storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a dynamic permission-based MCP plugin executor) for executing the aforementioned dynamic permission-based MCP plugin execution method. This solves the technical problems of over-authorization or under-authorization caused by fixed permissions in traditional MCP plugin execution, and the lack of isolation affecting system stability. Compared with the prior art, the beneficial effects of the storage medium provided in this application are the same as those of the dynamic permission-based MCP plugin execution method provided in the above embodiments, and will not be repeated here.

[0192] The above are only some embodiments of this application and do not limit the scope of the solution of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A method for executing an MCP plugin based on dynamic permissions, characterized in that, The method includes: When a plugin call request is received, obtain the context plugin awareness information corresponding to the plugin call request; Based on the context plugin awareness information, the minimum permission policy corresponding to the target MCP plugin is dynamically generated. The target plugin execution sandbox is determined according to the least privilege policy, and the target MCP plugin is executed in the target plugin execution sandbox.

2. The MCP plugin execution method based on dynamic permissions as described in claim 1, characterized in that, The context plugin awareness information includes, but is not limited to: user natural language, user identity information, plugin historical behavior information, plugin historical call records, and resource context information.

3. The MCP plugin execution method based on dynamic permissions as described in claim 2, characterized in that, The step of dynamically generating the least privilege policy corresponding to the target MCP plugin based on the context plugin awareness information includes: The context plugin awareness information is feature-encoded to obtain a plugin awareness vector; Intent recognition is performed based on the plugin perception vector to obtain the operation intent structure; The permission items corresponding to the operation task of the operation intent structure are selected from the preset permission library, and the minimum permission policy corresponding to the target MCP plugin is generated.

4. The MCP plugin execution method based on dynamic permissions as described in claim 1, characterized in that, The step of determining the target plugin's execution sandbox according to the least privilege policy includes: The least privilege policy is converted into a multi-dimensional permission feature vector. The vector dimensions of the multi-dimensional permission feature vector include, but are not limited to: API interface whitelist, parameter whitelist, file path access permission, network connection permission, script execution permission, and optional parameters. Based on the multi-dimensional permission feature vector, determine whether there is a matching sandbox call identifier in the sandbox identifier vector library; If a matching sandbox call identifier exists, the target plugin's execution sandbox is determined based on the matching sandbox call identifier.

5. The MCP plugin execution method based on dynamic permissions as described in claim 1, characterized in that, After determining the target plugin execution sandbox according to the least privilege policy and executing the target MCP plugin in the target plugin execution sandbox, the process further includes: Obtain the real-time behavior sequence corresponding to the target plugin's running sandbox; Behavioral anomaly monitoring is performed based on a preset security policy set and the real-time behavior sequence.

6. The MCP plugin execution method based on dynamic permissions as described in claim 5, characterized in that, The step of monitoring abnormal behavior based on a preset security policy set and the real-time behavior sequence includes: The real-time behavior sequence is finely matched according to a preset set of security policies to obtain a matching security policy; Based on the policy weights and scoring functions corresponding to the matching security policy, a policy weighting operation is performed to obtain the overall risk score corresponding to the target MCP plugin. If the overall risk score exceeds the sandbox operation warning threshold, the sandbox security response mechanism will be triggered.

7. The MCP plugin execution method based on dynamic permissions as described in claim 1, characterized in that, After determining the target plugin execution sandbox according to the least privilege policy and executing the target MCP plugin in the target plugin execution sandbox, the process further includes: Set the effective runtime of the target plugin's runtime sandbox, which is determined based on the expected execution time of the target MCP plugin; If the execution time of the target MCP plugin exceeds the effective runtime, the target plugin's runtime sandbox is destroyed, and the permission scope of the target MCP plugin is automatically reduced to basic operation permissions.

8. A dynamic permission-based MCP plugin execution device, characterized in that, The MCP plugin execution device based on dynamic permissions includes: The information acquisition module is used to acquire the context plugin awareness information corresponding to the plugin call request when a plugin call request is received. The permission determination module is used to dynamically generate the minimum permission policy corresponding to the target MCP plugin based on the context plugin awareness information. The plugin invocation module is used to determine the target plugin execution sandbox according to the least privilege policy, and execute the target MCP plugin in the target plugin execution sandbox.

9. A dynamic permission-based MCP plugin execution device, characterized in that, The MCP plugin execution device based on dynamic permissions includes: a memory, a processor, and an MCP plugin execution program based on dynamic permissions stored in the memory and executable on the processor, wherein the MCP plugin execution program based on dynamic permissions is configured to implement the steps of the MCP plugin execution method based on dynamic permissions as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and the storage medium stores an MCP plugin executor based on dynamic permissions. When the MCP plugin executor based on dynamic permissions is executed by a processor, it implements the steps of the MCP plugin execution method based on dynamic permissions as described in any one of claims 1 to 7.

Images