MCP agent permission dynamic shrinkage and recycling management method and system

Abstract

This invention provides a method and system for dynamic contraction and reclamation of permissions for MCP (Multi-Channel Programming) agents. The method includes: receiving agent requests and identifying task intent; obtaining permission scope and resource requirements, and generating a security pass through field-level intersection calculation; executing access operations sequentially, and immediately reclaiming the permission for each step upon completion, making consumed permissions unusable; maintaining an abnormal behavior counter during execution, triggering a circuit breaker when an abnormality reaches a threshold; automatically reclaiming all residual permissions upon task completion, timeout, or interruption; and maintaining persistent audit records across the entire chain, including snapshots before and after permission changes. This invention utilizes a three-pronged approach: a "one card, one checkpoint, one time" security pass mechanism, an abnormality cumulative penalty mechanism, and step-level dynamic contraction. It also provides quantifiable security assessment data through the Permission Exposure Risk (PER) model.

Description

Technical Field

[0001] This invention relates to the fields of MCP protocol communication and zero-trust data access control technology, and in particular to a method and system for dynamic contraction and revocation of MCP agent permissions. Background Technology

[0002] As MCP (Model Context Protocol) gradually becomes a universal standard protocol for AI agents to interact with external resources, various AI agents can use the MCP protocol to perform cross-module data operations such as database access, API calls, file system reading, and third-party service interaction. Currently, the industry generally adopts a traditional static identity authorization model for permission control of MCP agents: a list of accessible resources, data tables, and operation permissions are preset for a specified agent. Once the agent's permissions are configured, they are valid for a long time. During operation, permissions are simply granted or blocked based on the agent's identity. The granularity of permissions, the scope of authorization, and the lifecycle are all fixed.

[0003] The traditional static identity authorization model described above has the following technical problems that this invention aims to solve when adapting to dynamic interaction scenarios of MCP agents: I. Existing technologies lack a closed-loop management mechanism for the entire lifecycle of permissions, from generation to contraction to revocation. In traditional models, permissions are permanently bound to the agent's identity, without distinguishing between tasks or execution stages. The agent retains full access to resources regardless of whether it is performing business, is idle, or has completed a task. Permission generation relies on manual configuration, and permission revocation also relies on manual closure, with the permission scope remaining unchanged throughout task execution. This leads to two consequences: first, permissions persist after task completion, creating numerous invalid "ghost permissions" and continuously expanding the attack surface; second, the permission lifecycle is completely decoupled from the task lifecycle, making it impossible to achieve closed-loop management of "generating permissions on demand at task startup, contracting permissions according to progress during task execution, and automatically revoking permissions after task completion," lacking end-to-end traceability. Although there has been preliminary research on MCP protocol security in academia, such as tool-level scope authorization, protocol-layer authentication encryption enhancement, behavior access control based on risk accumulation scoring, and permission decision prediction based on machine learning, none of these studies have proposed a technical solution that integrates permission generation, contraction, and revocation into a closed loop.

[0004] Second, existing technologies cannot achieve dynamic contraction of step-level permissions and lack a method to quantify the risk of permission exposure. In traditional models, when an agent executes a multi-step task, it acquires all necessary permissions at once upon task initiation, and all permissions remain valid throughout the entire task execution period D. Taking refund approval in an online store as an example: step one requires reading the order amount field, and step two requires reading the refund status field. Each field is only truly needed during the execution period of its corresponding step. However, in existing technologies, permissions for these two fields are valid from task initiation to task completion, and the permission holding time is amplified to the total task duration D. More importantly, there is a quantitative relationship between this "permission exposure"—that is, the product of the effective permission scale and the permission holding time—and the number of task steps. However, within the existing technological methodology framework, this quantitative relationship has never been revealed. The industry lacks a measurable and comparable mathematical model to evaluate "how much security is improved by step-level permission contraction compared to one-time authorization," thus failing to provide a quantitative basis for optimizing permission control solutions.

[0005] Of the two technical issues mentioned above, the first involves the macro-level mechanism of access control (lifecycle closed loop), and the second involves the micro-level granularity of access control (step-level contraction and quantitative evaluation). Together, they constitute the technical bottlenecks that urgently need to be overcome in the field of MCP agent security. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method and system for dynamic contraction and revocation of permissions for MCP intelligent agents.

[0007] To address the technical problems of existing MCP agent permissions being statically persistent, coarse-grained, and lacking an automatic revocation mechanism, this invention provides a method for dynamically shrinking and revoking MCP agent permissions, comprising the following steps: S1: Receive the MCP agent protocol request, identify the task intent corresponding to the request, and generate a task context carrying the task identifier and task type.

[0008] S2: Based on the agent's identity and task type in the task context, obtain the agent's pre-configured permission range and the resource access requirements corresponding to the task type.

[0009] S3: Calculate the minimum permissions at the resource access granularity based on the pre-configured permission range and the resource access requirements to obtain the minimum permission set for this task.

[0010] S4: Execute the resource access operations of each step in the order of the execution steps of the task type, and revoke the permissions corresponding to each step after the execution of each step is completed.

[0011] S5: During task execution, monitor the resource access behavior of the intelligent agent and maintain an abnormal behavior counter. When an abnormal behavior that meets the preset conditions is detected, perform an adjustment operation on the permission set of the current task. When the cumulative value of the abnormal behavior counter reaches a configurable cumulative threshold, perform a circuit breaker operation to freeze permissions or terminate the task.

[0012] S6: When the task is detected to meet the preset exit conditions, all residual permissions of the task are automatically revoked.

[0013] S7: Persist the permission change events of the entire process from task generation to permission revocation as a traceable audit record.

[0014] Furthermore, S3, S4, and S6 work together in a progressive sequence to form a closed loop for full lifecycle management of permissions: S3 determines the initial boundary of task permissions based on the intersection of the pre-configured permission range and the resource access requirements; S4 gradually shrinks the boundary as each step is completed during task execution; and S6 clears all residual permissions when the task meets the exit conditions. The three work together to achieve integrated closed-loop management of permissions from generation to gradual shrinkage to final reclamation.

[0015] Further, in S3, the calculation of minimum permissions based on resource access granularity includes: obtaining a list of allowed resource granularities pre-configured by the agent; obtaining a list of resource granularities required by each execution step of the task type; taking the intersection of the list of allowed resource granularities and the list of required resource granularities, and using the intersection result as the minimum permission set for this task; wherein, if the intersection of necessary resources is empty, the task is determined to be outside the permission range and execution is refused.

[0016] Furthermore, in S3, the validity period of the minimum permission set is bound to the lifecycle of the task, and the minimum permission set automatically expires after the task ends.

[0017] Furthermore, in S4, the step of revoking the permissions corresponding to each step after its execution includes: pre-configuring the correspondence between each execution step of the task type and the required resources; after each step is completed, determining the permission entry associated with the step according to the correspondence, and removing the permission entry from the set of valid permissions for the current task, so that subsequent steps can no longer access the corresponding resources through the removed permission entry.

[0018] Furthermore, in S6, the preset exit conditions include at least one of the following: all steps of the task have been completed; the permission lifespan of the task exceeds the preset effective duration; the execution process of the task is abnormally interrupted; or the task does not perform any resource access operations during the preset idle period.

[0019] Furthermore, in S5, an abnormal behavior counter and a configurable cumulative threshold are maintained for the current task: when an agent attempts to access a resource field that exceeds the current valid permission set, the abnormal behavior counter is incremented; when an agent repeatedly accesses the same authorized resource field in a single step and the number of repeated accesses exceeds a preset frequency threshold, the abnormal behavior counter is incremented; when the cumulative value of the abnormal behavior counter reaches the configurable cumulative threshold, the current valid permission set of the task is frozen and the current task is terminated, transitioning to full permission revocation in S6, while simultaneously sending an alarm notification to a preset security alarm channel. This mechanism solves the problems of existing technologies that only intercept single instances of unauthorized access, cannot cumulatively evaluate abnormal behavior, and cannot detect abnormal behavior patterns within legal permissions.

[0020] Furthermore, the security improvement effect of S4 compared to the existing static licensing model is described in a formal language: Suppose a task T contains n ordered execution steps {s1, s2, ..., sn}. n}, Step S i Let R be the set of resources required. i Step M i The execution time is denoted as d. i Total task duration D = Σ i d i .

[0021] Under the existing static authorization model, all permissions P=U are granted at once when the task starts. i R i All permissions remain valid throughout the entire task execution period D. The Permission Exposure Risk (PER) metric is defined as the product of the effective permission size and the permission holding time. Therefore, the permission exposure risk of the static model is: PER static =|P|×D.

[0022] Under the dynamic shrinkage model of step S4 of the present invention, step s_i only holds R_i during its execution period d_i and reclaims it immediately after the step is completed. Then the permission exposure risk of the dynamic model is: PER_dynamic=Σᵢ(|Rᵢ|×dᵢ).

[0023] Define the permission exposure shrinkage ratio η = PER dynamic / PER static =Σ i (|R i |×d i ) / (|P|×D), η∈(0,1], the smaller the value of η, the more significant the security improvement effect of S4 compared to the static authorization model.

[0024] Further, the resource overlap rate ρ=|P| / Σ|R is introduced. i |, ρ∈[1 / n,1], where ρ=1 / n indicates that the resources required by all steps do not overlap, and the contraction effect of S4 reaches the theoretical optimality; ρ=1 indicates that all steps share the same set of resources, and S4 has no additional contraction space, but S3 has already minimized the permissions. Substituting ρ into the expression for η, we get the general form of the contraction ratio of S4: η=1 / (n×ρ).

[0025] This model has the following technical implications: (1) The value of η is strictly less than the constant value of 1 corresponding to the prior art, which quantitatively proves that the amount of permissions exposed by S4 is always lower than that of the static authorization model.

[0026] (2) η is inversely proportional to the number of task steps n, that is, the more task steps there are, the greater the reduction in permission exposure of this invention compared to the prior art. In the ideal case where resources do not overlap (ρ=1 / n), η=1 / n, for a 10-step task, the permission exposure risk is reduced to 10% of the static model.

[0027] (3) η is inversely proportional to the resource overlap rate ρ. That is, the lower the resource overlap required between task steps, the more significant the contraction effect of S4. This characteristic naturally fits the actual working mode of MCP agent tasks accessing different data resources step by step according to the process.

[0028] This invention also provides a system for implementing the above method, based on a dual-core architecture design, including an MCP-Security-Enhance security pass module and an MCP-Permission-Base permission platform, wherein: The MCP-Security-Enhance security pass module is used to receive MCP agent protocol requests, identify task intent and generate task context, obtain pre-configured permission range and resource access requirements according to agent identity and task type, obtain the minimum permission set for this task by calculating the minimum permission at the resource access granularity and encapsulate it as a security pass. The MCP-Permission-Base permission platform is used to execute resource access operations in the order of steps defined by the security pass, and reclaim the permission entries corresponding to each step after each step is completed. During task execution, it monitors resource access behavior and maintains an abnormal behavior counter. When the abnormal count reaches a configurable cumulative threshold, it performs circuit breaking, freezing, or alarm operations. When it detects that the task meets the preset exit conditions, it automatically reclaims all residual permissions and persists the entire process of permission change events as traceable audit records. Furthermore, the MCP-Security-Enhance security pass module includes a protocol access parsing submodule and a policy decision submodule. The protocol access parsing submodule receives MCP agent protocol requests and performs intent recognition, serving as the system's unified entry point to convert external protocol requests into internal task context. The policy decision submodule obtains the agent's pre-configured permission scope and task resource access requirements, and uses field-level intersection operations to obtain the minimum permission set for the current task, ensuring that the agent only obtains the resource access entries necessary to complete the task. The MCP-Permission-Base permission platform includes a permission execution and control submodule and an audit and revoke submodule. The permission execution and control submodule further includes: a step scheduler, used to read the step-resource mapping table and drive each execution step sequentially; activating access permissions for resource fields required by each execution step before activation; and removing activated permission entries after the execution step is completed; and a resource access proxy, serving as a unified proxy layer between the agent and the underlying data resources; intercepting each resource access request and checking whether the requested resource field exists in the current valid permission set before the request reaches the actual resource layer; if it exists, allowing access; otherwise, rejecting access and recording the unauthorized access event. The audit and recycling submodule further includes: an exit condition monitor and a recycling executor. The exit condition monitor is used to monitor all preset exit conditions of the task in a parallel listening manner. The exit conditions include the completion of all steps of the task, the task execution time exceeding the preset validity period, abnormal interruption of the agent process or heartbeat timeout, and the task idle time exceeding the preset idle threshold. When any condition is met, a recycling trigger signal is generated. The recycling executor is used to respond to the recycling trigger signal, traverse all activated residual permission entries of the current task and perform permission removal operations one by one. After the removal is completed, the effective permission set of the current task is set to an empty set. And an audit logger is used to persistently store all permission change events of the task, such as permission creation, permission activation, permission recycling, unauthorized interception and abnormal circuit breaking, in an append-written immutable log manner. Each audit record contains an event timestamp, task identifier, operation type, and a complete snapshot of the permission set before and after the operation. Furthermore, the permission execution control submodule also includes a behavior monitor and a threshold circuit breaker. The behavior monitor performs multi-dimensional real-time monitoring of the resource access agent's grant and deny records. The monitoring dimensions include at least one of the following: access frequency—monitoring whether the number of times the same resource field is accessed within a preset time window exceeds the frequency limit; access pattern—monitoring whether the sequence of continuously accessed resource fields deviates from a predefined normal access pattern; data volume—monitoring whether the amount of data returned in a single instance or the cumulative amount of data returned exceeds a preset limit; step time—monitoring whether the actual execution time of the current step exceeds a preset execution time threshold. The behavior monitor also maintains an abnormal behavior counter for the current task, used to accumulate counts for the following two types of events: the first type is an unauthorized access event where the resource access agent returns a deny response; the second type is an event where the agent repeatedly accesses the same authorized resource field within a single step, and the number of accesses exceeds a preset frequency threshold. The threshold circuit breaker is used to store configurable cumulative thresholds. When the cumulative value of the abnormal behavior counter reaches the cumulative threshold, the threshold circuit breaker simultaneously performs the following operations: sends a permission freeze command to the step scheduler to stop the execution of all subsequent steps of the current task; sends a pass revocation command to the resource access agent to immediately invalidate all permission entries of the current security pass; sends a task forced termination command to the audit revocation submodule to trigger the full permission revocation process of S6; and sends an alarm notification to the preset security alarm channel. The alarm notification includes the task identifier, abnormal event type and count value, and the timestamp that triggered the circuit breaker.

[0029] Compared with the prior art, the beneficial effects of the present invention are as follows: I. To address the technical problem of the lack of a closed-loop control mechanism for the entire lifecycle of permissions in existing technologies, this invention achieves the following effects through a three-in-one collaborative closed loop of S3+S4+S6: An integrated closed-loop management system is established, encompassing the generation, contraction, and revocation of permissions. S3 determines the minimum set of permissions for the current task as the initial boundary based on the intersection of the agent's pre-configured permission range and the task's resource access requirements. S4 gradually contracts this boundary as each step is completed during task execution. S6 clears all residual permissions when the task meets the exit conditions. These three mechanisms work in a progressive and sequential manner, achieving for the first time in the MCP agent domain a complete lifecycle closed loop where "permissions are generated with the task, reduced with each step, and destroyed upon completion," filling the technological gap in existing technologies that lack a closed-loop management mechanism.

[0030] Completely eliminates ghost privilege remnants. S6 covers four common exit scenarios: normal termination, timeout exit, abnormal interruption, and idle silence. Even in abnormal scenarios that existing technologies cannot handle, such as program crashes, network interruptions, and long-term idleness of the agent, it can still automatically complete the cleanup of all privileges and eliminate the persistent attack surface caused by privilege remnants.

[0031] Achieve end-to-end permission auditing. S7 synchronously records permission change events in a closed loop with S3-S4-S6, making every permission generation, contraction, and revocation operation traceable. All permission changes throughout the task lifecycle form a complete and traceable audit chain.

[0032] II. Addressing the technical problems of existing technologies being unable to achieve dynamic shrinkage of step-level permissions and lacking methods for quantitatively measuring the risk of permission exposure, this invention achieves the following effects through S4 step-level dynamic shrinkage and its PER mathematical model: S4 compresses the duration of permissions from the task level to the step level. By removing the permission entries associated with each step after its execution, S4 ensures that permissions are only valid for the necessary execution moments, rather than throughout the entire task lifecycle, thus reducing the time dimension of permission exposure from the source.

[0033] This invention provides the first quantifiable security assessment model for access control exposure. By defining the access control exposure risk metric PER and the access control exposure shrinkage ratio η, the security improvement effect is upgraded from a qualitative description to a quantitative proof: η = 1 / (n×ρ), where η is strictly less than the constant value of 1 corresponding to existing technologies, and is inversely proportional to the number of task steps n—the more task steps there are, the greater the security advantage of this invention compared to existing technologies.

[0034] This naturally aligns with the actual working mode of MCP agents. η is inversely proportional to the resource overlap rate ρ, meaning the lower the resource overlap required by each step, the more significant the S4 contraction effect. MCP agent tasks typically access different data resources step-by-step according to the process, resulting in a naturally low resource overlap rate. In this mode, the security improvement effect of S4 is maximized. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating the implementation of Embodiment 1 of the present invention. Detailed Implementation

[0036] The present invention will be further described in detail below with reference to embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto. Experimental methods in the following embodiments that do not specify specific conditions are generally performed under conventional conditions or as recommended by the manufacturer.

[0037] Example 1: This example provides a method for dynamically shrinking and reclaiming permissions for MCP intelligent agents, including the following steps: S1: Receive an MCP agent protocol request, extract intent identification information from the protocol request, the intent identification information including at least one of the following: tool name, parameter structure features, and resource URI template carried in the protocol request. Match the intent identification information with a preset task type-intent feature mapping table according to a priority-based strategy. In the priority-based strategy, exact matching of the tool name is the first priority, matching of parameter structure keywords is the second priority, and wildcard matching of the resource URI template is the third priority. When multiple rules are matched simultaneously, the highest priority matching result is taken. If the match is successful, obtain the corresponding task type identifier and generate a task context carrying a system-unique task identifier and the task type identifier; if the match fails, determine that the request is an unauthorized request, refuse execution, and generate an interception audit record.

[0038] For S1, the reason for setting up a separate intent recognition step at the entry point of the permission control chain is that the existing MCP agent permission control scheme only performs authorization judgment based on agent identity, without distinguishing the differences in the actual responsibilities undertaken by the same agent in different tasks—an agent may perform a refund task or a data export task, but under the existing scheme, it obtains the same set of permissions. Making intent recognition a separate step allows subsequent S2 and S3 to perform differentiated permission calculations based on task type; that is, the same agent will generate different minimum permission sets when performing a refund task and when performing a data export task. If an independent intent recognition step is not set up and intent judgment is embedded in the subsequent permission matching process, it is impossible to intercept requests with unrecognized intents before permission calculation—malicious requests can bypass intent judgment and directly enter the backend permission calculation logic by forging tool_names, increasing the consumption of system resources by invalid requests. Meanwhile, although the wildcard matching in the hierarchical matching strategy has lower accuracy, it covers reasonable edge scenarios of requests that are not precisely matched, preventing normal requests from being mistakenly blocked due to incomplete configuration coverage.

[0039] S2: Based on the agent identity identifier and task type identifier in the task context generated in S1, execute the first query and the second query respectively. The first query obtains the pre-configured permission range corresponding to the agent identity identifier from the preset agent permission configuration table. The pre-configured permission range is stored in a three-level hierarchical structure of resource type-data table-field. The second query obtains the resource access requirements corresponding to the task type from the preset task type resource requirement table. The resource access requirements record the list of resource fields required for each execution step at the field level, and annotate each resource field with required or optional attributes.

[0040] For S2, the reason for storing the agent's pre-configured permission scope and task resource access requirements in two separate configuration tables and querying them separately is that the agent's general permission scope (e.g., "which fields in the orders table this agent can access") and the specific task's resource requirements (e.g., "which fields in the orders table the refund task needs") are two independently changing dimensions. With separate table storage, when adding a new task type, only one record needs to be added to the task type resource requirements table, without modifying the agent's permission configuration; when adjusting the agent's general permissions, all tasks involving that agent automatically adapt to the new permission limit, without needing to adjust it task-by-task. If both were combined into a single configuration table (e.g., directly writing the list of fields that each task can use in the agent configuration), then every time a new task type is added, the configuration records of all related agents need to be modified. The configuration maintenance workload increases with the product of the number of agents and the number of task types, which is unacceptable in large-scale MCP deployment scenarios.

[0041] S3: Perform minimum permission calculation at the resource access granularity on the pre-configured permission range and the resource access requirements obtained in S2 to obtain the minimum permission set for this task. The calculation includes: representing the pre-configured permission range and the resource access requirements as mapping structures from data table identifiers to field lists, expanding each data table one by one at the data table granularity, performing a field-level intersection operation on each data table, taking the intersection of the allowed field set of the table in the pre-configured permission range and the required field set of the table in the resource access requirements, and using the intersection result as the allowed access fields of the table in this task. The intersection results of all data tables together constitute the minimum permission set. After the intersection operation is completed, the resource fields marked as required in the resource access requirements are traversed, and each required resource field is checked to see if it exists in the minimum permission set. If the intersection of required resource fields is empty, it is determined that the task exceeds the permission scope of the agent, the task is refused to be executed, and a permission refusal audit event is generated. If all required resource fields pass the verification, the minimum permission set is set as the valid permission set for the task, and the validity period of the minimum permission set is bound to the life cycle of the task. The minimum permission set automatically expires after the task ends.

[0042] The reason for choosing intersection instead of union or other set operations in S3 to calculate the minimum permission set is that the pre-configured permission range A defines the upper limit of resources that the agent can access, while the resource access requirement R defines the actual resource range needed by the task. Taking the intersection A∩R yields the common part of A and R—this result neither exceeds the limit of A (ensuring security) nor does it contain all the necessary items of R (ensuring availability). Choosing the union A∪R would allow the task to obtain resources beyond the agent's permission range; choosing A itself without performing any operation would allow the task to obtain resources it does not need—taking a refund task as an example, the agent's pre-configured permission range includes all 6 fields of the orders table, but the refund task only needs 4 of them. user_phone and shipping_address are irrelevant to the refund business. Not removing these two fields means that the user's phone number and shipping address will be exposed to the refund agent that only needs to process the order amount and status, violating the principle of minimum necessity. Furthermore, the reason for setting up necessary resource verification after intersection operation is that moving the verification to the permission calculation stage before task execution can expose execution failures caused by configuration errors in advance, avoid the task failing midway due to insufficient permissions after startup, reduce ineffective resource consumption, and facilitate direct location of configuration defects from audit records.

[0043] S4: Execute the resource access operations for each step sequentially according to the execution steps of the task type, and revoke the permissions corresponding to each step after its completion. Specifically, this includes: pre-configuring a step-resource mapping table, which records the correspondence between each execution step and the list of resource fields required for each task type. Before executing each step, activate the access permissions for the resource fields required for that step from the currently valid permission set; after the resource access operation for that step is completed, determine the permission entries associated with that step according to the step-resource mapping table, and remove the permission entries from the currently valid permission set, preventing subsequent steps from accessing the corresponding resources through the removed permission entries.

[0044] For S4, the reason for immediately revoking the permissions for each step after execution, instead of granting all permissions at task start and then revoking them only after the task is completed, is that in the existing one-time authorization method, the agent holds all the necessary permissions from task start until task completion. The actual holding time for each permission entry is the entire task duration D, even if the permission is only needed in a specific step. Taking the refund task as an example, the amount field is only truly needed in step one (execution time 0.3 seconds) and step three (execution time 0.5 seconds), but under the one-time authorization method, it maintains access for the entire 1.0 second—approximately 0.2 seconds (during step two execution) the amount field is in a "enabled but not used" permission exposure state. This time window poses a real security risk: if an attacker gains control of the agent session during step two execution, under the one-time authorization method, the attacker can access the amount field—even though the field was used up in step one, the permission was not revoked. With the approach of immediately reclaiming permissions upon completion of each step, the `amount` permission is removed after step one, preventing attackers from accessing this field in step two. This strictly limits the attack surface to the permissions required for the current step. Furthermore, the step-resource mapping table is pre-configured rather than dynamically inferred at runtime because the correspondence between steps and resources for a task type is an inherent attribute of that task type and can be fully determined during the analysis phase. Pre-configuration ensures the accuracy and completeness of this correspondence and allows for precise review of permission activation and revoke actions in the configuration table, meeting the security compliance review requirement for predictable permission changes.

[0045] The security improvement provided by S4 can be measured in the following way. Definition: Let task T contain n ordered execution steps {s1, s2, ..., sn}. n}, Steps s i Let R be the set of resources required. i Steps i The execution time is denoted as d. i Total task duration D = Σd i The union of the resources required for all steps is P = ∪R i Define the exposure limit (PE) as: PE = number of valid permission entries × permission duration. Under the existing one-time authorization method, PE_existing = |P| × D. Under the S4 dynamic shrinkage method of this invention, PE_S4 = Σ(|R i |×d i Since Σ(|R) i |×d i )≤Σ(|P|×d iSince PE_S4 ≤ PE_existing, a strict less-than sign is used when n ≥ 2 and at least two steps require different resources, meaning the permission exposure of S4 is always lower than that of existing technologies. The shrinkage ratio η is defined as PE_S4 / PE_existing, and the resource overlap rate ρ is defined as ρ = |P| / Σ|R. i | (ρ∈[1 / n,1]), η=1 / (n×ρ) under the condition that the execution time of each step is uniform. This relationship shows that: the larger the number of task steps n, the more significant the shrinkage effect (ideally η=1 / n²); the lower the resource overlap rate ρ of each step, the more significant the shrinkage effect. In real business scenarios, MCP intelligent agent tasks usually access different data resources step by step according to the process, and the resource overlap of each step is naturally low. S4 tends to have the optimal shrinkage effect in this scenario. If step-level shrinkage is not adopted and static permissions are maintained only after the minimum field-level permissions are calculated in S3, then S3 only optimizes the number of permissions (reduced from 6 fields to 4), but the time exposure of each permission is not controlled - the permissions of the four fields are effective throughout the task, which is equivalent to reducing the "surface" of permissions but not shortening the "line" of permissions.

[0046] S5: During task execution, continuously monitor the resource access behavior of the agent. Monitoring dimensions include: (a) access frequency—monitoring whether the number of times the same resource is accessed within a preset time window exceeds a first preset threshold; (b) access pattern—monitoring whether the resource fields actually accessed in the current step deviate from the preset resource field list corresponding to the step in the step-resource mapping table; (c) data volume—monitoring whether the data volume returned by a single resource access exceeds the preset normal data volume range for this task type; (d) step time consumption—monitoring whether the execution time of a single step exceeds a preset timeout threshold. When any abnormal indicator in any dimension is detected to meet the corresponding preset condition, an adjustment operation is performed on the permission set of the current task; the adjustment operation includes: temporarily suspending at least one permission entry, or narrowing the permission set of the current step to the minimum necessary subset corresponding to the step, or triggering the termination of the current task and transitioning to the full permission reclamation in S6.

[0047] The reason for adding a layer of behavior monitoring to S5, in addition to the pre-configured rule-based protection of S3 and S4, is that the rules of S3 and S4 are designed based on known normal execution paths. However, during operation, the agent may exhibit abnormal behavior that the rules cannot predict due to factors such as model illusion, prompt injection, or session hijacking. For example, in step two, the agent strictly follows the mapping table and only accesses the status field (without triggering S4's permission denial), but repeatedly reads this field at an extremely high frequency. This anomaly can be captured by S5 in terms of frequency, but cannot be prevented by S3 and S4 in terms of rules. S5 is designed as an independent monitoring layer decoupled from S4, rather than embedding the monitoring logic into the step execution flow of S4, because normal execution steps should not bear the processing overhead of monitoring logic—the sensitivity and threshold of the monitoring logic can be independently tuned without affecting the step execution flow. If S5 is not set up and only S3+S4 is relied upon, there is no ability to detect statistical anomalies (such as high-frequency repeated readings and large amounts of data dragging); if the monitoring logic is embedded in S4, the execution process of S4 is coupled with the monitoring logic, and any modification to the logic of one side may affect the stability of the other side.

[0048] S6: Continuously detect whether the task meets preset exit conditions, and automatically reclaim all residual permissions of the task when they are met. The preset exit conditions include at least one of the following: Condition (a) All preset steps of the task have been completed; Condition (b) The total execution time of the task exceeds a preset effective time threshold; Condition (c) The execution process of the task is abnormally interrupted, and no process survival signal is received for more than a preset heartbeat detection interval; Condition (d) The task does not perform any resource access operations during a preset idle period. The above four exit conditions are logically ORed, and the reclamation operation is triggered when any condition is met. The reclamation operation includes: enumerating all effective permission entries associated with the current task, performing a removal operation on each entry, and verifying whether there are still permission entries associated with the task identifier in the current effective permission set after reclamation.

[0049] For S6, four exit conditions are set instead of just "all steps of the task have been completed" because there are multiple exit modes. Relying solely on the normal termination condition, permission remnants will occur in the following three abnormal modes: the task times out due to slow response from external dependencies—permissions remain valid during the timeout period and are not reclaimed; the task process exits abnormally due to crashes, network interruptions, etc.—the subsequent step reclamation operation of S4 is not executed due to the interruption of the process, and the activated permissions remain permanently; the task is completed but the agent is idle—idle sessions still have residual permission entries that can be used by session hijackers. After setting four exit conditions, regardless of the exit mode of the task, S6 has a corresponding reclamation path that can be reached. Condition (b) is implemented through a timer mechanism, which does not rely on external signals and has a passive fallback attribute; condition (c) is implemented through a heartbeat detection mechanism as an active means of detecting process abnormalities; condition (d) is implemented through an idle timer to clear silently mounted permission entries. If the recycling logic of S6 is incorporated into S4 (i.e., S4 handles both normal and abnormal exits of recycling simultaneously), then the role of S4 expands from "step-level precise removal" to a hybrid "step-level + task-level" mode, increasing logical complexity. Furthermore, S4 itself becomes unusable in abnormal interruption scenarios—abnormal interruption cuts off the execution flow of S4, making it logically impractical to execute the recycling logic within the interrupted flow. Therefore, S6 is designed as an independent recycling layer, independently completing recycling in scenarios where S4 is unreachable.

[0050] S7: Persist the permission change events that occurred in steps S1 to S6 as traceable audit records. The audit records include the following fields: event timestamp, task identifier, operation type (including permission generation, permission activation, permission removal, permission adjustment, and permission revocation), involved resource identifier, a complete snapshot of the permission set before the operation, and a complete snapshot of the permission set after the operation. Audit records are stored using an append-only method; written records cannot be modified or deleted. The audit record table is indexed by task identifier, agent identity identifier, operation type, and time range.

[0051] The reason for using an event-driven synchronous write approach for S7, rather than asynchronously retrieving audit information from operation logs afterward, is that if the corresponding audit records are lost due to process termination before being solidified after permission revocation (especially in emergency revocation scenarios under S6), it becomes impossible to trace "who, when, and under what conditions which permissions were revoked," leading to a break in the audit chain. Including a complete snapshot of the permission set before and after the operation in each audit record, rather than just recording the operation itself, is because simply recording the operation (e.g., "the agent queried the amount field in step one") without knowing the permission scope before the operation (whether the query exceeded the granted scope) and the permission status after the operation (whether the permission has been revoked) cannot meet the substantive verification requirements for compliance review. Without S7, the entire permission control process lacks traceable audit evidence, making it impossible to pinpoint the key time points and responsible parties for permission changes after a security incident.

[0052] In steps S1 to S7, S3, S4, and S6 form a progressive chain for full lifecycle management of permissions in their execution sequence. The logical necessity of their connection lies in the following: S3 determines the initial boundary of the minimum permission set—if S3 is skipped and step-level contraction is performed directly by S4, the baseline of contraction is the entire range of permissions A pre-configured by the agent, rather than the already trimmed minimum permission set P_min. The base value of contraction is larger, and some permissions unrelated to the task are not completely eliminated after contraction by S4; S4 contracts step by step within the boundary defined by S3—if S4 is skipped and recycling is performed directly by S6, the uncontracted full set of P_min is recycled. Permissions during task execution remain fully valid throughout the entire task duration, and the time-dimensional security gain brought by the above step-level contraction is completely lost; S6 clears the scattered residual permissions converged by the preceding steps—if S6 is skipped and only S4 is relied upon, there is no independent recycling capability in abnormal interruption scenarios. Each of the three actions produces its own security effect when implemented individually, but the security effect of the series implementation is greater than the sum of the individual implementations—because S3 transmits a trimmed range to S4 instead of full permissions, and S4 transmits a shrunken residual list to S6 instead of the initial full set. Each transmission reduces the downstream processing scale, and this step-by-step reduction effect cannot be reproduced by executing three independent steps in parallel.

[0053] Example 2: This example provides an MCP intelligent agent permission dynamic contraction and revocation management system for executing the method described in Example 1. The system adopts a dual-core architecture, including an MCP-Security-Enhance security pass module and an MCP-Permission-Base permission platform.

[0054] The protocol access parsing submodule in the MCP-Security-Enhance security pass module is used to receive MCP agent protocol requests, identify the task intent corresponding to the request, and generate a task context carrying a task identifier and task type. The protocol access parsing submodule further includes: a request receiver, used to listen to the MCP protocol port, receive JSON-RPC format protocol requests initiated by the agent, perform transport layer security verification, extract the request payload, and configure an upper limit rule for the number of requests from the same agent per unit time; an intent recognition engine, used to extract intent recognition information from the request payload and match it with a preset task type-intent feature mapping table according to a priority-based strategy; and a context constructor, used to generate a task context object carrying a task identifier, task type identifier, agent identity identifier, and timestamp after successful intent recognition and inject it into a storage area accessible to subsequent modules.

[0055] The reason for configuring a request frequency limit in the request receiver instead of receiving requests without limit is that the MCP agent may initiate high-frequency requests due to program defects or malicious control. If no rate limit is set, high-frequency requests will consume the computing resources of the protocol access parsing submodule, causing legitimate requests to be blocked, and at the same time increasing the database pressure caused by the subsequent multiple queries of the configuration table by S2.

[0056] The policy decision submodule in the MCP-Security-Enhance security pass module is used to obtain the pre-configured permission range of the agent and the resource access requirements corresponding to the task type based on the task context, and to obtain the minimum permission set for this task by calculating the minimum permission at the resource access granularity. The policy decision submodule further includes: a permission range queryer, used to query the pre-configured permission range from a preset agent permission configuration table and return the query results in a three-level hierarchical structure; a requirement queryer, used to query the resource access requirements from a preset task type resource requirement table and return the query results in a mapping structure from step number to resource field list, and return the required / optional attribute markers for each resource field; an intersection calculation engine, used to perform field-level intersection operations on the pre-configured permission range and resource access requirements table by table and output the minimum permission set, and to traverse the required resource fields to perform verification; and a lifecycle binder, used to bind the validity period of the minimum permission set to the task context and generate a permission token carrying a time-limited marker.

[0057] The reason why the security pass in the lifecycle binder uses an expiration mark instead of a global variable table to manage the validity period of permissions is that the global variable table has the risk of cross-task pollution in concurrent task scenarios. If the permission status is stored in the form of global variables, the permission status of different tasks may be overwritten or confused in high-concurrency scenarios. The security pass is generated and revoked independently at the task level, and the permission status of each task does not interfere with each other.

[0058] The permission execution and control submodule in the MCP-Permission-Base permission platform is used to execute resource access operations of each step sequentially according to the execution steps of the task type, and revoke the permissions corresponding to each step after execution. It also monitors the resource access behavior of the agent during task execution and maintains an abnormal behavior counter when an anomaly is detected. When the cumulative value of the abnormal behavior counter reaches a configurable cumulative threshold, it performs circuit breaking, freezing, or alarm operations. The permission execution and control submodule further includes: a step scheduler, used to read the step-resource mapping table and drive each execution step sequentially; activates the access permissions of the resource fields corresponding to each step before execution; and removes the activated permission entries from the valid permission set after the step is completed; a resource access proxy, used to intercept every resource access request from the agent to the database, API, or file system, and check whether the resource field accessed by the request exists in the current valid permission set before the request reaches the actual resource layer; if it exists, it allows access; otherwise, it returns a permission denial response; and a behavior monitor, used to perform multi-dimensional monitoring of the resource access proxy's allowance and denial records, and triggers a permission adjustment operation when any abnormal indicator in any dimension exceeds a preset threshold.

[0059] The reason why the resource access proxy adopts the proxy mode instead of embedding permission checking logic in the actual resource layer such as database, API gateway or file server is that the permission checking logic is completely decoupled from the business resources in the proxy mode. The actual resource layer is unaware of the existence of permission control. When accessing the system of this invention, permission control can be achieved without making any code modifications to the existing database, API service or file system. When extending to new resource types, it is only necessary to add the corresponding resource entries in the configuration table instead of modifying the resource service itself.

[0060] The permission execution control submodule also includes a behavior monitor and a threshold circuit breaker. The behavior monitor performs multi-dimensional real-time monitoring of the resource access agent's grant and deny records. The monitoring dimensions include at least one of the following: access frequency—monitoring whether the number of times the same resource field is accessed within a preset time window exceeds the frequency limit; access pattern—monitoring whether the sequence of continuously accessed resource fields deviates from a predefined normal access pattern; data volume—monitoring whether the amount of data returned in a single instance or the cumulative amount of data returned exceeds a preset limit; step time—monitoring whether the actual execution time of the current step exceeds a preset execution time threshold. The behavior monitor also maintains an abnormal behavior counter for the current task, used to accumulate counts for the following two types of events: the first type is an unauthorized access event where the resource access agent returns a denial response; the second type is an event where the agent repeatedly accesses the same authorized resource field within a single step, and the number of accesses exceeds a preset frequency threshold. The threshold circuit breaker stores the configurable cumulative threshold. When the cumulative value of the abnormal behavior counter reaches the cumulative threshold, the threshold circuit breaker simultaneously performs the following operations: sends a permission freeze command to the step scheduler to stop the execution of all subsequent steps of the current task; sends a pass revocation command to the resource access agent to immediately invalidate all permission entries of the current security pass; sends a task forced termination command to the audit and reclamation submodule to trigger the full permission reclamation process of S6; and sends an alarm notification to the preset security alarm channel. The alarm notification includes the task identifier, abnormal event type and count value, and the timestamp that triggered the circuit breaker. The behavior monitor and the threshold circuit breaker together constitute the real-time security protection layer of the permission execution control submodule, providing dynamic detection and automatic response capabilities for abnormal behavior during agent operation based on the pre-configured rule-based protection of S3.

[0061] The audit and reclamation submodule in the MCP-Permission-Base permission platform is used to automatically reclaim all residual permissions of a task when the task meets preset exit conditions, and to persist permission change events that occur throughout the task as traceable audit records. The audit and reclamation submodule further includes: an exit condition monitor, used to monitor four exit conditions in parallel: normal termination, timeout, process heartbeat timeout, and idle timeout; generating a reclamation trigger signal when any condition is met; a reclamation executor, used to enumerate all valid permission entries associated with the current task after receiving the reclamation trigger signal and remove them one by one, and to perform verification after reclamation is completed; and an audit logger, used to receive permission change events in an event-driven manner and persistently store audit records by appending them to an immutable log.

[0062] Example 3: This example uses an online mall refund scenario as the application context to verify the technical effectiveness of the aforementioned method with specific data.

[0063] An e-commerce platform deploys an MCP refund agent. The agent's pre-configured permission scope A includes all six fields of the `orders` table: `order_id`, `amount`, `status`, `refund_amount`, `user_phone`, and `shipping_address`. The refund task T consists of three sequential steps: Step 1 – Query the order amount and refund amount, requiring the `amount` and `refund_amount` fields, execution time d1 is approximately 0.3 seconds; Step 2 – Query the order refund status, requiring the `status` field, execution time d2 is approximately 0.2 seconds; Step 3 – Update the order refund completion status, requiring the `order_id`, `amount`, and `status` fields, execution time d3 is approximately 0.5 seconds. The total task duration D = 1.0 second.

[0064] The system receives an MCP protocol request initiated by the refund agent. S1 extracts the tool name "refund_process" from the request, which matches the task type "refund" in the intent mapping table, and generates a task context. S2 queries the pre-configured permission scope A and task resource requirements R (the union of the three-step requirements is {order_id, amount, status, refund_amount}) based on the agent's identity and the task type "refund".

[0065] S3 performs a field-level intersection operation: P_min = A ∩ R = {order_id, amount, status, refund_amount}. user_phone and shipping_address are excluded—if these two fields are not excluded, sensitive personal information would be accessible throughout the execution of the current refund task, increasing the risk of data leakage. Required resource validation passes (amount, status, and order_id all exist in P_min).

[0066] S4 performs dynamic shrinkage according to the following timing sequence: Before step one is executed, access permissions for `amount` and `refund_amount` are activated from `P_min`. After the agent completes the order amount and refund amount queries, these two permissions are immediately revoked—at this point, the valid permission set is updated to `{order_id, status}`, `amount` has been removed, and subsequent steps can no longer read the order amount using `amount`. If not revoked at this step, the `amount` permission remains valid throughout subsequent steps; `amount` is a core field for personal transaction amount data.

[0067] Before step two is executed, activate the status access permission from the valid permission set. After the agent completes the refund status query, immediately revoke the status permission—the valid permission set is updated to {order_id}.

[0068] Before executing step three, reactivate the access permissions for order_id, amount, and status (note that amount and status are newly activated in this step, not reused permissions from previous steps, as they were revoked in previous steps). After the agent completes the order status update, revoke the three permissions—the set of valid permissions is now empty.

[0069] Calculate the amount of permissions exposed. In this embodiment: n=3, |P|=4 (number of fields in the union set), Σ|R i |=2+1+3=6,ρ=|P| / Σ|R i |=2 / 3. Existing one-time authorization method: PE_existing=4×1.0=4.0 (fields·seconds). S4 dynamic shrinkage method: PE_S4=2×0.3+1×0.2+3×0.5=2.3 (fields·seconds). Shrinkage ratio η=2.3 / 4.0≈0.575=57.5%. That is, in this refund task, S4 reduces the permission exposure from 4.0 (fields·seconds) of the one-time authorization method to 2.3 (fields·seconds), a reduction of approximately 42.5%.

[0070] If S3 (no field-level intersection operation) is not used, the refund agent holds all 6 fields within its pre-configured permission range, increasing P_min to 6 fields, and PE_existing = 6 × 1.0 = 6.0 (fields per second), a 50% increase in permission exposure compared to using S3. If S4 (only S3 performs minimum field-level permission calculation while permissions are statically held throughout the process) is not used, PE = 4 × 1.0 = 4.0 (fields per second), approximately 74% more permission exposure than the combined implementation of S3 and S4. S3 reduces the number of permissions in the spatial dimension (6 → 4), while S4 reduces the permission holding duration in the temporal dimension (D → d). i The combined effect of the two is greater than the effect of each on its own.

[0071] Suppose that during step two, the refund agent, due to model illusion, repeatedly reads the status field approximately 100 times per second. The behavior monitor in S5 detects that the access frequency exceeds a preset threshold (e.g., 10 times per second) and triggers an adjustment operation—narrowing the permission set for the current step and generating an alarm notification, preventing the continued abnormally high-frequency reading. Without S5, this abnormal behavior would not be prevented by the rule layer (S3+S4)—the agent's access to the status field in step two is itself legitimate (compliant with the step-resource mapping table); the anomaly lies in the frequency, not the resource, and cannot be detected solely by S3+S4.

[0072] In this embodiment, S6 covers the following recycling paths: (a) Normal termination – After step three is completed, S4 has completed the three-step permission recycling, and S6 scans and confirms that the set of valid permissions is empty; (b) Timeout exit – If the total time taken by the task in step two reaches the preset effective duration threshold (e.g., 2 seconds) due to database response delay, S6 forcibly terminates and reclaims the current valid permissions (including status which is active in step two and amount and refund_amount which were not reclaimed in step one – if the normal recycling process of S4 is interrupted); (c) Abnormal interruption – The agent process crashes during step two, and S6 triggers recycling after the heartbeat timeout; (d) Idle silence – The agent is idle for more than the preset idle time threshold (e.g., 300 seconds) after the task is completed, and S6 clears the associated permission entries. If S6 is not set, the residual permissions in scenarios (b) to (d) cannot be automatically recycled – the timed-out task continues to occupy the database connection authorization, and the session-related permissions left by the crashed process remain permanently. The scenario that deserves particular attention is that in existing technologies that grant permissions only once and do not automatically reclaim them, the permission entries left behind after a process crash cannot be reclaimed through program logic, and there is also a lack of an independent timeout / idle clearing mechanism, requiring manual investigation and cleanup.

[0073] S7 synchronously records permission change events for each of the above steps. An example of an audit log (simplified display) is shown below: ① Task creation: task_id=T001,ts=1686700000.000,op=CREATE,access={order_id,amount,status,refund_amount} ② Step 1 activation: ts=1686700000.001,op=ACTIVATE,resource=orders.amount,orders.refund_amount ③ Step 1 removal: ts=1686700000.301,op=REMOVE,resource=orders.amount,orders.refund_amount ④ Step 2 activation… (and so on) ⑤ S6 recycling: op=RECLAIM,reason=normal_completion or timeout or crash or idle

[0074] Example 4: Online data query application scenario for R&D personnel This embodiment uses the scenario of R&D personnel querying the online production database to troubleshoot faults to verify the technical effect of the present invention.

[0075] Scenario Description: An internet company deploys an MCP agent to assist R&D personnel in troubleshooting online faults. The company's security policy requires: (1) R&D personnel must not access users' sensitive personal information (such as mobile phone numbers, home addresses, etc.); (2) A complete permission usage audit log must be recorded for each fault troubleshooting task. R&D personnel A is granted a pre-configured permission scope A in the agent permission configuration table, which covers the user table's users field {id, name, email, phone, address} (a total of 5 fields) and the order table's orders field {id, user_id, amount, status, refund_amount} (a total of 5 fields), for a total of 10 fields.

[0076] Developer A initiates a "User Complaint Investigation" task (task type = USER_COMPLAINT_DEBUG), which requires querying user order records to verify the content of the complaint. The task consists of three sequential steps: Step 1 – Query basic user information, requiring the fields users.id and users.name, execution time d1 = 0.3 seconds; Step 2 – Query order amount and refund amount, requiring the fields orders.amount and orders.refund_amount, execution time d2 = 0.2 seconds; Step 3 – Query order refund status, requiring the field orders.status, execution time d3 = 0.5 seconds. The total task time is D = 1.0 second.

[0077] S1: The request extracts the tool name "database_query", the parameter keyword contains "FROM users JOINorders", the resource identifier is "prod_db", and the three-level matching is to the USER_COMPLAINT_DEBUG task type, generating a task context (task_id=E001).

[0078] S2: The permission scope query returns the pre-configured permission scope for developer A—users{id,name,email,phone,address} and orders{id,user_id,amount,status,refund_amount}. The requirement query returns the resource access requirements—Step 1 = {users.id,users.name}, Step 2 = {orders.amount,orders.refund_amount}, Step 3 = {orders.status}.

[0079] S3: The intersection calculation engine performs field-level intersection operations on a table-by-table basis. For the `users` table: A={id,name,email,phone,address}∩R={id,name}={id,name}—fields `email`, `phone`, and `address` are excluded. For the `orders` table: A={id,user_id,amount,status,refund_amount}∩R={amount,refund_amount,status}={amount,status,refund_amount}—fields `id` and `user_id` are excluded. The minimum permission set P contains 5 fields, and all required field validations pass. The system encapsulates P as a security pass, with its validity period bound to the lifecycle of this task.

[0080] Key observation: Throughout the entire task, developer A never accessed the phone number (users.phone) or home address (users.address) – these two fields, although within its pre-configured permission range, were excluded from the security pass by S3's intersection operation. Similarly, although the user email (users.email) and order ID (orders.id) were in A's data, they were not actually needed for the task and were not included in the security pass.

[0081] S4 performs dynamic shrinking in the following sequence: Step 1: Before execution, activate {users.id, users.name} (2 entries), query user basic information, and immediately reclaim them, reducing the effective permission set to 3 entries. Step 2: Before execution, activate {orders.amount, orders.refund_amount} (2 entries), query and immediately reclaim them, reducing the effective permission set to 1 entry. Step 3: Before execution, activate {orders.status} (1 entry), query and reclaim it, leaving the effective permission set empty.

[0082] PER quantitative assessment: n=3, |P|=5, Σ|R i |=2+2+1=5, ρ=5 / 5=1, η=1 / (3×1)≈33.3%. Static model PE_existing=5×1.0=5.0 (field·second), S4 dynamic shrinkage PE_S4=2×0.3+2×0.2+1×0.5=1.5 (field·second), η=1.5 / 5.0=30%. If S3 (no intersection operation) is not used, all 10 fields of the pre-configured permission range enter the task, PE_existing=10.0, which is about 5.67 times more exposure than the combined implementation of S3+S4 - fully verifying the superposition effect of S3 spatial pruning and S4 temporal pruning.

[0083] Anomaly monitoring scenario: Assume the following three anomaly events occur during step two. Event 1 (Unauthorized Access) – Developer A attempts to indirectly query the `users.phone` field by modifying SQL conditions. This field is not in the valid permission set of the security pass. The resource access proxy intercepts and returns a denial response. The behavior monitor records anomaly type A, anomaly_counter=1. Event 2 (Duplicate Access) – After obtaining order amount data through `orders.amount`, Developer A queries `orders.amount` twice more with different query conditions. The behavior monitor detects this duplicate access pattern, recording anomaly type B, anomaly_counter=2. Event 3 (Unauthorized Access) – Developer A further attempts to query the `users.address` field. The resource access proxy intercepts, anomaly_counter=3, reaching the preset cumulative threshold (threshold=3). The threshold circuit breaker is triggered immediately: freezes all permission entries of the security pass, forcibly terminates the task and transfers it to S6 full permission reclamation, and sends an alarm notification to the preset security alarm channel (task_id=E001, number of exceptions=3, operation=task termination+permission freeze).

[0084] In the above scenarios, S6 ensures that permissions are completely revoked in any exit mode through multiple paths, including timeout exit (timer expires), abnormal interruption (S5 circuit breaker forced termination), or idle silence (no operation after task completion). S7 records the complete audit chain.

[0085] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A method for dynamically contracting and reclaiming permissions for MCP intelligent agents, characterized in that: Includes the following steps: S1: Receive the MCP agent protocol request, identify the task intent corresponding to the request, and generate a task context carrying the task identifier and task type; S2: Based on the agent's identity and task type in the task context, obtain the agent's pre-configured permission range and the resource access requirements corresponding to the task type, respectively; S3: Perform minimum permission calculation at the resource access granularity on the pre-configured permission range and the resource access requirements to obtain the minimum permission set for this task; S4: Execute the resource access operations of each step in the order of the execution steps of the task type, and revoke the permissions corresponding to each step after the execution of each step is completed; S5: During task execution, monitor the resource access behavior of the intelligent agent and maintain an abnormal behavior counter. When an abnormal behavior that meets the preset conditions is detected, perform an adjustment operation on the permission set of the current task. When the cumulative value of the abnormal behavior counter reaches a configurable cumulative threshold, perform a circuit breaker operation to freeze permissions or terminate the task. S6: When the task is detected to meet the preset exit conditions, all residual permissions of the task are automatically revoked; S7: Persist the permission change events of the entire process from task generation to permission revocation as a traceable audit record.

2. The method as described in claim 1, characterized in that: The minimum permission calculation at the resource access granularity described in S3 includes: representing the pre-configured permission range and the resource access requirements as mapping structures from data table identifiers to field lists, and performing field-level intersection operations on a table-by-table basis; if the intersection of any resource fields marked as required is empty, the task is rejected; if all required fields pass the validation, the validity period of the minimum permission set is bound to the lifecycle of this task; the permission revoke described in S4 includes: pre-configuring a step-resource mapping table, activating the access permissions of the resource fields required for each step before execution, and removing the activated permission entries from the current valid permission set according to the step-resource mapping table after the step is completed, so that subsequent steps cannot access the corresponding resources through the removed permission entries.

3. The method as described in claim 1, characterized in that: The preset exit conditions in S6 include at least one of the following: (a) all preset steps of the task have been completed; (b) the total execution time of the task exceeds the preset effective time threshold; (c) the execution process of the task is abnormally interrupted, and no process survival signal is received for more than the preset heartbeat detection interval; (d) the task does not perform any resource access operations during the preset idle period. The above four exit conditions are logically ORed, and the recycling operation is triggered when any condition is met.

4. The method as described in claim 1, characterized in that: S3, S4, and S6 work together in a sequential manner to form a closed loop for full lifecycle management of permissions: S3 determines the initial boundary of task permissions based on the intersection of the pre-configured permission range and resource access requirements; S4 gradually shrinks the boundary as each step is completed during task execution; and S6 clears all residual permissions when the task meets the exit conditions. The three work together to achieve integrated closed-loop management of permissions from generation to gradual shrinkage to final revocation.

5. The method as described in claim 1, characterized in that: The monitoring dimensions of S5 include at least one of the following: (a) access frequency - monitoring whether the number of times the same resource is accessed within a preset time window exceeds a first preset threshold; (b) access mode - monitoring whether the resource fields actually accessed in the current step deviate from the preset resource field list; (c) data volume - monitoring whether the data volume returned by a single resource access exceeds the preset normal data volume range; (d) step time consumption - monitoring whether the execution time of a single step exceeds a preset timeout threshold; accordingly, when the abnormal behavior is detected, at least one of the following adjustment operations is performed: temporarily suspending at least one permission entry, or narrowing the permission set of the current step to the minimum necessary subset corresponding to the step, or triggering the termination of the current task and transitioning to the full permission reclamation in S6.

6. The method as described in claim 1, characterized in that: S1 identifies the task intent by extracting at least one of the tool name, parameter structure features, and resource identifier from the protocol request, and matching it with a preset task type-intent feature mapping table according to priority, wherein exact matching of the tool name is the first priority, matching of parameter structure keywords is the second priority, and wildcard matching of resource identifier templates is the third priority; S2 stores the pre-configured permission scope in a three-level hierarchical structure of resource type-data table-field; S7 includes the event timestamp, task identifier, operation type, involved resource identifier, a complete snapshot of the permission set before the operation, and a complete snapshot of the permission set after the operation, and stores them in an append-only manner that cannot be modified or deleted.

7. The method as described in claim 5, characterized in that: S5 further maintains an abnormal behavior counter and a configurable cumulative threshold for the current task; when the agent attempts to access a resource field that exceeds the current valid permission set, the abnormal behavior counter is incremented by one; when the agent repeatedly accesses the same authorized resource field in a single step and the number of repeated accesses exceeds a preset frequency threshold, the abnormal behavior counter is incremented by one; when the cumulative value of the abnormal behavior counter reaches the configurable cumulative threshold, the current valid permission set of the task is frozen and the current task is terminated and transferred to S6 for full permission reclamation, while an alarm notification is sent to a preset security alarm channel.

8. A system for implementing the method according to any one of claims 1 to 7, characterized in that, Includes the MCP-Security-Enhance security pass module and the MCP-Permission-Base permission platform: The MCP-Security-Enhance security pass module is used to receive MCP agent protocol requests, identify task intent and generate task context, obtain pre-configured permission range and resource access requirements according to agent identity and task type, obtain the minimum permission set for this task by calculating the minimum permission at the resource access granularity and encapsulate it as a security pass. The MCP-Permission-Base permission platform is used to execute resource access operations in the order of steps defined by the security pass, and reclaim the permission entries corresponding to each step after each step is completed. During task execution, it monitors resource access behavior and maintains an abnormal behavior counter. When the abnormal count reaches a configurable cumulative threshold, it performs circuit breaking, freezing, or alarm operations. When it detects that the task meets the preset exit conditions, it automatically reclaims all residual permissions and persists the entire process of permission change events as traceable audit records.

9. The system as described in claim 8, characterized in that: The MCP-Security-Enhance security pass module further includes a protocol access parsing submodule and a policy decision submodule. The protocol access parsing submodule is used to receive MCP agent protocol requests and perform intent recognition. The policy decision submodule is used to obtain the agent's pre-configured permission range and task resource access requirements, and obtain the minimum permission set through field-level intersection operation. The MCP-Permission-Base permission platform further includes a permission execution control submodule and an audit revoke submodule. The permission execution control submodule includes: a step scheduler, used to read the step-resource mapping table and drive each execution step in sequence, activate the access permission of the corresponding resource field before each step is executed, and remove the activated permission entry after execution; a resource access proxy, used to intercept each resource access request and check whether the accessed resource field exists in the current valid permission set before the request reaches the actual resource layer; the audit revoke submodule includes: an exit condition monitor and a revoke executor, used to automatically revoke all residual permissions when the task meets the preset exit conditions; and an audit logger, used to persistently store audit records in an append-written immutable log format.

10. The system as described in claim 8, characterized in that: The permission execution and control submodule in the MCP-Permission-Base permission platform further includes a behavior monitor and a threshold circuit breaker; the behavior monitor is used to monitor the allow and deny records of resource access agents in multiple dimensions, including access frequency, access mode, data volume and step time, and maintains an abnormal behavior counter to accumulate counts of unauthorized access events and repeated access events to the same resource. The threshold circuit breaker is used to store configurable cumulative thresholds. When the cumulative value of the abnormal behavior counter reaches the cumulative threshold, it sends a permission freeze command to the step scheduler, a pass revocation command to the resource access agent, a task forced termination command to the audit recovery submodule, and an alarm notification to the preset security alarm channel.

Images