Private cloud dynamic permission generation system and method

Abstract

The invention provides a private cloud dynamic permission generation system and method, and relates to the field of cloud computing permission management. According to the method, a ternary graph structure is constructed to represent the relationship among tenants, resources and contexts; reverse deduction of a legal access path is realized through a graph search algorithm (such as DFS); automatically generating a permission set based on the path result; authority merging, minimum authorization and signature verification mechanisms are realized; the method can be applied to cloud systems. According to the method, the problems of permission mixing, configuration lag and fine-grained access control among tenants are effectively solved, and the dynamic property, the safety and the expandability of permission management are improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of cloud computing rights management, and in particular to a system and method for generating dynamic rights in a private cloud. Background Art

[0002] With the continuous evolution of cloud computing technology, private cloud platforms, as an important carrier for enterprise-level IT resource management, are widely used in complex business environments shared by multiple tenants. Among related technologies, the MCP (Model Context Protocol), a standardized interface connecting large language models with external resources, has enabled context-aware resource invocation capabilities in private clouds. Specifically, this technology system covers the entire process from tenant identity identification, resource access control, to context operation binding, including key links such as permission configuration, policy management, and access verification. Among them, permission control is the core mechanism for ensuring tenant isolation and resource security. Traditional methods rely on static policy tables or role-based permission models, which are difficult to adapt to the complex needs of dynamic resource changes and context associations.

[0003] However, existing permission management methods directly use preset permission tables for access control without dynamically inferring the request context. This can lead to problems such as delayed permission configuration, unauthorized tenant access, and ineffective resource isolation. This is especially true in scenarios where resources are frequently created, deleted, or drifted, as permission synchronization mechanisms are unable to respond in real time, posing security risks. Furthermore, traditional methods lack systematic modeling of the tenant-resource-context ternary relationship, making it difficult to achieve fine-grained, structured permission expression and verification, thus impacting the scalability and security of private cloud platforms in large-scale concurrent environments. Summary of the Invention

[0004] The present invention aims to solve one of the technical problems in the related art at least to a certain extent.

[0005] To this end, the first objective of the present invention is to propose a dynamic permission generation system for private cloud MCP servers. Specifically for MCP server implementation, a ternary graph structure is introduced for the first time to model tenant-resource-context relationships; a path verification mechanism based on depth-first graph search is constructed; permission merging, minimum authorization, and signature verification mechanisms are implemented for MCP servers, and a permission-request binding mechanism is introduced for the authentication process.

[0006] The second object of the present invention is to propose a method for generating dynamic permissions for a private cloud MCP Server.

[0007] A third object of the present invention is to provide a computer-readable storage medium.

[0008] To achieve the above objectives, the first embodiment of the present invention proposes a private cloud MCP Server dynamic permission generation system, including: A graph construction module, configured to construct a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing derivable paths between the three nodes; The request parsing and context extraction module is used to parse the MCP Client request, extract the tenant identifier, resource identifier, and context operation in the request, and map them to triple nodes in the graph structure; A path reasoning and permission generation module is used to use a graph search algorithm to reversely infer whether there is a legal access path from the tenant node to the context node based on the triple node, and automatically generate a permission set including operation type, resource identifier and constraint conditions based on the legal access path; The permission verification and injection module is used to perform triplet signature verification on each path in the permission set and inject the verified permission set into the response header or context structure of the MCP Server; The graph dynamic maintenance module is used to detect state changes and trigger dynamic updates of the graph structure and permission verification through the message queue.

[0009] In one embodiment of the present invention, the graph construction module is further configured to: Tenant nodes, resource nodes, and context nodes are stored as entities in the graph database, and attribute information is added to each directed edge, including validity period, operation type, and signature information. By subscribing to change events in the configuration center or CMDB database, the graph structure is initialized and continuously maintained, ensuring real-time synchronization of tenants, resources, and contextual relationships.

[0010] In one embodiment of the present invention, the request parsing and context extraction module is further configured to: Standardize the context field in the request and map it to predefined context operation nodes in the graph structure; If the request does not include resource_id, then based on the tenant identifier and the context operation node, a possible set of resource nodes is derived through the association relationship in the graph structure.

[0011] In one embodiment of the present invention, the path reasoning and authority generation module is further configured to: Use the depth-first search algorithm to traverse the graph structure, verify whether there is a legal path from the tenant node to the context node, and record the resource nodes involved in the path; If there are multiple legal paths, the minimum scope merging algorithm is used to deduplicate and merge the permission sets to ensure the minimization and security of permission expression.

[0012] In one embodiment of the present invention, the generated permissions are bound to the request or used in the authentication process; the generated permissions are injected in the following ways: Embed the authorization result as a token in the response header and return it to the client; Attach the permissions to the MCP context structure and pass them into the subsequent processing flow.

[0013] In one embodiment of the present invention, verification is performed based on a preset permission verification function. If the verification fails, the system returns HTTP 403 Access Denied and records it in the audit log. At the same time, the MCP Client obtains permission failure information.

[0014] In one embodiment of the present invention, the graph dynamic maintenance module is further configured to: When the graph dynamic maintenance module detects a change in tenant or resource status, it obtains the change event through the message queue monitoring mechanism and triggers a dynamic update of the graph structure, including adding, deleting or modifying tenant nodes, resource nodes or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

[0015] To achieve the above objectives, a second embodiment of the present invention provides a method for generating dynamic permissions for a private cloud MCP Server, including: S1, constructing a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing derivable paths between the three nodes; S2, parses the MCP Client request, extracts the tenant identifier, resource identifier, and context operation in the request, and maps them to triple nodes in the graph structure; S3, based on the triple node, using a graph search algorithm to infer whether there is a legal access path from the tenant node to the context node, and automatically generating a permission set including the operation type, resource identifier, and constraint conditions according to the legal access path; S4: Perform triplet signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server; S5, detects state changes and triggers dynamic updates of the graph structure and permission verification through the message queue.

[0016] To achieve the above-mentioned purpose, the third embodiment of the present invention proposes a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the method described in the second embodiment is implemented.

[0017] The system, method, and storage medium of the embodiments of the present invention realize automatic generation and real-time verification of permissions in a multi-tenant private cloud MCP Server environment, effectively solving the problems of mixed permissions, delayed configuration, and insufficient fine-grained control, and improving system security and scalability.

[0018] Additional aspects and advantages of the present invention will be set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which: Figure 1 This is a structural diagram of a private cloud MCP Server dynamic permission generation system according to an embodiment of the present invention; Figure 2 is a data flow diagram of a graph dynamic maintenance module according to an embodiment of the present invention; Figure 3 The present invention is a flowchart of a method for generating dynamic permissions for a private cloud MCP Server according to an embodiment of the present invention. DETAILED DESCRIPTION

[0020] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments of the present invention can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0021] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0022] The following describes a system, method, and computer-readable storage medium for generating dynamic permissions for a private cloud MCP Server, according to embodiments of the present invention, with reference to the accompanying drawings.

[0023] The technical terms of the present invention are introduced below: Cloud platform: Cloud computing platform, also known as cloud platform, refers to services based on hardware resources and software resources, providing computing, network and storage capabilities.

[0024] MCP: Model Context Protocol (MCP) is an open source protocol launched by Anthropic. It aims to integrate large language models with external data sources and tools, and is used to establish a secure two-way connection between large models and data sources.

[0025] MCP Server: Provides AI MCP (Model Context Protocol) services, allowing AI to call tools more freely.

[0026] Based on the implementation of a cloud operating agent (based on a private cloud MCP server), this paper proposes a method for dynamic permission generation for a private cloud MCP server based on a tenant resource map. This method, implemented in the MCP server, constructs a ternary graph structure that supports multi-level reasoning. By combining request context to infer the set of legal access permissions, this method enables automatic permission generation and instant verification. This method, based on rapid graph traversal, addresses issues such as inconsistent permissions, a lack of context, and non-scalability. The key concepts are as follows: First, define the tenant, resource, and context ternary graph structure G = (T, R, C, E), where: T is a set of tenant nodes (Tenant), each node represents a tenant ID; R is a collection of resource nodes (Resource), such as virtual machines, storage volumes, containers, models, etc. C is a collection of context nodes (Context), including function calls, system events, model names, inference scenarios, and control interfaces such as create_vm, delete_vm, and resize_vm; E is a set of directed edges, representing a set of derivable paths such as T->R, R->C, and C->R.

[0027] The permission inference path is as follows: When an MCP Cli request is received by the MCP Server, the request context is extracted and mapped to the node set C in the graph structure. The system then performs a path inversion algorithm to find all subgraphs that satisfy the following path conditions: Treq → Ri → Creq, where Treq is the tenant node of the current request and Creq is the context node (e.g., create_vm). If there is a path from Treq through Ri to Creq, the request has permission to access Creq. Based on this path, the permission set Perm(Treq, Creq) is automatically generated.

[0028] Permission set generation: Construct a permission expression based on a set of valid paths, for example: Perm(T123, Context['create_vm']) = { resource_id: Cluster_12, action: [vm.create,quota.assign], valid_scope: project['cloud-native-dev']}, and encapsulate the permission set as the token information in the MCP response header.

[0029] Instant Permission Verification This method provides a permission cache refresh mechanism. When the tenant or resource status changes (such as creating a virtual machine or deleting a storage volume), the graph structure is dynamically updated and the permission reasoning path is synchronized in real time.

[0030] Permission Verification Each inference path must pass the triple signature verification mechanism: Sign(TID, RID, CID) to prevent path forgery or unauthorized access.

[0031] Figure 1 is a structural diagram of a private cloud MCP Server dynamic authority generation system according to an embodiment of the present invention, such as Figure 1 Shown, including: The graph construction module 100 is used to construct a tenant, resource and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes and directed edges representing derivable paths between the three.

[0032] This module is used to initialize and continuously maintain the graph structure relationship between tenants, resources and context triples, and store it in a graph database such as neo4j.

[0033] When the MCP Server starts, it connects to the configuration center or the CMDB database (mostly a relational database) to obtain information about tenants, resources, and their operational capabilities.

[0034] Each tenant T_i is used as the starting node, each resource R_j is used as the intermediate node, and each context operation C_k is used as the target node to construct a ternary path T_i → R_j → C_k.

[0035] The graph structure G can be formally defined as a ternary directed graph: G = (V, E), where V = T ∪ R ∪ C, E ⊆V×V.

[0036] All edges E are persistently stored in the graph database. For example, in the Neo4j graph database, they are represented as follows: MERGE (t:Tenant {id: 'T001'}) MERGE (r:Resource {id: 'VM001'}) MERGE (c:Context {action: 'create_vm'}) MERGE (t)-[:OWNS]->(r)-[:ALLOWS]->(c) Attributes need to be added to each edge: expiry, operation type (op_type), signature, etc.

[0037] Specifically, the three entities of tenants, resources, and contexts, and their operational relationships, are abstracted as nodes and directed edges in a graph structure, enabling structured reasoning and dynamic generation of permissions. Specifically, the ternary graph structure is defined as G = (T, R, C, E), where T is the set of tenant nodes, R is the set of resource nodes, C is the set of context nodes, and E is the set of directed edges representing derivable paths between tenants and resources, and between resources and contexts. Each tenant node T_i represents a tenant ID, resource nodes R_j represent specific resource instances in the cloud platform (such as virtual machines, storage volumes, containers, models, etc.), and context nodes C_k represent the operational behavior or control interface in the request (such as create_vm, delete_vm, resize_vm, etc.).

[0038] At the parameter indicator level, tenant nodes must include metadata such as tenant ID, project, and region; resource nodes must include attributes such as resource type, resource ID, cluster, and status; and context nodes must standardize operational behavior to ensure consistency with request context fields (such as the context field). Furthermore, edge signatures are generated using an asymmetric encryption algorithm (such as RSA or ECDSA) via the `sign_edge(tid, rid, cid, private_key)` function to prevent path forgery and unauthorized access.

[0039] In practical applications, it is primarily used in the permission control system of private cloud MCP Servers, and is particularly suitable for scenarios with multiple tenants and frequent dynamic resource changes. By constructing a graph structure, the system can automatically derive and instantly verify permissions, eliminating the need for manual configuration of permission tables, significantly improving the real-time and scalability of permission management. In terms of technical effectiveness, this graph structure provides a data foundation for subsequent path inference algorithms (such as DFS), enabling the permission verification process to possess structured reasoning capabilities, thereby achieving fine-grained, context-aware access control, and effectively resolving technical challenges in traditional permission management, such as inconsistent permissions, delayed configuration, and a lack of contextual awareness.

[0040] In one embodiment of the present invention, the graph construction module 100 is also used to: store tenant nodes, resource nodes and context nodes as entities in the graph database respectively, and add attribute information to each directed edge, including validity period, operation type and signature information; by subscribing to change events of the configuration center or CMDB database.

[0041] At the technical implementation level, the system first defines three entities: tenants, resources, and contexts, as node types in the graph database. Tenant nodes typically contain unique identification information such as the tenant ID; resource nodes include resource types (such as virtual machines, storage volumes, and containers) and resource IDs; and context nodes represent specific operations, such as `create_vm` and `delete_vm`, typically consisting of an action type and parameters (such as `region` and `project`). In the graph database, these nodes are connected by directed edges, forming a ternary path structure, such as T_i → R_j → C_k, indicating that tenant T_i has permission to operate on resource R_j in context C_k.

[0042] Furthermore, to enhance the security and timeliness of permission verification, the system adds key attribute information to each directed edge. The expiry period (expiry) is used to control the lifecycle of permissions and is typically expressed in ISO 8601 time format (e.g., `2025-12-31T16:00:00Z`), ensuring that permissions are valid within a specified timeframe. The operation type (op_type) identifies the specific operation represented by the edge, such as `read`, `write`, `delete`, and supports a hybrid model of RBAC (role-based access control) and ABAC (attribute-based access control). The signature information (signature) digitally signs the triple (TID, RID, CID) using an asymmetric encryption algorithm (e.g., RSA or ECDSA) to prevent path tampering or forgery, ensuring the integrity and immutability of the graph structure.

[0043] In practical applications, this approach is widely used during the permission initialization phase of private cloud MCP servers, as well as during graph structure updates when resources dynamically change. For example, when a tenant applies to create a virtual machine, the system quickly determines whether they possess the `create_vm` permission based on the path relationships in the graph database and verifies the permission based on the validity period and signature information in the edge attributes. This provides a structured, queryable graph model foundation for subsequent path reasoning and permission generation modules, a prerequisite for automatic permission derivation and instant verification.

[0044] Furthermore, the core implementation method of the dynamic graph maintenance and security verification module in the present invention is based on the technical principle of the event-driven architecture (EDA) and the incremental update mechanism of the graph database, which realizes the automatic construction and dynamic evolution of the tenant resource mapping graph.

[0045] At the technical implementation level, the MCP Server subscribes to the change event stream from the configuration center or CMDB database through a messaging middleware (such as Kafka or RabbitMQ). The configuration center or CMDB typically uses a relational database (such as MySQL or PostgreSQL) to store metadata about tenants, resources, and their operational permissions. When tenant-resource relationships change (such as adding a virtual machine, deleting a storage volume, or adjusting tenant permissions), the system publishes the change event to a message queue through a database trigger or Change Data Capture (CDC) mechanism. The MCP Server, acting as a consumer, listens to this queue in real time, parses the event content, and maps it to node and edge change operations in the graph structure.

[0046] The specific operation methods include: For new resource events, the system creates a corresponding Resource node in the graph database and establishes a T→R edge through the tenant-resource relationship. For resource deletion events, the system executes the graph database node deletion operation and simultaneously cleans up the related edges. For context operation extensions (such as the new create_model interface), the system creates a new Context node in the graph and establishes an R→C edge. Each edge must be digitally signed using the Sign(TID, RID, CID) function when it is created or updated to ensure the integrity and tamper-proofness of the graph structure.

[0047] At the parameter and metric level, the system supports multiple message queue protocols. For example, the Kafka topic is "resource_change," and the message format is JSON, containing fields such as event type (event_type), tenant ID (tenant_id), resource ID (resource_id), and context action (context_action). Edge attributes in the graph database include expiry, operation type (op_type), and signature. Signatures are generated using asymmetric encryption algorithms (such as RSA or ECDSA) to ensure the verifiable legitimacy of each edge. Furthermore, the system supports version control of the graph structure. After each change event is triggered, the graph database records the change timestamp and operator for audit and backtracking purposes.

[0048] At the application scenario level, this feature is applied to the permission management of MCP servers in private cloud platforms, particularly in environments where tenant resources frequently change and context operations dynamically expand. For example, when the cloud platform is elastically expanded, the system can automatically associate newly added virtual machine resource nodes with tenant nodes and add the corresponding create_vm or delete_vm permission paths in the context operations, thereby achieving instant synchronization and effectiveness of permissions.

[0049] Through an event-driven mechanism and the real-time update capabilities of a graph database, the system dynamically maintains tenant-resource-context relationships, ensuring that the permission inference path remains consistent with the actual resource state. This improves the real-time, accuracy, and security of permission control and effectively prevents unauthorized access caused by configuration delays. Furthermore, this mechanism supports the evolution of permission models in high-concurrency, large-scale tenant environments, providing a reliable data foundation for subsequent permission verification and reasoning.

[0050] The request parsing and context extraction module 200 is used to parse the MCP Client request, extract the tenant identifier, resource identifier and context operation in the request, and map them into triple nodes in the graph structure.

[0051] Specifically, in some implementations, parsing the MCP Client request and extracting the tenant identifier, resource identifier, and context operation from it, and mapping them into triple nodes in a graph structure, is the primary technical step in the dynamic permission generation and verification process of the present invention. Its core lies in structuring the original request information and converting it into a reasonable path in the graph model, thereby providing basic data support for subsequent permission verification.

[0052] This is achieved through the request parsing and context extraction module. The specific process includes: first, extracting the `tenant_id` field from the JSON-formatted request sent by the MCP client as the tenant node T in the graph structure; second, parsing the `context` field and normalizing it into a context operation node C, for example, mapping "create_vm" to the graph's Context node; finally, if the request includes the `resource_id` field, it is used as the resource node R, and a triple (T, R, C) is constructed as the input for the graph path search. If the request does not specify a resource ID, the system infers a set of possible resource nodes from the graph structure based on the resource ownership relationships of the current tenant T to support the validity verification of the context operation.

[0053] During request parsing, the system must ensure standardized field processing. For example, the `context` field must conform to a predefined enumeration of operation types (such as create_vm and delete_vm). This standardization process must adhere to the specifications of a hybrid RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) model. Furthermore, the tenant ID must strictly match the node ID in the T set of the graph database, and the resource ID must be consistent with the node ID in the R set to ensure graph path accuracy. Response time should be kept within 5ms to meet the real-time requirements of the MCP Server for context operations.

[0054] This module is widely used in the permission control process of MCP servers in private cloud platforms, especially in multi-tenant environments. For example, when tenant T001 requests to create virtual machine VM001, the system must quickly identify whether the tenant has the permission path for the corresponding resource and context operation. This module can be deployed in the front-end gateway or API gateway of the MCP server as the first line of defense for permission control, ensuring that all requests are structured and permission path mapped before entering the core processing flow.

[0055] Through this, the system achieves a precise mapping of request context and graph structure, providing structured input for subsequent path reasoning and permission generation, effectively avoiding issues such as delayed permission configuration and missing context in traditional RBAC models. Furthermore, it supports real-time identification of dynamic resources and contextual operations, laying the foundation for implementing the principle of least privilege and fine-grained access control, significantly improving the security and response efficiency of the MCP Server in multi-tenant environments.

[0056] Furthermore, the request parsing and context extraction module 200 is also used to: standardize the context field in the request and map it to a predefined context operation node in the graph structure; if the request does not contain resource_id, then based on the tenant identifier and the context operation node, derive the possible resource node set through the association relationship in the graph structure.

[0057] This module is responsible for structuring requests received by the MCP Server into graph node information. The overall processing flow is as follows: a. Extract the tenant_id from the request and use it as the starting node T. b. Parse the context field and normalize it to create the target context node C. c. If the request contains a resource_id, use it as the intermediate node R, and the triple (T, R, C) as the path search input. Otherwise, possible resources are derived from the graph.

[0058] Specifically, the request parsing and context extraction module first processes received MCP requests. Requests are typically transmitted in JSON format and contain fields such as `tenant_id`, `context`, and `resource_id`. The system parses the `context` field and matches it against a predefined set of context operation nodes C in the graph structure. Nodes in set C represent specific context operations, such as `create_vm`, `delete_vm`, and `resize_vm`. Each node must meet certain naming conventions and operational semantic standards, such as those in RBAC (role-based access control) or ABAC (attribute-based access control). To achieve standardized mapping, the system can use regular expression matching, natural language processing (NLP) classification models, or predefined mapping tables for field conversion. In some implementations, the system can incorporate a context normalization engine to unify context fields with different formats or similar semantics into a standard operation identifier, for example, normalizing "create virtual machine" to `create_vm`, to ensure consistency and identifiability of nodes in the graph structure.

[0059] The mapping process requires consideration of several key parameters, including regular expression rules for field parsing, the accuracy of the context classification model (e.g., F1-score ≥ 0.95), the mapping table update frequency (hourly synchronization with the configuration center is recommended), and the unique identifier of the context node (e.g., the `action` field must be a globally unique string). Furthermore, the mapping result must include metadata about the context node, such as the operation type (op_type), resource category (resource_type), and scope (scope), to support subsequent permission constraint generation.

[0060] In the permission control process of a private cloud MCP server, particularly in a multi-tenant environment, the system needs to dynamically determine whether a tenant has permission to perform a specific operation based on the request context. For example, when tenant T001 initiates a request to create a virtual machine, the system maps the `context` field to the `create_vm` node and performs path inference on the tenant node T001 and the resource node VM001 to generate the corresponding permission set.

[0061] By mapping the request context to standard nodes in a graph structure, the permission verification process is structured and automated, effectively improving the accuracy and real-time nature of permission determination. Furthermore, standardization provides a unified input format for subsequent path search algorithms (such as DFS), enhancing the system's scalability and maintainability. This is the core prerequisite for achieving fine-grained, context-aware permission control.

[0062] Furthermore, in some implementations, if the request does not include `resource_id`, the system infers a possible set of resource nodes through the association relationship in the graph structure based on the tenant identifier (`tenant_id`) and the context operation node (`context`). This is one of the core logics of the path reasoning and permission generation module in the present invention. Its technical implementation is based on the ternary relationship modeling in the graph database, that is, the directed edge relationship between tenant (Tenant), resource (Resource), and context operation (Context). Specifically, the system first maps the `tenant_id` in the request to the tenant node `Treq` in the graph, parses and standardizes the `context` field into the context operation node `Creq`, and then uses a graph traversal algorithm (such as depth-first search DFS) to find all resource node sets `{R_i}` that meet the path condition `Treq → R_i → Creq`.

[0063] The path reasoning and permission generation module 300 is used to reversely infer whether there is a legal access path from the tenant node to the context node based on the triple node using a graph search algorithm, and automatically generate a permission set including operation type, resource identifier and constraint conditions based on the legal path.

[0064] Specifically, in the path reasoning and permission generation module, the system uses a depth-first search (DFS) algorithm based on the constructed tenant-resource-context ternary graph structure to infer whether a valid access path exists from the tenant node to the context node. Based on this path, it automatically generates a permission set containing the operation type, resource identifier, and constraints. This is the core logic for implementing dynamic permission control. Its technical implementation principle is based on path reachability analysis in graph theory, combining contextual semantics with tenant resource ownership to achieve fine-grained, real-time permission derivation.

[0065] In some implementations, the DFS algorithm starts with the tenant node Treq in the request and traverses all possible directed edges in the graph (e.g., T→R, R→C, C→R), searching for a path from Treq to the target context node Creq. This path must satisfy both resource ownership and context operation permissions. For example, if the request context is "create_vm," the system checks for a path from Treq → R_i → Creq, where R_i is a resource node owned by the tenant Treq. If a path exists, it indicates that the tenant has permission to perform the context operation.

[0066] Furthermore, after successful path verification, the system generates a permission set (Perm(Treq, Creq)) based on the resource nodes, context operations, and edge attributes (such as validity period, operation type, and signature) in the path. A permission set typically includes the tenant ID, resource ID, operation type (such as vm.create and quota.assign), and constraints (such as region restrictions and the validity period valid_until). The generation of permission sets must adhere to the principle of minimum scope (MinScope), which selects the permission set with the smallest scope among multiple legal paths to implement the principle of least privilege.

[0067] Optionally, the system supports merging permission sets, using a Union or Intersection algorithm to merge and deduplicate permissions generated by multiple paths, ensuring the uniqueness and consistency of permission expressions. Furthermore, permission sets are encapsulated as structured token information and injected into the MCP response header or context structure for subsequent authentication modules.

[0068] This system plays a key role in private cloud MCP Servers. Its technical benefits are reflected in the automatic derivation and instant verification of permissions, effectively resolving issues such as permission lag, unauthorized access, and high maintenance costs associated with traditional static permission configuration. Through rapid graph traversal and path verification, the system can complete permission determination within millisecond response times, making it suitable for private cloud environments with high concurrency and dynamically changing resources. Furthermore, the triple signature mechanism (Sign (TID, RID, CID)) prevents path forgery and enhances system security and credibility.

[0069] Furthermore, the path reasoning and permission generation module 300 is also used to: use a depth-first search algorithm to traverse the graph structure, verify whether there is a legal path from the tenant node to the context node, and record the resource nodes involved in the path; if there are multiple legal paths, use the minimum scope merging algorithm to deduplicate and merge the permission sets to ensure the minimization and security of permission expression.

[0070] It is understandable that this module uses a deep graph search algorithm to identify legal access paths and outputs permission expressions to perform access control. After inputting the triple (T, R, C), the path verification algorithm expression is executed: def verify_path(graph, T, C): stack = [(T, [])] while stack: node, path = stack.pop() if node == C: return True, path for neighbor in graph.successors(node): if neighbor not in path: stack.append((neighbor, path + [neighbor])) return False, [] If the path exists, construct the permission set Perm(T, C), the expression is: { "tenant": "T001", "resource": "VM001", "operation": "create_vm", "constraints": { "region": "cn-beijing", "valid_until": "2025-12-31" } } If there are multiple legal paths, a merging algorithm is needed to merge permissions, such as: Perm = Union(Perm_1, Perm_2, ..., Perm_n) or Perm = MinScope(Perm_i). After removing duplicates, the minimum scope set is selected.

[0071] Specifically, the algorithm uses a pre-built ternary directed graph G = (T, R, C, E) in a graph database (such as Neo4j), where T is the set of tenant nodes, R is the set of resource nodes, C is the set of context nodes, and E is the set of directed edges between nodes. Upon receiving a request, the MCPServer first extracts the tenant ID, resource ID, and context action through the request parsing and context extraction module, forming a triplet (T, R, C) that serves as the input for the DFS algorithm. Starting from a tenant node Treq, the DFS algorithm recursively traverses all reachable resource nodes Ri, further checking whether a resource node can connect to the target context node Creq. The algorithm implements non-recursive traversal by maintaining a stack structure. Each time a node is popped, it checks whether it is the target context node. If a match is not found, the unvisited adjacent nodes are pushed onto the stack. The algorithm also records the visited paths to prevent circular traversal.

[0072] The DFS algorithm requires a maximum traversal depth (default is 5) to avoid infinite recursion or performance bottlenecks in large-scale graph structures. Each edge must carry metadata such as signature, expiry, and operation type (op_type) for subsequent permission verification. Path verification results must return a Boolean value (True / False) and a list of path nodes (path), which are used to construct the permission set Perm(Treq, Creq). The permission set must include key parameters such as resource ID, operation type, region constraint (region), and validity period (valid_until) to support fine-grained access control.

[0073] This is widely used in the permission verification process of private cloud MCP servers. Specifically, when tenants initiate resource operation requests (such as creating a virtual machine or deleting a storage volume), the system must determine in real time whether the operation exists in a valid path within the permission graph. For example, when tenant T001 requests the create_vm operation, the system automatically verifies the existence of the path T001 → VM001 → create_vm, records the resource node VM001 involved in the path, and generates the corresponding permission token.

[0074] Leveraging the efficient path search capabilities of the DFS algorithm, the system can complete permission verification within millisecond response times, significantly improving the real-time and accuracy of permission control. Furthermore, the path recording mechanism provides a structured basis for subsequent permission consolidation, minimum scope selection, and audit tracking, enhancing the system's security and traceability. This approach effectively addresses the latency and configuration complexity of permission synchronization in traditional RBAC or ABAC models in multi-tenant, dynamic resource environments, enabling automated permission derivation and context-aware control.

[0075] Furthermore, in the path reasoning and permission generation module, if multiple valid paths exist, the system uses a minimum scope merging algorithm to deduplicate and merge permission sets, ensuring the minimization and security of permission expressions. This is a core component of the present invention's implementation of fine-grained permission control and context-aware access. Its technology implements graph-based path search results, combining semantic analysis of permission expressions with scope comparison to generate the optimal and most secure permission set.

[0076] In some implementations, the system uses a depth-first search (DFS) algorithm to identify the set of all legal paths from the tenant node Treq to the context node Creq: PathSet = {P1, P2, ..., Pn}. Each path P_i corresponds to a permission expression Perm_i. Because different paths may involve different resource nodes R_j and their operation constraints (such as regions, validity periods, and operation types), the system must merge these permission expressions to avoid permission redundancy, conflicts, or unauthorized access.

[0077] The specific operation is as follows: First, the system compares the scopes of all resource nodes R_j in Perm_i to determine whether the metadata, such as the project, region, and tenant level, to which they belong, are consistent. If there are multiple paths pointing to the same context operation but involving different resource nodes, the system uses the minimum scope principle (MinScope) to merge them, that is, selecting the resource node with the smallest scope and the most fine-grained permissions as the basis for the final permission expression. For example, if path P1 involves resource Cluster_12 with the scope project['cloud-native-dev'], and path P2 involves resource Cluster_13 with the scope project['cloud-native-prod'], the system will prioritize Cluster_12 to ensure minimal permissions.

[0078] Furthermore, the system deduplicates and merges the action sets in permission expressions to ensure that the final permission set contains only unique and valid action items. For example, if multiple paths contain the vm.create and quota.assign actions, the system will merge them into a unified action list to avoid duplicate authorization.

[0079] Optionally, the system can also introduce a priority strategy, such as sorting multiple paths based on path length, resource type, operational risk level, and other dimensions, prioritizing the shortest or most secure path for permission merging. Furthermore, to ensure the immutability of permissions, the system performs triple signature verification on the merged permission set, namely Sign(TID, RID, CID), to ensure that the tenant, resource, and context triples in the permission expression exist in the graph structure and have not been illegally modified.

[0080] Through the minimum scope merging algorithm, the system automatically generates a minimum set of permissions when multiple paths exist, effectively reducing the risk of permission leakage and improving the accuracy and security of permission control. This mechanism also supports permission derivation for high-concurrency, large-scale tenants and resources, meeting the real-time and scalability requirements of private cloud MCP Server in dynamic resource management scenarios.

[0081] The permission verification and injection module 400 is used to perform triplet signature verification on each path in the permission set to prevent path forgery or unauthorized access, and inject the verified permission set into the response header or context structure of the MCP Server for subsequent authentication processes.

[0082] Specifically, this module binds the generated permissions to the request or uses them in the authentication process. Permission injection can be done in two ways: a. Embedding the permission result as a token in the response header and returning it to the client; b. Attaching the permission to the MCP context structure and passing it to the subsequent processing flow.

[0083] The permission verification function is expressed as follows: def check_permission(perm, context): return perm['operation'] == context['action']and \ perm['resource'] == context['resource_id'] If the verification fails, the system returns HTTP 403 Access Denied and records it in the audit log. At the same time, the MCP Client receives permission failure information.

[0084] Specifically, this step involves performing a triplet signature verification on each path in the permission set. The verified permission set is then injected into the MCP server's response header or context structure for subsequent authentication. This technical implementation is based on the edge signature mechanism in the graph structure, using asymmetric encryption algorithms to ensure the legitimacy and unforgeability of the paths, thereby achieving fine-grained access control.

[0085] At the technical implementation level, each graph path consists of a triplet (TID, RID, CID), where TID is the tenant identifier, RID is the resource identifier, and CID is the contextual operation identifier. To prevent path forgery or unauthorized access, the system generates a digital signature for each edge during the graph construction phase. This signature algorithm can use a standard asymmetric encryption algorithm such as RSA or ECDSA, signing the triplet with the tenant's private key to generate `signature = Sign(TID, RID, CID, private_key)`. This signature is stored as an edge attribute in a graph database (such as Neo4j) for subsequent verification.

[0086] Once the permission set is generated, the system performs signature verification on each path. This involves decrypting the signature using the tenant's public key to verify its consistency with the original triplet. If verification fails, the path is deemed invalid, the permission set is discarded, and the system returns an HTTP 403 error and records an audit log. The verification process must meet standard requirements such as timestamp verification and signature algorithm consistency verification (such as SHA-256 + RSA) to ensure signature timeliness and algorithm compliance.

[0087] In application scenarios, this is primarily used by the MCP Server to perform real-time verification of the derived permission path after receiving client requests, ensuring the legitimacy of the permission source. Passed permissions are encapsulated in a JWT or custom token format and injected into the response header (e.g., X-Perm-Token) or the MCP context structure for secondary authentication by subsequent service modules (e.g., resource scheduler, model controller).

[0088] The introduction of a triplet signature mechanism effectively prevents security threats such as intermediate node tampering and path forgery, enhancing the credibility of permission derivation results. Furthermore, the signature verification process features low latency (typically completed within 1-5ms), supporting real-time permission control in high-concurrency scenarios and providing secure and efficient technical support for dynamic permission management across multiple tenants and resources in private clouds.

[0089] The method for generating dynamic permissions for a private cloud MCP server based on a tenant resource map in an embodiment of the present invention realizes automatic generation and real-time verification of tenant permissions in a private cloud MCP server, effectively solving the problems of delayed permission configuration, insufficient isolation, and lack of context in a multi-tenant environment, and improving the dynamic nature and security of permission management.

[0090] The graph dynamic maintenance module 500 is used to detect state changes and trigger dynamic updates of the graph structure and permission verification through the message queue.

[0091] It can be understood that this module ensures the security consistency of the system in dynamic situations such as resource changes and context expansion, e.g. Figure 2 shown.

[0092] Subscribe to a message queue (such as Kafka) for listening to obtain real-time operations, for example: VM addition / deletion: triggers R node addition / deletion and its edge update; context operation expansion: updates C node and related R→C edges; tenant change: updates T node and R binding.

[0093] def sign_edge(tid, rid, cid, private_key): message = f"{tid}|{rid}|{cid}" Specifically, when a tenant or resource status change is detected, the system acquires the change event in real time through a message queue monitoring mechanism (such as Kafka or RabbitMQ). This event triggers a dynamic update of the graph structure, including the addition, deletion, or modification of tenant nodes, resource nodes, or context nodes, and their associated directed edges. This also involves revalidating and refreshing the cache of affected permission paths. This is one of the core implementations of the dynamic graph maintenance and security verification module in this invention, ensuring strong consistency between the permission model and the actual resource status.

[0094] At the technical implementation level, the message queue listening mechanism captures change events from the configuration center, CMDB, or resource scheduling system by subscribing to specific topics. Event messages typically contain fields such as the change type (e.g., create / delete / update), tenant ID, resource ID, and context action. Upon receiving the event, the system first parses the event type and associated node information. It then calls the update interface of a graph database (e.g., Neo4j or JanusGraph) to perform atomic operations on nodes and edges within the graph. For example, when a virtual machine resource is added, the system creates a corresponding Resource node and establishes an OWNS edge from the tenant node to the Resource node, as well as an ALLOWS edge from the Resource node to the context node (e.g., create_vm). Each edge carries metadata attributes such as expiry date, operation type (op_type), and signature to support subsequent permission verification.

[0095] Furthermore, after updating the graph structure, the system triggers a revalidation process for the permission path. This process, based on a depth-first search (DFS) algorithm, initiates a path query for the affected tenant nodes to verify that they still have access to specific contextual operations. If the path validation results change (e.g., permissions are removed or added), the system updates the permission cache (e.g., Redis or a local cache) and refreshes the permission token associated with the tenant, ensuring the immediacy and accuracy of subsequent authentication requests.

[0096] Regarding parameter settings, the message queue listener module must be configured with appropriate consumer groups, offset strategies, and retry policies to ensure reliable and sequential event processing. Graph database updates must adhere to ACID transaction principles to ensure atomicity and consistency of node and edge updates. The permission cache refresh strategy can adopt a TTL (Time to Live) mechanism or an event-based active expiration strategy to balance performance and real-time requirements.

[0097] This mechanism plays a key role in the private cloud MCP Server's permission control system. By responding to changes in tenant and resource status in real time, the system can dynamically adjust the permission model, preventing unauthorized access or invalid permissions caused by configuration delays, thereby improving system security and responsiveness. This mechanism significantly enhances the flexibility and automation of permission control, especially in cloud environments with frequently changing resources.

[0098] The tenant resource map-based private cloud MCP Server dynamic permission generation method of the embodiment of the present invention implements real-time response to tenant or resource status changes by introducing a message queue monitoring mechanism, dynamically updates the tenant resource map structure, and re-verifies the relevant permission paths, further improving the real-time and accuracy of permission management and strengthening the system's permission isolation and context association capabilities in complex and changing environments.

[0099] Through the collaboration of the above modules and algorithms, the present invention realizes the automatic derivation, instant authorization, and dynamic control of cloud resource operation permissions under the MCP Server, and combines context, which is particularly suitable for private cloud scenarios with frequent dynamic resource changes and high tenant isolation requirements.

[0100] In order to implement the above embodiment, Figure 3 As shown, this embodiment also provides a method for generating dynamic permissions for a private cloud MCP Server, including: S1, constructing a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing derivable paths between the three nodes; S2, parses the MCP Client request, extracts the tenant identifier, resource identifier, and context operation in the request, and maps them to triple nodes in the graph structure; S3, based on the triple node, using a graph search algorithm to infer whether there is a legal access path from the tenant node to the context node, and automatically generating a permission set including the operation type, resource identifier, and constraint conditions according to the legal access path; S4: Perform triplet signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server; S5, detects state changes and triggers dynamic updates of the graph structure and permission verification through the message queue.

[0101] Furthermore, the S1 includes: S11, store tenant nodes, resource nodes, and context nodes as entities in the graph database, and add attribute information to each directed edge, including validity period, operation type, and signature information; S12, by subscribing to change events in the configuration center or CMDB database, realizes the initialization and continuous maintenance of the graph structure, ensuring the real-time synchronization of tenants, resources and context relationships.

[0102] Furthermore, the S2 includes: S21, normalize the context field in the request and map it to a predefined context operation node in the graph structure; S22: If the request does not include resource_id, a possible resource node set is derived based on the tenant identifier and the context operation node through the association relationship in the graph structure.

[0103] Furthermore, the S3 includes: S31, uses the depth-first search algorithm to traverse the graph structure, verifies whether there is a legal path from the tenant node to the context node, and records the resource nodes involved in the path; S32: If there are multiple legal paths, the minimum scope merging algorithm is used to deduplicate and merge the permission sets to ensure the minimization and security of permission expression.

[0104] Furthermore, the generated permissions are bound to the request or used in the authentication process; the generated permissions can be injected in the following ways: Embed the authorization result as a token in the response header and return it to the client; Attach the permissions to the MCP context structure and pass them into the subsequent processing flow.

[0105] Furthermore, the method further includes performing verification based on a preset permission verification function. If the verification fails, the system returns HTTP 403 Access Denied and records an audit log. At the same time, the MCP Client obtains permission failure information.

[0106] Furthermore, the state change is detected, and the dynamic update of the graph structure and permission verification are triggered through the message queue, including: When a change in tenant or resource status is detected, the change event is obtained through the message queue monitoring mechanism, and the dynamic update of the graph structure is triggered, including adding, deleting or modifying tenant nodes, resource nodes or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

[0107] The method for dynamic permission generation for a private cloud MCP server according to an embodiment of the present invention implements automatic permission generation and instant verification in a private cloud MCP server, solving problems such as tenant and resource isolation, context association, and fine-grained permission control.

[0108] The present invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the above-mentioned private cloud MCP Server dynamic permission generation method is implemented.

[0109] In the description of this specification, the reference terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" mean that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0110] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

Claims

1. A private cloud MCP Server dynamic permission generation system, characterized by: include: A graph construction module, configured to construct a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing derivable paths between the three nodes; The request parsing and context extraction module is used to parse the MCP Client request, extract the tenant identifier, resource identifier, and context operation in the request, and map them to triple nodes in the graph structure; A path reasoning and permission generation module is used to use a graph search algorithm to reversely infer whether there is a legal access path from the tenant node to the context node based on the triple node, and automatically generate a permission set including operation type, resource identifier and constraint conditions based on the legal access path; The permission verification and injection module is used to perform triplet signature verification on each path in the permission set and inject the verified permission set into the response header or context structure of the MCP Server; The graph dynamic maintenance module is used to detect state changes and trigger dynamic updates of the graph structure and permission verification through the message queue.

2. The system according to claim 1, wherein The graph construction module is further configured to: Tenant nodes, resource nodes, and context nodes are stored as entities in the graph database, and attribute information is added to each directed edge, including validity period, operation type, and signature information. By subscribing to change events in the configuration center or CMDB database, the graph structure is initialized and continuously maintained, ensuring real-time synchronization of tenants, resources, and contextual relationships.

3. The system according to claim 2, wherein: The request parsing and context extraction module is also used to: Standardize the context field in the request and map it to predefined context operation nodes in the graph structure; If the request does not include resource_id, then based on the tenant identifier and the context operation node, a possible set of resource nodes is derived through the association relationship in the graph structure.

4. The system according to claim 3, wherein: The path reasoning and authority generation module is also used to: Use the depth-first search algorithm to traverse the graph structure, verify whether there is a legal path from the tenant node to the context node, and record the resource nodes involved in the path; If there are multiple legal paths, the minimum scope merging algorithm is used to deduplicate and merge the permission sets to ensure the minimization and security of permission expression.

5. The system according to claim 4, wherein: The system is further used to bind the generated permissions to the request or use them in the authentication process; The generated permissions can be injected in the following ways: Embed the authorization result as a token in the response header and return it to the client; Attach the permissions to the MCP context structure and pass them into the subsequent processing flow.

6. The system according to claim 5, wherein: The system is also used to perform verification based on a preset permission verification function. If the verification fails, the system returns HTTP 403 Access Denied and records an audit log. At the same time, the MCP Client obtains permission failure information.

7. The system according to claim 6, wherein: The dynamic graph maintenance module is also used to: When the graph dynamic maintenance module detects a change in tenant or resource status, it obtains the change event through the message queue monitoring mechanism and triggers a dynamic update of the graph structure, including adding, deleting or modifying tenant nodes, resource nodes or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

8. A method for generating dynamic permissions for a private cloud MCP Server, characterized in that: include: S1, constructing a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing derivable paths between the three nodes; S2, parses the MCP Client request, extracts the tenant identifier, resource identifier, and context operation in the request, and maps them to triple nodes in the graph structure; S3, based on the triple node, using a graph search algorithm to infer whether there is a legal access path from the tenant node to the context node, and automatically generating a permission set including the operation type, resource identifier, and constraint conditions according to the legal access path; S4: Perform triplet signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server; S5, detects state changes and triggers dynamic updates of the graph structure and permission verification through the message queue.

9. The method according to claim 8, wherein Said S1 comprises: S11, store tenant nodes, resource nodes, and context nodes as entities in the graph database, and add attribute information to each directed edge, including validity period, operation type, and signature information; S12, by subscribing to change events in the configuration center or CMDB database, realizes the initialization and continuous maintenance of the graph structure, ensuring the real-time synchronization of tenants, resources and context relationships.

10. The method according to claim 8, wherein Said S2 comprises: S21, normalize the context field in the request and map it to a predefined context operation node in the graph structure; S22: If the request does not include resource_id, a possible resource node set is derived based on the tenant identifier and the context operation node through the association relationship in the graph structure.

11. The method according to claim 8, wherein The S3 includes: S31, uses the depth-first search algorithm to traverse the graph structure, verifies whether there is a legal path from the tenant node to the context node, and records the resource nodes involved in the path; S32: If there are multiple legal paths, the minimum scope merging algorithm is used to deduplicate and merge the permission sets to ensure the minimization and security of permission expression.

12. The method according to claim 8, wherein Bind the generated permissions to the request or use them in the authentication process; The generated permissions can be injected in the following ways: Embed the authorization result as a token in the response header and return it to the client; Attach the permissions to the MCP context structure and pass them into the subsequent processing flow.

13. The method according to claim 12, wherein: The method further comprises: Verification is performed based on the preset permission verification function. If the verification fails, the system returns HTTP 403 Access Denied and records it in the audit log. At the same time, the MCP Client obtains permission failure information.

14. The method according to claim 8, wherein Detect state changes and trigger dynamic updates of graph structures and permission verification through message queues, including: When a change in tenant or resource status is detected, the change event is obtained through the message queue monitoring mechanism, and the dynamic update of the graph structure is triggered, including adding, deleting or modifying tenant nodes, resource nodes or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

15. A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 8 to 14 is implemented.

Images