Dynamic authorization multi-protocol gateway method and system for agent operating system

Abstract

The application discloses a dynamic authorization multi-protocol gateway method and system for an intelligent agent operating system, and relates to the technical field of information security. The gateway is a unified access entrance of the intelligent agent, plug-in, MCP service and deployment application, receives a request carrying a resource dynamic code and verifies the source, and derives a unified authorization context containing the caller identity, subscription relationship, data authority range, tool authorization set and revocation version number by taking the resource dynamic code as a unique authorization anchor point; a session identifier is generated when the MCP event stream is accessed, the real message address is rewritten as the gateway proxy address and written into the structured session mapping, and the subsequent message and tool call reload the same authorization context according to the session identifier instead of the trusted client input value, the server controlled parameter is injected or covered according to the source, and the revocation version number is changed, and each protocol processing stage is synchronously invalidated. The application forms a secure boundary which is consistent across protocols and can be uniformly revoked while hiding the real address.

Description

Technical Field

[0001] This invention relates to the fields of network communication and information security technology, and in particular to a dynamic authorization multiprotocol gateway method and system for intelligent agent operating systems. Background Technology

[0002] With the development of intelligent agent platforms and tool calling ecosystems, internal enterprise applications need to uniformly publish knowledge bases, plugins, model capabilities, MCP services, and custom deployment applications to callers. These callers may be front-end pages, third-party platforms, intelligent agent runtimes, MCP clients, or other business systems, each with different protocol formats and access methods, including intelligent agent sessions, plugin HTTP calls, MCP SSE, MCP streamable HTTP, and web resources for deployment applications.

[0003] Existing technologies typically use the following methods for access: First, providing a separate HTTP interface for the agent service; second, providing a separate plugin call interface for the plugin service; third, directly exposing the SSE or HTTP address for the MCP service; fourth, exposing the access address for deployed applications through Nginx, Ingress, or container port mapping; and fifth, implementing forwarding logic separately for file downloads, web static resources, and streaming responses.

[0004] The above methods have significant shortcomings. First, the real service address is easily leaked, especially in the real message address returned during the MCP SSE handshake phase, container port mappings, and absolute paths of web resources. Callers can use this information to bypass the gateway and directly access downstream applications, leading to internal topology leaks and unauthorized access. Second, authentication, rate limiting, auditing, and parameter validation are scattered across different modules, making it difficult to form a unified security boundary. Furthermore, governance logic is repeatedly implemented for each type of resource, resulting in inconsistent behavior. Third, the standard MCP SSE service may return the real message address during the handshake phase. Subsequent client messages are sent via this address. Without proxy rewriting, subsequent messages will no longer pass through a unified gateway, rendering authentication, rate limiting, parameter policies, and log auditing ineffective. Fourth, parameters in MCP tool call requests may be forged, missing, or exceed the authorized scope by the caller. Relying solely on front-end validation or simple format validation cannot meet server-side security governance requirements. Fifth, downstream response types are heterogeneous, potentially returning JSON, SSE, HTML, CSS, JavaScript, SVG, binary files, or downloaded attachments. Using a single forwarding logic for pass-through can easily lead to encoding errors, abnormal file downloads, unrewritten web resource addresses, or missing security response headers. Sixth, the actual runtime address of containerized applications usually changes with image deployment and port mapping. The external access address needs to be decoupled from the actual runtime address and dynamically generated by the server.

[0005] Even if dynamic codes or session identifiers are used instead of real addresses, if the dynamic code is not bound to the request source, caller identity, or authorization context, and if it is not restricted to one-time use, sliding validity period, active revocation, and replay protection, it can still be reused by any client once leaked. If the session identifier is only used as a regular random identifier without binding to client characteristics, limiting the frequency of messages in a single session, or verifying message order or time window, it can be guessed, intercepted and replayed, or abused frequently. Therefore, it is necessary to provide a unified gateway engine that integrates the above-mentioned different types of backend capabilities into a single access point, hides the real address through dynamic authorization and proxy conversion, and completes protocol adaptation, parameter verification, response processing, and security governance at the gateway layer, while enabling all protocol stages to share the same trusted authorization basis and revocation to be consistent. Summary of the Invention

[0006] To address the problems in existing technologies such as easy leakage of real addresses, duplicate trust of clients at protocol boundaries, difficulty in consistent authorization revocation, lack of server-side mandatory verification of tool parameters, and inconsistent handling of heterogeneous responses, this invention proposes a dynamic authorization multi-protocol gateway method for intelligent agent operating systems. The gateway serves as a unified access point for intelligent agents, plug-in services, MCP services, and containerized deployment applications. Its features include: Receive an access request carrying a resource dynamic code, query the dynamic code record corresponding to the resource dynamic code, and perform existence verification, validity period verification, and source constraint verification on the dynamic code record; After verification, the resource dynamic code is used as the unique authorization anchor point to derive a trusted unified authorization context for the server in one go. The unified authorization context includes the caller identity, tenant, subscription relationship, data permission scope, tool authorization set and revocation version number. When the access request is an MCP event stream access, a session identifier is generated, the real message address returned by the downstream is replaced with the gateway proxy address carrying the session identifier and returned to the client, and the identifier of the unified authorization context and the revocation version number are written into the structured session mapping with the session identifier as the key; When subsequent message requests or tool call requests arrive based on the session identifier, the same unified authorization context is reloaded, and the identity and server-controlled parameters carried in the request are not trusted. For the tool invocation request, the tool visibility is determined based on the tool authorization set, and the server-side controlled parameters are injected or overwritten from the unified authorization context according to the source and then forwarded to the real downstream address; When the revocation version number changes, all protocol processing stages bound to the same unified authorization context are synchronously disabled.

[0007] Furthermore, injecting or overriding server-side controlled parameters from the unified authorization context by source includes: Configure constraint type, control type, client value processing action and missing value processing action for each parameter of the tool. The constraint type includes parameter type validation, enumeration value validation, numerical or length range validation, regular expression validation and Boolean rule validation. The control type identifies whether the parameter is a server-controlled parameter. When the request body of the tool call request is missing a server-controlled parameter and the missing value handling action is injection, the server-controlled parameter is completed from the unified authorization context, the subscription relationship or the server configuration according to the value source, and the corresponding value passed by the caller is not accepted; When the request body carries server-controlled parameters, it is processed according to the client value processing action: if it is to be overwritten, the value passed by the caller is replaced with a trusted value in the unified authorization context; if it is to be discarded, the parameter is deleted and not passed down downstream; if it is to be rejected, forwarding is terminated and a parameter policy error is returned; if it is to be retained, the constraint type is first executed and the value passed by the caller is retained after passing the constraint type validation. When the client-side value processing action is not explicitly configured, if the independent processing identifier of the parameter is strict and it is a server-controlled parameter, the tool call request is rejected; otherwise, the default processing action is derived according to the sensitivity level of the parameter, where highly sensitive parameters are rejected by default, sensitive parameters are overridden by default, and ordinary parameters are retained by default. The policy hit log records the overwrite, discard, reject and injection processing actions. The policy hit log only saves the parameter name, policy identifier, processing action and source, and does not record the plaintext value of sensitive parameters.

[0008] Furthermore, the dynamic code record stores an irreversible digest of the allowed source IP, network segment, or caller exit rules, as well as client characteristics; The source constraint verification includes comparing the request's source IP and device fingerprint with the source identifier bound to the dynamic code record, respectively; When the dynamic code record is configured for one-time use, the usage flag of the dynamic code record is changed from unused to used by database condition update or cache atomic script. If the condition update fails, it is determined that it has been consumed and an unauthorized error is returned. When the dynamic code record is configured with a sliding validity period, a cache structure with an expiration time is used to store the most recent access time. After each successful verification, the most recent access time and the expiration time are refreshed if the maximum validity period has not been exceeded. If the maximum validity period has been exceeded, the cache is deleted and access is denied. When the dynamic code record is actively revoked, the server increases the revocation version number and publishes a revocation event. After receiving the revocation event, each gateway instance clears its local dynamic code cache, session mapping cache, and rate limiting window cache. Gateway instances that do not receive the revocation event complete the failure propagation by comparing the revocation version number.

[0009] Furthermore, the structured session mapping stores the real message address, MCP service identifier, dynamic code record identifier, gateway instance identifier holding long-lived event stream connection, connection identifier, creation time, expiration time, client feature summary, message sequence number, and session state in key-value or document form; The gateway instance that generates the session identifier stores the connection index from the connection identifier to the actual event stream output object within the process, and the connection index is not used as a cross-instance shared state; When the subsequent message request reaches the gateway instance that does not hold the long connection, the gateway instance reads the structured session mapping based on the session identifier, queries the internal network address of the holding instance based on the gateway instance identifier, and forwards the original message, the session identifier, the connection identifier, and the caller identity digest to the holding instance through the internal forwarding interface that only allows intranet or inter-service authentication calls. The holding instance then verifies the session state, client characteristics, message sequence number, and local connection index again before writing the response back to the long connection.

[0010] Furthermore, replacing the real message address returned by the downstream with the gateway proxy address includes: The gateway identifies event type fields and data fields according to the event popularity protocol, and is compatible with spaces, case differences and multi-line data fragments in the fields; For real message addresses with absolute addresses in the data field, verify whether their protocol, host, and port are consistent with the authorized MCP service target or meet the whitelist rules; For real message addresses that are relative paths or only carry query strings, normalization is performed based on the configuration address of the MCP service or the target address of the current long connection, and the path, query string and encoded characters are merged to form a complete real message address; Then, the normalized real message address is uniformly replaced with the gateway proxy address carrying the session identifier, and the real message address is written into the structured session mapping.

[0011] Furthermore, when a plugin application identifier exists in the configuration of the MCP service, the tool invocation request or tool list request is transferred to the plugin adaptation process, including: Map the tool code of the plug-in tool to the name of the MCP tool, map the name and purpose description of the plug-in tool to the description of the MCP tool, convert the code, data type, enumeration value, default value and length or range constraint of the plug-in input parameter into the attributes of the MCP tool input mode, and generate a list of required fields of the input mode according to the required field identifier of the plug-in input parameter. When the plugin input parameters include objects or array objects, the properties of the nested object are recursively generated based on the correspondence between the parent field identifier and the parent field alias of the subfield record, and the required subfields within the nested object are written into the required field list of the nested object.

[0012] Furthermore, when the tool call request declares asynchronous execution, the plugin adaptation process creates a task record and immediately returns a success response carrying the task identifier and execution status after the parameter verification is passed. Then, the background thread executes the real plugin and updates the task status between pending execution, in execution and final state. In polling mode, the client queries the task based on the polling address in the success response. If the task is not completed, the client returns the task identifier, status and progress. If the task is completed, the client also returns the execution result. If the task fails, the client also returns the error information. In callback mode, the server only accepts pre-registered or signature-verified callback targets. After the task enters the final state, it sends a callback request carrying the task identifier, callback identifier, status and result to the callback address. The receiver performs idempotent deduplication based on the callback identifier. If the callback fails, it retryes according to the backoff strategy and retains the polling address for the client to obtain the final state.

[0013] Furthermore, after forwarding to the actual downstream address, the method reads the content type of the downstream response and selects a response strategy that matches the content type from multiple response strategies through a response strategy factory. For event stream types, maintain a long connection and perform the proxy address replacement on the message address events within it; For JSON types, read the normal response stream and the error response stream respectively and process the compressed content; For text-based web page resources, replace the actual downstream base address with the gateway proxy base address; For download types, copy the necessary response headers and supplement them with content sniffing protection headers, cache control headers, and secure content handling headers, and write the file content back in a buffered stream manner; If no exact matching response strategy exists, fall back to the fallback response strategy.

[0014] Furthermore, it also includes adaptive authorization governance based on multi-dimensional risk signals: Risk signals are collected within the unified entry point and session lifecycle. These risk signals include the deviation between the request source and the source identifier bound to the dynamic code record, device fingerprint drift, deviation of call frequency per unit time, parameter policy hit frequency, message sequence number rollback frequency, and downstream error rate. The risk signals are weighted and aggregated into a real-time risk score based on subscription and session dimensions, and then mapped to a risk level using a sliding time window and a decay factor. The authorization strength, parameter policy strictness, rate limiting threshold, session validity period and handshake requirements are dynamically adjusted according to the risk level. Under the high risk level, a re-handshake is required, the session identifier is suspended or the revocation version number is increased. The parameter policy hit logs, risk score changes, and session exception events are fed back to the system, and the call frequency baseline and default processing actions are automatically adjusted according to the subscription.

[0015] A dynamic authorization multi-protocol gateway system for an intelligent agent operating system, used to implement the aforementioned dynamic authorization multi-protocol gateway method for the intelligent agent operating system, includes: The dynamic authorization code module is used to query dynamic code records and perform existence, validity period and source constraint verification. The resource dynamic code corresponding to the dynamic code record is used as the unique authorization anchor point to derive a unified authorization context that includes caller identity, tenant, subscription relationship, data permission scope, tool authorization set and revocation version number in one go. The session proxy module is used to generate a session identifier when the MCP event stream is accessed, replace the downstream real message address with the gateway proxy address carrying the session identifier, and write the identifier of the unified authorization context and the revocation version number into a structured session mapping with the session identifier as the key. The parameter strategy module is used to reload the same unified authorization context based on the session identifier when subsequent message requests or tool call requests arrive, determine tool visibility based on the tool authorization set, and inject or overwrite server-side controlled parameters from the unified authorization context according to the source. The security governance module is used to synchronously disable all protocol processing stages bound to the same unified authorization context when the revocation version number changes.

[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention provides a dynamic authorization multi-protocol gateway method and system for intelligent agent operating systems, which hides the real service address. The caller can only access the gateway address in the form of dynamic code or session identifier, and cannot directly obtain the real address, intranet IP and port of intelligent agent, MCP service, plug-in service or deployed application.

[0017] 2. This invention provides a dynamic authorization multi-protocol gateway method and system for intelligent agent operating systems, ensuring that subsequent SSE messages of MCP pass through the gateway, and that authentication, rate limiting, parameter verification and log auditing remain effective through endpoint event rewriting and two-phase message brokering.

[0018] 3. This invention provides a dynamic authorization multi-protocol gateway method and system for intelligent agent operating systems. It derives a unified authorization context from a single authorization anchor point and uses it from the same source in each protocol stage, avoiding repeated trust of the identity and controlled parameters passed by the client at the protocol boundary, and drives consistent failure in each stage through a single revocation version number.

[0019] 4. This invention provides a dynamic authorization multi-protocol gateway method and system for intelligent agent operating systems, which provides server-side mandatory parameter policy verification, injects or overwrites server-side controlled parameters according to subscription relationships, tool definitions and parameter policies to prevent unauthorized access and illegal value retrieval; through multi-dimensional risk signal-driven adaptive governance, it has the ability to aggregate and process combined anomalies such as low-frequency probing after credential leakage, slow parameter unauthorization and scattered replay.

[0020] 5. This invention provides a dynamic authorization multi-protocol gateway method and system for intelligent agent operating systems. Existing plug-in applications do not need to implement the MCP server protocol separately, but can provide capabilities to the outside world in the form of MCP service through the gateway. The gateway is compatible with multiple response types such as JSON, SSE, Web resources and file downloads, reducing encoding anomalies, file download anomalies, Web resource path errors and missing security response headers. Attached Figure Description

[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the system architecture of the unified gateway engine of this invention; Figure 2 This is a flowchart illustrating the dynamic authorization code verification and unified authorization context derivation process of the present invention. Figure 3 This is a schematic diagram illustrating the process of MCP SSE endpoint rewriting and session mapping establishment in this invention. Figure 4 This is a schematic diagram illustrating the process of MCP message two-phase proxy and multi-instance session routing in this invention; Figure 5This is a schematic diagram of the server-side controlled parameter policy verification process of the present invention; Figure 6 This is a flowchart illustrating the process of selecting a response processing strategy based on content type according to the present invention. Detailed Implementation

[0023] The technical solution of the present invention will be more clearly and completely explained below with reference to the accompanying drawings and through the description of preferred embodiments of the present invention.

[0024] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and an implementation method based on a pingress gateway engine. This embodiment is only for explaining the invention and does not constitute a limitation on the scope of protection. All equivalent substitutions or modifications based on the same inventive concept should fall within the scope of protection of this invention.

[0025] like Figure 1 As shown, the gateway system in this embodiment uses a pingress as the entry gateway. The pingress is an independent Spring Boot application that enables Zuul proxy, service discovery, Feign client, Hystrix, Ribbon, and Undertow long-connection capabilities, and configures Undertow thread pool, buffer, request timeout, and long-connection related parameters. The gateway exposes a unified entry point and proxies specified paths to its own service through routing configuration. To ensure compatibility with the differences in error path handling between Spring Boot and Zuul, the gateway enhances the Zuul handler mapping after Bean initialization. This prevents incompatible method calls from being triggered when the request path is an error path, thereby improving the stability of gateway startup and exception handling.

[0026] The gateway system logically includes the following modules: a unified entry module, providing an HTTP entry point based on pingress; a dynamic authorization code module, used to generate, query, and verify resource dynamic codes, and derive a unified authorization context; an intelligent agent gateway module, providing an entry point in the form of / agent / {dynamicCode}, verifying the dynamic code and converting the call into an intelligent agent session service call and supporting streaming response write-back; an MCP gateway module, providing entry points in the form of / mcp / {dynamicCode} / {mcpServerCode} / sse, / mcp / {dynamicCode} / {mcpServerCode} / mcp, / mcp-servers / {mcpServerCode} / sse, / mcp-servers / {mcpServerCode} / mcp, and / mcp / message; and an MCP adaptation module, used for calibration... The application performs the following functionalities: MCP service record verification, MCP service address retrieval, merging database configuration request headers with the current request headers, and forwarding the request to the standard MCP service or the plugin MCP engine; SSE session proxy module, which identifies downstream SSE endpoint events, generates session identifiers, caches real endpoints, and returns the gateway proxy endpoint; parameter policy module, which performs server-side validation of MCP tool call requests at the subscription, tool, and parameter dimensions; plugin MCP adaptation module, which encapsulates plugin applications and plugin tools into JSON-RPC MCP services; response policy module, which selects response policies such as SSE, JSON, general web, and file download based on content type; application deployment proxy module, which dynamically generates the target address for application deployment based on application encoding, rule encoding, mirroring relationships, and host port mapping; and security governance module, which performs rate limiting, validity period verification, status verification, security response header setting, anomaly information convergence, log anonymization, and call log recording. These modules can be implemented by different processors within the same application.

[0027] When publishing or authorizing resources, the dynamic authorization code module first checks if a dynamic code for the same resource and authorized object already exists. If not, a new record is generated and saved. The dynamic code uses a random string that is difficult to predict, and the primary key of the record is generated using the snowflake algorithm. The dynamic code record includes resource ID, resource type, resource object ID, authorization type, authorized object, creator, creation time, dynamic code, validity start time, and validity end time.

[0028] To support source constraint verification, this implementation further stores allowed source IPs, network segments, or caller exit rules in the dynamic code record, and stores an irreversible digest of browser, terminal, or application instance characteristics in the call log table. It also stores the user ID, tenant ID, application ID, and digests of the authorization scope, subscription relationship, and data permission context to prevent clients from tampering with the authorization context. The source constraint verification includes comparing the requested source IP and device fingerprint with the source identifier bound to the dynamic code record.

[0029] like Figure 2 As shown, after a request enters the gateway, the controller reads the dynamic code from the path or request header. The dynamic code verification order is as follows: read the dynamic code from the path or request header; query the database record and Redis authorization cache; verify the existence of the record and the revocation version number; verify the fixed validity period; verify the source IP, caller identity, and authorization context digest; only after passing these steps are resource status verification, rate limiting, and routing performed. If the record is empty, an unauthorized response is returned; if the record contains a validity period, it is determined whether the current time is within the validity period, and if not, access is denied.

[0030] For dynamic codes configured for one-time use, a database conditional update or a Redis atomic script is used to change the used flag (used_flag) from unused to used. If the conditional update fails, it indicates that the dynamic code has been consumed, and the gateway returns an unauthorized error, thus preventing the dynamic code from being reused. For dynamic codes configured with a sliding expiration time, the sliding renewal data structure uses a Redis hash with a set TTL. After each successful verification, if the current time is still before the maximum expiration time (maxExpireTime), the last access time (lastAccessTime) and TTL are refreshed; if it exceeds maxExpireTime, the cache is deleted and access is denied.

[0031] When a dynamic code is actively revoked, the server writes revocation information to a set with the dynamic code record identifier as the key. This information includes the revocation version number (revokeVersion), the revocation reason (reason), the operator, the revocation time (revokeTime), and the expiration time (expireTime), and publishes a revocation event. Each gateway instance, upon receiving the revocation event, clears its local dynamic code cache, session mapping cache, and rate limiting window cache. Gateway instances that do not receive a revocation event complete failure propagation by comparing the revocation version number or by fetching compensation data in a short period. Therefore, the revocation version number becomes the single basis for driving consistent failure across all stages, corresponding to the characteristic that changes in the revocation version number cause synchronous failure across all protocol stages, as well as the failure propagation characteristics.

[0032] Based on the successful verification mentioned above, the dynamic authorization code module uses the resource dynamic code as the unique authorization anchor point to derive a trusted unified authorization context for the server in one go, and saves it as an authorization snapshot in the storage location auth:snapshot:{snapshotId} with the snapshot identifier as the key. The unified authorization context includes at least the snapshot identifier snapshotId, the dynamic code record identifier codeId, the tenant identifier tenantId, the user identifier userId, the organization code orgCode, the data permission scope dataScope, the subscription relationship identifier subscriptionId, the tool authorization set toolGrantSet, the source constraint sourceConstraint, the revocation version number revokeVersion, and the expiration time expireTime. The unified authorization context is derived once after the first entry and successful dynamic code verification. Subsequent stages such as intelligent agent conversation, MCP SSE handshake, two-phase messaging, tool invocation, and plugin tool discovery all reference the same authorization context with the snapshot identifier and the revocation version number, without re-trusting the identity and controlled parameters passed by the client at the protocol boundary.

[0033] like Figure 3 As shown, when a client accesses / mcp / {dynamicCode} / {mcpServerCode} / sse, the gateway performs the following actions in sequence: rate limiting based on the MCP service code; querying the dynamic code record based on the dynamic code; verifying the validity period of the dynamic code; querying the MCP service configuration based on the object ID in the dynamic code record and the MCP service code in the path; verifying the MCP service status, and denying access if the service is invalid; reading the MCP service URL and the request headers configured in the database; overwriting the request header with the same name as the database configuration in the current request into the forwarding request header; establishing an HTTP connection to the downstream MCP service; and selecting the SSE response strategy based on the downstream content type.

[0034] After the gateway completes dynamic code verification, it constructs an MCP context object, which includes the request object, response object, dynamic code, dynamic code record ID, MCP service ID, request method, request body, and target URL. The HTTP request executor establishes a connection to the downstream MCP service and writes the request headers and request body to the downstream. When the downstream returns text / event-stream, the response strategy factory selects the SSE response strategy. The SSE response strategy sets Content-Type to text / event-stream; charset=UTF-8, Cache-Control to no-cache, and Connection to keep-alive, and reads the downstream event stream line by line. If an endpoint event is encountered, a proxy endpoint is generated; otherwise, the event is passed through line by line.

[0035] The generation method of the proxy endpoint and the robust parsing of the downstream real message address are as follows: The gateway identifies the event: endpoint and data: fields according to the event flow protocol, and is compatible with spaces, case differences and multi-line data fragments that may exist in the fields; For real message addresses with absolute addresses in the data field, it verifies whether their protocol, host and port are consistent with the authorized MCP service target or meet the whitelist rules; For real message addresses with relative paths or only carrying query strings, they are normalized based on the configuration address of the MCP service or the target address of the current long connection, and the path, query string and encoded characters are merged to form a complete real message address; Then, the normalized real message address is uniformly replaced with the gateway proxy address carrying the session identifier / mcp / message?sessionId={sessionId}.

[0036] While generating the proxy endpoint, the gateway generates a random session identifier (sessionId) and a connection identifier (sseConnectionId). The current gateway instance generates a gateway instance identifier (gatewayInstanceId). Session information is saved in JSON structured form to a storage location `mcp:sse:session:{sessionId}` with the session identifier as the key. This avoids parsing errors caused by vertical bar characters, encoded characters, or complex query strings in the real endpoint. The structured session mapping stores the real endpoint, MCP service identifier, dynamic code record identifier, snapshot identifier and revocation version number of the unified authorization context, gateway instance identifier holding the SSE long connection, connection identifier, creation time, last access time, expiration time, TTL, client feature digest, message sequence number, and session state fields. The current instance only saves the connection index from the connection identifier to the actual SSE output stream object within the process; this index is not used as a cross-instance shared state. The gateway then returns ` / mcp / message?sessionId={sessionId}` to the client, allowing subsequent client messages to continue entering the gateway.

[0037] like Figure 4As shown, when a client sends a message to / mcp / message, the gateway reads the structured session mapping from Redis based on the session identifier. If the session identifier does not exist, its status is revoked or closed, or its TTL has expired, an invalid session is returned. If it exists, the gateway parses the MCP service identifier, dynamic code record identifier, real endpoint, gateway instance identifier, connection identifier, expiration time, and client characteristic fields, and reloads the same unified authorization context based on the snapshot identifier. The gateway then checks the session existence, whether the dynamic code has been revoked, whether the client IP matches the caller's identity, whether the request timestamp is within the allowed time window, whether the message sequence number has not been rolled back and is not duplicated, and whether the number of requests and frequency within a single session window do not exceed the threshold. If the verification passes, the session TTL is updated and refreshed; if the verification fails, the session is marked as abnormal and forwarding is refused.

[0038] This implementation uses a multi-instance routing approach that forwards to the holding instance. Each gateway instance generates a stable gateway instance identifier (gatewayInstanceId) upon startup and writes registration information, including the instance's intranet access address, health status, most recent heartbeat time, and forwarding interface path, to a storage location with the gateway instance identifier as the key: instance:gateway:{gatewayInstanceId}. The instance that generates the session identifier is the holding instance. It writes the gateway instance identifier and connection identifier to the session mapping and saves a reference from the connection identifier to the actual SSE output stream object in the local connection index.

[0039] When a ` / mcp / message` request arrives at a non-holding instance, that instance first reads `mcp:sse:session:{sessionId}`, queries `instance:gateway:{gatewayInstanceId}` based on the gateway instance identifier to obtain the holding instance's internal network address, and then forwards the message via the internal interface `POST / internal / mcp / session-message`. The forwarding request body includes the session identifier, connection identifier, original JSON-RPC request body, request header whitelist field, caller identity digest, message sequence number, and request timestamp; the internal forwarding interface only allows authentication calls within the gateway cluster or between services. Upon receiving the request, the holding instance re-verifies the Redis session state, client characteristics, message sequence number, time window, and local connection index. If the verification passes, it sends the message to the real endpoint and is responsible for writing back the response to the original SSE connection or returning the synchronization processing result to the forwarding instance.

[0040] When cross-instance forwarding fails, it is handled in the following order: If the holding instance registration information does not exist, the heartbeat times out, or the internal forwarding connection fails, the current instance rereads the Redis session state and marks the session state as closing, returning an invalid session or an error requiring a re-handshake to the client; if the holding instance exists but the connection corresponding to the connection identifier is closed, the holding instance deletes the local connection index and changes the session state to closed, while publishing a session cleanup event; if a brief network anomaly occurs within the allowed retry time window, the current instance can retry once according to the idempotent message sequence number. If the retry still fails, forwarding is rejected to avoid duplicate delivery of the same JSON-RPC message.

[0041] For MCP streamable HTTP access, when a client accesses / mcp / {dynamicCode} / {mcpServerCode} / mcp or / mcp-servers / {mcpServerCode} / mcp, the gateway reads the path dynamic code or the request header dynamic code, performs dynamic code verification and rate limiting. For the JSON-RPC content in the request body, the gateway parses the method; if the method is tools / call, parameter policy verification is performed before forwarding. When the MCP service is a standard MCP service, the gateway forwards the request to the service configuration URL; when the MCP service is bound to a plugin application, the gateway enters the plugin MCP adaptation process, and the plugin MCP adapter returns a JSON-RPC response.

[0042] like Figure 5 As shown, the gateway performs parameter policy validation before forwarding the tools / call request. The gateway queries the subscription relationship based on the dynamic code record identifier, queries the parameter policy based on the subscription ID and tool code, queries the parameter type based on the MCP service and tool definition, and performs parameter validation and completion through a constraint validator. The constraint validator is an enumerable finite set, including parameter type validators, enumerated value validators, numerical or length range validators, regular expression validators, required parameter validators, default value completion validators, sensitive parameter server-side injection validators, and sensitive parameter server-side overriding validators.

[0043] For server-controlled parameters such as tenant ID, user identity, organization code, data permission scope, and channel code, the gateway does not trust values ​​passed in by the caller. Each parameter is pre-configured with constraint type constrainType, control type controlType, client value processing action clientValueAction, and missing value processing action missingValueAction. When a request body lacks a server-controlled parameter and the missing value processing action is injection missingValueAction=INJECT, the gateway completes the parameter from the unified authorization context, dynamic code, subscription relationship, login context, or server-side configuration according to the valueSource, and does not accept supplementation from the caller; when the request body carries such parameters, the gateway discards, overwrites, or rejects them, and records the policy hit log.

[0044] The priority of processing actions is as follows: First, execute the explicitly configured `clientValueAction` or `missingValueAction`. If not explicitly configured, if the parameter's independent processing identifier `standalone=STRICT` and the caller passes a server-controlled parameter, then reject the request. Otherwise, deduce the default action based on the sensitivity level `sensitiveLevel`, where highly sensitive parameters are rejected by default, sensitive parameters are overridden by default, and ordinary parameters are retained by default while continuing to execute the corresponding `constraintType` validation. The values ​​of `clientValueAction` include `KEEP`, `OVERRIDE`, `DROP`, and `REJECT`. All `DROP`, `OVERRIDE`, `REJECT`, and auto-completion actions are recorded in the policy hit log. The log only saves the parameter name, policy ID, action, source, and desensitized summary, excluding sensitive plaintext values. In this way, parameter policy validation not only performs JSON Schema-level format validation but also forcibly converges the server-controlled parameter source, preventing the caller from unauthorizedly passing sensitive contexts such as tenant, identity, or data range.

[0045] An example of a parameter strategy decision table is shown in Table 1, where the value of parameter injection comes from the aforementioned unified authorization context, so that tool visibility and parameter injection follow the constraints of the same authorization snapshot.

[0046] Table 1

[0047] For MCP services bound to plugin applications, the gateway no longer forwards the actual downstream URL; instead, it directs traffic to the plugin MCP adapter. The plugin MCP adapter first parses the JSON-RPC request body, verifies that JSON-RPC is 2.0, reads the method, id, and params, and then dispatches it to handlers such as initialize, tools / list, and tools / call via the method handler factory. The handler's return value is encapsulated from the JSON-RPC response into a structure containing JSON-RPC, id, and result; a JSON-RPC error is returned if parsing fails, the plugin application does not exist, or the method is not supported.

[0048] The field mapping rules from plugin tool definition to MCP tool schema are as follows: The plugin tool's tool code (machineCode) is mapped to the MCP tool's name (name); the plugin tool name (machineName) and purpose description (machineDesc) are mapped to the title (title) and description (description); the plugin input parameters' codes, data types, enumeration values, default values, and length or range constraints are converted to the input schema's properties attribute (properties); and the required field list (required) of the input schema is generated based on the required field identifier (isRequired) of the plugin input parameters. Taking the customer profile query plugin tool as an example, the plugin tool record is pluginMachineId=86010001, machineCode=customer_profile_query, machineName=customer profile query, machineDesc=query customer profile, risk level, and recent order summary by customer code. The tool list processor calls buildInputSchema to query the input fields and generate the input schema.

[0049] If object or array object parameters exist, for example, if `contactFilter(fieldType=Object, fieldAlias=F_CONTACT)` contains `mobileMasked(fieldType=Boolean, fieldParentId=F_CONTACT, isRequired=1)` and `province(fieldType=String, fieldParentId=F_CONTACT)`, then `contactFilter.properties` is recursively generated based on the mapping between the parent field identifier `fieldParentId` and the parent field alias `fieldAlias` of the sub-field records, and `mobileMasked` is written to `contactFilter.required`. The root pattern is fixed to an object type and does not allow additional attributes. The root field `required` only contains the root parameter `isRequired=1`. Extended constraints such as enumeration, length, and range are written to the same properties node without changing the generation rules of `required`. An example of the MCP tool pattern returned by the tool list is as follows: {"name":"customer_profile_query","title":"Customer Profile Query", "description":"Query customer profile, risk level, and recent order summary by customer code", "inputSchema":{"type":"object","additionalProperties":false,"properties":{"customerId":{"type":"string","description":"customer code"}, "regionCode":{"type":"string","description":"region code","default":"HN"}, "riskLevel":{"type":"string","description":"risk level", "enum":["LOW","MEDIUM","HIGH"], "default":"MEDIUM"}, "includeOrders":{"type":"boolean","description":"Whether to return recent orders", "default":"false"}, "pageNo":{"type":"integer","description":"page number", "default":"1"},"tags":{"type":"array","description":"Customer tag collection"}}, "required":["customerId","regionCode"]}} The result structures for synchronous and asynchronous execution are as follows: For synchronous tools / calls, the `CallToolResult` structure is used, where `result.content` is a list of text content, and `result.isError=false` indicates successful execution. If an exception is caught during plugin execution, the tool call handler returns `isError=true` and adds the error text to `content`. For streaming plugins, the streaming determination method identifies empty response types or `responseType=stream`. The adapter no longer returns a standard JSON-RPC result but instead outputs it via the SSE link. During asynchronous execution, the `result` retains the outer `CallToolResult` structure, while the specific task information is placed in `structuredContent`.

[0050] The asynchronous polling mode process is as follows: The client calls tools / call and declares executionMode=async in params.arguments or params._meta; after the adapter completes parameter validation, it creates a task record and immediately returns a success response carrying the task identifier and execution status; the background thread executes the real plugin and updates the task status from PENDING to RUNNING, and after completion, it updates it to SUCCESS or PARTIAL_SUCCESS and writes the plugin back to result; in case of an exception, it updates it to FAILED and writes the error information; the client queries according to the pollUrl address, and if it is not completed, it returns the task identifier taskId, status status, progress progressPercent, current step code currentStepCode and name currentStepName; if completed, it additionally returns result; if it fails, it additionally returns error information and mappable JSON-RPC error information.

[0051] The asynchronous execution callback mode process is as follows: The client submits the callback address callbackUrl or callback identifier callbackId when calling tools / call. The server only accepts callback targets that are pre-registered or have passed signature verification. After the task enters the final state, the server sends a callback request to callbackUrl carrying the task identifier, callback identifier, status, progress, result or error. If necessary, it also includes a timestamp, a random number nonce and a signature. The receiver uses the callback identifier callbackId for idempotent deduplication. If the callback fails, the server records the number of failures and retryes according to the backoff strategy. After exceeding the threshold, the polling result is retained, and the client can still obtain the final state through the polling address pollUrl.

[0052] The mapping from error types to JSON-RPC error codes is as follows: JSON parsing failure mapping -32700 Parse error, data.errorType=PARSE_ERROR; invalid request object, jsonrpc not 2.0, empty method or invalid params structure mapping -32600 Invalid Request, data.errorType=INVALID_REQUEST; unsupported method, plugin application not found, tool not found or tool not enabled mapping -32601 Method not found, data.errorType=METHOD_NOT_FOUND or TOOL_NOT_FOUND; missing required parameters, type mismatch, invalid enumeration value, length or range validation failure, parameter strategy validation failure mapping -32602 Invalid params, data.errorType=INVALID_PARAMS and can carry the business error code bizCode; invalid dynamic code, no resource permissions, no tool call permissions mapping -32001. Unauthorized: data.errorType=AUTH_FAILED or PERMISSION_DENIED; Plugin execution timeout mapping -32002 Timeout, data.errorType=EXECUTION_TIMEOUT; Downstream HTTP, script, workflow, or deployment application exception mapping -32003 Downstream error, data.errorType=DOWNSTREAM_ERROR and only returning a de-identified downstream error summary; Unclassified system exception mapping -32603 Internal error, data.errorType=INTERNAL_ERROR. A uniform error response format example is shown below, and the response should avoid disclosing stack traces, internal IP addresses, physical paths, database table fields, or SQL statements: {"jsonrpc":"2.0","id":Request ID or null,"error":{"code":-32602,"message":"Parameter validation failed", "data":{"errorType":"INVALID_PARAMS","bizCode":"10120","field":"customerId"}}} like Figure 6 As shown, after connecting to the downstream service, the gateway HTTP request executor reads the downstream content type (Content-Type) and selects the response strategy that matches the content type from multiple response strategies through the response strategy factory. The response strategy factory maintains multiple response strategy instances, each strategy declaring the content types it supports. The gateway traverses the strategy list and selects the first supported strategy. If there is no exact match, it falls back to JSON or other fallback strategies.

[0053] The SSE response strategy is used for text / event-stream, maintaining a persistent connection, passing the event stream line by line, and performing the aforementioned proxy address replacement on endpoint events. The JSON response strategy is used for application / json and application / problem+json, reading normal and error response streams respectively, handling gzip and deflate compressed content, setting UTF-8 JSON responses, and writing them back. The general web response strategy is used for text resources such as HTML, CSS, JavaScript, XML, and SVG. After reading the content, it replaces the actual downstream base URL with the gateway proxy base URL before writing it back to the client, and only performs URL rewriting on text resources to avoid modifying binary content. The file download response strategy is used for download responses of binary files, images, Office documents, PDFs, and compressed files. It copies necessary response headers, supplements X-Content-Type-Options: nosniff, cache control headers, and secure Content-Disposition, and writes the file content back as a buffered stream, avoiding loading large files entirely into memory. Through this method, the gateway can be compatible with different response types, avoiding protocol corruption or missing security headers caused by a single forwarding logic.

[0054] The application proxy module dynamically constructs the target URL on the gateway server based on the application code, rule code, rule type, image relationship, host relationship, and port mapping. This enables unified proxy access for containerized applications, allowing external callers to access only the stable application code path. The real image address, host address, and port mapping are dynamically resolved by the server.

[0055] The security governance module performs the following security processing in the forwarding chain: dynamic code existence and validity period verification; rate limiting at the agent and MCP resource levels; MCP service status verification; only allowing the current request to overwrite the request headers configured in the database to avoid arbitrary request header pass-through; setting expiration time for Redis session mappings, and setting expiration and removing listeners for local SSE output stream caches; using HTML encoding or JSON serialization for error output to reduce the risk of script injection; adding nosniff and cache control headers to download responses; performing safe character processing on filenames; filtering newlines and invisible control characters in log output to reduce log injection; and recording resource type and executor type by calling log aspects for easy auditing. The above chain governance corresponds to the consistent governance capabilities at the unified entry point.

[0056] Building upon the aforementioned security governance, this implementation further provides adaptive authorization governance based on multi-dimensional risk signals, collaboratively completed by a risk signal collector, a risk scorer, a risk policy executor, and a policy self-tuner. The risk signal collector gathers risk signals within a unified entry point and session lifecycle. These risk signals include the deviation between the request source and the source identifier bound to the dynamic code record, device fingerprint drift, deviation in call frequency per unit time, parameter policy hit frequency, message sequence number rollback frequency, and downstream error rate.

[0057] The risk scorer weights and aggregates risk signals into a real-time risk score based on subscription and session dimensions. A sliding time window and attenuation factor are used to map the risk score to low, medium, and high risk levels, ensuring that the risk score reflects instantaneous anomalies while avoiding the long-term accumulation of historical noise. The risk policy executor dynamically adjusts authorization strength, parameter policy strictness, rate limiting threshold, session validity period, and handshake requirements based on the risk level: low risk maintains existing authorization strength and rate limiting threshold; medium risk upgrades controlled parameter actions to coverage, tightens the scope, or enumerates verification and lowers the rate limiting threshold and shortens the session TTL; high risk requires a re-handshake, suspends the session identifier, or upgrades the revocation version number to trigger dynamic code invalidation, and writes the handling results to the security audit log. The policy self-tuner feeds back parameter policy hit logs, risk score changes, and session anomaly events, and calls the baseline frequency and default processing actions based on subscription self-tuning, upgrading authorization governance from static per-request verification to adaptive governance oriented towards sessions and subscriptions. Therefore, although individual requests such as low-frequency probing, slow parameter overreach, and scattered replay after credential leakage are individually verified through static checks, they can still be identified and processed step by step under cross-signal aggregation.

[0058] The above-described specific embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Various modifications, substitutions, and improvements made by those skilled in the art to the technical solutions of the present invention based on the provided textual description and drawings, without departing from the design concept and spirit of the present invention, should all fall within the scope of protection of the present invention. The scope of protection of the present invention is determined by the claims.

Claims

1. A method for a dynamic authorization multi-protocol gateway for an intelligent agent operating system, wherein the gateway serves as a unified access point for intelligent agents, plug-in services, MCP services, and containerized deployment applications, characterized in that, include: Receive an access request carrying a resource dynamic code, query the dynamic code record corresponding to the resource dynamic code, and perform existence verification, validity period verification, and source constraint verification on the dynamic code record; After verification, the resource dynamic code is used as the unique authorization anchor point to derive a trusted unified authorization context for the server in one go. The unified authorization context includes the caller identity, tenant, subscription relationship, data permission scope, tool authorization set and revocation version number. When the access request is an MCP event stream access, a session identifier is generated, the real message address returned by the downstream is replaced with the gateway proxy address carrying the session identifier and returned to the client, and the identifier of the unified authorization context and the revocation version number are written into the structured session mapping with the session identifier as the key; When subsequent message requests or tool call requests arrive based on the session identifier, the same unified authorization context is reloaded, and the identity and server-controlled parameters carried in the request are not trusted. For the tool invocation request, the tool visibility is determined based on the tool authorization set, and the server-side controlled parameters are injected or overwritten from the unified authorization context according to the source and then forwarded to the real downstream address; When the revocation version number changes, all protocol processing stages bound to the same unified authorization context are synchronously disabled.

2. The dynamic authorization multi-protocol gateway method for an intelligent agent operating system according to claim 1, characterized in that, Injecting or overriding server-side controlled parameters from the unified authorization context by source includes: Configure constraint type, control type, client value processing action and missing value processing action for each parameter of the tool. The constraint type includes parameter type validation, enumeration value validation, numerical or length range validation, regular expression validation and Boolean rule validation. The control type identifies whether the parameter is a server-controlled parameter. When the request body of the tool call request is missing a server-controlled parameter and the missing value handling action is injection, the server-controlled parameter is completed from the unified authorization context, the subscription relationship or the server configuration according to the value source, and the corresponding value passed by the caller is not accepted; When the request body carries server-controlled parameters, it is processed according to the client value processing action: if it is to be overwritten, the value passed by the caller is replaced with a trusted value in the unified authorization context; if it is to be discarded, the parameter is deleted and not passed down downstream; if it is to be rejected, forwarding is terminated and a parameter policy error is returned; if it is to be retained, the constraint type is first executed and the value passed by the caller is retained after passing the constraint type validation. When the client-side value processing action is not explicitly configured, if the independent processing identifier of the parameter is strict and it is a server-controlled parameter, the tool call request is rejected; otherwise, the default processing action is derived according to the sensitivity level of the parameter, where highly sensitive parameters are rejected by default, sensitive parameters are overridden by default, and ordinary parameters are retained by default. The policy hit log records the overwrite, discard, reject and injection processing actions. The policy hit log only saves the parameter name, policy identifier, processing action and source, and does not record the plaintext value of sensitive parameters.

3. The dynamic authorization multi-protocol gateway method for an intelligent agent operating system according to claim 1, characterized in that, The dynamic code record stores an irreversible digest of allowed source IPs, network segments, or caller exit rules, as well as client characteristics; The source constraint verification includes comparing the request's source IP and device fingerprint with the source identifier bound to the dynamic code record, respectively; When the dynamic code record is configured for one-time use, the usage flag of the dynamic code record is changed from unused to used by database condition update or cache atomic script. If the condition update fails, it is determined that it has been consumed and an unauthorized error is returned. When the dynamic code record is configured with a sliding validity period, a cache structure with an expiration time is used to store the most recent access time. After each successful verification, the most recent access time and the expiration time are refreshed if the maximum validity period has not been exceeded. If the maximum validity period has been exceeded, the cache is deleted and access is denied. When the dynamic code record is actively revoked, the server increases the revocation version number and publishes a revocation event. After receiving the revocation event, each gateway instance clears its local dynamic code cache, session mapping cache, and rate limiting window cache. Gateway instances that do not receive the revocation event complete the failure propagation by comparing the revocation version number.

4. The dynamic authorization multi-protocol gateway method for an intelligent agent operating system according to claim 1, characterized in that, The structured session mapping stores the real message address, MCP service identifier, dynamic code record identifier, gateway instance identifier holding long-lived event stream connection, connection identifier, creation time, expiration time, client feature summary, message sequence number and session state in key-value or document form; The gateway instance that generates the session identifier stores the connection index from the connection identifier to the actual event stream output object within the process, and the connection index is not used as a cross-instance shared state; When the subsequent message request reaches the gateway instance that does not hold the long connection, the gateway instance reads the structured session mapping based on the session identifier, queries the internal network address of the holding instance based on the gateway instance identifier, and forwards the original message, the session identifier, the connection identifier, and the caller identity digest to the holding instance through the internal forwarding interface that only allows intranet or inter-service authentication calls. The holding instance then verifies the session state, client characteristics, message sequence number, and local connection index again before writing the response back to the long connection.

5. The dynamic authorization multi-protocol gateway method for an intelligent agent operating system according to claim 1, characterized in that, The step of replacing the real message address returned by the downstream with the gateway proxy address includes: The gateway identifies event type fields and data fields according to the event popularity protocol, and is compatible with spaces, case differences and multi-line data fragments in the fields; For real message addresses with absolute addresses in the data field, verify whether their protocol, host, and port are consistent with the authorized MCP service target or meet the whitelist rules; For real message addresses that are relative paths or only carry query strings, normalization is performed based on the configuration address of the MCP service or the target address of the current long connection, and the path, query string and encoded characters are merged to form a complete real message address; Then, the normalized real message address is uniformly replaced with the gateway proxy address carrying the session identifier, and the real message address is written into the structured session mapping.

6. The dynamic authorization multi-protocol gateway method for an intelligent agent operating system according to claim 1, characterized in that, When a plugin application identifier exists in the configuration of the MCP service, the tool invocation request or tool list request is transferred to the plugin adaptation process, including: Map the tool code of the plug-in tool to the name of the MCP tool, map the name and purpose description of the plug-in tool to the description of the MCP tool, convert the code, data type, enumeration value, default value and length or range constraint of the plug-in input parameter into the attributes of the MCP tool input mode, and generate a list of required fields of the input mode according to the required field identifier of the plug-in input parameter. When the plugin input parameters include objects or array objects, the properties of the nested object are recursively generated based on the correspondence between the parent field identifier and the parent field alias of the subfield record, and the required subfields within the nested object are written into the required field list of the nested object.

7. The dynamic authorization multiprotocol gateway method for an intelligent agent operating system according to claim 6, characterized in that, When the tool call request declares asynchronous execution, the plugin adaptation process creates a task record and immediately returns a success response carrying the task identifier and execution status after the parameter verification is passed. Then, the background thread executes the real plugin and updates the task status between pending execution, execution and final state. In polling mode, the client queries the task based on the polling address in the success response. If the task is not completed, the client returns the task identifier, status and progress. If the task is completed, the client also returns the execution result. If the task fails, the client also returns the error information. In callback mode, the server only accepts pre-registered or signature-verified callback targets. After the task enters the final state, it sends a callback request carrying the task identifier, callback identifier, status and result to the callback address. The receiver performs idempotent deduplication based on the callback identifier. If the callback fails, it retryes according to the backoff strategy and retains the polling address for the client to obtain the final state.

8. The method for a dynamic authorization multi-protocol gateway for an intelligent agent operating system according to claim 1, characterized in that, After forwarding to the actual downstream address, the method reads the content type of the downstream response and selects a response strategy that matches the content type from multiple response strategies through a response strategy factory. For event stream types, maintain a long connection and perform the proxy address replacement on the message address events within it; For JSON types, read the normal response stream and the error response stream respectively and process the compressed content; For text-based web page resources, replace the actual downstream base address with the gateway proxy base address; For download types, copy the necessary response headers and supplement them with content sniffing protection headers, cache control headers, and secure content handling headers, and write the file content back in a buffered stream manner; If no exact matching response strategy exists, fall back to the fallback response strategy.

9. The method for a dynamic authorization multi-protocol gateway for an intelligent agent operating system according to claim 1, characterized in that, It also includes adaptive authorization governance based on multi-dimensional risk signals: Risk signals are collected within the unified entry point and session lifecycle. These risk signals include the deviation between the request source and the source identifier bound to the dynamic code record, device fingerprint drift, deviation of call frequency per unit time, parameter policy hit frequency, message sequence number rollback frequency, and downstream error rate. The risk signals are weighted and aggregated into a real-time risk score based on subscription and session dimensions, and then mapped to a risk level using a sliding time window and a decay factor. The authorization strength, parameter policy strictness, rate limiting threshold, session validity period and handshake requirements are dynamically adjusted according to the risk level. Under the high risk level, a re-handshake is required, the session identifier is suspended or the revocation version number is increased. The parameter policy hit logs, risk score changes, and session exception events are fed back to the system, and the call frequency baseline and default processing actions are automatically adjusted according to the subscription.

10. A dynamic authorization multi-protocol gateway system for an intelligent agent operating system, implementing the dynamic authorization multi-protocol gateway method for an intelligent agent operating system as described in any one of claims 1-9, characterized in that, include: The dynamic authorization code module is used to query dynamic code records and perform existence, validity period and source constraint verification. The resource dynamic code corresponding to the dynamic code record is used as the unique authorization anchor point to derive a unified authorization context that includes caller identity, tenant, subscription relationship, data permission scope, tool authorization set and revocation version number in one go. The session proxy module is used to generate a session identifier when the MCP event stream is accessed, replace the downstream real message address with the gateway proxy address carrying the session identifier, and write the identifier of the unified authorization context and the revocation version number into a structured session mapping with the session identifier as the key. The parameter strategy module is used to reload the same unified authorization context based on the session identifier when subsequent message requests or tool call requests arrive, determine tool visibility based on the tool authorization set, and inject or overwrite server-side controlled parameters from the unified authorization context according to the source. The security governance module is used to synchronously disable all protocol processing stages bound to the same unified authorization context when the revocation version number changes.

Images