Secure access control method and device of MCP protocol, storage medium and program product

Abstract

The invention relates to the field of artificial intelligence, and discloses a security access control method and device of an MCP protocol, a storage medium and a program product. The method comprises the following steps: in a tool registration stage, performing digital signature on tool metadata registered in an MCP server, and signing and issuing an access token containing a client identity attribute to complete bidirectional identity authentication of a client and an external tool; a tool calling request initiated by the MCP client is acquired and intercepted, context information of the request is collected, the context information comprises at least one of a main body attribute, a resource attribute, an operation attribute and an environment attribute, and the tool calling request carries an access token; the context information is submitted to a strategy decision point, dynamic evaluation is carried out based on a preset attribute-based access control strategy rule, an authorization decision is generated, and the authorization decision comprises permission and rejection; and executing releasing or blocking operation on the tool calling request according to the authorization decision.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, specifically to a secure access control method, apparatus, storage medium, and program product for the MCP protocol. Background Technology

[0002] With the rapid development of artificial intelligence technology, large-scale language models and intelligent agent systems are increasingly becoming core components of enterprise business processing and decision support. In these systems, intelligent agents calling external tools through the Model Context Protocol (MCP) has become the main way to extend their capabilities and complete complex tasks. However, the traditional MCP protocol has significant shortcomings in terms of secure access control, especially in scenarios involving the integration of multiple tools and complex calls, making it difficult to effectively prevent potential security threats.

[0003] In existing technologies, the MCP protocol itself does not mandate strong authentication of tool identities, nor does it implement dynamic access control for invocation behavior. The tool registration process lacks integrity protection, allowing attackers to tamper with tool metadata or impersonate legitimate tools, leading to the injection and invocation of malicious tools. Furthermore, existing access control mechanisms largely rely on static permission allocation and token authorization; once tokens are stolen or abused, the system struggles to block abnormal invocation behavior in real time. Especially in multi-tenant, multi-role enterprise environments, static authorization policies cannot be evaluated in real time based on the context of the invocation (such as user role, time, geographical location, network environment, etc.), resulting in overly lenient permission control, contradicting the "principle of least privilege" in zero-trust security. Moreover, existing technologies have shortcomings in security monitoring and auditing during tool invocation. The lack of a systematic context collection and policy evaluation mechanism makes it impossible to record complete access tracing, leading to difficulties in post-incident tracing and analysis, and hindering the timely detection and blocking of potential attack paths. More critically, these security mechanisms often lack deep integration with the MCP protocol itself, requiring significant adjustments to the system architecture or the deployment of independent security middleware, increasing deployment costs and system complexity.

[0004] Therefore, existing MCP security mechanisms suffer from problems such as insufficient trust in tool identities, static access control, weak context awareness, and inflexible integration and deployment. They are difficult to adapt to the security access control requirements of intelligent agent systems in complex, dynamic, and high-risk environments. There is an urgent need for an access control scheme that can ensure the trust in the identities of both tools and users, and can achieve dynamic, fine-grained, and context-aware access control to improve the overall security, compliance, and controllability of intelligent agent systems. Summary of the Invention

[0005] The purpose of this application is to provide a secure access control method, device, storage medium, and program product for the MCP protocol, in order to solve the technical problems in the existing MCP protocol, such as the tool identity being easily tampered with, access control relying on static permissions, lack of context awareness, and the high security risks, rigid permission management, and inability to adapt to complex and ever-changing calling scenarios caused by the difficulty in implementing dynamic fine-grained authorization.

[0006] To achieve the above objectives, the first aspect of this application provides a secure access control method for the MCP protocol, comprising:

[0007] During the tool registration phase, the tool metadata registered in the MCP server is digitally signed, and an access token containing the client's identity attributes is issued to complete the two-way authentication between the client and the external tool.

[0008] Obtain and intercept tool call requests initiated by the MCP client, and collect the context information of the request. The context information includes at least one of the following: subject attributes, resource attributes, operation attributes, and environment attributes. The tool call request carries an access token.

[0009] Context information is submitted to the policy decision point, and dynamic evaluation is performed based on the preset attribute-based access control policy rules to generate authorization decisions, including allow and deny;

[0010] Based on the authorization decision, the system will either allow or block the tool call request.

[0011] In this embodiment of the application, digitally signing the tool metadata registered in the MCP server includes: defining the tool metadata in JSON format, wherein the JSON format includes at least the tool name, description, input / output parameters and access permission requirements; and the MCP server using a private key to digitally sign the JSON-formatted tool metadata definition to generate signature data conforming to the JSON Web Signature standard.

[0012] In this embodiment of the application, issuing an access token containing client identity attributes includes: the MCP client initiating an authentication request to the identity authentication module of the MCP server according to a standard identity authentication protocol; the identity authentication module performing identity verification according to the authentication request, and issuing a short-term access token containing client identity identifier, role and security attributes after successful verification.

[0013] In this embodiment of the application, the two-way authentication between the client and the external tool is completed as follows: before initiating a tool call request, the MCP client needs to verify the validity of the received tool metadata signature; when the MCP server receives the request, it needs to verify the validity of the access token; if both the tool metadata signature and the access token are verified, the two-way authentication is successful.

[0014] In this embodiment of the application, dynamic evaluation is performed based on preset attribute-based access control policy rules. The policy rules include at least one of the following: limiting the tools that can be called and the operations that can be executed by the MCP client according to the role of the client; verifying the permission scope carried in the access token according to the permission requirements defined by the called tool; and performing access control according to at least one of the following: the time of request initiation and the source network location.

[0015] In this embodiment of the application, the operation of allowing or blocking the tool call request is performed according to the authorization decision, including: if the authorization decision is to allow, allowing the tool call request to the backend tool executor to perform the corresponding operation; if the authorization decision is to deny, immediately interrupting the request process and returning a permission denial response to the MCP client.

[0016] In this embodiment of the application, the method further includes: after executing the authorization decision, recording the complete context information of the request, the matching policy rules and the final decision result to the security audit log to form a traceable audit trail.

[0017] A second aspect of this application provides a secure access control device for the MCP protocol, comprising:

[0018] Memory, used to store computer programs;

[0019] A processor for implementing any of the above-mentioned secure access control methods for the MCP protocol when executing a computer program.

[0020] A third aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform any of the above-described secure access control methods for the MCP protocol.

[0021] A fourth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the security access control method for the MCP protocol described above.

[0022] Through the above technical solution, in the tool invocation process of the MCP protocol, the tool metadata is digitally signed to verify its authenticity and integrity, and a short-term access token carrying identity attributes is issued to the intelligent agent client to complete two-way identity authentication; all tool invocation requests are intercepted and context information containing subject, resource, operation, and environment attributes is collected in real time; the context information is submitted to the policy decision point, and dynamic evaluation is performed based on pre-set attribute-based access control policy rules to generate an authorization decision; based on the authorization decision, the tool invocation request is allowed or blocked. This system and method, by integrating the zero-trust security concept into the MCP protocol, realizes dynamic security control of the entire process from tool registration and identity authentication to each invocation, which can effectively defend against security threats such as tool tampering, identity impersonation, and permission abuse, and significantly improve the proactive defense capability and security compliance level of the intelligent agent system in complex and dynamic environments.

[0023] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:

[0025] Figure 1 The illustration shows a flowchart of a secure access control method for the MCP protocol according to an embodiment of this application;

[0026] Figure 2 A schematic diagram illustrating a system architecture according to an embodiment of this application is shown.

[0027] Figure 3 The diagram illustrates the internal structure of a computer device according to an embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0029] It should be noted that if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0030] Figure 1 A schematic flowchart illustrating a secure access control method for the MCP protocol according to an embodiment of this application is shown. Figure 1 As shown, in one embodiment of this application, a secure access control method for the MCP protocol is provided, comprising the following steps:

[0031] Step 101: During the tool registration phase, digitally sign the tool metadata registered in the MCP server and issue an access token containing client identity attributes to complete two-way authentication between the client and the external tool.

[0032] In one embodiment, the processor digitally signs the tool metadata registered in the MCP Server, including: defining the tool metadata in JSON format, whereby the JSON format includes at least the tool name, description, input / output parameters, and access permission requirements; and the MCP Server digitally signing the JSON-formatted tool metadata definition using a private key to generate signature data conforming to the JSON Web Signature standard. Here, MCP is a Model Context Protocol whose core goal is to enable large AI models to securely and systematically connect to external data sources, tools, and applications. JSON format refers to a lightweight data exchange format. The private key is a secret key in an asymmetric encryption algorithm.

[0033] In this embodiment of the application, the processor issues an access token containing client identity attributes, including: the MCP client initiating an authentication request to the identity authentication module of the MCP server according to a standard identity authentication protocol; the identity authentication module performs identity verification according to the authentication request, and after successful verification, issues a short-term access token containing client identity identifier, role and security attributes.

[0034] In this embodiment of the application, before initiating a tool call request, the MCP client needs to verify the validity of the received tool metadata signature; when the MCP server receives the request, it needs to verify the validity of the access token; if both the tool metadata signature and the access token are verified, the two-way authentication is successful.

[0035] In one embodiment, upon receiving a new tool registration request from an administrator, the MCP server initiates a tool identity trust process. First, the tool is defined using JSON (JavaScript Object Notation) metadata. This definition file includes at least the tool's unique name, functional description, input and output parameter specifications, semantic version number, a list of executable functions or skills, and the client permission scope required to invoke the tool, such as `required_scope:"customer:read"`, indicating the need for "customer:read" permission. To ensure the tool definition is not tampered with or forged during subsequent distribution, transmission, and storage, the MCP server performs a digital signature operation on the JSON-formatted tool metadata using its strictly confidential private key. The signed data generates signature data conforming to the JWS (JSON Web Signature) specification, which is stored bound to the original tool metadata. JWS is a JSON-based data signature standard. Simultaneously, the MCP server's corresponding public key is pre-distributed securely to all legitimate MCP clients for signature verification before invoking the tool. Any modification to the registered tool definition requires a re-generated signature, thus ensuring the integrity, authenticity, and version controllability of the tool's identity from the source. During client authentication, the MCP client initiates an authentication request to the identity authentication module integrated into the MCP server based on standard protocols such as client credential authorization. This request carries a client identifier and key pre-configured by the system administrator. The identity authentication module forwards this credential to the enterprise's existing identity provider (IdP) for verification to confirm the legitimacy of the client's identity. Upon successful verification, the identity authentication module issues a short-lived access token (in JWT format, i.e., JSON Web Token). The payload of this JWT token encodes the client's core identity attributes, including the client's unique identifier, assigned role, allowed permission scope, and token validity period. Two-way authentication requires collaborative verification between the client and server: before initiating a specific tool call request, the MCP client must first obtain the target tool's metadata and its JWS signature from the server and verify the signature using a pre-distributed server public key. If signature verification fails, the tool's identity is considered untrusted, and the client should terminate the call and issue an alert. On the other hand, when a client's call request arrives at the MCP server, the Policy Enforcement Point (PEP) intercepts the request and extracts the JWT access token from the HTTP authorization header. It then verifies the token's signature validity, expiration date, and whether it was issued by a trusted IdP. Only when both the tool metadata signature verification confirms the tool's trustworthiness and the client access token verification confirms the caller's trustworthiness are successfully completed is the two-way authentication for this session considered successful.If any step fails, the request will be terminated immediately and the corresponding authentication error message will be returned.

[0036] Step 102: Obtain and intercept tool call requests initiated by the MCP client, and collect the context information of the request. The context information includes at least one of the following: subject attributes, resource attributes, operation attributes, and environment attributes. The tool call request carries an access token.

[0037] In one embodiment, the Policy Enforcement Point (PEP) in the MCP server is configured as the mandatory control gateway for all inbound requests. When an MCP client initiates a request to the server's tool invocation endpoint via the HTTP protocol, the request is first intercepted by the PEP component. The PEP ensures that a complete access control process is completed before the request is passed to the backend tool processor that actually executes the business logic. Upon successful interception, the PEP triggers the Policy Information Point (PIP) to initiate a context collection process. The PIP collects various attributes related to the current invocation from multiple distributed and trusted data sources in real time and structures them into a unified context information object. This object is the data foundation for subsequent dynamic authorization decisions and must contain at least one of four types of attributes: 1. Subject Attributes: Describe the identity and permissions of the request initiator. The PIP parses the embedded identity claims from the access token carried in the request, such as the client's unique identifier, role, department, and list of permission scopes. 2. Resource Attributes: Describe the tool itself being requested to be invoked. PIP queries the digitally signed tool metadata definition based on the tool name in the request body to obtain the tool name, description, skill list, required permission scope, and the static sensitivity level pre-marked by the administrator for the tool. 3. Action Attributes: Describes the specific operation intended to be performed in this request. PIP extracts the specific skill name to be invoked from the request body, as well as all input parameters and their values ​​provided by the client. 4. Environment Attributes: Describes the objective environmental state at the time the request occurs. PIP collects information in real time from the network and system layers, including the client's source IP address, the timestamp of the request, the geographic region (if available), whether the current network is marked as abnormal, and the device identifier of the request, etc.

[0038] Step 103: Submit the context information to the policy decision point, perform dynamic evaluation based on the preset attribute-based access control policy rules, and generate an authorization decision, which includes allow and deny.

[0039] In one embodiment, dynamic evaluation is performed based on pre-defined attribute-based access control policy rules, which include at least one of the following: limiting the tools that can be invoked and the operations that can be executed by the MCP client based on the role of the client; verifying the permission scope carried in the access token based on the permission requirements defined by the invoked tool; and performing access control based on at least one of the following: the time of request initiation and the source network location.

[0040] In one embodiment, after collecting context information, the policy enforcement point submits the structured context information object as input to the system's policy decision point (PDP). The PDP loads and executes a set of policy rules predefined and configured by the policy management point (PAP). These rules are written using an attribute-based access control (ABAC) model. ABAC is a fine-grained, dynamic access control model whose core idea is that access decisions are not based on fixed user-resource mappings, but are dynamically calculated in real-time based on a series of attributes, including subject, resource, operation, and environment, at the time of the access request. Specifically, after receiving the context information, the PDP treats it as facts and matches and logically evaluates it against all loaded policy rules. The evaluation process is dynamic and real-time, performed independently for each tool call request. The PDP ultimately outputs a clear, binary authorization decision: "allow" or "deny." This decision is immediately returned to the policy enforcement point (PEP) for execution. This mechanism ensures that access control strictly adheres to the zero-trust principles of "every access must be verified" and "least privilege."

[0041] Step 104: Based on the authorization decision, perform the operation of allowing or blocking the tool call request.

[0042] In one embodiment, the PEP performs an operation to allow or block a tool call request based on an authorization decision, including: if the authorization decision is to allow, allowing the tool call request to be passed to the backend tool executor to perform the corresponding operation; if the authorization decision is to deny, immediately interrupting the request process and returning a permission denial response to the MCP client.

[0043] In one embodiment, the method further includes: after executing the authorization decision, the processor records the complete context information of the request, the matching policy rules, and the final decision result to the security audit log to form a traceable audit trail.

[0044] In one embodiment, the PEP receives and executes the authorization decision of the PDP. If the decision is "allow," the original request is allowed to proceed to the backend tool executor; if the decision is "deny," the request process is immediately aborted, and a clear permission denial error, such as a 400 parameter mismatch, is returned to the client. Regardless of the outcome, the complete context of each decision, the matching policy, and the final result are logged in the security log, forming an audit trail.

[0045] Through the above technical solution, within the MCP protocol framework, the metadata of the external tools to be registered is digitally signed to ensure their trustworthy identity. Short-term access tokens carrying identity attributes are issued to the MCP client to establish two-way trust and intercept each tool invocation request. Context information, including multi-dimensional attributes such as subject, resource, operation, and environment, is collected and structured in real time. This context information is submitted to the policy decision point, where it is dynamically evaluated based on pre-set attribute-based access control policy rules to generate real-time authorization decisions. Finally, the policy enforcement point executes the permission or blocking operation for the tool invocation request based on the decision results, generating a complete audit log. This solution deeply integrates the zero-trust security concept into the entire tool invocation chain, achieving integrated security control from identity authentication and context awareness to dynamic policy execution. It can effectively resist various security threats such as tool tampering, identity impersonation, permission abuse, and abnormal invocation, and supports seamless integration with existing enterprise identity systems and policy engines. This application significantly reduces the security blind spots and maintenance costs of traditional static authorization mechanisms, and realizes fine-grained, real-time, and adaptive security governance of intelligent agents' behavior of calling external tools, which significantly improves the active defense capability, security compliance level and operational reliability of intelligent agent systems in complex open environments.

[0046] In one specific embodiment, this application can be applied to an enterprise customer service intelligent query assistant. It describes how the intelligent agent uses the identity authentication and dynamic access control module proposed in this application when calling the tool, allowing customer service team members to securely and compliantly query the customer database using natural language. The Claude desktop application has built-in MCP protocol support. As an MCP client, it can call the enterprise's self-built MCP database server, encapsulates a read-only database interface, and performs digital signing during tool registration.

[0047] The specific process, according to the method described in detail in this application, is as follows:

[0048] 1. When deploying MCP Server, enterprises integrate the security module of this application as middleware. This means that MCP Server now includes: PEP as a mandatory gateway for all API requests; PIP configured with a data source for subsequent real-time attribute collection; PDP deploying and configuring an OPA instance; PAP providing a management interface or Git repository for writing and managing OPA policies; and an identity authentication module integrated with the enterprise's existing identity provider (IdP, such as Azure AD). OPA is an open-source, general-purpose policy engine used for fine-grained access control, policy management, and compliance checks.

[0049] 2. The administrator registers multiple tools on the MCP Server, among which the database query tool is named query_customer_info. The JSON definition of this tool includes its {"name":"query_customer_info","description":"*","skills":{"skill_name":"search_by_pii","description":"*","parameters":["query_by":"order_id",...]}}}}}

[0050] The definition is saved using the server's private key to ensure it is not tampered with. In PAP, a static attribute "tool_sensitivity" is associated with the tool.

[0051] 3. The IT administrator registers a service account (Client ID / Secret) for the MCP client in the IdP for backend OAuth2.0 authentication. Different user roles are defined in the IdP, such as junior_support and senior_analyst, and customer service team employees are assigned to the corresponding roles.

[0052] 4. Security administrators use PAP, written in Rego language and loaded into OPA (PDP). These policies embody the zero-trust "least privilege" principle. For example: 1) Role-based access control policy: The junior_support role is only allowed to use customer_id or order_id to call the search_by_pii skill of the query_customer_info tool; the senior_analyst role is additionally allowed to use email or phone_number to call the search_by_pii skill of the query_customer_info tool. 2) Parameter constraint policy: When any role queries, the client scope field must meet the required_scope requirements defined by the tool. 3) Environment constraint policy: All query operations must be initiated during working hours, and all source IPs must come from the company's internal network or a registered VPN segment.

[0053] 5. A customer service representative (role: junior_support) entered a natural language request ("Hello, could you please check the shipping address of the customer with order number ORD-2025-9981?") on the Claude desktop application on their office computer at 10:00 AM on Wednesday. Claude's Agent understood the natural language and recognized the need to call the query_customer_info tool. 1) The client verifies the tool's integrity: The MCP Client uses a pre-distributed public key to verify the tool definition and signature returned by the MCP Server. The result is valid, confirming the tool has not been tampered with. 2) Using the client credentials and user identity configured in the backend, an authentication request is initiated to the IdP to obtain a JWT short-lived token {"name":"*","role":"junior_support","exp","device_id":"int","scope":["customer:read","openid","profile"]}. Claude constructs a tool / call request, placing the JWT token in the HTTP Authorization header, with the request body being: {"tool_name":query_customer_info,"skill_name":"search_by_pii","parameters":{"query_by":"order_id","value":"ORD-2025-9981"}}.

[0054] 6. Upon reaching the MCP Server, the request is immediately intercepted by PEP. First, the client's identity is verified: PEP parses the JWT token, verifying that the token is trustworthy and has not expired. Then, the tool's integrity is verified: PEP loads the tool named query_customer_info from storage, which has been digitally signed, and verifies the signature using a pre-distributed public key. The result is valid, confirming that the tool has not been tampered with.

[0055] 7. When PIP is triggered, a comprehensive context JSON object is quickly collected from multiple sources and constructed: {"subject":{"user_id":"*","role":"*","scope_from_token":}

[0056] "*"},"resource":{"tool_name":"query_customer_info","signat ure_valid":true,"skills":"*","required_scope":"*","sensitivity":"high"},"action":{"skill_invoked":"search_by_pii","para meters":{"query_by","value"}},"environment":{"ip_address":"Company intranet","timestamp":"2025-09-25T10:00:00Z"}}

[0057] 8. PEP sends this context JSON object as input to the OPA engine (PDP) and evaluates all loaded Rego policies. 1) The role-based access control policy (input.subject.role = junior_support and input.action.parameters.query_by = order_id and input.action.skill_invoked = search_by_pii) is evaluated, and the condition is met. 2) The parameter constraint policy (input.subject.scope_from_token in input.resource.required_scope) is evaluated. 3) The environment constraint policy (input.environment.timestamp is within working hours and input.environment.ip_address belongs to the internal network segment) is evaluated, and the condition is met. Since all relevant policies have passed the evaluation, OPA finally returns a clear decision {"allow": True} to PEP.

[0058] 9. Upon receiving the decision, PEP will allow the request to proceed to the backend database query logic and generate a detailed security audit log. The backend logic uses a pre-defined read-only database account to execute the SQL query. The queried customer information is then returned to the Claude desktop application, which presents the information to the user in natural language.

[0059] Figure 2 A schematic diagram illustrating a system architecture according to an embodiment of this application is provided. Figure 2 As shown, this application applies the zero-trust security concept to the MCP protocol. By combining the ABAC model and identity authentication methods, it aims to design and implement a secure access system for intelligent agents when calling external tools through the MCP protocol. It includes the following four main components: (1) two-way identity authentication; (2) policy information point; (3) policy decision point; and (4) policy execution point.

[0060] Specifically, the steps of the two-way authentication component are as follows: 1) Tool Identity Verification: The tool definition describes its name, description, input / output parameters, semantic version, list of functions (resources accessible under specific conditions), and the permissions required for users or applications to access the tool via JSON. The MCP Server digitally signs the tool's metadata definition using a private key, and the output conforms to the JWS standard. The private key is kept secret by the MCP server, while the public key is securely provided to the MCP client. Any changes to the tool definition require a new signature version. Before a user uses the tool, they must verify the digital signature using the declared public key to ensure the tool's authenticity. If the signature is invalid or lost, the tool is marked as unverified or potentially malicious, triggering a warning or completely blocking the tool's invocation. 2) Client Identity Authentication: Before establishing a session with the MCP server, the MCP client (agent) must request a short-lived access token (JWT) containing its identity identifier, role, and security attributes from the identity authentication module through a standard identity authentication protocol such as OAuth 2.0 client credential authorization mode. If two-way authentication is successful, policy evaluation continues; if authentication fails... The system will then return an authentication failure error to the client, such as 401 "Token Invalid" or 403 "Tool Signature Verification Failed".

[0061] Steps (3) and (4) can simultaneously perform request interception and context attribute collection: 1) Inside the MCP server, the PEP module, as a necessary node for request processing, intercepts all API requests pointing to the tools / call endpoint. 2) The PIP module is triggered to collect and structure the context attributes of this request from multiple sources in real time, forming an attribute set. This set includes at least:

[0062] Main attributes: Client ID, role, and permission scope parsed from the JWT token;

[0063] Resource attributes: the name of the invoked tool, metadata after its integrity has been verified through signature verification, and the predefined tool sensitivity level;

[0064] Environmental attributes: the source IP address of the request, timestamp, geographical location, and other anomalies detected by network security systems;

[0065] Operation attributes: The specific name of the method being called, as well as all input parameters and their values ​​carried in the request.

[0066] Step (5) Dynamic Authorization Decision Step: The PAP module utilizes an open-source policy engine, such as Open Policy Agent (OPA), or uses a policy language like Cedar / YAML to predefine attribute-based policy rules. The PDP module accepts the complete set of attributes and policy rules submitted by the PIP, evaluates them, and returns a "allow" or "deny" decision.

[0067] Step (6) Policy Enforcement: The PEP receives and executes the authorization decision of the PDP. If the decision is "Allow," the original request is allowed to proceed to the backend tool executor; if the decision is "Deny," the request process is immediately interrupted, and a clear permission denial error (such as 400 Parameter Mismatch) is returned to the client. Regardless of the outcome, the complete context of each decision, the matched policy, and the final result are recorded in the security log, forming an audit trail.

[0068] In one embodiment, a secure access control device for the MCP protocol is provided, comprising:

[0069] Memory, used to store computer programs;

[0070] A processor for implementing any of the above-mentioned secure access control methods for the MCP protocol when executing a computer program.

[0071] In one embodiment, a machine-readable storage medium is provided that stores instructions that, when executed by a processor, cause the processor to perform any of the above-described secure access control methods for the MCP protocol.

[0072] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the above-described secure access control methods for the MCP protocol.

[0073] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 3 As shown. The computer device includes a processor A01, a network interface A02, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The database stores security audit logs. The network interface A02 communicates with external terminals via a network connection. When executed by the processor A01, the computer program B02 implements a secure access control method based on the MCP protocol.

[0074] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0075] This application provides an apparatus including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs the following steps: During the tool registration phase, it digitally signs the tool metadata registered in the MCP server and issues an access token containing client identity attributes to complete two-way authentication between the client and the external tool; it acquires and intercepts tool call requests initiated by the MCP client and collects the request's context information, including at least one of subject attributes, resource attributes, operation attributes, and environment attributes, with the tool call request carrying an access token; it submits the context information to a policy decision point, dynamically evaluates it based on preset attribute-based access control policy rules, and generates an authorization decision, including allow and deny; and it executes an operation to allow or block the tool call request based on the authorization decision.

[0076] In one embodiment, digitally signing the tool metadata registered in the MCP server includes: defining the tool metadata in JSON format, whereby the JSON format includes at least the tool name, description, input / output parameters, and access permission requirements; and the MCP server using a private key to digitally sign the JSON-formatted tool metadata definition to generate signature data conforming to the JSON Web Signature standard.

[0077] In one embodiment, issuing an access token containing client identity attributes includes: the MCP client initiating an authentication request to the MCP server's identity authentication module according to a standard identity authentication protocol; the identity authentication module performing identity verification based on the authentication request, and issuing a short-term access token containing the client's identity identifier, role, and security attributes after successful verification.

[0078] In one embodiment, completing two-way authentication between the client and the external tool includes: before initiating a tool call request, the MCP client needs to verify the validity of the received tool metadata signature; when the MCP server receives the request, it needs to verify the validity of the access token; if both the tool metadata signature and the access token are verified, the two-way authentication is successful.

[0079] In one embodiment, dynamic evaluation is performed based on pre-defined attribute-based access control policy rules, which include at least one of the following: limiting the tools that can be invoked and the operations that can be executed by the MCP client based on the role of the client; verifying the permission scope carried in the access token based on the permission requirements defined by the invoked tool; and performing access control based on at least one of the following: the time of request initiation and the source network location.

[0080] In one embodiment, performing an operation to allow or block a tool call request based on an authorization decision includes: if the authorization decision is to allow, allowing the tool call request to be passed to the backend tool executor to perform the corresponding operation; if the authorization decision is to deny, immediately interrupting the request process and returning a permission denial response to the MCP client.

[0081] In one embodiment, the method further includes: after executing the authorization decision, recording the complete context information of the request, the matching policy rules, and the final decision result to the security audit log to form a traceable audit trail.

[0082] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0083] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0084] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0085] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0086] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0087] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0088] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0089] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0090] The above are merely embodiments of this application and are not intended to limit the scope of 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 scope of the claims of this application.

Claims

1. A secure access control method for the MCP protocol, characterized in that, The method includes: During the tool registration phase, the tool metadata registered in the MCP server is digitally signed, and an access token containing the client's identity attributes is issued to complete the two-way authentication between the client and the external tool. The tool call request initiated by the MCP client is acquired and intercepted, and the context information of the request is collected. The context information includes at least one of subject attributes, resource attributes, operation attributes and environment attributes. The tool call request carries the access token. The context information is submitted to the policy decision point, and dynamic evaluation is performed based on the preset attribute-based access control policy rules to generate an authorization decision, which includes allow and deny. Based on the authorization decision, the operation of allowing or blocking the tool call request is executed.

2. The secure access control method according to claim 1, characterized in that, The digital signature of the tool metadata registered in the MCP server includes: The tool metadata is defined in JSON format, which includes at least the tool name, description, input / output parameters, and access permission requirements. The MCP server uses a private key to digitally sign the JSON-formatted tool metadata definition, generating signature data that conforms to the JSON Web Signature standard.

3. The secure access control method according to claim 1, characterized in that, The issuance of the access token, which includes client identity attributes, includes: The MCP client initiates an authentication request to the MCP server's authentication module according to the standard authentication protocol; The identity authentication module performs identity verification based on the authentication request, and after successful verification, issues a short-term access token containing the client's identity identifier, role, and security attributes.

4. The secure access control method according to any one of claims 1 to 3, characterized in that, The process of completing two-way authentication between the client and external tools includes: Before initiating the tool invocation request, the MCP client needs to verify the validity of the received tool metadata signature; When the MCP server receives a request, it needs to verify the validity of the access token. If both the tool metadata signature and the access token are verified, the two-way authentication is successful.

5. The secure access control method according to claim 1, characterized in that, The dynamic evaluation is based on preset attribute-based access control policy rules, wherein the policy rules include at least one of the following: Based on the role of the MCP client, the tools that the role can call and the operations that can be performed are limited; Based on the permission requirements defined by the invoked tool, verify the permission scope carried in the access token; Access control is performed based on at least one of the time the request was initiated and the location of the source network.

6. The secure access control method according to claim 1, characterized in that, The step of performing the permission or blocking operation on the tool invocation request based on the authorization decision includes: If the authorization decision allows, the tool call request will be allowed to proceed to the backend tool executor to perform the corresponding operation; If the authorization decision is denied, the request process is immediately interrupted, and a permission denial response is returned to the MCP client.

7. The secure access control method according to claim 1, characterized in that, The method further includes: After executing the authorization decision, the complete context information of the request, the matching policy rules, and the final decision result are recorded in the security audit log to form a traceable audit trail.

8. A secure access control device for the MCP protocol, characterized in that, The control device includes: Memory, used to store computer programs; A processor, configured to implement the secure access control method for the MCP protocol as described in any one of claims 1 to 7 when executing the computer program.

9. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the secure access control method for the MCP protocol according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the secure access control method for the MCP protocol according to any one of claims 1 to 7.

Images