Large model tool invocation management method and system

Abstract

The application discloses a large model tool calling control method and system, and relates to the technical field of artificial intelligence security. The method comprises the following steps: grabbing HTTP messages and extracting protocol feature vectors, calculating MCP confidence and A2A confidence, and identifying MCP protocol traffic, A2A protocol traffic and A2A derived MCP calling traffic in combination with time sequence determination results; mapping the identified protocol messages into standardized security events; constructing a cross-protocol tool calling event graph with the security events as nodes, establishing parent-child calling relationship and calling chain identification; executing multi-dimensional security policy determination based on the event graph and outputting the determination results, and executing permission, auditing or blocking disposal according to the determination results. The application can realize cross-protocol calling chain tracing and dynamic security control in the mixed deployment scene of MCP and A2A.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence security technology, specifically to a method and system for controlling the invocation of large model tools. Background Technology

[0002] With the rapid development of large-scale model technology, AI applications have evolved from simple large language model chat to complex agent-based applications. In this context, MCP (Model Context Protocol) is used to standardize the interaction between large models and external tools and resources, while A2A (Agent-to-Agent) protocol is used to standardize capability discovery, task delegation, and result return between agents. These two protocols enable large models to invoke external tools such as file systems, databases, code execution environments, and business systems, as well as to collaborate with multiple agents to complete complex tasks.

[0003] Currently, security management for MCP and A2A protocols primarily employs methods such as transport layer authentication, API key verification, or general API gateway access control. These methods verify the legitimacy of the request source based on authentication fields in the HTTP protocol header (such as API Key and BearerToken), and perform coarse-grained filtering of requests through blacklists and whitelists at the gateway level. For authenticated requests, the gateway forwards them to the corresponding MCP or A2A server. Upon receiving the request, the server determines the authorization for tool invocation or task execution based on its internally configured permission rules. Simultaneously, the system generates an audit log after request processing, recording basic information such as the invocation time, source IP, and the server interface called. The above solutions only manage the transport and authentication layers of the request and do not involve parsing the request message body.

[0004] Because the MCP / A2A protocol message body is not parsed, the above solutions cannot obtain the specific tool name, parameter values, Agent Card information, etc., from the call parameters, thus making it impossible to implement tool-level access control. For example, for two MCP tools that both perform database operations, such as the "Query User Information" tool and the "Delete User Table" tool, the gateway can only recognize that both are legitimate MCP calls, but cannot distinguish which is a high-risk operation, nor can it intercept the high-risk operation at the gateway layer. For the A2A protocol, the skill declaration in the Agent Card is not verified, and attackers can forge the Agent Card to add unregistered skills. In addition, the above solutions typically treat each request as an independent event. When an MCP tool call is triggered after an A2A task is delegated, the MCP call is only reflected in the audit log as agent B calling a certain tool, and it is impossible to reconstruct that the call was indirectly triggered by agent A's A2A task. In terms of behavior analysis, existing solutions mainly rely on statically configured permission whitelists, which match tool call requests one by one against the whitelist rules. If a match is found, the request is allowed; otherwise, it is rejected. This approach cannot identify situations where a single call may appear legitimate, but the overall behavior pattern is abnormal. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a method and system for controlling large-scale tool calls. By capturing and parsing MCP / A2A protocol messages and constructing a cross-protocol call chain, it implements tool-level access control, indirect unauthorized call identification, and dynamic behavior risk control at the protocol semantic layer. This forms a closed-loop protection across the entire chain in a non-intrusive deployment manner and supports auditing and tracing.

[0006] In a first aspect, the technical solution of the present invention provides a method for managing and controlling large model tool calls, comprising the following steps: Capture HTTP request and response messages between the large model agent client and the MCP server and A2A server, extract protocol feature vectors from the HTTP message headers and HTTP message bodies; calculate the MCP confidence and A2A confidence based on the protocol feature vectors, and determine the timing of whether an MCP protocol call occurs after A2A protocol traffic, thus identifying MCP protocol traffic, A2A protocol traffic, and A2A-derived MCP call traffic; Based on a unified security event model, the original fields in the protocol messages of the identified traffic are mapped to a standardized security event; Using the currently mapped security events as nodes and the call relationships between security events as directed edges, incrementally update the cross-protocol tool call event graph to establish parent-child call relationships and call chain identifiers between security events; The system performs security policy judgments on the currently mapped security events using the event graph, outputs the judgment results for the current security events, and performs allow, audit, or block actions based on the judgment results, and records the audit logs in an append-only manner; the security policies include at least one or more of the following: trusted tool list verification, Agent Card trusted verification, sensitive data detection, cross-protocol call chain verification, and behavioral risk control scoring.

[0007] Secondly, the technical solution of the present invention provides a large model tool call management system, including: The protocol identification module is used to capture HTTP request and response messages between the large model intelligent agent client and the MCP server and A2A server, extract protocol feature vectors from the HTTP message header and HTTP message body of the messages, calculate the MCP confidence and A2A confidence based on the protocol feature vectors, and determine the timing of whether an MCP protocol call occurs after the A2A protocol traffic, thereby identifying MCP protocol traffic, A2A protocol traffic, and A2A derived MCP call traffic. The protocol parsing module is used to map the raw fields in the protocol messages of the identified traffic into a standardized security event based on a unified security event model. The event graph construction module is used to incrementally update the cross-protocol tool call event graph, with the currently mapped security events as nodes and the call relationships between security events as directed edges, and to establish parent-child call relationships and call chain identifiers between security events. The security decision module is used to perform security policy judgments on the currently mapped security events using an event graph, output the judgment results for the current security events, perform allow, audit, or block actions based on the judgment results, and record audit logs in an append-only manner; the security policies include at least one or more of the following: trusted tool list verification, Agent Card trusted verification, sensitive data detection, cross-protocol call chain verification, and behavioral risk control scoring.

[0008] As can be seen from the above technical solutions, this application has the following advantages: By capturing HTTP messages and extracting protocol feature vectors, this application identifies MCP protocol traffic, A2A protocol traffic, and A2A-derived MCP call traffic. Unlike traditional gateways that only verify transport layer authentication information without parsing the protocol message body, this application can obtain semantic information such as the tool name, call parameters, and Agent Card in each call. This allows for the differentiation of high-risk and compliant operations under the same protocol at the tool level, and can intercept attacks that forge Agent Cards to add unregistered skills at the gateway level. By constructing a cross-protocol tool call event graph, a parent-child call relationship and a unified call chain identifier are established for security events. Unlike existing auditing models that treat each request as an independent event, this approach associates A2A task delegation with subsequent triggered MCP tool calls as a complete call chain. This makes the final initiator and complete transmission path of each call clearly traceable, preventing the implicit diffusion of permissions through multiple layers of delegation from going unnoticed. This system employs a multi-dimensional security strategy based on event graphs, including trusted tool verification, Agent Card verification, sensitive data detection, cross-protocol call chain verification, and behavioral risk control scoring. It replaces the traditional single-judgment logic that relies solely on static blacklists and whitelists. Among these, the behavioral risk control scoring analyzes the deviation of call behavior from historical baselines to identify hidden risks where individual calls appear legitimate but the overall behavioral pattern is abnormal. This can be used to discover security threats that are difficult to cover by static rules, such as credential theft, automated attacks, and unauthorized combined calls. The solution is deployed between the large-scale model agent client and the MCP / A2A server, capturing packets without requiring modifications to existing large-scale model applications, MCP servers, or A2A agents. It achieves end-to-end closed-loop control without intruding on business systems. The system records audit logs append-only, ensuring log integrity while supporting the tracing and analysis of security events, meeting the auditability requirements of enterprise-level scenarios. Attached Figure Description

[0009] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of a large model tool call control method provided in an embodiment of the present invention.

[0011] Figure 2 A schematic diagram of the process architecture for a specific implementation of the control method for calling large model tools.

[0012] Figure 3 This is a schematic block diagram of a large model tool call control system provided in an embodiment of the present invention. Detailed Implementation

[0013] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The various terms used in this specification are merely for describing specific embodiments and do not constitute a limitation thereof.

[0015] Figure 1 This is a schematic diagram illustrating a method for managing and controlling large model tool calls, provided as an embodiment of the present invention. Figure 1 The executing entity can be a large model tool invocation control system. The large model tool invocation control method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the large model tool invocation control system runs on the computer device. Depending on different needs, the order of the steps in this flowchart can be changed, and some steps can be omitted.

[0016] like Figure 1 As shown, the method includes the following steps.

[0017] SS1 captures HTTP request and response messages between the large model agent client and the MCP server and A2A server, extracts protocol feature vectors from the HTTP message headers and bodies of the messages, calculates the MCP confidence and A2A confidence based on the protocol feature vectors, and determines the timing of whether an MCP protocol call occurs after the A2A protocol traffic, thus identifying MCP protocol traffic, A2A protocol traffic, and A2A-derived MCP call traffic.

[0018] SS2, based on a unified security event model, maps the raw fields in the protocol messages of the identified traffic to a standardized security event.

[0019] SS3 uses the currently mapped security events as nodes and the call relationships between security events as directed edges to incrementally update the cross-protocol tool call event graph, establishing parent-child call relationships and call chain identifiers between security events.

[0020] SS4 uses an event graph to perform security policy judgments on the currently mapped security events, outputs the judgment results for the current security events, performs allow, audit, or block actions based on the judgment results, and records audit logs in an append-only manner; the security policies include at least one or more of the following: trusted tool list verification, Agent Card trusted verification, sensitive data detection, cross-protocol call chain verification, and behavioral risk control scoring.

[0021] This method deploys between the large model agent client and the MCP / A2A server via proxies and gateways. It captures HTTP request and response messages, parses message headers, message bodies, and streaming fragments, and identifies MCP messages, A2A messages, and mixed messages containing A2A-derived MCP tool calls. Based on this, it performs tool access control, permission verification, risk scoring, sensitive data detection, blocking measures, and audit logging. This method is not simply adding a generic security gateway, but rather forming a combined solution: packet capture-based protocol semantic recognition, unified security event modeling, cross-protocol call chain management, and closed-loop request-response auditing. The system does not require large model applications, MCP servers, or A2A agents to pre-integrate dedicated SDKs; instead, it obtains parsable content from the HTTP layer and reconstructs tool call semantics based on protocol fields and context.

[0022] Furthermore, as a refinement and extension of the specific implementation methods described above, and to fully illustrate the specific implementation process in this embodiment, a specific embodiment of a large model tool call control method is provided. Figure 2 This is a schematic diagram of the architecture of the method in this specific embodiment, which includes the following steps.

[0023] SS100, HTTP traffic interception and protocol identification.

[0024] In this step, the system is deployed between the large model agent client and the MCP server and A2A server, and HTTP request and response messages between them are captured by packet capture. The system first extracts the original content from the HTTP message header and HTTP message body to generate protocol feature vectors. Then, based on the protocol feature vectors of the MCP protocol and the A2A protocol, it calculates the MCP confidence and A2A confidence for the current message, as well as the timing determination result of whether an MCP protocol call occurs after the A2A protocol traffic, thus identifying MCP protocol traffic, A2A protocol traffic, and A2A-derived MCP call traffic.

[0025] Specifically, the system intercepts HTTP request and response messages destined for the server using pcap or netfilter interfaces, extracting the HTTP headers and HTTP body content. The HTTP headers primarily contain four-tuple information (source IP, destination IP, source port, destination port), content-type, content-length, protocol, accept, URL path, request method, streaming flags, and characteristic fields such as mcp-session-id. The HTTP body is in JSON-RPC format and mainly includes the jsonrpc version number, id field, method field, params field, Agent Card information, task field, skills field, and result field. A typical JSON-RPC format message body is as follows:

[0026] The system extracts fields from the HTTP message header and body and converts them into structured protocol feature vectors according to preset feature mapping rules.

[0027] Specifically, the protocol feature vector is a multi-dimensional Boolean vector or a set of binary tuples, where each dimension corresponds to a preset protocol feature judgment condition. The system checks the HTTP message header and HTTP message body of the current message one by one. For each preset judgment condition, it determines whether the current message meets the condition. If it does, the dimension is marked as 1 (indicating that the feature is matched); if it does not, it is marked as 0 (indicating that the feature is not matched). The judgment results of all dimensions are combined to form the structured protocol feature vector of the current message.

[0028] For example, regarding the condition "the HTTP message header contains the mcp-session-id field," the system checks if the current message's HTTP message header contains a field named mcp-session-id. If it exists, the corresponding dimension is 1; otherwise, it is 0. Regarding the condition "the HTTP message body contains a JSON-RPC format method field belonging to the MCP method set," the system first parses the HTTP message body into JSON format, checks if the jsonrpc and method fields exist, and then determines if the method field value belongs to the MCP method set (initialize, tools / list, tools / call, resources / read, etc.). If all conditions are met, the corresponding dimension is 1; otherwise, it is 0. Regarding the condition "the HTTP message body conforms to the JSON-RPC format," the system checks if the HTTP message body is a valid JSON-RPC 2.0 format, i.e., whether it contains a jsonrpc field with a value of "2.0," and whether it contains an id field.

[0029] The features in this feature vector are categorized as strong or weak. Strong features are those with high discriminative power against protocol types and are assigned higher weights in the confidence calculation. Weak features are those with relatively low discriminative power against protocol types and are assigned lower weights in the confidence calculation. Specifically: Strong features belonging to the MCP protocol include: the HTTP message header contains the mcp-session-id field; the JSON-RPC format method field in the HTTP message body belongs to the MCP method set, which includes initialize, tools / list, tools / call, resources / read, etc. Strong characteristics belonging to the A2A protocol include: the HTTP message path is the path to obtain Agent Card information (such as / .well-known / agent-card.json and / agent / authenticatedExtendedCard); the HTTP message body contains a JSON object conforming to the Agent Card format; Weak features belonging to the MCP protocol include: the HTTP message body contains an MCP response message structure, which contains tools and content fields; Weak features belonging to the A2A protocol include: the HTTP message body contains an A2A request message structure or an A2A response message structure, wherein the A2A request message structure contains the messageId field and the parts field, and the A2A response message structure contains the contextId field, the artifacts field, and the status field. Weak features shared by the MCP and A2A protocols include: HTTP message bodies conforming to the JSON-RPC format.

[0030] Then, for the current request message, the confidence level is calculated and the traffic type is identified, specifically including the following steps SS110 to S130.

[0031] SS110, for the current request message, respectively count the number of strong features n_mcp and weak features m_mcp belonging to the MCP protocol in the protocol feature vector of the message, and the number of strong features n_a2a and weak features m_a2a belonging to the A2A protocol.

[0032] Specifically, the protocol feature vector consists of multiple dimensions of judgment results. Each dimension corresponds to a preset protocol feature judgment condition, and each dimension is pre-labeled with its corresponding protocol type (MCP or A2A) and feature level (strong feature or weak feature). The system iterates through all dimensions of the protocol feature vector, and for each dimension with a value of 1, it accumulates the values ​​to the corresponding count variable according to its corresponding protocol type and feature level.

[0033] Specifically, if a feature of a certain dimension belongs to the MCP protocol and is a strong feature, then n_mcp is incremented by 1; if a feature of a certain dimension belongs to the MCP protocol and is a weak feature, then m_mcp is incremented by 1; if a feature of a certain dimension belongs to the A2A protocol and is a strong feature, then n_a2a is incremented by 1; if a feature of a certain dimension belongs to the A2A protocol and is a weak feature, then m_a2a is incremented by 1; for weak features shared by MCP and A2A (such as JSON-RPC format), this dimension is counted as a weak feature in both MCP and A2A statistics, that is, m_mcp is incremented by 1 and m_a2a is incremented by 1.

[0034] Through the above traversal and statistics, the system obtains four count values: n_mcp, m_mcp, n_a2a, and m_a2a, which serve as inputs for subsequent confidence calculations.

[0035] SS120, calculate the MCP confidence score C_mcp=n_mcp×W_s+m_mcp×W_w, and the A2A confidence score C_a2a=n_a2a×W_s+m_a2a×W_w, where W_s is the weight of the strong feature and W_w is the weight of the weak feature.

[0036] In one optional implementation, the strong feature weight W_s = 50, and the weak feature weight W_w = 10. The physical meaning of the confidence score C is the total score of the feature strength matched by the message; the larger the value, the higher the confidence that the message belongs to the corresponding protocol type.

[0037] SS130, Traffic Identification.

[0038] 1) If the protocol feature vector of the current message matches a strong feature belonging to the MCP protocol, and A2A protocol traffic has been identified in the historical messages of the same session, then the current call is identified as A2A derived MCP call traffic.

[0039] For example, in a typical multi-agent collaboration scenario, agent A delegates a task to agent B via the A2A protocol. During task execution, agent B invokes a database query tool via the MCP protocol. In this case, the database query request message matches strong characteristics of the MCP protocol, such as `mcp-session-id` and the `tools / call` method. Furthermore, A2A protocol traffic, such as the task delegation message between agent A and agent B, has already been identified in the session's historical messages. Therefore, the system identifies this database query call as an A2A-derived MCP call. This type of derived call carries higher security risks because it involves indirect calls across agents and could be used to bypass access control in direct call scenarios; therefore, it needs to be identified first.

[0040] 2) Otherwise, compare C_mcp with the MCP threshold B_mcp. If C_mcp > B_mcp, it is identified as MCP protocol traffic. Compare C_a2a with the A2A threshold B_a2a. If C_a2a > B_a2a, it is identified as A2A protocol traffic.

[0041] Among them, the thresholds B_mcp and B_a2a are configurable policy parameters, and their values ​​can be adjusted according to the actual security needs of the enterprise.

[0042] 3) If the current message is not identified as any of the following: MCP protocol traffic, A2A protocol traffic, or A2A derived MCP call traffic, it will be directly passed through.

[0043] Direct pass-through means that the system does not perform subsequent security event mapping, event graph construction, or security policy determination on the message, maintaining the original communication path unchanged, thereby ensuring that unrelated traffic is not affected. For example, ordinary web browsing requests or API calls that are not based on the MCP / A2A protocol will be directly pass-through and will not enter the security control process of this invention.

[0044] It should be noted that if the current packet is identified as A2A-derived MCP call traffic, the system further obtains the session identifier of the historical A2A event that triggered the call and records it as the parent session identifier (parent_session_id) for establishing an explicit parent-child call relationship during subsequent event graph construction. In addition, the system records the current timestamp when capturing packets as the time when the security event was generated, which is used for time-series association during subsequent event graph construction.

[0045] SS200, protocol parsing and information extraction.

[0046] In step SS200, the MCP protocol message, A2A protocol message, and A2A derived MCP call message identified in step SS100 are received, and the original fields in the protocol message header and message body are uniformly mapped to standardized security events for subsequent toolchain association and security policy determination.

[0047] The system parses the HTTP headers and bodies of MCP protocol messages, A2A protocol messages, and A2A-derived MCP call messages in the identified traffic, extracts key information fields, and maps them to standardized security events in a unified format according to a predefined security event model. This unified format masks the message structure differences between the MCP and A2A protocols, allowing subsequent toolchain associations and security policy determinations to be processed based on a unified data structure without the need to write separate adaptation logic for each protocol.

[0048] The fields included in the security event model and their correspondence with the original fields of the MCP / A2A protocol are shown in Table 1.

[0049] Table 1: Security Incident Model

[0050] An example of a standardized security incident is as follows: In a scenario where agent A delegates a task to agent B via the A2A protocol, and agent B invokes a database query tool via the MCP protocol, the system generates two security events: the first event is of the A2A protocol type, recording agent A's delegation request, including fields such as session identifier, task identifier, skill information, and Agent Card fingerprint, with a false derivation call flag; the second event is of the MCP protocol type, recording agent B's database query tool invocation, containing the same task identifier, tool information, and parameter summary fields, with a true derivation call flag, and the parent session identifier pointing to the session identifier of the first event. These two security events are associated through the task identifier and the parent session identifier, which can be used to construct parent-child invocation relationships in subsequent toolchain associations.

[0051] SS300, toolchain association.

[0052] In step SS300, the standardized security events output in the previous step are received. Using the security events as nodes and the call relationships between security events as directed edges, a cross-protocol tool call event graph is constructed. This event graph is used to reconstruct the complete call chain across agents and protocols, providing data for cross-protocol call chain verification and behavioral risk control.

[0053] The system maintains a global, continuously accumulating directed graph structure to store all security events and their invocation relationships. This directed graph contains the following data structures: nodes, edges, node table, edge table, and hash index table.

[0054] EventNode: Each standardized security event is encapsulated as a graph node. The node's identifier, event_id, is generated by concatenating the session identifier (session_id), request identifier (request_id), and timestamp from that security event, and then calculating the SHA256 hash value. Each node stores the following information: event_id: A unique identifier for the node; Complete security incident information (i.e., all fields of the standardized security incident output by step SS200); in_edges: Enters the directed edge list of this node, recording which nodes call the current node; out_edges: A list of directed edges originating from this node, recording which nodes the current node has accessed; call_chain_id: The identifier of the call chain to which this node belongs. All nodes on the same call chain share the same call_chain_id. depth: The depth of this node in the call chain. The depth of the root node is 0, and the depth increases by 1 for each level of tracing downwards.

[0055] EventEdge: A directed edge that records the call relationships between nodes. Each edge contains the following information: source_id: Source node identifier; target_id: Identifier of the destination node; edge_type: Edge type, including DERIVED_CALL (derived call), SEQUENTIAL (intra-session sequential call), and TASK_FORK (cross-session task branch). timestamp: The creation time of the edge.

[0056] Node table and edge table: The system maintains a node table EventNodeTable and an edge table EventEdgeTable, which are used to store all graph nodes and all directed edges, respectively. The node table uses event_id as the primary key, and the edge table uses (source_id, target_id, edge_type) as the composite primary key.

[0057] Hash Index Tables: To reduce the complexity of node and edge association queries, the system maintains three hash index tables: session_id→EventNode list, task_id→EventNode list, and event_id→EventNode list. The session_id index is used for quickly finding all nodes within the same session, the task_id index is used for cross-session task association queries, and the event_id index is used to directly find the corresponding node by event identifier.

[0058] It should be noted that the system distinguishes between two scenarios when constructing the event graph: initial creation and incremental update.

[0059] Initial creation scenario: When the first security event arrives after system startup, there are no historical nodes in the event graph, and no relationships can be established. The system directly creates a new node as the root node of the event graph, creates a new call chain identifier (call_chain_id) for this node, and sets its depth to 0. This node serves as a potential parent node for subsequent incremental updates.

[0060] Incremental update scenario: When a new security event arrives and a historical node already exists in the event graph, the system executes the following incremental update process.

[0061] SS310, create a node.

[0062] Create a new graph node for the newly arrived security event and calculate its event_id: concatenate the session_id, request_id, and timestamp from the security event into a string in sequence, calculate the SHA256 hash value of this string, and use the hash value as the event_id. Initialize in_edges and out_edges as empty lists; call_chain_id and depth are not yet assigned.

[0063] SS320: Find potential parent nodes and establish directed edges. Search for potential parent nodes in the existing event graph according to the following priority order.

[0064] 1) Explicit Parent-Child Relationship (DERIVED_CALL). If the parent session identifier `parent_session_id` in the security event is not null, the system directly searches for the historical node corresponding to `parent_session_id` in the `session_id` index table. If found, a directed edge of type `DERIVED_CALL` is established, pointing from the parent node to the current node. This edge type is used to record the explicit parent-child relationship of the A2A task-derived MCP tool call.

[0065] 2) In-session temporal association (SEQUENTIAL). If no directed edge was established in step 1), the system searches for historical nodes with the same session ID (session_id) in the session_id index. The system maintains a sliding time window T (default 30 seconds). When a new event arrives, it searches for the same session ID in the session_id index with a timestamp falling within the current time. Existing nodes within the interval [T, current time]. If multiple candidates exist, the one with the largest timestamp is selected as the direct predecessor, and a directed edge of type SEQUENTIAL is established. Old events outside the time window are no longer included in the construction of new edges, but existing edges are retained in the graph. This edge type is used to record the temporal sequence relationship between multiple requests within the same session.

[0066] 3) Cross-session task association (TASK_FORK). If no directed edge is established in steps 1) and 2), and the task identifier (task_id) in the security event is not empty, the system searches for historical nodes with the same task_id but different session identifiers in the task_id index. If found, a directed edge of type TASK_FORK is established. This edge type is used to record scenarios where a task is decomposed into multiple sessions for execution.

[0067] SS330, anti-environmental testing.

[0068] Before establishing each directed edge, the system checks whether the event graph forms a cycle. Specifically, starting from the current node, the system traverses backwards along the in_edges direction, checking whether it is possible to reach the current node itself, i.e., whether there exists a path starting from the current node, traversing several edges, and returning to the current node. If a cycle is formed, the establishment of that edge is skipped and an alarm log is recorded to avoid getting stuck in an infinite loop during chain tracing.

[0069] SS340, assigns the call chain identifier and depth.

[0070] After establishing a directed edge, if the current node finds a parent node, the parent node's call chain identifier (call_chain_id) is assigned to the current node, and the current node's depth is set to the parent node's depth plus 1. If the current node does not find any parent node (i.e., the root node of the call chain), a new call chain identifier (call_chain_id) is created for the current node, and the depth is set to 0.

[0071] Once the event graph is constructed, the system supports subsequent security policy determinations in the following ways: Forward traversal: Starting from the root node where in_edges is empty, traverse along the out_edges direction to the leaf node to obtain the complete forward call chain.

[0072] Reverse tracing: Starting from a given node, traverse backwards along the in_edges direction to the root node to obtain the complete call chain path of that node. This method is used for cross-protocol call chain verification to determine whether the current call has passed through an unauthorized indirect call path.

[0073] Taking the example of agent A delegating to agent B via the A2A protocol, and agent B calling a database query tool via the MCP protocol, the event diagram constructed by the system is as follows: Table 2: Node Table for this Scene

[0074] Table 3: Side Tables for this Scene

[0075] Forward traversal: Starting from the root node N1, traverse along the out_edges direction: N1 → E1 → N2 → E2 → N3, to obtain the complete call chain (A2A delegation request → A2A confirmation response → MCP tool call).

[0076] Reverse tracing: Starting from N3 (MCP tool call), traverse backwards along the in_edges direction: N3 ← E2 ← N2 ← E1 ← N1, to obtain the source path of the call.

[0077] SS400 is the security policy execution engine.

[0078] In step SS400, the security policy engine receives the security event graph, analyzes the nodes and edges in the event graph, performs security policy judgments, and outputs the judgment results for the current security event. Specifically, the security policy engine includes five sub-units: trusted tool list verification, Agent Card trusted verification, cross-protocol call chain verification, behavioral risk control scoring, and sensitive data detection.

[0079] The system executes security policies in the order of "hard verification first, followed by soft verification." Specifically, it first performs trusted tool manifest verification and Agent Card trusted verification (hard verification for access control). After both pass, it then performs cross-protocol call chain verification (also a hard verification). Finally, it performs behavioral risk control scoring and sensitive data detection (soft verification for dynamic risk control). This ensures that before the system invests computing resources in complex call chain tracing and behavioral analysis, it quickly filters obviously non-compliant calls through lightweight access verification.

[0080] (1) Verification of the list of trusted tools.

[0081] Trusted tool inventory verification is a type of hard verification in access control. It is performed first in security policy determination and is used to verify whether the tool information in the current security incident is in the preset trusted tool inventory.

[0082] The system maintains a list of trusted tools, which records information on approved and certified trusted tools, including at least the tool name, signature, hash value, and source verification information. When the system extracts tool information from a current security event, it queries the trusted tool list using the tool name as the key. If the tool name being called is not in the list, the call is blocked directly. If the tool name is in the list, the system further verifies whether the tool signature and hash value match to ensure the tool has not been tampered with. If either the signature or hash value verification fails, the call is also blocked. Only when the tool name is in the list and both the signature and hash value verification pass, this policy outputs an allowed sub-decision result. This policy does not involve an audit branch; the output is either blocked or allowed.

[0083] (2) Agent Card Trust Verification.

[0084] Agent Card trust verification is also a type of hard verification for access control. It is used in conjunction with trusted tool inventory verification and is executed first in security policy determination. Trusted tool inventory verification operates on the tool side, while Agent Card trust verification operates on the agent side. Together, they constitute a two-dimensional trust verification, used to verify whether the Agent Card fingerprint and skill information in the current security event are in the preset trusted agent directory.

[0085] The system maintains an A2A trusted agent directory, which records the Agent Card fingerprints, authentication methods, and skill lists of registered agents. The Agent Card fingerprint is a unique identifier obtained by calculating the hash value of the agent's Agent Card JSON object after normalization, used to distinguish different agent identities. The skill list records the list of skills that the agent is authorized to publicly disclose and invoke.

[0086] Once the system obtains the Agent Card fingerprint and skill information from the current security event, it first verifies whether the Agent Card fingerprint is registered in the trusted agent directory. If not registered, it indicates that the agent's identity is unknown or unapproved, and the system blocks the current call. If registered, it further verifies whether the skill involved in the current request is in the agent's skill list. If the skill is not in the list, for example, if an attacker temporarily adds an unregistered skill, the system blocks the current call. This policy outputs an allowed sub-decision result only when the Agent Card fingerprint is registered in the directory and the skill information is in the corresponding list. This policy does not involve an audit branch; the output is either blocked or allowed.

[0087] (3) Cross-protocol call chain verification.

[0088] Cross-protocol call chain verification is performed only after the current security event has passed the trusted tool manifest verification and Agent Card trusted verification. It should be noted that cross-protocol call chain verification is only performed if the current security event node has an incoming edge (i.e., it is a derived call). If the current node is the root node (in_edges is empty), it means that the call is not a derived call, there is no indirect call path, and cross-protocol call chain verification is not required; the allowed sub-determination result is directly output.

[0089] Step 1: Starting from the current security event node, traverse backwards along the incoming edges of the event graph to extract the complete call chain from the root node to the current node and obtain the call chain length of the complete call chain.

[0090] The total number of nodes from the root node to the current node is the call chain length. If the call chain length exceeds the preset depth limit (default is 5), it indicates that the nested call chain has too many levels, which may involve an excessively deep agent delegation chain and pose a risk of permission diffusion. The system will output a prohibited sub-decision result.

[0091] Step 2: Obtain the Agent Card information of the root node.

[0092] The root node is the top-level intelligent agent that initiates the entire call chain. The system extracts AgentCard fingerprint information from the security events of the root node.

[0093] Step 3: Use the Agent Card of the root node and the name of the tool called by the current node as the key to query the indirect call authorization table.

[0094] The indirect call authorization table records whether an agent is authorized to indirectly call the corresponding tool. That is, when agent A delegates a task to agent B via A2A, and agent B calls a certain MCP tool during task execution, the system needs to determine whether agent A is authorized to indirectly call that tool. For example, agent A itself may not be allowed to directly access the database, but it can delegate a task to agent B via A2A, and agent B can call a database query tool. In this case, the indirect call authorization table records whether (agent A's Agent Card, the database query tool) is permitted.

[0095] If the record corresponding to the key combination is unauthorized, the system outputs a prohibited sub-determination result.

[0096] Step 4: Identify the protocol conversion nodes in the call chain and count the number of protocol conversions.

[0097] Protocol conversion includes conversion between the A2A protocol and the MCP protocol. For example, an A2A task delegation may trigger an MCP tool call, or the MCP tool may return a result that triggers the A2A task to continue execution. If the number of protocol conversions exceeds the preset limit (default is 2 times), it indicates that the call chain has undergone multiple protocol conversions, which is an abnormal call mode, and the system will output a prohibited sub-determination result.

[0098] Step 5: If the record corresponding to the combination key in the indirect call authorization table is unauthorized, or the number of protocol conversions exceeds the preset limit, or the call chain length exceeds the preset depth limit, then output the prohibited sub-determination result; otherwise, output the allowed sub-determination result.

[0099] The system also checks whether the call chain length exceeds a preset depth limit. The call chain length is the total number of nodes from the root node to the current node. If the call chain length exceeds the limit, it indicates that the nested call chain has too many levels, which may involve an excessively deep agent delegation chain and pose a risk of permission diffusion. The system will then output a prohibited sub-decision result.

[0100] If any of the checks in steps 1 to 4 above fails, a prohibited sub-decision result is output; if all checks pass, an allowed sub-decision result is output.

[0101] (4) Behavioral risk control score.

[0102] Behavioral risk control scoring is executed only after the trusted tool list verification, Agent Card trust verification, and cross-protocol call chain verification have all passed. If any hard verification output is blocked, behavioral risk control scoring will not be executed.

[0103] Behavioral risk control scoring is a type of dynamic risk control software verification used to identify potential risks where a single call may appear legitimate, but the overall behavioral pattern is abnormal. This strategy performs multi-dimensional detection and outputs a comprehensive behavioral risk score based on the source address, tool name, and call time of the current security event, as well as the tool name in the predecessor node of the current event node obtained from the event graph.

[0104] Step 1: Maintain a behavior baseline table.

[0105] The behavior baseline table records at least the historical call information and historical tool combination information for the same source address calling the same tool.

[0106] Specifically, the table uses the combination of source address and tool name as the key to record historical behavior information of the same source address calling the same tool. The behavior baseline table contains two data dimensions: one is the hourly count of historical calls

[24] , which records the number of times the source address calls the tool in each hour of the day; the other is the historical tool combination information prev_tools, which records the set of tools that appeared before the source address called the tool and the number of times each tool appeared. The baseline table is continuously accumulated during the operation of the system and is updated after each event is processed.

[0107] Step 2: Obtain the source address, tool name, and call time of the current security event, and obtain the tool name of the predecessor node of the current event node from the event graph, and perform the following detection.

[0108] 1) Short-term high-frequency call detection: Count the number of events C in which the same source address s calls the same tool t within a preset time window W, and calculate the high-frequency call risk score R1 according to R1=min(100,(C / B_f)×S1).

[0109] If a large number of calls occur in a short period of time, it may indicate an automated attack or abnormal batch operation after the credentials have been stolen. The high-frequency call risk score R1 is calculated according to the formula R1=min(100,(C / B_f)×S1), where B_f is the preset high-frequency threshold, which represents the maximum number of calls allowed within the time window; S1 is the preset scaling factor used to map the ratio to a percentage system.

[0110] For example, when C reaches B_f, R1=50; when it reaches twice B_f, R1=100.

[0111] 2) Abnormal tool combination detection: with the tool name t_prev in the predecessor node of the current event taken as the preamble of the combination, query the historical tool combination set of tool t under the same source address s in the behavior baseline table, and obtain the number of occurrences P of t_prev among all historical predecessor tools of tool t and the total number of occurrences Tools_t of all predecessor tools; if P=0, then R2=V1; if P>0 and P / Tools_t<T_ratio, then R2=V2; if P>0 and P / Tools_t≥T_ratio, then R2=0, wherein V1 and V2 are preset risk scores with V1>V2, and T_ratio is a preset proportional threshold.

[0112] Specifically, if P=0, it indicates that the predecessor tool has never appeared before the current tool, which means the combination is an unprecedented tool combination with high risk, and R2=V1 is set; if P>0 and P / Tools_t<T_ratio, it indicates that although the tool combination has appeared in history, the occurrence probability is extremely low, which means the combination is a rare combination, and R2=V2 is set; if P>0 and P / Tools_t≥T_ratio, it indicates that the tool combination conforms to the normal historical mode, and R2=0.

[0113] For example, normally a user calls the "query order" tool first and then calls the "export data" tool. If a combination of calling the "delete user" tool first and then calling the "export data" tool occurs, this combination rarely appears in history, which triggers abnormal combination detection.

[0114] 3) Uncommon time period invocation detection: obtain the number of hours H corresponding to the current invocation time, query the invocation times Hour_t of tool t in the H time period and the total historical invocation times TotalHour_t under the same source address s in the behavior baseline table; if TotalHour_t<T_min, then R3=0; if Hour_t=0, then R3=V3; if Hour_t / TotalHour_t<T_period, then R3=V4; otherwise R3=0, wherein T_min is a preset minimum sample threshold, V3 and V4 are preset risk scores with V3>V4, and T_period is a preset time period proportion threshold.

[0115] Specifically, if TotalHour_t < T_min, it indicates that there are insufficient historical samples of the tool being called by the source address, and meaningful time-period analysis cannot be performed, so R3 is set to 0; if Hour_t = 0, it indicates that there has never been any call record in this time period, which means the call occurs in an infrequent time period, so R3 is set to V3; if Hour_t / TotalHour_t < T_period, it indicates that the proportion of calls in this time period is extremely low, so R3 is set to V4; otherwise R3 is set to 0. Wherein, T_min is a preset minimum sample threshold, V3 and V4 are preset risk scores with V3 > V4, and T_period is a preset time period proportion threshold. For example, the call records of a certain database tool show that its calls are concentrated in working hours (9:00-18:00), and there has never been any call record at 3 o'clock in the early morning. If a call occurs at this time, the infrequent time period detection will be triggered.

[0116] Step 3: Perform weighted summation of each risk score to obtain the comprehensive behavior risk score R, that is R = W1×R1 + W2×R2 + W3×R3, wherein W1, W2 and W3 are preset weight coefficients.

[0117] For example, W1 = 0.4, W2 = 0.4, W3 = 0.2. When R < 40, the risk value is low, and the sub-decision result is allow; when 40 ≤ R < 70, the risk value is relatively high, and the sub-decision result is audit; when R ≥ 70, the risk value is very high, and the sub-decision result is block.

[0118] (5) Sensitive data detection.

[0119] Sensitive data detection is performed after the trusted tool list check, Agent Card trust check and cross-protocol call chain check all pass. If any hard check outputs a block result, the sensitive data detection will not be performed.

[0120] Sensitive data detection belongs to dynamic risk control soft check, which is used to detect sensitive data leakage risk on the request side and the response side. This strategy takes the current security event node as the analysis object, reads the messages on the request side and the response side, then performs sensitive data matching detection, and outputs the sub-decision result of sensitive data detection.

[0121] Step 1: Maintain a sensitive data rule base, wherein the sensitive data rule base includes sensitive data keywords and their corresponding scores.

[0122] The sensitive data rule base SensRuleLib contains a plurality of sensitive data rules, and each rule includes a sensitive data keyword or pattern (such as ID card numbers, mobile phone numbers, bank card numbers, account passwords, etc.) and a corresponding risk score. The sensitive data rule base can be configured and updated according to the actual data security policy of the enterprise.

[0123] Step 2, request-side detection: extract a parameter summary from the current security event as the text to be detected, match the text to be detected with each rule in the sensitive data rule base, sum the scores corresponding to the hit rules and cap the sum at a preset upper limit to obtain a request-side sensitivity score; output a request-side sub-decision result according to the comparison result between the request-side sensitivity score and a preset threshold.

[0124] Wherein, the preset thresholds include a first preset threshold and a second preset threshold, and the first preset threshold is greater than the second preset threshold; when the sensitivity score exceeds the first preset threshold, the sub-decision result is blocking; when the sensitivity score exceeds the second preset threshold but does not exceed the first preset threshold, the sub-decision result is auditing; otherwise, the sub-decision result is allowing.

[0125] Specifically, the system extracts the parameter summary parameter_digest from the current security event as the text to be detected. For the MCP protocol, data is extracted from the params.arguments structure; for the A2A protocol, data is extracted from the text, file, and data fields in params.parts. The text to be detected is sequentially matched with each rule in the sensitive data rule base, all hit rules and their corresponding scores Sn are recorded, and the request-side sensitivity score is calculated by the following formula: S_req=min(100, ΣS_n) That is, sum the scores of all hit rules, and cap the sum at the preset upper limit of 100. The request-side sub-decision result is output according to the comparison result between S_req and the preset threshold.

[0126] For example, if S_req>70, the sub-decision result is blocking; if 40<S_req≤70, the sub-decision result is auditing; if S_req≤40, the sub-decision result is allowing.

[0127] Step 3, response-side detection: extract a response summary from the current security event as the text to be detected, match the text to be detected with each rule in the sensitive data rule base, sum the scores corresponding to the hit rules and cap the sum at a preset upper limit to obtain a response-side sensitivity score; output a response-side sub-decision result according to the comparison result between the response-side sensitivity score and the preset threshold.

[0128] Specifically, the system extracts the response summary response_digest from the current security event as the text to be detected. For the MCP protocol, data is extracted from the result.content structure; for the A2A protocol, data is extracted from result.parts and result.artifacts. The calculation method of the response-side sensitivity score S_resp is consistent with that of the request-side: S_resp=min(100, ΣS_n) The threshold determination logic is the same as that on the request side, and the sub-determination result is output on the response side.

[0129] Step 4: When the response is a streaming transmission, maintain an incremental cache and a sliding window for each streaming session. Whenever a new data block is received, it is appended to the cache. When the cached data volume reaches the preset window size, extract the content of the current window as the text to be detected. Match the text to be detected with each rule in the sensitive data rule base. Add the scores corresponding to the matched rules and cap them with a preset upper limit to obtain the sensitivity score of the current window. Accumulate the sensitivity scores of each window and cap them with a preset upper limit to obtain the cumulative sensitivity score. Based on the comparison result of the cumulative sensitivity score and the preset threshold, output the streaming response sub-judgment result.

[0130] Specifically, when the streaming flag `chunked_flag` in a security event is true, the response is streamed. In a streaming response, sensitive data often appears in subsequent segments rather than the first. If detection is performed only after the complete response has been received, the sensitive data may have already been partially or completely leaked. Therefore, the system employs incremental caching and a sliding window mechanism to perform real-time detection during response transmission.

[0131] The system maintains a streaming detection state structure for each streaming session, which includes the following fields: session_id: Session identifier; buffer: Incremental buffer, which accumulates bytes that have been received but have not yet completed window matching; window_ptr: A window pointer that points to the starting position of the next window to be processed in the buffer; S_stream: Cumulative streaming sensitivity score, initially set to 0.

[0132] Set the sliding window size to W_size (e.g., 2048 bytes). Whenever a session receives a new data chunk, the system performs the following processing: a) Extract the data block content and append it to the buffer; b) When len(buffer) - window_ptr > W_size, extract the current window content W_content = buffer[window_ptr : window_ptr + W_size]; c) Take W_content as the text to be detected, match it with each rule in the sensitive data rule base, record all the matched rules and their corresponding scores Sn, and calculate the current window sensitivity score according to the following formula: S_window=min(100,ΣS_n); d) Update the cumulative streaming sensitivity score: S_stream=min(100, S_stream+S_window); e) Move the window pointer: window_ptr=window_ptr+W_size; f) Repeat steps b to e until all data blocks are processed.

[0133] For example, a streaming response contains 10 data blocks, and sensitive data appears in the 7th data block. When the 7th data block arrives, the system extracts window content containing this data block through a sliding window for matching, detects the sensitive data immediately and updates the cumulative score, without waiting for the 8th to 10th data blocks to arrive before performing detection. This enables the system to trigger blocking before the sensitive data is completely leaked.

[0134] After the streaming response processing is completed, the sub-judgment result of the streaming response is output according to the comparison result between the cumulative sensitivity score S_stream and a preset threshold.

[0135] By way of example, if S_stream>70, the sub-judgment result is blocking; if 40<S_stream≤70, the sub-judgment result is auditing; if S_stream≤40, the sub-judgment result is allowing.

[0136] In step 5, if any sub-judgment result is blocking, the final sub-judgment result is blocking; if there is no blocking result and any sub-judgment result is auditing, the final sub-judgment result is auditing; if all sub-judgment results are allowing, the final sub-judgment result is allowing.

[0137] Trusted tool list verification, Agent Card trust verification and cross-protocol call chain verification are hard verifications. When any hard verification outputs blocking, subsequent soft verifications will not be executed, and the system directly outputs blocking. After all hard verifications are passed, two soft verifications, namely behavior risk control scoring and sensitive data detection, are executed. After each executed policy sub-unit independently outputs a sub-judgment result, the system makes a comprehensive decision according to the rule of blocking first, then auditing, and allowing last.

[0138] SS500, Decision and Execution.

[0139] In step SS500, the final judgment result output by the security policy engine is received, and corresponding disposal actions are executed according to the judgment result, including allowing, auditing or blocking, and the disposal result is recorded in an audit log.

[0140] Specifically, when the final judgment result is allowing, the system forwards the request normally to the target MCP server or A2A server, or returns the response normally to the client, and the communication link is not affected.

[0141] When the final determination is an audit, the system allows the request or response, but generates a high-priority audit log, recording the specific policy that triggered the audit and the risk score, for the security administrator to review later. See step SS600 for details on the audit log content.

[0142] When the final determination result is blocking, the system performs the corresponding blocking action according to the protocol type: For MCP protocol requests, the system returns a JSON-RPC error object. The error code uses a custom code within the range of standard JSON-RPC error codes. The error message is a general prompt, such as "The request has been blocked by the security policy", without exposing the specific details of the rule being hit. For A2A protocol requests, the system returns a task rejection, task failure, or policy prohibition status. Specifically, the corresponding status code is set in the status field of the A2A response message to indicate that the task is prohibited from execution due to security policies. In the event of a blockage in a streaming response, the system immediately terminates the connection upon detecting sensitive data, stops transmitting subsequent data blocks to the client, and returns a correctly formatted error JSON fragment to the client to help the client application identify the exception and handle it gracefully.

[0143] During the blocking process, the system adheres to the principle of minimal information disclosure, returning only general error messages to the client without any details regarding specific rules, sensitive data content, or policy configurations. All detailed rule hit information, sensitive data matching records, and handling basis are stored in the audit backend, accessible to security administrators through an internal management interface, preventing attackers from probing the boundaries of security policies by analyzing error feedback.

[0144] It should be noted that the "blocking" action in step SS500 only applies to requests or responses identified as MCP / A2A protocols that fail the security policy assessment. For packets identified as non-MCP / A2A protocol traffic and directly passed through in step SS130, their communication is not affected by step SS500, and they continue to be forwarded normally along the original path.

[0145] SS600, audit log records.

[0146] In step SS600, audit events are recorded in an append-only manner for use in tracing security events, compliance auditing, and policy optimization.

[0147] Specifically, after step SS500 executes the handling action, the system assembles the key information of this security incident into an audit record and stores it in the audit log by appending it. Each audit record contains at least the following fields: The four-tuple information consists of the source address, destination address, source port, and destination port, used to identify the two communicating parties. Protocol type: MCP, A2A, or A2A-derived MCP call; Protocol confidence: The MCP confidence C_mcp and A2A confidence C_a2a calculated in step SS120; Agent Card Fingerprint: Agent Card fingerprint information in the A2A protocol message (if applicable); Tool Name: The tool name requested by the MCP protocol (if applicable); Skill Name: The skill name requested by the A2A protocol (if applicable); Parameter Summary: A summary of the request parameters; Response Summary: A summary of the response results; Call chain identifier: The call chain identifier (call_chain_id) of this event in the event graph; Parent event identifier: the event_id of the parent node of this event (if it exists); Risk scoring: Risk scores output by each strategy submodule and overall risk score; Actions to take: Permission, audit, or block; Policy Version: The version number of the security policy on which this determination is based.

[0148] When recording audit logs, the system performs anonymization on fields containing sensitive data. Specifically, for content that matches the sensitive data rule base, the system replaces all or part of the sensitive data characters with generic placeholders, retaining sufficient information for source tracing analysis while reducing the security risk of the audit logs themselves being leaked.

[0149] The system ensures the integrity and immutability of audit logs through digital signatures. Specifically, the system calculates a hash value for each audit record and signs it using the system's private key. Each record stores the hash value of the previous record, forming a blockchain-like chain structure. Any modification to the historical record will cause the hash values ​​of subsequent records to mismatch, thus being detected by the system.

[0150] Audit logs are stored in a structured format (such as JSON) for easy retrieval and analysis by security analysis tools. Audit logs can be queried through the management interface, allowing security administrators to perform post-incident tracing, security incident analysis, and policy optimization.

[0151] The system allows administrators to periodically review false alarms or missed alarms in the audit logs. When a false alarm is detected, the administrator can adjust the corresponding policy parameters, such as behavioral risk control thresholds and sensitive data rules. The system supports hot-loading the updated policy configuration without restarting the service, enabling policy optimization to take effect quickly.

[0152] The foregoing has described in detail an embodiment of a method for controlling large model tool calls. Based on the large model tool call control method described in the above embodiment, this invention also provides a large model tool call control system corresponding to the method.

[0153] Figure 3 This is a schematic block diagram of a large model tool invocation control system provided in an embodiment of the present invention. In this embodiment, the large model tool invocation control system can be divided into multiple functional modules according to the functions it performs. A module, as referred to in this invention, is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory.

[0154] The protocol identification module is used to capture HTTP request and response messages between the large model agent client and the MCP server and A2A server, extract protocol feature vectors from the HTTP message headers and HTTP message bodies, calculate the MCP confidence and A2A confidence based on the protocol feature vectors, and determine the timing of whether an MCP protocol call occurs after the A2A protocol traffic, thereby identifying MCP protocol traffic, A2A protocol traffic, and A2A derived MCP call traffic.

[0155] The protocol parsing module is used to map the raw fields in the protocol messages of the identified traffic into a standardized security event based on a unified security event model.

[0156] The event graph construction module is used to incrementally update the cross-protocol tool call event graph, using the currently mapped security events as nodes and the call relationships between security events as directed edges, and to establish parent-child call relationships and call chain identifiers between security events.

[0157] The security decision module is used to perform security policy judgments on the currently mapped security events using an event graph, output the judgment results for the current security events, perform allow, audit, or block actions based on the judgment results, and record audit logs in an append-only manner; the security policies include at least one or more of the following: trusted tool list verification, Agent Card trusted verification, sensitive data detection, cross-protocol call chain verification, and behavioral risk control scoring.

[0158] The large model tool call control system in this embodiment is used to implement the aforementioned large model tool call control method. Therefore, the specific implementation of this system can be found in the embodiment section of the large model tool call control method above. Thus, the specific implementation can be referred to the description of the corresponding embodiments, and will not be elaborated here.

[0159] In addition, since the large model tool call control system in this embodiment is used to implement the aforementioned large model tool call control method, its function corresponds to the function of the above method, and will not be repeated here.

[0160] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for controlling the invocation of large model tools, characterized in that, Includes the following steps: Capture HTTP request and response messages between the large model intelligent agent client and the MCP server and A2A server, and extract protocol feature vectors from the HTTP message headers and HTTP message bodies of the messages; according to The protocol feature vectors are used to calculate the MCP confidence and A2A confidence, as well as the timing determination result of whether an MCP protocol call occurs after the A2A protocol traffic, thereby identifying MCP protocol traffic, A2A protocol traffic, and A2A derived MCP call traffic. Based on a unified security event model, the original fields in the protocol messages of the identified traffic are mapped to a standardized security event; Using the currently mapped security events as nodes and the call relationships between security events as directed edges, incrementally update the cross-protocol tool call event graph to establish parent-child call relationships and call chain identifiers between security events; The system performs security policy judgments on the currently mapped security events using the event graph, outputs the judgment results for the current security events, and performs allow, audit, or block actions based on the judgment results, and records the audit logs in an append-only manner; the security policies include at least one or more of the following: trusted tool list verification, Agent Card trusted verification, sensitive data detection, cross-protocol call chain verification, and behavioral risk control scoring.

2. The method for controlling the invocation of large model tools according to claim 1, characterized in that, The protocol features in the protocol feature vector are classified into strong and weak features, where: Strong features belonging to the MCP protocol include: the HTTP message header contains the mcp-session-id field; the HTTP message body contains a JSON-RPC format method field that belongs to the MCP method set; Strong characteristics belonging to the A2A protocol include: the HTTP message path is the path to obtain AgentCard information; the HTTP message body contains a JSON object conforming to the AgentCard format; Weak features belonging to the MCP protocol include: the HTTP message body contains an MCP response message structure; Weak features belonging to the A2A protocol include: the HTTP message body contains an A2A request message structure or an A2A response message structure; Weak features shared by the MCP and A2A protocols include: HTTP message bodies conforming to the JSON-RPC format.

3. The method for controlling the invocation of large model tools according to claim 2, characterized in that, Based on the protocol feature vectors, the MCP confidence score and A2A confidence score are calculated respectively, along with the timing determination result of whether an MCP protocol call occurs after the A2A protocol traffic. This identifies MCP protocol traffic, A2A protocol traffic, and A2A-derived MCP call traffic, specifically including: For the current request message, count the number of strong features n_mcp and the number of weak features m_mcp belonging to the MCP protocol in the protocol feature vector of the message, and the number of strong features n_a2a and the number of weak features m_a2a belonging to the A2A protocol. Calculate the MCP confidence score C_mcp=n_mcp×W_s+m_mcp×W_w, and the A2A confidence score C_a2a=n_a2a×W_s+m_a2a×W_w, where W_s is the weight of the strong feature and W_w is the weight of the weak feature. If the protocol feature vector of the current message matches a strong feature belonging to the MCP protocol, and A2A protocol traffic has been identified in the historical messages of the same session, then the current call is identified as A2A derived MCP call traffic. Otherwise, compare C_mcp with the MCP threshold B_mcp. If C_mcp > B_mcp, it is identified as MCP protocol traffic. Compare C_a2a with the A2A threshold B_a2a. If C_a2a > B_a2a, it is identified as A2A protocol traffic. If the current message is not identified as MCP protocol traffic, A2A protocol traffic, or A2A derived MCP call traffic, it will be directly passed through.

4. The method for controlling the invocation of large model tools according to claim 1, characterized in that, Incremental update of cross-protocol tool call event graph, specifically including: A node table and an edge table are pre-maintained, wherein the node table is used to store all graph nodes and the edge table is used to store all directed edges; a hash index table is pre-maintained, wherein the hash index table contains at least an index structure that indexes graph nodes by session identifier, task identifier and event identifier respectively; When a new security event arrives, a new graph node is created for the new security event, and the identifier of the graph node is calculated. The identifier is generated by concatenating the session identifier, request identifier and timestamp in the security event and then calculating the hash value. The graph node stores the following information: inbound edge list, outbound edge list, call chain identifier and node depth. Find potential parent nodes and construct directed edges according to the following priority order: 1) If the parent session identifier in the security event is not empty, then search for the historical node corresponding to the parent session identifier in the node table. If found, then create a directed edge of type DERIVED_CALL from the parent node to the current node. 2) If no DERIVED_CALL edge is established and there are historical nodes with the same session identifier, then within the preset time window, the historical node with the largest timestamp is taken as the direct predecessor, and a directed edge of type SEQUENTIAL is established. 3) If a directed edge has not yet been established and the task identifier in the security event is not empty, then search for historical nodes with the same task identifier but different session identifiers in the node table and establish a directed edge of type TASK_FORK. Before establishing each directed edge, check whether the event graph forms a cycle. If a cycle is formed, skip the establishment of the edge and record an alarm log. After establishing a directed edge, if the current node finds a parent node, the parent node's call chain identifier is assigned to the current node, and the depth of the current node is set to the parent node's depth plus 1; if the current node does not find any parent node, a new call chain identifier is created for the current node, and the depth is set to 0.

5. The method for controlling the invocation of large model tools according to claim 1, characterized in that, Trusted tool list verification is used to verify whether the tool information in the current security incident is in the preset trusted tool list; Agent Card trust verification is used to verify whether the Agent Card fingerprint and skill information in the current security incident is in the preset trusted agent directory.

6. The method for controlling the invocation of large model tools according to claim 1, characterized in that, Sensitive data detection specifically includes: Maintain a sensitive data rule base, which includes sensitive data keywords and their corresponding scores; Request-side detection: Extract parameter summaries from the current security event as the text to be detected, match the text to be detected with each rule in the sensitive data rule base, add up the scores corresponding to the matched rules and cap them with a preset upper limit to obtain the request-side sensitivity score; output the request-side sub-judgment result based on the comparison result between the request-side sensitivity score and the preset threshold. Response-side detection: Extract the response summary from the current security event as the text to be detected, match the text to be detected with each rule in the sensitive data rule base, add up the scores corresponding to the matched rules and cap them with a preset upper limit to obtain the response-side sensitivity score; output the response-side sub-judgment result based on the comparison result between the response-side sensitivity score and the preset threshold. When the response is a streaming transmission, an incremental cache and a sliding window are maintained for each streaming session. Whenever a new data block is received, it is appended to the cache. When the cached data volume reaches the preset window size, the content of the current window is extracted as the text to be detected. The text to be detected is matched with each rule in the sensitive data rule base. The scores corresponding to the matched rules are added together and capped at a preset upper limit to obtain the sensitivity score of the current window. The sensitivity scores of each window are accumulated and capped at a preset upper limit to obtain the cumulative sensitivity score. Based on the comparison result of the cumulative sensitivity score and the preset threshold, the streaming response sub-judgment result is output. If any sub-decision result is blocking, then the final sub-decision result is blocking; if there is no blocking and any sub-decision result is auditing, then the final sub-decision result is auditing; if all sub-decision results are allowing, then the final sub-decision result is allowing. The preset thresholds include a first preset threshold and a second preset threshold, with the first preset threshold being greater than the second preset threshold. When the sensitivity score exceeds the first preset threshold, the sub-determination result is blocking; when the sensitivity score exceeds the second preset threshold but does not exceed the first preset threshold, the sub-determination result is auditing; otherwise, the sub-determination result is allowing.

7. The method for controlling the invocation of large model tools according to claim 1, characterized in that, Cross-protocol call chain detection is performed on security events that pass trusted tool manifest verification and Agent Card trusted verification.

8. The method for controlling the invocation of large model tools according to claim 7, characterized in that, Cross-protocol call chain verification specifically includes: Starting from the current security event node, traverse backwards along the incoming edges of the event graph to extract the complete call chain from the root node to the current node and obtain the call chain length of the complete call chain. Obtain the Agent Card information of the root node; Using the Agent Card of the root node and the name of the tool called by the current node as the key, query the indirect call authorization table, which is used to record whether the agent is authorized to indirectly call the corresponding tool; Identify protocol conversion nodes in the call chain and count the number of protocol conversions, including conversions between A2A protocol and MCP protocol; If the record corresponding to the combination key in the indirect call authorization table is unauthorized, or the number of protocol conversions exceeds the preset limit, or the call chain length exceeds the preset depth limit, then output a prohibited sub-decision result; otherwise, output an allowed sub-decision result.

9. The method for controlling the invocation of large model tools according to claim 1, characterized in that, Behavioral risk control scoring specifically includes: Maintaining a behavior baseline table, wherein the behavior baseline table at least records historical call information and historical tool combination information of the same tool called by the same source address; Acquiring the source address, tool name and call time in the current security event, and acquiring the tool name in the precursor node of the current event node from an event graph, and performing the following detection: 1) Short-time high-frequency call detection: counting the number of events C that the same source address s calls the same tool t within a preset time window W, and calculating the high-frequency call risk score R1 according to R1=min(100,(C / B_f)×S1), wherein B_f is a preset high-frequency threshold, and S1 is a preset scaling factor; 2) Abnormal tool combination detection: taking the tool name t_prev in the precursor node of the current event as the combination preorder, querying the historical tool combination set of the tool t under the same source address s in the behavior baseline table, and acquiring the number of occurrences P of t_prev among all historical precursor tools of the tool t and the total number of occurrences Tools_t of all precursor tools; if P=0, then R2=V1; if P>0 and P / Tools_t<T_ratio, then R2=V2; if P>0 and P / Tools_t≥T_ratio, then R2=0, wherein V1 and V2 are preset risk scores satisfying V1>V2, and T_ratio is a preset proportional threshold; 3) Uncommon time period call detection: acquiring the number of hours H corresponding to the current call time, querying the number of calls Hour_t of the tool t under the same source address s in the H time period and the total historical number of calls TotalHour_t in the behavior baseline table; if TotalHour_t<T_min, then R3=0; if Hour_t=0, then R3=V3; if Hour_t / TotalHour_t<T_period, then R3=V4; otherwise R3=0, wherein T_min is a preset minimum sample threshold, V3 and V4 are preset risk scores satisfying V3>V4, and T_period is a preset time period proportion threshold; Performing weighted summation on each risk score to obtain R=W1×R1+W2×R2+W3×R3, so as to obtain a comprehensive behavior risk score R, wherein W1, W2 and W3 are preset weight coefficients.

10. A large model tool call control system, characterized in that, Comprising: a protocol identification module, configured to capture HTTP request and response messages between a large model agent client and an MCP server and an A2A server, and extract protocol feature vectors from the HTTP header and HTTP body of the messages; According to the protocol feature vectors, calculating MCP confidence and A2A confidence respectively, and obtaining a timing determination result of whether an MCP protocol call occurs after A2A protocol traffic, so as to identify MCP protocol traffic, A2A protocol traffic and A2A-derived MCP call traffic; a protocol parsing module, configured to map original fields in the protocol messages of the identified traffic into a standardized security event based on a unified security event model; The event graph construction module is used to incrementally update the cross-protocol tool call event graph, with the currently mapped security events as nodes and the call relationships between security events as directed edges, and to establish parent-child call relationships and call chain identifiers between security events. The security decision module is used to perform security policy judgments on the currently mapped security events using an event graph, output the judgment results for the current security events, perform allow, audit, or block actions based on the judgment results, and record audit logs in an append-only manner; the security policies include at least one or more of the following: trusted tool list verification, Agent Card trusted verification, sensitive data detection, cross-protocol call chain verification, and behavioral risk control scoring.

Images