MCP service boundary isolation and signature protection method and MCP service platform

Abstract

This application discloses a method for MCP service boundary isolation and signature protection, as well as an MCP service platform. The method is applied to an MCP service platform comprising a service layer, a runtime layer, a skill package layer, and a gateway layer. The service layer generates a registration record with a digital signature for the target object and distributes the verification key to the runtime layer. The skill package layer stores skill packages containing only object identifiers and no credential information. The runtime layer parses the object identifier from the skill package and retrieves the registration record from the service layer. It then uses the verification key to verify the digital signature to ensure the integrity and authenticity of the object description information. After successful verification, it obtains a credential reference and forwards it to the gateway layer. The gateway layer retrieves the plaintext credential based on the credential reference, executes the target call, and renders the plaintext credential unusable after execution. This application achieves zero exposure of credentials across the entire link and tamper-proof method calls, significantly improving the security protection capabilities of MCP services in multi-tenant environments.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence security technology, and more specifically, to an MCP service boundary isolation and signature protection method and an MCP service platform. Background Technology

[0002] Currently, security protection solutions for Model Context Protocol (MCP) services have many shortcomings in AI intelligent agent platforms, especially in SaaS multi-tenant scenarios such as digital parking lot operations.

[0003] In existing solutions, authentication credentials for MCP services are often exposed in plaintext on the client or distributed across multiple components. Once stolen, attackers can impersonate legitimate users to perform high-risk operations. Furthermore, existing technologies lack effective integrity checks and boundary isolation. The absence of signature verification mechanisms makes method descriptors vulnerable to tampering, and the lack of isolation between the service layer and runtime layer means that a single point of attack can lead to the collapse of the entire security defense. In addition, lax key management results in weak supply chain and operational security. The inclusion of plaintext keys in skill packages allows them to spread with the packages, expanding the supply chain attack surface. The lack of a centralized credential vault makes credential revocation and rotation difficult, leading to delayed security responses.

[0004] In summary, existing technologies have failed to effectively address the security protection issues throughout the entire lifecycle of MCP services, and a security architecture capable of achieving service boundary isolation and signature protection is urgently needed. Summary of the Invention

[0005] The main purpose of this application is to provide a method for MCP service boundary isolation and signature protection, as well as an MCP service platform, to solve the problem that existing technologies have failed to effectively address the security protection issues throughout the entire lifecycle of MCP services. This achieves the technical effect of effectively preventing security threats such as MCP credential leakage, method forgery, and skill package tampering, and ensuring the data asset security and business continuity of parking lot operators.

[0006] To achieve the above objectives, the first aspect of this application proposes an MCP service boundary isolation and signature protection method, applied to an MCP service platform. The MCP service platform includes a service layer, a runtime layer, a skill package layer, and a gateway layer. The skill package layer stores skill packages, which contain object identifiers but do not contain any credential information for establishing MCP connections. The service layer generates a registration record for the target object, which contains object description information and a digital signature, and distributes the verification key corresponding to the digital signature to the runtime layer. When the runtime layer receives a call request, it parses the object identifier from the skill package, obtains the corresponding registration record from the service layer based on the object identifier, and verifies the digital signature in the registration record using the verification key to confirm the integrity and authenticity of the object description information. If the verification is successful, the runtime layer obtains a credential reference corresponding to the object identifier and sends an execution request carrying the credential reference to the gateway layer. The gateway layer receives the execution request, obtains the plaintext credential based on the credential reference, executes the target call using the plaintext credential, and makes the plaintext credential unusable after execution.

[0007] In one optional embodiment, the service layer generates a registration record for the target object, including: constructing object description information for the target object, the object description information including a unique object identifier, object name, parameter structure, and the domain name portion of the target service address; digitally signing the serialization result of the object description information using a private key to generate a digital signature, determining the signature algorithm identifier, and hashing the verification key to obtain a key fingerprint; obtaining a registration timestamp and calculating an expiration timestamp based on the registration timestamp and a preset validity period; receiving and recording the workspace binding list and data reach level requirements; and writing the digital signature, key fingerprint, signature algorithm identifier, registration timestamp, expiration timestamp, workspace binding list, and data reach level requirements into the registration record.

[0008] In an optional embodiment, after verifying the digital signature, the runtime layer further includes: checking whether the registration record is registered and not expired; checking whether the workspace identifier is in the workspace binding list based on the workspace identifier associated with the call request; obtaining the data reach level of the current workspace based on the workspace identifier and checking whether the data reach level meets the data reach level requirements; checking whether the input parameter structure of the call request is consistent with the definition of the parameter structure; and checking whether the verification request frequency of the same workspace within a preset time exceeds a preset threshold.

[0009] In an optional embodiment, after parsing the object identifier from the skill pack, the method further includes: checking whether the object version specified in the call request meets the version constraints in the skill pack; if not, refusing to load the corresponding object and returning an error code for version constraint violation.

[0010] In an optional embodiment, when the runtime layer obtains a credential reference corresponding to the object identifier, the method further includes: the runtime layer initiating a credential reference query request to the credential vault, wherein the credential reference is an encrypted pointer to the credential vault, the credential reference does not contain plaintext credentials, the credential vault stores an access control list corresponding to the credential reference, and the access control list records the gateway instance identifiers that are allowed to use the credential reference; the credential vault checks whether the current gateway instance has permission to access the credential reference according to the access control list, and if it has permission, it returns the credential reference, otherwise it returns a denial error code.

[0011] In one optional embodiment, before executing the target call, the gateway layer further includes: querying the corresponding authorization snapshot based on the authorization snapshot identifier associated with the current session; verifying the authorization snapshot and confirming whether the current call request is within the authorization boundary; verifying whether the current time is within the validity period of the authorization snapshot; and generating a security audit event if the authorization snapshot verification fails. The authorization boundary includes user identity, role, workspace permissions, authorized skill packs, and data reach level.

[0012] In an optional embodiment, the service layer generates a registration record for the target object, further comprising: in response to receiving a method registration request, determining whether the domain name of the target service address in the method registration request belongs to a preset service whitelist; if not, rejecting the execution of the method registration request; determining whether the parameter structure in the method registration request contains a preset sensitive field type; if it contains such a field and no field-level encryption strategy is configured, rejecting the execution of the method registration request; determining whether the workspace binding list in the method registration request is empty; if empty, rejecting the execution of the method registration request.

[0013] In an optional embodiment, the system further includes: the service layer performing state management on the registration record, with states including pending review, registered, about to expire, rotated, and obsolete; when the digital signature of the registration record is less than or equal to a preset expiration time, a key rotation reminder operation is automatically triggered; when the registration record is explicitly removed, the state of the registration record is changed to obsolete, and thereafter, in response to any verification request for the registration record, an error code indicating that the method is obsolete is returned.

[0014] In an optional embodiment, before executing the target call using plaintext credentials, the method further includes: constructing a complete MCP call request using plaintext credentials, the MCP call request including authentication information and the target service address; clearing the plaintext credentials from the memory of the gateway layer and setting the credential clearing confirmation flag to true; if the credential clearing confirmation flag is false, triggering an emergency security process, the emergency security process including terminating the current gateway process and starting a backup gateway instance.

[0015] A second aspect of this application proposes an MCP service platform, comprising: a service layer for generating registration records for target objects, the registration records containing object description information and digital signatures, and distributing the verification key corresponding to the digital signatures to the runtime layer; a skill package layer for storing skill packages, the skill packages containing object identifiers but not containing any credential information for establishing MCP connections; a runtime layer for parsing the object identifier from the skill package upon receiving a call request, obtaining the corresponding registration record from the service layer based on the object identifier, verifying the digital signature in the registration record using the verification key to confirm the integrity and authenticity of the object description information; if the verification is successful, obtaining a credential reference corresponding to the object identifier, and sending an execution request carrying the credential reference to the gateway layer; and a gateway layer for receiving the execution request, obtaining plaintext credentials based on the credential reference, executing the target call using the plaintext credentials, and making the plaintext credentials unusable after execution.

[0016] This application constructs a four-layer isolation architecture consisting of a service layer, a runtime layer, a skill package layer, and a gateway layer, combined with digital signature verification and a credential vault mechanism, to achieve end-to-end security protection for the MCP service. Specifically, the skill package layer stores only object identifiers and does not contain any credential information, fundamentally cutting off the risk path of credential leakage through clients or skill packages. The service layer generates a digitally signed registration record for each object. Before invocation, the runtime layer verifies the signature using a verification key, ensuring the integrity and authenticity of the object description information and effectively preventing method tampering or redirection. After successful call verification, the runtime layer only obtains an encrypted credential reference, not the plaintext credential. The gateway layer temporarily decrypts and executes the call within its hardware security module, immediately clearing the plaintext credential from memory after execution. This architecture minimizes the risk of MCP credential leakage. Even if the runtime layer is compromised, attackers cannot forge legitimate method calls because they cannot obtain the signature private key. It also completely blocks supply chain attack paths caused by skill package tampering, achieving workspace-level fine-grained authorization and data access level linkage, significantly improving the service boundary isolation strength and overall security in a multi-tenant environment. Attached Figure Description

[0017] Figure 1 A schematic diagram of the structure of the MCP service platform provided in this application; Figure 2 A flowchart illustrating an embodiment of the MCP service boundary isolation and signature protection method provided in this application; Figure 3 A flowchart illustrating how a service layer generates registration records for a target object, as provided in one embodiment of this application; Figure 4 A flowchart illustrating an MCP service boundary isolation and signature protection method provided in another embodiment of this application; Figure 5 A flowchart of an MCP service boundary isolation and signature protection method provided in another embodiment of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0019] Figure 1 A schematic diagram of the structure of the MCP service platform provided in this application. Figure 1 As shown, an MCP service boundary isolation and signature protection method is applied to an MCP service platform 1. The MCP service platform 1 includes a service layer 101, a runtime layer 102, a skill package layer 103, and a gateway layer 104. The skill package layer stores skill packages, which contain object identifiers but do not contain any credential information used to establish MCP connections.

[0020] In this process, service layer 101 generates a registration record for the target object, which includes object description information and a digital signature. The verification key corresponding to the digital signature is then distributed to runtime layer 102. Upon receiving a call request, runtime layer 102 parses the object identifier from the skill package, retrieves the corresponding registration record from service layer 101 based on the object identifier, and verifies the digital signature in the registration record using the verification key to confirm the integrity and authenticity of the object description information. If the verification passes, runtime layer 102 obtains a credential reference corresponding to the object identifier and sends an execution request carrying the credential reference to gateway layer 104. Gateway layer 104 receives the execution request, obtains the plaintext credential based on the credential reference, executes the target call using the plaintext credential, and renders the plaintext credential unusable after execution.

[0021] For example, the target object is the callable service unit exposed to the outside in the MCP service platform 1, including MCP methods (single functional operation), MCP tools (method collection), MCP services (independent service instances) or MCP skill packs (predefined functional modules).

[0022] For example, object description information is a set of metadata used to uniquely identify and describe the target object, including the object's unique identifier, object name, parameter structure, target service address domain name portion, version number, return type, workspace binding list, and data access level requirements. The data access level is a security classification indicator describing the scope of data currently accessible in the workspace, divided into three levels from low to high: General Knowledge Only, Cloud Data Accessible, and Local Device Accessible. Each level corresponds to different network reachability, device online status, and data access permissions. The determination of the data access level adopts a multi-dimensional comprehensive scoring mechanism, calculating a comprehensive score between 0 and 1 by weighting five dimensions: desktop online status (weight 30%), cloud service reachability (weight 20%), LAN connectivity (weight 20%), device health check (weight 20%), and security snapshot validity (weight 10%). Based on the scoring results, the system determines the level according to the following logic: when the comprehensive score is ≥0.9 and the desktop online status score is 1, the LAN connectivity score is 1, and the device health check score is ≥0.5, it is determined to be at the local device reachability level; when the comprehensive score is ≥0.6 and the cloud service reachability score is 1, it is determined to be at the cloud data reachability level; when the comprehensive score is <0.6 or the cloud service reachability score is 0, it is determined to be at the general knowledge only level. When the level is downgraded, all methods requiring local device reachability are automatically removed from the available method set within 5 seconds. The agent model no longer receives capability descriptions for these methods, but currently executing local device operations are allowed to complete, and new local device operation requests are no longer accepted. When the level is upgraded, the new available methods take effect at the start of the next session, and the current session is unaffected. In practical applications, the weight values ​​of each dimension can be adjusted according to the needs of business scenarios and security policies. For example, in scenarios with higher security requirements, the weight of security snapshot effectiveness can be increased, or in scenarios with poor device stability, the weight of device health checks can be increased. After the weights are adjusted, the corresponding level determination thresholds also need to be adapted accordingly.

[0023] It should be understood that making plaintext credentials unusable after execution means clearing the plaintext credentials from memory without leaving any trace.

[0024] This article will provide a detailed explanation using the example of each method registered in the MCP service as the target object, and the method descriptor as the object description information.

[0025] This method runs on an MCP service platform 1, which consists of a service layer 101 (responsible for registration and signing), a skill package layer 103 (responsible for managing and storing skill packages), a runtime layer 102 (responsible for verification and scheduling), and a gateway layer 104 (responsible for executing calls). This method adopts an overall architecture of "three-layer isolation + credential vault + four-layer link + workspace binding," and includes the following four core steps: Step 1: MCP service layer 101 signature generation.

[0026] In the MCP service layer 101, a unique signature key pair is generated for each registered method (target object). The private key is stored in the hardware security module or key management service, and the public key is distributed to the runtime layer 102. Each time a method is registered or updated, the service layer 101 uses the method descriptor (including method name, parameter structure, version number, and workspace binding identifier) ​​and the private key to generate a digital signature, and appends the signature to the method descriptor metadata.

[0027] The key storage data structure can contain the following fields: key identifier (string, uniquely identifying the key pair); private key ciphertext (string, encrypted using AES-256-GCM, the key is managed by the hardware security module); public key plaintext (string, PEM format, can be directly distributed); key status (enumeration, values ​​"active", "rotating", "deprecated"); creation timestamp (integer); last rotation timestamp (integer).

[0028] It should be understood that the hardware security module adopts a clustered deployment architecture, deployed in an independent security subnet of the cloud platform, and achieves triple isolation from the business service layer, runtime layer, and gateway layer at both the physical and logical network levels.

[0029] Step 2: Runtime layer 102 signature verification.

[0030] Before the agent executes the MCP method call, the runtime layer 102 parses the method identifier and version from the skill package and requests the corresponding method descriptor and signature from the service layer 101. The runtime layer 102 uses a pre-set public key to verify the signature of the method descriptor. Execution can continue only after successful verification; otherwise, an execution rejection process is triggered. The verification algorithm is consistent with the signature algorithm and can be either RSA-SHA256 or ECDSA-SHA256.

[0031] Specifically, the verification request data structure of runtime layer 102 may include the following fields: Request Unique Identifier (string, in UUID v4 format, used for idempotency verification); Workspace Identifier (string, identifying the workspace to which the current agent session belongs); Method Identifier (string, a method reference parsed from the skill pack); Method Version (string, semantic version number); Input Parameter Summary (string, hashing the input parameters using SHA256, used for integrity verification); Agent Event Identifier (string, an audit event associated with the current agent session).

[0032] The verification result data structure of runtime layer 102 includes the following fields: verification result (enumeration, values ​​"pass", "reject", "requires manual review"); rejection reason code (string, only has a value when the result is "reject"); matching method descriptor hash (string, returned when verification passes, used for subsequent steps); public key fingerprint (string, used to trace the public key used in this verification); verification timestamp (integer, Unix timestamp, millisecond level).

[0033] Step 3: Skill Pack 103 Zero Key Visibility and Credential Vault Reference.

[0034] During the definition phase, the skill package only references the method identifier and version number, and does not contain any sensitive information such as keys, credential URLs, or connection configurations. After the runtime layer 102 verifies the signature, it retrieves the corresponding credential reference from the credential vault based on the method identifier. The credential reference is encrypted pointer information and does not contain plaintext credentials.

[0035] Step 4: Temporary password retrieval execution at the gateway layer 104.

[0036] Runtime layer 102 forwards the signed request to gateway layer 104. Gateway layer 104 temporarily retrieves the plaintext credential from the credential vault based on the credential reference, constructs a complete MCP call request, and sends it to the target open platform for execution. After execution, gateway layer 104 immediately clears the plaintext credential from memory without leaving any trace.

[0037] The execution request data structure of gateway layer 104 includes the following fields: gateway request identifier (string, UUID format); original request forwarded by runtime layer 102 (nested object, including workspace identifier, method identifier, input parameters, etc.); credential reference (nested object, from the output of step three); authorization snapshot identifier (string, associated with the security snapshot of the current agent session); model policy snapshot identifier (string, associated with the model policy snapshot of the current agent session).

[0038] The execution result data structure of gateway layer 104 includes the following fields: execution status (enumeration, values ​​"success", "failure", "timeout", "rejection"); response data (object, only has a value when the status is "success", and has been de-identified); error message (string, only has a value when the status is "failure" or "rejection"); execution time (integer, milliseconds); credential clearing confirmation (boolean value, must be "true", indicating that the gateway has completed memory clearing).

[0039] It should be understood that a workspace is a basic unit of multi-tenant isolation within the intelligent agent platform, representing the digital operating environment of an independent parking lot operating entity within the platform. Each workspace has its own independent set of configurations, permissions, data views, and method authorizations. Workspaces are logically completely isolated from each other, and users, data, and operations in one workspace cannot directly affect other workspaces.

[0040] The correspondence between workspaces and physical parking lots can be one-to-many or one-to-one: a chain parking lot group can create independent workspaces for each of its parking lots to achieve refined decentralized management; an independently operated parking lot can also create only one workspace to simplify management processes. The creation of workspaces is performed by the platform administrator or authorized regional administrator. When creating a workspace, the workspace name, its region, the person in charge information, and the initial data access level must be specified.

[0041] The workspace identifier is a globally unique string identifier, formatted as a 16-character string with the prefix "ws_" followed by a random alphanumeric combination. The workspace identifier is generated upon creation and cannot be modified; it serves as the namespace prefix for all associated resources.

[0042] The workspace name is a user-friendly name that supports Chinese, English, and numbers, and is limited to 2 to 50 characters in length. The workspace name can be modified in the management console; modifications will not affect the workspace identifier or associated resources.

[0043] The workspace data access level refers to the current workspace's data access capability level, which is automatically determined by the system based on real-time network and device status. It can also be manually locked to a specific level by the administrator in the management console. Once manually locked, the automatic access logic is suspended until the administrator unlocks it.

[0044] Authorized Skill Packs in the Workspace: This is a list of skill packs subscribed to by the workspace. Each skill pack contains a set of method references. Subscribing to a skill pack requires administrator confirmation. Once subscribed, the methods in the skill pack are automatically added to the workspace's capability list. Unsubscribing to a skill pack takes effect immediately; upon unsubscribing, the methods in the skill pack are removed from the capability list.

[0045] Workspace audit configuration includes audit log retention period (default is 90 days, configurable from 30 days to 365 days), audit event alarm threshold (e.g., an alarm is triggered if more than 10 high-risk operations per hour are performed), and audit report generation cycle (supports daily, weekly, and monthly reports).

[0046] The workspace isolation mechanism covers four levels: data isolation, access control isolation, network isolation, and service isolation.

[0047] Figure 2A flowchart illustrating an embodiment of the MCP service boundary isolation and signature protection method provided in this application. Figure 2 As shown, this method uses the MCP method as the target object to illustrate the complete process from method registration to method execution completion. This method runs on the MCP service platform, which includes a service layer, runtime layer, skill package layer, and gateway layer. These layers are independent yet collaborative, forming a defense-in-depth system. The following provides a detailed explanation of each node in the flowchart and their connections.

[0048] Starting node: "MCP Method Registration". This node represents the registration operation of the target object at the service layer and is the starting point of the entire process. The MCP service layer receives the method registration request, constructs object description information for the target object, and generates a registration record. After this node is completed, the process enters the "MCP Service Signature" processing node.

[0049] Processing Node 1: "MCP Service Signature". The service layer uses its private key to digitally sign the serialized result of the object description information, generating a digital signature and signature metadata, and distributes the corresponding verification key (public key) to the runtime layer. After this node is completed, the process proceeds to the "Runtime Verification Signature" processing node.

[0050] Processing Node Two: "Runtime Signature Verification". The runtime layer parses the object identifier from the skill package, retrieves the corresponding registration record from the service layer, and verifies the digital signature using a pre-set verification key. Simultaneously, the runtime layer performs several auxiliary checks, including: checking the validity of the registration record's status, checking if the workspace to which the call request belongs is in the binding list, checking if the data reach level of the current workspace meets the requirements, and checking if the input parameter structure is consistent with the registration record. After this node is completed, the process proceeds to the "Verification Passed?" judgment node.

[0051] Decision Node: This node is the core decision node of this process. The decision condition is: successful signature verification and all auxiliary verifications pass. If the decision result is "No" (i.e., verification failed), the process redirects to the "Refuse Execution" terminal node on the left; if the decision result is "Yes" (i.e., verification passed), the process continues to execute downwards, entering the "Skill Pack Zero Key Visible" processing node. This branch structure reflects the "default rejection" security design principle of this method: any problem in the verification process leads to rejection rather than continued execution.

[0052] Terminal Node 1: "Execution Rejected". This node indicates the handling result after verification failure. The runtime layer refuses to execute the current MCP method call, returns an error message to the caller, and generates a security audit event. From this node, the process directly proceeds to the "End" terminal node at the bottom.

[0053] Processing Node 3: "Skill Package Zero-Key Visibility". During the definition phase, the skill package only references the object identifier and version number, and does not contain any sensitive information such as keys, credential URLs, or connection configurations. After this node is completed, the process proceeds to the "Credential Vault Reference" processing node.

[0054] Processing Node 4: "Credential Vault Reference". After the signature verification is successful, the runtime layer retrieves the corresponding credential reference from the credential vault based on the object identifier. The credential reference is encrypted pointer information and does not contain plaintext credentials. After this node is completed, the process proceeds to the "Gateway Temporary Decryption Execution" processing node.

[0055] Processing Node 5: "Gateway Temporary Credential Retrieval and Execution". The gateway layer receives the execution request forwarded by the runtime layer, temporarily retrieves the plaintext credential from the credential vault based on the credential reference, constructs a complete MCP call request, and sends it to the target open platform for execution. After execution, the gateway layer immediately clears the plaintext credential from memory, leaving no trace. After this node is completed, the process enters the "End" terminal node at the bottom.

[0056] Terminal Node Two: "End". This node represents the end point of the entire process. Whether the process completes normally from the "Gateway Temporary Password Retrieval Execution" node or terminates abnormally from the "Refuse Execution" node, it ultimately converges at this node.

[0057] This application introduces a digital signature mechanism during the MCP service registration phase to ensure the integrity and authenticity of object description information. At the runtime layer, signature verification and isolated parsing of zero-key skill packages are implemented. Then, the gateway layer completes the on-demand acquisition and execution of temporary credentials, resulting in an expired temporary credential, forming a closed-loop "registration-verification-reference-cryptography-execution" process. This process not only achieves the security goals of invisible keys at the skill package layer, zero credential exposure at the runtime layer, and temporary cryptography execution at the gateway layer, but also blocks unauthorized calls through signature verification, effectively preventing credential abuse and man-in-the-middle attacks, significantly improving the boundary isolation capability and overall security level of the MCP service in a multi-tenant environment.

[0058] Figure 3 A flowchart illustrating how the service layer generates registration records for a target object, as provided in one embodiment of this application, is shown below. Figure 3 As shown, the service layer generates registration records for the target object, including the following steps: Step S10: Construct object description information for the target object.

[0059] For example, the object description information includes the object's unique identifier, object name, parameter structure, and the domain name portion of the target service address.

[0060] The unique identifier for an object is formatted as "Workspace Identifier_Service Name_Method Name_Version", with the version using a semantic version number (major version.minor version.revision). The default version for initial registration is "1.0.0". The object name is a user-friendly name. The parameter structure uses JSON Schema format, including parameter name, parameter type, whether it is required, and value range constraints. Only the domain name portion of the target service address is recorded, not the complete URL path, to prevent URL leakage.

[0061] Step S11: Use the private key to digitally sign the serialization result of the object description information, generate a digital signature, determine the signature algorithm identifier, and perform hash calculation on the verification key to obtain the key fingerprint.

[0062] For example, the public key serves as the verification key. The private key is held by the service layer, and the public key is distributed to the runtime layer for signature verification. The runtime layer can only verify, not forge, signatures.

[0063] Step S12: Obtain the registration timestamp and calculate the expiration timestamp based on the registration timestamp and the preset validity period.

[0064] Step S13: Receive and record the workspace binding list and data reach level requirements.

[0065] Step S14: Write the digital signature, key fingerprint, signature algorithm identifier, registration timestamp, expiration timestamp, workspace binding list, and data reach level requirements into the registration record.

[0066] In one specific embodiment, generating a registration record includes the following specific steps: The first step is to receive the method registration request. The request parameters include the method name, parameter structure definition, target service address, workspace binding list, and data reach level requirements.

[0067] The second step is to generate a unique identifier for the method.

[0068] The third step is to construct the method descriptor object.

[0069] The fourth step is to use the JSON serialization result of the method descriptor object (sorted lexicographically by key name and whitespace removed) as the original signature, and execute the digital signature algorithm using the currently active private key (preferably ECDSA-SHA256, but downgraded to RSA-SHA256 if the hardware security module does not support it).

[0070] The fifth step is to write metadata such as the signature result, public key fingerprint, signature algorithm identifier, registration timestamp, expiration timestamp, workspace binding list, and data reach level requirements into the method registration record table.

[0071] The sixth step is to synchronize the public key plaintext and the corresponding public key fingerprint to the public key cache service at the runtime layer to ensure that the runtime layer can obtain the latest public key in a timely manner.

[0072] Figure 4 A flowchart of an MCP service boundary isolation and signature protection method provided in another embodiment of this application is shown below. Figure 4 As shown, after verifying the digital signature, the runtime layer also includes: Step S20: Check whether the registration record status is registered and not expired.

[0073] Specifically, check the status recorded by the method. If the status is "discarded" or "expired", return a rejection result.

[0074] Step S21: Check whether the workspace identifier is in the workspace binding list based on the workspace identifier associated with the call request.

[0075] The workspace identifier is the identifier of the workspace associated with the agent session that initiated the call request. If the workspace identifier is not in the workspace binding list, a rejection result is returned, and an audit event is generated.

[0076] Step S22: Obtain the data reach level of the current workspace based on the workspace identifier, and check whether the data reach level meets the data reach level requirements.

[0077] For example, if a method requires "local device accessibility" but the current workspace only reaches "cloud data accessibility", then methods involving local device operations will be refused execution.

[0078] Step S23: Check whether the input parameter structure of the call request is consistent with the definition of the parameter structure.

[0079] Calculate the SHA256 hash of the input parameter and compare it with the parameter structure stored in the method registration record (only compare structural consistency, not the specific values). If the structure does not match, return a rejection result.

[0080] Step S24: Check whether the frequency of verification requests in the same workspace within a preset time exceeds a preset threshold.

[0081] Specifically, the preset time is set to 1 minute, and the preset threshold is set to 100 times. If the same workspace initiates more than 100 verification requests within 1 minute, rate limiting is triggered, a rejection result is returned, and a security event is generated.

[0082] In one embodiment of this application, after parsing the object identifier from the skill pack, the method further includes: checking whether the object version specified in the call request meets the version constraints in the skill pack; if not, refusing to load the corresponding object and returning an error code for version constraint violation.

[0083] Specifically, if the specified version of the call request does not meet the version constraints defined in the skill package (for example, the latest version of the method registration record has been upgraded to "2.1.0", exceeding the skill package's allowed limit of "<2.0.0"), the runtime layer refuses to load the corresponding object, terminates the subsequent signature verification and execution process, and returns a version constraint violation error code to the requester. This judgment condition prevents call exceptions caused by interface incompatibility, parameter structure changes, or function obsolescence due to method version upgrades, while ensuring the application security and stability of the skill package in different working environments.

[0084] In one embodiment of this application, when the runtime layer obtains a credential reference corresponding to an object identifier, the method further includes: the runtime layer initiating a credential reference query request to a credential vault, wherein the credential reference is an encrypted pointer to the credential vault, the credential reference does not contain plaintext credentials, the credential vault stores an access control list corresponding to the credential reference, and the access control list records gateway instance identifiers that are allowed to use the credential reference; the credential vault checks whether the current gateway instance has permission to access the credential reference according to the access control list, and if it has permission, it returns the credential reference, otherwise it returns a denial error code.

[0085] In one embodiment of this application, before executing the target call, the gateway layer further includes: querying the corresponding authorization snapshot based on the authorization snapshot identifier associated with the current session; verifying the authorization snapshot and confirming whether the current call request is within the authorization boundary; verifying whether the current time is within the validity period of the authorization snapshot; and generating a security audit event if the authorization snapshot verification fails. The authorization boundary includes user identity, role, workspace permissions, authorized skill packs, and data reach level.

[0086] Specifically, after receiving the execution request forwarded by the runtime layer, the gateway layer first extracts the authorization snapshot identifier (e.g., "snap_20250618_143052_abc123") carried in the request. Based on this identifier, the gateway layer queries the snapshot store (an immutable object storage architecture) for the corresponding authorization snapshot. Upon successful query, the gateway layer performs multi-dimensional authorization snapshot verification. This verification is performed before the gateway layer executes the MCP method call, and its purpose is to confirm that the current request remains within the authorization boundaries defined by the authorization snapshot. The verification process includes three dimensions: identity verification, permission verification, and time verification.

[0087] Identity verification: The gateway layer extracts the user identifier and session identifier from the request and compares them with the user identity digest in the authorization snapshot. The comparison includes whether the user identifier, user role, and authentication method are consistent. If any item is inconsistent, the verification fails and a security alert is triggered.

[0088] Permission Dimension Verification: The gateway layer extracts the method identifier and workspace identifier from the request and compares them with the workspace permission list and capability list in the authorization snapshot. The comparison includes whether the current method is in the capability list, whether the current workspace is in the permission list, and whether the data access level requirement of the current method is covered by the data access level requirement of the current workspace. If any item fails to meet the requirements, a verification failure is returned, and an audit event is generated.

[0089] Time-based verification: The gateway layer checks whether the current time is within the validity period of the authorized snapshot. If the snapshot has expired (more than 8 hours or the session has been terminated), the verification fails, and the runtime layer is required to regenerate the authorized snapshot. This mechanism prevents attackers from replaying expired authorized snapshots to perform unauthorized operations.

[0090] Snapshot integrity verification: After reading the snapshot, the gateway layer recalculates the SHA256 hash of the snapshot content and compares it with the overall snapshot hash recorded in the snapshot. If the hashes do not match, it indicates that the snapshot content has been tampered with during storage or transmission, returns a verification failure, and triggers the highest priority security alarm.

[0091] This application uses an authorized snapshot mechanism to atomically freeze the authorization boundaries of user identity, permissions, and data access levels when a session starts, and performs multi-dimensional verification before executing the call at the gateway layer. This ensures that every MCP call is executed within a fixed authorization range, effectively preventing unauthorized operations caused by permission changes or snapshot tampering during the session, and reducing the cross-workspace unauthorized execution rate to zero.

[0092] In one embodiment of this application, in response to receiving a method registration request, it is determined whether the domain name of the target service address in the method registration request belongs to a preset service whitelist; if it does not belong, the method registration request is rejected; it is determined whether the parameter structure in the method registration request contains a preset sensitive field type; if it contains such a field and no field-level encryption policy is configured, the method registration request is rejected; it is determined whether the workspace binding list in the method registration request is empty; if it is empty, the method registration request is rejected.

[0093] Specifically, the following judgments need to be performed during the signature generation process: Judgment criterion 1: Whether the domain name of the target service address belongs to the approved service whitelist. If not, registration is rejected and the audit event is recorded.

[0094] The second criterion is whether the parameter structure contains sensitive fields (such as passwords, keys, credit card numbers, ID card numbers, etc.). If so, additional field-level encryption configuration is required; otherwise, registration is rejected.

[0095] Condition 3: Is the workspace binding list empty? If so, registration is rejected, requiring at least one workspace to be bound to prevent the method from being abused globally.

[0096] This application prevents the registration of illegal domains, unencrypted sensitive data, and unauthorized global abuse of methods by setting up a domain whitelist, sensitive field detection, and workspace binding verification during the method registration stage. This eliminates insecure or non-compliant MCP methods at the registration stage and significantly reduces the security risks in the subsequent invocation stage.

[0097] Figure 5 A flowchart of an MCP service boundary isolation and signature protection method provided in another embodiment of this application is shown below. Figure 5 As shown, the method also includes: Step S25: The service layer performs state management on the registration records.

[0098] The status includes pending review, registered, about to expire, rotated, and abandoned.

[0099] Step S26: When the digital signature of the registration record is less than or equal to the preset expiration time, the key rotation reminder operation is automatically triggered.

[0100] The preset threshold is set to 7 days. That is, when the signature has less than 7 days left before expiration, the service layer automatically changes the registration record status to "expiring soon" and triggers a key rotation reminder to notify the administrator to complete the key rotation in time to prevent service interruption caused by signature expiration.

[0101] Step S27: When a registration record is explicitly removed, change the status of the registration record to obsolete.

[0102] Subsequently, any verification request for the registration record is responded to with an error code indicating that the method is obsolete, ensuring that the deprecated method cannot be invoked. Furthermore, once the key rotation is complete, the registration record is switched to a "rotated" state, the original signature automatically expires after its expiration time, and the new signature immediately takes effect, ensuring a smooth transition during the key rotation process.

[0103] This mechanism addresses the shortcomings of existing solutions, such as uncontrolled key expiration and the continued abuse of delisted methods. It achieves refined security control over method registration from admission, continuation to exit, ensuring that expired or obsolete methods cannot be executed beyond the authorization boundary. At the same time, it ensures business continuity and stability through early warning.

[0104] In one embodiment of this application, before performing the target call using plaintext credentials, the method further includes: A complete MCP call request is constructed using plaintext credentials. The MCP call request includes authentication information and the target service address. Plaintext credentials are cleared from the gateway layer's memory, and the credential clearing confirmation flag is set to true. If the credential clearing confirmation flag is false, an emergency security procedure is triggered, which includes terminating the current gateway process and starting a backup gateway instance.

[0105] Specifically, the gateway layer constructs a complete MCP call request using plaintext credentials, including a request header (containing authentication information), a request body (containing input parameters), and the target service address. Once constructed, the plaintext credentials are immediately cleared from the gateway layer's memory, and the credential clearing confirmation flag is set to "true." Before returning the execution result, the credential clearing confirmation flag is forcibly checked. If it is "false," an emergency security process is triggered: the gateway process is immediately terminated (to prevent the plaintext credentials remaining in memory from being read), a backup gateway instance is started, a highest-priority alarm is sent to the security administrator, and the security event is logged to the audit event store.

[0106] This application ensures that plaintext credentials are destroyed immediately after the call execution by clearing them from memory and verifying the clearing confirmation flag immediately after the request is constructed at the gateway layer, thus eliminating the risk of credential leakage caused by memory residue. If the clearing fails, an emergency circuit breaker mechanism is triggered to terminate the process and switch to a backup instance. This achieves physical-level isolation and high availability in the event of a loss of control over underlying memory security, compressing the exposure window of credentials in untrusted environments to zero.

[0107] The technical solution of this application will be described in detail below with reference to specific application scenarios. Those skilled in the art should understand that the specific embodiments described herein are only for explaining this application and are not intended to limit the scope of protection of this application.

[0108] Suppose Manager Zhang, the operations supervisor of a chain parking lot group, is responsible for the daily operations of five parking lots under the group. Manager Zhang uses the Tingxiaoai T×Ai intelligent agent platform for parking lot operation analysis and equipment management.

[0109] Manager Zhang needs to use the smart agent to query yesterday's fee summary report for the "Sunshine Plaza Parking Lot" and verify the online status of the barrier gate equipment. This operation involves two MCP methods: one is the "fee data query" method, with a risk level of R2 (analysis recommendation level) and a data access level requirement of "cloud data accessible level"; the other is the "equipment status query" method, with a risk level of R1 (low-risk reading level) and a data access level requirement of "local device accessible level".

[0110] Workspace settings: "Sunshine Plaza Parking Lot" corresponds to an independent workspace, identified as "ws_sunshine_plaza_001". The current data reach level of this workspace is "Local Device Reachable", indicating that the desktop is online, WebSocket heartbeat is normal, LAN ping is successful, and all device health checks have passed, demonstrating full capability for local device operation.

[0111] Step 1: Manager Zhang initiates a conversation. Manager Zhang enters a natural language command in the T×Ai chat interface: "Please check how much parking fee Sunshine Plaza collected yesterday, and whether the gate is working properly?" The input is transmitted to the cloud server in real time via the WebSocket protocol.

[0112] Step Two: Input Security Review. The input security review module of the intelligent agent platform performs a seven-dimensional risk score on Manager Zhang's request. After evaluation, the risk level of the request is determined to be R2 (involving a paid data query), with no risk of keyword injection and no intention to abuse. The result is "Execution Allowed".

[0113] Step 3: Authorization Snapshot Freeze. Upon session startup, the system freezes the authorization snapshot, recording Manager Zhang's user identity (Operations Supervisor), role permissions (Workspace Administrator), workspace permissions (full permissions for "ws_sunshine_plaza_001"), authorized skill packages ("Parking Lot Operation Analysis Skill Package v3.2", "Equipment Management Skill Package v2.1"), data access level ("Local Device Accessible Level"), and R3 / R4 pre-authorization status (currently no high-risk operations awaiting confirmation). The unique identifier for this authorization snapshot is "snap_20250618_143052_abc123".

[0114] Step 4: Skill Package Loading and Parsing. The agent kernel loads the skill packages that Manager Zhang has subscribed to from the skill factory. The skill packages only contain method reference information: "parking_fee_daily_report" (version constraint ">= 3.0.0, data reach level requirement "cloud data reachable") and "gate_status_query" (version constraint ">= 2.0.0, data reach level requirement "local device reachable"). The skill packages do not contain any key, URL, or credential information.

[0115] Step 5: Runtime Layer Signature Verification – Fee Data Query Method. The runtime layer initiates a signature verification request to the MCP service layer, verifying the method "parking_fee_daily_report_v3.1". The verification process is as follows: Query the method registration record to confirm its status is "registered" and not expired; check if the workspace "ws_sunshine_plaza_001" is in the binding list, and the check passes; check the data reach level – the current workspace's data reach level is "local device reachable level", while the method requires "cloud data reachable level". "Local device reachable level" overrides "cloud data reachable level", and the check passes; verify the digital signature using the preset public key, and the verification passes; compare the input parameter structure, and the comparison passes. Verification conclusion: Pass.

[0116] Step Six: Credential Vault Reference Query – Fee Data Query Method. The runtime layer queries the credential vault for the corresponding credential reference based on the method identifier. The credential vault returns an encrypted pointer containing the reference identifier "credref_fee_001", the credential type "API_KEY", and the encryption context (including the internal path of the hardware security module and AES-GCM parameters). The runtime layer appends the credential reference to the execution request.

[0117] Step Seven: Temporary Decryption and Execution at the Gateway Layer – Fee Data Query Method. The gateway layer receives the execution request and extracts the credential reference and authorized snapshot identifier “snap_20250618_143052_abc123”. Based on this identifier, the gateway layer queries the authorized snapshot to confirm that Manager Zhang has the authority to execute the “parking_fee_daily_report” method in the workspace “ws_sunshine_plaza_001”. Subsequently, the gateway layer initiates a decryption request to the hardware security module, using the encryption context corresponding to “credref_fee_001” to obtain the plaintext credentials (API key). The gateway layer uses this API key to construct an HTTPS request and sends it to the fee data interface of the TingSimple Open Platform. Upon successful request, yesterday's fee summary data is returned: total transactions 1,247, total revenue 18,950.00 yuan, refund amount 320.00 yuan, net revenue 18,630.00 yuan. The gateway layer immediately clears the API key from memory and sets the credential clearing confirmation flag to “true”. The response data is returned to the runtime layer after being anonymized.

[0118] Step 8: Runtime Layer Signature Verification – Device Status Query Method. The runtime layer verification method is “gate_status_query_v2.3”. The verification process is similar to Step 5. If the data reach level check passes (the current workspace's data reach level is “local device reachable”, and the method requirement is also “local device reachable”), the signature verification passes.

[0119] Step Nine: Temporary Decryption Execution at the Gateway Layer – Device Status Query Method. The gateway layer obtains the credential reference corresponding to "gate_status_query", decrypts it, and sends a query request to the local device gateway. The local device gateway communicates with the barrier gate controller via the LAN to obtain the real-time status of the 6 barrier gates: 5 are online and operating normally, and 1 (Entrance / Exit 3) is in an "offline" state, with its last heartbeat occurring 2 hours ago. The gateway layer clears the credential and returns the result.

[0120] Step 10: Result Encapsulation and Output. The agent kernel encapsulates the results of the two methods into a result encapsulation object, which includes: structured results (JSON format billing report and equipment status list); to-do suggestions ("Entrance / Exit Gate No. 3 has been offline for 2 hours. It is recommended to check the network connection immediately or contact the equipment maintenance personnel"); memory update suggestions (record "Entrance / Exit Gate No. 3 offline event" to the workspace memory); and a summary visible to the operator (natural language summary: "Yesterday's net income was 18,630 yuan. The offline status of Entrance / Exit Gate No. 3 needs attention").

[0121] Step 11: Output Security Review. The output security review module performs twelve types of information interception checks on the result encapsulation object. If it confirms that the object does not contain sensitive information such as system prompts, developer prompts, hidden context, or vault boundaries, the result is "Output Allowed".

[0122] Step Twelve: Audit Loop Closure. The system generates an audit event, recording the complete chain of this session, including: the authorized snapshot identifier "snap_20250618_143052_abc123", the verification and execution records of the two MCP methods, all security review judgment results, and Manager Zhang's final confirmation operation. The audit event is written to the audit event storage and cannot be deleted or modified.

[0123] The embodiments of this application, through a technical architecture of three-layer isolation + credential vault + four-layer link + workspace binding, achieve the following quantitative beneficial effects in the field of MCP service security: First, the risk of MCP credential leakage is reduced to zero. Through the "four no's" mechanism of the credential vault, credentials are not stored on the client, do not enter the model context, do not expose the service address URL, and do not expose the original key. The number of exposure points for plaintext credentials throughout the entire chain is reduced from more than five in traditional solutions (client configuration, server configuration, database, environment variables, network transmission) to one (within the hardware security module), and this exposure point is a trusted execution environment subject to strict access control. Even if the client device is completely controlled, the runtime layer service is compromised, and the skill package file is stolen, attackers cannot obtain plaintext credentials that can be used to forge MCP calls.

[0124] Second, even if the runtime is compromised, attackers cannot forge legitimate methods. Through a three-layer isolation architecture, the service layer holds the private key, the runtime layer only verifies signatures, and the skill package layer has zero key visibility. Even if the runtime layer is compromised, attackers can still tamper with the runtime code, but they cannot obtain the private key to forge new legitimate signatures, nor can they modify registered method descriptors (because the descriptor's hash and signature are permanently stored in the method registration record). At most, attackers can only relay verified requests; they cannot construct new unauthorized requests, thus strictly limiting the scope of the attack.

[0125] Third, the signature verification failure rate is 100% after the skill package is tampered with. The skill package only contains method identifiers and version references, not signatures or keys. When the skill package file is tampered with (such as changing the method identifier to point to a malicious method or injecting a fake method reference), the runtime layer signature verification process will detect the mismatch between the method identifier and the registration record, signature verification failure, or workspace binding check failure, with a verification failure rate of up to 100%, completely blocking the supply chain attack path.

[0126] Fourth, workspace-level authorization precision is improved, reducing the cross-workspace unauthorized execution rate to 0. By independently registering available MCP services in a method registry for each workspace, each workspace can only access its explicitly authorized set of methods. Methods authorized for Manager Zhang in the "Sunshine Plaza Parking Lot" workspace cannot be executed in other parking lot workspaces. Even if an attacker gains access to a particular workspace, they cannot use that access to perform operations across workspaces, extending multi-tenant isolation from the data layer to the service layer.

[0127] Fifth, the data access level linkage reduces the false injection rate of local tools to 0% when local devices are offline. When the desktop goes offline, causing the workspace data access level to downgrade from "local device accessible" to "cloud data accessible," all methods requiring "local device accessible" are automatically removed from the available method set, and the runtime layer no longer injects these methods into the agent model. When Manager Zhang queries the "gate status" while the desktop is offline, the agent will reply "The local device status cannot be queried at present. Please confirm that the desktop is online and try again," instead of attempting to execute a local tool call that is destined to fail, thus avoiding accidental operations and invalid requests.

[0128] Sixth, the integrity and evidentiary capabilities of audit traceability are significantly improved. All signature verification, credential access, and gateway execution operations generate audit events and are associated with authorized snapshot identifiers. In post-event traceability, it is possible to accurately reconstruct "who was under what authorization boundary, which key was used, which method was called, and what result was obtained," meeting compliance audit and judicial evidentiary requirements. The generation rate and association rate of audit events both reach 100%, and the audit traceability time is reduced from several hours in traditional solutions to seconds.

[0129] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0130] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0131] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for MCP service boundary isolation and signature protection, applied to an MCP service platform, the MCP service platform comprising a service layer, a runtime layer, a skill package layer, and a gateway layer, wherein the skill package layer stores skill packages, each skill package containing an object identifier and not containing any credential information used to establish an MCP connection, characterized in that... The service layer generates a registration record for the target object. The registration record includes object description information and a digital signature. The service layer then distributes the verification key corresponding to the digital signature to the runtime layer. When the runtime layer receives a call request, it parses the object identifier from the skill package, obtains the corresponding registration record from the service layer based on the object identifier, and uses the verification key to verify the digital signature in the registration record to confirm the integrity and authenticity of the object description information. If the verification passes, the runtime layer obtains the credential reference corresponding to the object identifier and sends an execution request carrying the credential reference to the gateway layer; The gateway layer receives the execution request, obtains the plaintext credential based on the credential reference, executes the target call using the plaintext credential, and makes the plaintext credential unusable after execution.

2. The method according to claim 1, characterized in that, The service layer generates registration records for the target object, including: Construct object description information for the target object, the object description information including object unique identifier, object name, parameter structure and domain name part of target service address; The serialization result of the object description information is digitally signed using the private key to generate the digital signature, the signature algorithm identifier is determined, and the verification key is hashed to obtain the key fingerprint; Obtain the registration timestamp and calculate the expiration timestamp based on the registration timestamp and the preset validity period; Receive and record the workspace binding list and data reach level requirements; The digital signature, key fingerprint, signature algorithm identifier, registration timestamp, expiration timestamp, workspace binding list, and data reach level requirements are written into the registration record.

3. The method according to claim 2, characterized in that, After verifying the digital signature, the runtime layer further includes: Check whether the registration record is in the state of registered and not expired; Based on the workspace identifier associated with the call request, check whether the workspace identifier is in the workspace binding list; Obtain the data reach level of the current workspace based on the workspace identifier, and check whether the data reach level meets the data reach level requirements; Check whether the input parameter structure of the call request is consistent with the definition of the parameter structure; Check whether the frequency of verification requests in the same workspace exceeds a preset threshold within a preset time period.

4. The method according to claim 2, characterized in that, After parsing the object identifier from the skill pack, the method further includes: Check whether the object version specified in the call request meets the version constraints in the skill pack; If the conditions are not met, the corresponding object will be refused to be loaded, and an error code for version constraint violation will be returned.

5. The method according to claim 2, characterized in that, When the runtime layer obtains a credential reference corresponding to the object identifier, it also includes: The runtime layer initiates a credential reference query request to the credential vault. The credential reference is an encrypted pointer to the credential vault. The credential reference does not contain plaintext credentials. The credential vault stores an access control list corresponding to the credential reference. The access control list records the gateway instance identifiers that are allowed to use the credential reference. The credential vault checks whether the current gateway instance has permission to access the credential reference based on the access control list. If permission is granted, the credential reference is returned; otherwise, a denial error code is returned.

6. The method according to any one of claims 1 to 5, characterized in that, Before executing the target call, the gateway layer also includes: Query the corresponding authorization snapshot based on the authorization snapshot identifier associated with the current session; Verify the authorized snapshot and confirm whether the current call request is within the authorized boundaries; Verify whether the current time is within the validity period of the authorized snapshot; If the authorized snapshot verification fails, a security audit event will be generated; The authorization boundaries include user identity, role, workspace permissions, authorized skill packs, and data access levels.

7. The method according to any one of claims 1 to 5, characterized in that, The service layer generates registration records for the target object, and also includes: In response to receiving a method registration request, determine whether the domain name of the target service address in the method registration request belongs to a preset service whitelist; if it does not belong, refuse to execute the method registration request. Determine whether the parameter structure in the method registration request contains a preset sensitive field type; if it does, and no field-level encryption strategy is configured, then refuse to execute the method registration request. Determine whether the workspace binding list in the method registration request is empty; if it is empty, refuse to execute the method registration request.

8. The method according to any one of claims 1 to 5, characterized in that, Also includes: The service layer performs status management on the registration records, and the status includes pending review, registered, about to expire, rotated, and abandoned. When the digital signature of the registration record is less than or equal to a preset expiration time, a key rotation reminder operation is automatically triggered. When the registration record is explicitly removed, the status of the registration record is changed to obsolete, and thereafter, any verification request for the registration record will return an error code indicating that the method is obsolete.

9. The method according to any one of claims 1 to 5, characterized in that, Before executing the target call using the plaintext credentials, the following is also included: A complete MCP call request is constructed using the plaintext credentials, the MCP call request including authentication information and the target service address; Clear the plaintext credentials from the memory of the gateway layer and set the credential clearing confirmation flag to true; If the credential clearing confirmation flag is false, an emergency security process is triggered, which includes terminating the current gateway process and starting a backup gateway instance.

10. An MCP service platform, characterized in that, include: The service layer is used to generate registration records for target objects. The registration records include object description information and digital signatures, and distribute the verification key corresponding to the digital signatures to the runtime layer. The skill package layer is used to store skill packages, which contain object identifiers but do not contain any credential information for establishing an MCP connection. The runtime layer is used to parse the object identifier from the skill package when a call request is received, obtain the corresponding registration record from the service layer based on the object identifier, and verify the digital signature in the registration record using the verification key to confirm the integrity and authenticity of the object description information. If the verification passes, obtain the credential reference corresponding to the object identifier, and send the execution request carrying the credential reference to the gateway layer; The gateway layer is used to receive the execution request, obtain the plaintext credential based on the credential reference, execute the target call using the plaintext credential, and make the plaintext credential unusable after execution.

Images