Layered authentication and user information transmission method of AI agent platform

Abstract

The application provides a layered authentication and user information transparent transmission method of an AI Agent platform, relates to the technical field of identity authentication and access control, and comprises the following steps: an AI Agent platform checks a temporary token application request based on a system-level access credential, generates a session-level temporary token and a token context; after receiving an AI Agent calling request, the session-level temporary token and a target service identifier are checked, a user identity transparent transmission data packet is taken as a ciphertext load to calculate a ciphertext digest, and a platform forwarding signature and platform forwarding envelope are generated based on the ciphertext digest, a business system identifier, a token unique identifier and the target service identifier. Therefore, session authorization verification, user identity ciphertext transparent transmission and transparent transmission data integrity binding are realized.

Description

Technical Field

[0001] This application belongs to the field of identity authentication and access control technology, specifically involving a layered authentication and user information pass-through method for an AI Agent platform. Background Technology

[0002] With the application of large language models and intelligent agent technology in enterprise-level business systems, AI Agent platforms are increasingly being used to handle functions such as natural language interaction, task orchestration, tool invocation, and access to external business systems. In these application scenarios, users typically initiate dialogue requests through business systems, which then send the user requests to the AI ​​Agent platform. The AI ​​Agent platform, based on the user's intent, invokes the corresponding tool services, MCP services, or business service interfaces to complete operations such as data querying, business processing, workflow approval, and information generation.

[0003] In existing enterprise-level system access architectures, business systems and platforms typically use methods such as API keys, access tokens, OAuth authorization, unified gateway authentication, or inter-service certificate authentication for identity verification and access control. For example, business systems can access the platform through a fixed API key; the platform can also identify the caller's identity through a unified access token; in some systems, a unified authentication of requests is also performed through an API gateway, and the user's identity information is forwarded to downstream services after successful authentication. These methods can achieve caller authentication and basic access control in typical inter-system call scenarios.

[0004] However, in scenarios where AI Agent platforms call business systems, the call chain typically involves multiple rounds of sessions, continuous task execution, multi-level forwarding of tool services, and the need to transfer user identity across systems with each request. Existing authentication methods still have certain shortcomings in this scenario.

[0005] First, existing solutions typically combine business system access authentication, session call authorization, and end-user permission verification into a single authentication process. For example, when using a single API key, the platform can only identify whether the accessing system is trustworthy, but it's difficult to distinguish whether a specific AI Agent session is still within the valid authorization scope. When using a single access token, the token often carries information such as the caller's identity, user identity, or authorization scope simultaneously, resulting in unclear boundaries between system-level authentication and session-level authorization. When an AI Agent calls different tool services or business service interfaces multiple times during a session, the platform needs to perform repeated authentication for each call, or rely on tokens with longer validity periods to maintain the session state. The former increases the authentication overhead of the call chain, while the latter increases the risk of continuous abuse after token leakage.

[0006] Secondly, during cross-system calls, user identity information typically needs to be transmitted between business systems, the AI ​​Agent platform, the MCP service layer, and business service interfaces. In existing methods, the platform or intermediate gateway often needs to parse the user identity information before routing, permission checks, or request forwarding. This exposes user identity information to intermediate nodes outside the business system and places the responsibility for user identity parsing, permission checks, and user data storage on the AI ​​Agent platform. For business systems with independent user and permission systems, user identity data and permission rules are usually maintained by the business system itself. If the AI ​​Agent platform is involved in parsing or managing user identity information, it can easily lead to unclear permission boundaries, complex user data synchronization, and increased data processing responsibilities on the platform side.

[0007] Furthermore, when the AI ​​Agent platform calls MCP services or business service interfaces, user identity information may be forwarded through multiple intermediate service nodes. In existing solutions, if user identity information is only passed as a regular request header or parameter, downstream business service interfaces cannot determine whether the user identity information matches the current session authorization, the target service call, and the platform's forwarding chain, nor can they confirm whether the information has been replaced or tampered with during intermediate forwarding. Especially in scenarios with multiple tool services and multiple business interfaces, the lack of a binding relationship between the user identity data and the call context may lead to inconsistencies between the identity information and the actual call target, thereby affecting the reliability of subsequent permission verification by the business service interface. Summary of the Invention

[0008] This application provides a layered authentication and user information pass-through method for an AI Agent platform to solve one of the aforementioned technical problems.

[0009] The technical solution adopted in this application is as follows: This application provides a method for layered authentication and user information pass-through in an AI Agent platform, including: S100, receive a temporary token application request sent by the business system, wherein the temporary token application request carries a system-level access credential identifier, an application timestamp, and a first request signature; S200: Obtain credential verification data based on the system-level access credential identifier, and verify the application timestamp and the first request signature based on the credential verification data. If the verification passes, generate a session-level temporary token and a token context corresponding to the session-level temporary token, and return the session-level temporary token to the business system. The token context includes at least a business system identifier, a unique token identifier, and an authorized service scope. S300, receive the AI ​​Agent call request initiated by the business system based on the session-level temporary token, the AI ​​Agent call request carries the session-level temporary token, the target service identifier and the user identity transparent data packet, the user identity transparent data packet includes the user identity encrypted payload; S400, perform validity verification on the session-level temporary token carried in the AI ​​Agent call request, and if the session-level temporary token verification passes, obtain the corresponding token context based on the session-level temporary token, and perform authorization verification on the target service identifier based on the authorized service scope in the token context; S500, if the target service identifier passes the authorization verification, the user identity transparent data packet is written into the request-level context corresponding to the AI ​​Agent call request, and the digest of the user identity transparent data packet is calculated without decrypting the user identity transparent data packet to obtain the ciphertext digest. S600, generate data to be signed based on the ciphertext digest, the business system identifier, the token unique identifier and the target service identifier, and perform signature processing on the data to be signed to obtain the platform forwarding signature; S700, a platform forwarding envelope is generated based on the user identity transparent data packet, signature association data, and the platform forwarding signature; wherein, the signature association data includes the business system identifier, the token unique identifier, and the target service identifier; S800, determine the target MCP service layer based on the target service identifier, and send the platform forwarding envelope to the target MCP service layer.

[0010] According to one embodiment of this application, in step S200, the credential verification data includes credential status, business system identifier, signature verification key, and time window parameters; The verification of the application timestamp and the first request signature based on the credential verification data includes: Determine whether the system-level access credential corresponding to the system-level access credential identifier is in an available state based on the credential status. Determine whether the application timestamp is within the allowed application time range based on the time window parameter; A local request signature is generated based on the signature verification key and the application timestamp; Compare the local request signature with the first request signature; If the system-level access credential is available, the application timestamp is within the allowed application time range, and the local request signature is consistent with the first request signature, then the temporary token application request is determined to have passed verification.

[0011] According to one embodiment of this application, in step S200, the token context further includes a tenant identifier, a token activation time, and a token expiration time; The generation of the session-level temporary token and the token context corresponding to the session-level temporary token includes: The business system identifier, the tenant identifier, and the authorized service scope are determined based on the credential verification data. The token's effective time and expiration time are determined based on the token's generation time and preset validity period. Generate a unique identifier for the token; The token context is generated based on the business system identifier, the tenant identifier, the authorized service scope, the token effective time, the token expiration time, and the token unique identifier; The session-level temporary token is generated based on the token context, and the unique identifier of the token and the token state are written into the token state storage area.

[0012] According to one embodiment of this application, in step S400, the validity of the session-level temporary token carried in the AI ​​Agent invocation request is verified, and the authorization verification of the target service identifier is performed based on the authorized service scope in the token context, including: Parse the session-level temporary token to obtain the context of the token to be verified; The token status is obtained by querying the token status storage area based on the unique token identifier in the context of the token to be verified. Determine whether the current time is between the token's effective time and the token's expiration time; Match the target service identifier with the authorized service scope; If the token is in a valid state, the current time is between the token's effective time and its expiration time, and the target service identifier belongs to the authorized service scope, then the session-level temporary token verification is determined to be successful and the target service identifier passes the authorization verification. If the token is invalid, the current time is not between the token's effective time and its expiration time, or the target service identifier is not within the scope of the authorized service, the platform forwarding envelope will not be generated.

[0013] According to one embodiment of this application, in step S300, the user identity transparent data packet further includes an encryption algorithm identifier, a key identifier, and a data packet random number; The encrypted payload of user identity is an encrypted payload obtained by encrypting plaintext data of user identity based on the encryption key of the business system side. The plaintext data of user identity includes at least one of user identifier, organization identifier, role identifier and permission identifier. The AI ​​Agent platform does not hold the encryption key on the business system side, and after receiving the user identity transparent data packet, it transmits the user identity encrypted payload, the encryption algorithm identifier, the key identifier, and the data packet random number as a whole.

[0014] According to one embodiment of this application, in step S500, the user identity transparent data packet is written into the request-level context corresponding to the AI ​​Agent invocation request, and a digest calculation is performed on the user identity transparent data packet without decrypting it to obtain a ciphertext digest, including: Generate a request identifier for the AI ​​Agent invocation request; Establish the association between the request identifier, the target service identifier, and the user identity transparent data packet in the request-level context; Read the user identity transparent data packet based on the aforementioned association; The ciphertext digest is obtained by performing a digest calculation on all ciphertext fields or a preset digest field set in the user identity transparent data packet. The request-level context is used to temporarily store the user identity transparent data packet during the processing cycle of the AI ​​Agent call request.

[0015] According to one embodiment of this application, in step S600, generating data to be signed based on the ciphertext digest, the business system identifier, the token unique identifier, and the target service identifier includes: Read the request identifier from the request-level context; Determine the target MCP service identifier based on the target service identifier; The encrypted digest, the request identifier, the business system identifier, the unique token identifier, the target service identifier, and the target MCP service identifier are combined in a preset field order to obtain the data to be signed; The step of signing the data to be signed to obtain the platform forwarding signature includes: The data to be signed is processed using the platform-side signature key to obtain the platform forwarding signature.

[0016] According to one embodiment of this application, in step S700, the signature association data further includes the request identifier and the target MCP service identifier; The process of generating a platform forwarding envelope based on the user identity transparent data packet, signature association data, and the platform forwarding signature includes: Write the user identity transparent data packet as the object to be transparently transmitted into the platform forwarding envelope; The business system identifier, the unique token identifier, the target service identifier, the request identifier, and the target MCP service identifier are written as signature association data into the platform forwarding envelope; Write the platform forwarding signature into the platform forwarding envelope; The platform forwarding envelope is used to enable the target MCP service layer or business service interface to recalculate the ciphertext digest based on the user identity transparent data packet, and to verify the platform forwarding signature based on the recalculated ciphertext digest and the signature association data.

[0017] According to one embodiment of this application, in step S800, determining the target MCP service layer based on the target service identifier and sending the platform forwarding envelope to the target MCP service layer includes: Based on the target service identifier, query the service routing mapping relationship to determine the target MCP service identifier corresponding to the target service identifier; The access address of the target MCP service layer is determined based on the target MCP service identifier; According to the service invocation protocol corresponding to the target MCP service layer, the platform forwarding envelope is sent to the access address; The user identity transparent data packet sent to the platform forwarding envelope of the target MCP service layer is consistent with the user identity transparent data packet received by S300.

[0018] According to one embodiment of this application, the method further includes an exception control process associated with the temporary token request, the AIAgent invocation request, and the request-level context; The anomaly control process includes: If the temporary token application request verification fails, the number of application failures corresponding to the system-level access credential identifier is recorded, and when the number of application failures reaches a preset failure threshold, the system-level access credential corresponding to the system-level access credential identifier is set to a temporary locked state. If the session-level temporary token verification fails or the target service identifier fails the authorization verification, the platform forwarding envelope will not be generated. If the platform forwards the envelope and sends it, the AI ​​Agent call request fails to process, or the AI ​​Agent call request times out, the request-level context is released. Specifically, the log records generated for the AI ​​Agent call request do not contain the plaintext of the user identity after the user identity pass-through data packet is decrypted.

[0019] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows: This application separates business system access authentication and subsequent AI Agent call authorization into two continuous but independent processing stages by receiving a system-level access credential identifier, an application timestamp, and a first request signature during the temporary token application stage, and generating a session-level temporary token and token context after verifying the application timestamp and the first request signature based on credential verification data. The system-level access credential is used to determine whether the business system is qualified to apply for a session-level temporary token, and the session-level temporary token is used for session authorization verification of subsequent AI Agent call requests. This avoids mixing system-level access authentication and session-level call authorization in the same long-term credential, allowing the platform to use different verification data and control rules for different stages.

[0020] This application enables the AI ​​Agent platform to bind each AI Agent call request to a specific business system, a specific session authorization, and the permitted service scope by setting at least a business system identifier, a unique token identifier, and an authorized service scope in the token context, and obtaining the corresponding token context based on the session-level temporary token during the AI ​​Agent invocation phase. This processing mechanism ensures that the target service identifier is not only used to determine the subsequent invocation object, but also participates in the authorized service scope verification. This allows the platform to determine whether the current session has the permission to invoke the target service before forwarding the user identity transparent data packet, reducing the risk of using expired, revoked, or unauthorized session-level temporary tokens to continue accessing business services.

[0021] This application enables the AI ​​Agent to carry a user identity transparent data packet in its invocation request. This user identity transparent data packet includes a encrypted payload of the user identity, ensuring that the user's identity information is processed into encrypted form by the business system before entering the AI ​​Agent platform. The AI ​​Agent platform does not need to obtain the plaintext user identity information during subsequent processing, nor does it need to perform user-level permission checks based on the user identity content. This limits the AI ​​Agent platform's responsibilities to system-level authentication, session-level authorization, and forwarding trustworthiness processing, which helps maintain the permission boundaries between the AI ​​Agent platform and the business system.

[0022] This application, after the target service identifier passes authorization verification, writes the user identity transparent data packet into the request-level context corresponding to the AIAgent call request, and calculates a ciphertext digest from the user identity transparent data packet without decrypting it. This allows the AI ​​Agent platform to generate digest data from the user identity transparent data packet that can be used for subsequent integrity binding without parsing the user identity content. The request-level context is used to associate the target service identifier and the user identity transparent data packet within the processing cycle of a single AI Agent call request, avoiding the need for the platform to persistently manage user identity information for transparent transmission.

[0023] This application generates data to be signed based on a ciphertext digest, a business system identifier, a unique token identifier, and a target service identifier. This data is then processed to obtain a platform forwarding signature, establishing a binding relationship between the user identity transparent data packet and the business system source, session authorization identifier, and target service call object. Since the platform forwarding signature is generated based on a ciphertext digest and call context data, the subsequent target MCP service layer or business service interface can recalculate the ciphertext digest and combine it with the signature association data for verification. This verifies whether the user identity transparent data packet has been replaced or tampered with during forwarding, and whether the transparent data packet corresponds to the current business system, current session, and current target service.

[0024] This application generates a platform forwarding envelope based on the user identity transparent data packet, signature association data, and platform forwarding signature. This encapsulates the encrypted user identity payload to be transparently transmitted, the context data used for signature verification, and the platform-side signature result into a unified data structure. This platform forwarding envelope eliminates the need for the MCP service layer to parse the content of the user identity transparent data packet during subsequent forwarding. Forwarding this envelope alone maintains the correspondence between the user identity transparent data packet, signature association data, and platform forwarding signature, thereby reducing the need for intermediate service layers to process user identity content.

[0025] This application determines the target MCP service layer based on the target service identifier and sends the platform forwarding envelope to the target MCP service layer, enabling the target service identifier to participate in authorization verification, signature binding, and routing forwarding simultaneously in this method. In the preceding steps, the target service identifier is used to determine whether the current session has permission to access the target service; in the signature stage, it is used to bind the user identity pass-through data packet to the target service call context; and in the forwarding stage, it is used to determine the target MCP service layer. This avoids the target service identifier being used merely as a routing parameter, creating a continuous data processing chain between service authorization, identity pass-through, and service forwarding.

[0026] This application, through the coordinated steps of "system-level access credential verification to generate session-level temporary tokens—session-level temporary token verification and target service authorization—user identity transparent transmission data packet undecrypted digest calculation—ciphertext digest and call context signature binding—platform forwarding envelope sent to the target MCP service layer," enables collaborative processing between business system access authentication, AI Agent session authorization, encrypted transmission of user identity, and forwarding integrity verification without the AI ​​Agent platform parsing the user's identity in plaintext. This collaborative mechanism differs from the conventional method of directly writing user identity information into the token or having the platform parse user identity information, allowing the AI ​​Agent platform to maintain opaque processing of user identity information while still controlling the scope of session authorization and the integrity of transparently transmitted data. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This embodiment provides a flowchart of a layered authentication and user information pass-through method for an AI Agent platform. Detailed Implementation

[0028] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0029] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0030] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0031] Example 1 This invention provides a layered authentication and user information pass-through method for an AI Agent platform. This method is executed by the AI ​​Agent platform and is applicable to cross-system call scenarios where a business system calls the MCP service layer through the AI ​​Agent platform and accesses business service interfaces via the MCP service layer.

[0032] The business systems can be internal enterprise systems such as transaction systems, approval systems, customer management systems, financial systems, human resource systems, data query systems, or other business application systems with independent user and permission systems. The AIAgent platform provides natural language interaction, task understanding, tool orchestration, session management, and external service invocation capabilities. The MCP service layer handles tool invocation requests from the AI ​​Agent platform and accesses the corresponding business service interfaces based on the target service identifier. The business service interfaces are used to execute specific business operations, such as querying business data, submitting business forms, triggering business processes, or returning business processing results.

[0033] In this embodiment, the target service identifier represents the specific business capability or tool capability that the business system expects to invoke through the AI ​​Agent platform, such as data query service, process approval service, form submission service, or information generation service. The target MCP service identifier represents the MCP service instance or MCP service node that carries the business capability corresponding to the target service identifier. The target MCP service layer represents a service receiving layer composed of one or more MCP service instances, which receives the platform forwarding envelope forwarded by the AI ​​Agent platform and invokes the corresponding business service interface according to the target service identifier or the target MCP service identifier. The business service interface performs specific business processing after receiving the platform forwarding envelope and can perform user-level permission judgment based on the user's identity and transparently transmitted data packets. Thus, a hierarchical invocation relationship is formed between the target service identifier, the target MCP service identifier, the target MCP service layer, and the business service interface, from the business capability identifier to the service node and then to the business interface.

[0034] The core of this embodiment lies in the fact that the AI ​​Agent platform only verifies the access qualifications of the business system, the session-level temporary token, and the authorized scope of the target service, without parsing the plaintext user identity in the user identity transparent data packet. The AI ​​Agent platform performs digest calculation on the user identity transparent data packet and signs and binds the encrypted digest with the business system identifier, the token's unique identifier, and the target service identifier, forming a platform forwarding envelope before sending it to the target MCP service layer. Thus, without the AI ​​Agent platform possessing the plaintext user identity, the user identity transparent data packet can be reliably forwarded along with the target service call request.

[0035] In one embodiment, the method of this invention includes a temporary token issuance phase and an AI Agent invocation phase.

[0036] The temporary token issuance phase enables business systems to request session-level temporary tokens from the AI ​​Agent platform based on system-level access credentials. The AI ​​Agent platform verifies the system-level access credential identifier, request timestamp, and first request signature. Upon successful verification, it generates a session-level temporary token and its corresponding token context, and returns the session-level temporary token to the business system.

[0037] The AI ​​Agent invocation phase enables business systems to include a session-level temporary token, target service identifier, and user identity transparent data packet in subsequent AI Agent invocation requests. The AI ​​Agent platform validates the session-level temporary token and determines whether the target service identifier falls within the authorized service scope of the current session based on the authorized service scope in the token context. Upon successful validation, the AI ​​Agent platform treats the user identity transparent data packet as opaque ciphertext, performs digest calculation, and generates a platform forwarding signature based on the ciphertext digest and invocation context. Subsequently, the AI ​​Agent platform encapsulates the user identity transparent data packet, signature association data, and platform forwarding signature into a platform forwarding envelope and sends it to the target MCP service layer.

[0038] Through the above processing, system-level access credentials are used to control whether a business system is eligible to apply for a session-level temporary token; the session-level temporary token is used to control whether the AI ​​Agent call request is within the scope of a valid session authorization; and the user identity pass-through data packet is used to transmit user identity information to subsequent business service interfaces without the AI ​​Agent platform parsing the user's plaintext identity. These three correspond to system-level access authentication, session-level call authorization, and user-level identity pass-through, respectively, forming a layered processing relationship.

[0039] like Figure 1 As shown, step S100 is: receiving a temporary token application request sent by the business system, wherein the temporary token application request carries a system-level access credential identifier, an application timestamp, and a first request signature.

[0040] In this step, the AI ​​Agent platform receives a temporary token request from the business system. This temporary token request is used to trigger the session-level temporary token issuance process.

[0041] The system-level access credential identifier uniquely indicates the system-level access credential that the business system has pre-registered in the AI ​​Agent platform. The system-level access credential can be a long-term valid and revocable access credential, used to establish a system-level trust relationship between the business system and the AI ​​Agent platform. The system-level access credential identifier itself may not contain plaintext credential data, but is only used by the AI ​​Agent platform to retrieve the corresponding credential verification data.

[0042] The application timestamp indicates when the business system initiated the temporary token application request. The AI ​​Agent platform can then use the application timestamp to determine whether the temporary token application request is within the allowed application time range, thereby reducing the risk of historical requests being replayed.

[0043] The first request signature is used to prove that the temporary token application request comes from a business system holding a valid system-level access credential, and to verify whether request data such as the application timestamp has been tampered with. The first request signature can be generated by the business system based on the signature key corresponding to the system-level access credential and the application timestamp, or it can be further generated by combining data such as the request path, request body digest, and random number.

[0044] In one implementation, when the business system generates the first request signature, it first obtains the system-level access credential identifier, application timestamp, application random number, request path of the temporary token application request, and request body digest. Then, it performs a normalized combination of the system-level access credential identifier, application timestamp, application random number, request path, and request body digest according to a preset field order to obtain a first string to be signed. Subsequently, it performs signature processing on the first string to be signed based on the signature key corresponding to the system-level access credential to obtain the first request signature. After receiving the temporary token application request, the AI ​​Agent platform generates a local request signature based on the same fields and the same normalized combination rules, and compares the local request signature with the first request signature.

[0045] Step S200 is as follows: Obtain credential verification data based on the system-level access credential identifier, and verify the application timestamp and the first request signature based on the credential verification data. If the verification is successful, generate a session-level temporary token and a token context corresponding to the session-level temporary token, and return the session-level temporary token to the business system. The token context includes at least a business system identifier, a unique token identifier, and an authorized service scope.

[0046] In this step, the AI ​​Agent platform queries pre-stored credential verification data based on the system-level access credential identifier from step S100. The credential verification data can be stored in a database, cache, key management system, or other secure storage components. The credential verification data is used to determine whether the business system is eligible to request a session-level temporary token.

[0047] Credential verification data may include credential status, business system identifier, signature verification key, time window parameter, tenant identifier, access source restriction information, and authorized service scope. Specifically, credential status determines whether the system-level access credential is available; the business system identifier identifies the business system requesting the temporary token; the signature verification key generates or verifies the request signature; the time window parameter determines whether the request timestamp is within the allowed request time range; and the authorized service scope limits the service range accessible by the session-level temporary token that can be requested based on this system-level access credential.

[0048] The AI ​​Agent platform performs verification based on credential verification data. Specifically, the AI ​​Agent platform first determines whether the credential status is available; then, based on the time window parameter, it determines whether the application timestamp is within the allowed application time range; subsequently, it generates a local request signature based on the signature verification key and the application timestamp, and compares the local request signature with the first request signature. If the credential status is available, the application timestamp is within the allowed application time range, and the signatures match, then the temporary token application request is deemed to have passed verification.

[0049] If the verification passes, the AI ​​Agent platform generates a session-level temporary token and a corresponding token context. The session-level temporary token is used for session authorization verification in subsequent AI Agent call requests. The token context records information such as the business system corresponding to the session-level temporary token, the token identifier, and the authorized service scope.

[0050] The token context includes at least a business system identifier, a unique token identifier, and an authorized service scope. The business system identifier is used to bind the source of the user identity transparent data packet in the subsequent platform forwarding signature; the unique token identifier is used to associate the AI ​​Agent call request with the specific session authorization in subsequent steps; and the authorized service scope is used in step S400 to determine whether the target service identifier belongs to the scope of access allowed by the current session.

[0051] After generating a session-level temporary token, the AI ​​Agent platform returns this token to the business system. The business system then includes this session-level temporary token when initiating subsequent AI Agent call requests.

[0052] In one implementation, the session-level temporary token can be a self-contained token. The AI ​​Agent platform writes the business system identifier, tenant identifier, authorized service scope, token effective time, token expiration time, and token unique identifier into the token payload, and signs the token payload based on the platform-side token signing key to obtain the session-level temporary token. When the AI ​​Agent makes a subsequent call request carrying this session-level temporary token, the AI ​​Agent platform first verifies the signature of the session-level temporary token, and then parses the token payload to obtain the token context to be verified.

[0053] In another implementation, the session-level temporary token can be a reference token. After generating a unique token identifier, the AI ​​Agent platform writes the unique token identifier, business system identifier, tenant identifier, authorized service scope, token validity period, token expiration period, and token status into the token status storage area, and generates a session-level temporary token based on the unique token identifier. When the AI ​​Agent makes a subsequent call request carrying this session-level temporary token, the AI ​​Agent platform queries the token status storage area based on the unique token identifier in the session-level temporary token to obtain the corresponding token context and token status.

[0054] The technical effect of this step is to separate system-level access credential verification from session-level call authorization, so that system-level access credentials do not directly run through the subsequent AI Agent call process, reducing the risk of long-term credentials being repeatedly exposed in multiple calls, and providing a foundation for subsequent target service authorization control based on session-level temporary tokens.

[0055] Step S300 is: receiving an AI Agent call request initiated by the business system based on the session-level temporary token. The AI ​​Agent call request carries the session-level temporary token, the target service identifier, and the user identity transparent data packet. The user identity transparent data packet includes the user identity encrypted payload.

[0056] In this step, the AI ​​Agent platform receives an AI Agent call request initiated by the business system. This AI Agent call request occurs after step S200 generates and returns a session-level temporary token. After obtaining the session-level temporary token, the business system can include it in one or more AI Agent call requests, allowing the AI ​​Agent platform to determine whether the call request belongs to an authorized session.

[0057] The session-level temporary token carried in the AI ​​Agent call request will be validated by the AI ​​Agent platform in step S400. The target service identifier is used to indicate the tool service, MCP service, or business service that the AI ​​Agent call request intends to access. The target service identifier will be used to match the authorized service scope in step S400, participate in the generation of data to be signed in step S600, and be used to determine the target MCP service layer in step S800.

[0058] The user identity transparent data packet carries the user identity information to be transparently transmitted. The user identity transparent data packet includes a encrypted user identity payload. This encrypted payload can be data obtained by encrypting the plaintext user identity data using the business system's encryption key before sending the AI ​​Agent call request. The plaintext user identity data may include user identifiers, organization identifiers, role identifiers, permission identifiers, tenant information, or other data used by the business service interface for user-level permission determination.

[0059] In one implementation, the user identity transparent transmission data packet includes a data packet version number, an encryption algorithm identifier, a key identifier, a data packet random number, a data packet generation time, and a user identity encrypted payload. The data packet version number indicates the data structure version of the user identity transparent transmission data packet; the encryption algorithm identifier indicates the encryption algorithm type of the user identity encrypted payload; the key identifier indicates the business system-side key used by the business service interface to subsequently decrypt the user identity encrypted payload; the data packet random number participates in the business system-side encryption process or in ciphertext digest calculation; the data packet generation time enables the business service interface to determine whether the user identity transparent transmission data packet is within the allowed usage time range; and the user identity encrypted payload carries the encrypted user identity plaintext data.

[0060] After receiving the user identity pass-through data packet, the AI ​​Agent platform does not parse the user identity plaintext corresponding to the user identity encrypted payload. Instead, it treats the data packet version number, encryption algorithm identifier, key identifier, data packet random number, data packet generation time, and user identity encrypted payload as a whole pass-through object and performs request-level temporary storage, digest calculation, and envelope forwarding.

[0061] In this embodiment, the AI ​​Agent platform receives the user identity transparent data packet, but does not require the AI ​​Agent platform to possess the corresponding decryption key, nor does it require the AI ​​Agent platform to decrypt the user identity encrypted payload. The user identity transparent data packet is used by the AI ​​Agent platform for subsequent digest calculation, signature binding, and envelope forwarding.

[0062] Step S400 is as follows: perform validity verification on the session-level temporary token carried in the AI ​​Agent call request, and if the session-level temporary token verification passes, obtain the corresponding token context based on the session-level temporary token, and perform authorization verification on the target service identifier based on the authorized service scope in the token context.

[0063] In this step, the AI ​​Agent platform verifies the validity of the session-level temporary token received in step S300. This verification differs from the temporary token request verification in step S200. Step S200 verifies whether the business system is eligible to request a session-level temporary token; this step verifies whether the session-level temporary token carried in this AI Agent call request is still valid, and whether the session-level temporary token allows the call to the service corresponding to the target service identifier.

[0064] The AI ​​Agent platform can parse session-level temporary tokens to obtain the token context to be verified, and can also query the corresponding token context in the token state storage area based on the unique token identifier in the session-level temporary token. The AI ​​Agent platform can determine whether the signature of the session-level temporary token is valid, whether the token state is valid, whether the current time is between the token's effective time and expiration time, and whether the unique token identifier exists in the token state storage area.

[0065] If the session-level temporary token passes validity verification, the AI ​​Agent platform obtains the corresponding token context and performs authorization verification on the target service identifier based on the authorized service scope in the token context. Specifically, the AI ​​Agent platform determines whether the target service identifier falls within the authorized service scope. If the target service identifier falls within the authorized service scope, the target service identifier passes the authorization verification; if the target service identifier does not fall within the authorized service scope, the platform forwarding envelope is not generated.

[0066] This step allows the AI ​​Agent platform to determine whether the current AI Agent call request is within the scope of a valid session authorization and whether the target service is a service allowed by that session before the user identity transparent data packet is forwarded. This step avoids indiscriminate forwarding based solely on business system access credentials or a single token, ensuring that subsequent user identity transparent data packets establish a correspondence with legitimate session authorization and target service calls.

[0067] The token context obtained in this step will be used to generate data to be signed in step S600; the business system identifier and the unique token identifier will participate in the generation of the platform forwarding signature, thereby binding the subsequent platform forwarding envelope with the business system source and session authorization identifier.

[0068] Step S500 is as follows: if the target service identifier passes the authorization verification, the user identity transparent data packet is written into the request-level context corresponding to the AI ​​Agent call request, and without decrypting the user identity transparent data packet, a digest calculation is performed on the user identity transparent data packet to obtain a ciphertext digest.

[0069] In this step, after confirming that the session-level temporary token is valid and the target service identifier passes the authorization verification, the AI ​​Agent platform performs opaque processing on the platform side for the user identity transparent data packet.

[0070] Request-level contexts are used to store data related to a single AI Agent invocation request within its processing cycle. A request-level context can be an in-memory data structure, a request context object, a thread context, a coroutine context, a temporary field in a session context, or any other structure capable of temporarily storing data during the request processing cycle. The request-level context corresponds to the AI ​​Agent invocation request and is used to establish the association between the AI ​​Agent invocation request, the target service identifier, and the user identity transparent data packet.

[0071] After writing the user identity pass-through data packet into the request-level context, the AI ​​Agent platform performs a digest calculation on the user identity pass-through data packet without decrypting it, obtaining a ciphertext digest. The digest calculation can be performed on all ciphertext fields in the user identity pass-through data packet, or on a preset set of digest fields. For example, the digest calculation can be performed on the user identity ciphertext payload, or on a combination of the user identity ciphertext payload, encryption algorithm identifier, key identifier, and data packet random number.

[0072] In one implementation, the AI ​​Agent platform performs digest calculations on the user identity transparent data packets according to a preset digest field set. The preset digest field set includes at least the user identity encrypted payload, encryption algorithm identifier, key identifier, data packet random number, and data packet generation time. The AI ​​Agent platform reads each field in the preset digest field set in a preset field order and performs normalized serialization on each field to obtain the data to be digested. The normalized serialization includes: using a unified character encoding to represent field values, arranging fields in a preset field order, using a preset null value identifier to represent null fields, and adding a preset separator between adjacent fields. The AI ​​Agent platform performs digest calculations on the data to be digested to obtain the encrypted digest.

[0073] Since the ciphertext digest calculation includes the user identity ciphertext payload and the encryption algorithm identifier, key identifier, and data packet random number associated with the user identity ciphertext payload, if the user identity ciphertext payload or any field involved in the digest calculation changes during forwarding, the ciphertext digest recalculated by the target MCP service layer or business service interface will not match the platform forwarding signature.

[0074] The ciphertext digest is used to generate the data to be signed in step S600. Since the ciphertext digest is calculated based on the user identity transparent data packet, if the user identity transparent data packet is replaced or tampered with during subsequent forwarding, the ciphertext digest recalculated by the target MCP service layer or business service interface will not correspond to the platform forwarding signature, thus enabling the detection of data inconsistency.

[0075] The technical advantage of this step is that the AI ​​Agent platform can generate digest data for integrity binding without decrypting the user identity transparent data packet, enabling the user identity transparent data packet to participate in subsequent platform forwarding signature, while preventing the AI ​​Agent platform from obtaining the user's identity in plaintext.

[0076] In one implementation, the AI ​​Agent platform establishes an independent request-level context for each AI Agent invocation request. Different AI Agent invocation requests correspond to different request identifiers. The AI ​​Agent platform manages the request-level contexts in isolation based on the request identifiers, prohibiting the reuse or reading of user identity transparent data packets between different request-level contexts. The request-level context is only valid within the processing cycle of the current AI Agent invocation request. After the platform has completed the generation and sending of the forwarding envelope, the request processing has failed, or the request processing has timed out, the AI ​​Agent platform releases the corresponding request-level context and deletes the temporarily stored user identity transparent data packets within it.

[0077] Step S600 is as follows: Generate data to be signed based on the ciphertext digest, the business system identifier, the token unique identifier and the target service identifier, and perform signature processing on the data to be signed to obtain the platform forwarding signature.

[0078] In this step, the AI ​​Agent platform combines the ciphertext digest obtained in step S500 with the business system identifier, the unique token identifier in the token context obtained in step S400, and the target service identifier received in step S300 to generate data to be signed.

[0079] The encrypted digest is used to characterize the integrity of the user identity transparent data packet; the business system identifier is used to characterize the business system source corresponding to the AI ​​Agent call request; the unique token identifier is used to characterize the session authorization corresponding to the AI ​​Agent call request; and the target service identifier is used to characterize the target service to be accessed in this call request. All of the above data participate in the generation of the data to be signed, establishing a binding relationship between the user identity transparent data packet and the business system, session authorization, and target service call.

[0080] In one implementation, the AI ​​Agent platform can concatenate the ciphertext digest, business system identifier, token unique identifier, and target service identifier according to a preset field order to obtain the data to be signed. In another implementation, the AI ​​Agent platform can construct the above fields into structured data, such as key-value pairs, serialized objects, or normalized strings, and then perform signing processing on the structured data.

[0081] In one implementation, the data to be signed includes a ciphertext digest, a request identifier, a business system identifier, a unique token identifier, a target service identifier, and a target MCP service identifier. The AI ​​Agent platform normalizes and combines these fields according to a preset signature field order to obtain the data to be signed. The preset signature field order can be: ciphertext digest, request identifier, business system identifier, unique token identifier, target service identifier, and target MCP service identifier. For missing fields, the AI ​​Agent platform refuses to generate a platform forwarding signature; for null fields, the AI ​​Agent platform fills them in according to a preset null value identifier.

[0082] By incorporating the ciphertext digest, request identifier, business system identifier, token unique identifier, target service identifier, and target MCP service identifier into the data to be signed, the platform can bind the user identity transparent data packet, the current AI Agent call request, the business system source, the session-level temporary token, the target service, and the target MCP service layer when forwarding the signature, thus preventing the user identity transparent data packet from being used for other requests, other sessions, or other target services.

[0083] Signature processing can employ either symmetric or asymmetric signature methods. The platform forwarding signature is used by the target MCP service layer or business service interface to verify whether the platform forwarding envelope was generated by the AI ​​Agent platform, and whether the binding relationship between the user identity transparent data packet, business system identifier, token unique identifier, and target service identifier has been disrupted. The specific signature algorithm can be selected based on system security requirements; this embodiment does not impose a unique limitation on the signature algorithm.

[0084] The technical effect of this step is that, through signature processing, the encrypted digest of the user identity pass-through data packet is bound to the calling context, so that the user identity pass-through data packet is no longer an ordinary request parameter, but verifiable pass-through data associated with a specific business system, specific session authorization and specific target service.

[0085] Step S700 is as follows: Based on the user identity transparent data packet, signature association data and the platform forwarding signature, a platform forwarding envelope is generated; wherein, the signature association data includes the business system identifier, the token unique identifier and the target service identifier.

[0086] In this step, the AI ​​Agent platform generates a platform forwarding envelope. The platform forwarding envelope is a data structure used to send data to the target MCP service layer. The platform forwarding envelope includes at least the user identity transparent data packet, signature association data, and a platform forwarding signature.

[0087] The user identity pass-through data packet is written into the platform forwarding envelope as the object to be pass-through. This user identity pass-through data packet maintains a correspondence with the data packet received by the AI ​​Agent platform in step S300. The signature association data includes the business system identifier, the token unique identifier, and the target service identifier. The signature association data is used by the subsequent target MCP service layer or business service interface to reconstruct the signature to be verified data based on the same fields. The platform forwarding signature is used for subsequent signature verification.

[0088] In one implementation, the platform forwarding envelope can adopt a structured message format, including a transparent data field, a signature association field, and a signature field. The transparent data field stores the user identity transparent data packet; the signature association field stores the business system identifier, the token unique identifier, and the target service identifier; and the signature field stores the platform forwarding signature.

[0089] In one implementation, the platform forwarding envelope includes an envelope version field, a transparent data field, a signature association field, and a signature field. The envelope version field indicates the data structure version of the platform forwarding envelope; the transparent data field stores the user identity transparent data packet; the signature association field stores the business system identifier, the token unique identifier, the target service identifier, the request identifier, and the target MCP service identifier; and the signature field stores the platform forwarding signature.

[0090] Among them, the user identity transparent data packet in the transparent data field is consistent with the user identity transparent data packet received by the AI ​​Agent platform in S300; the fields in the signature association field are consistent with the fields involved in the generation of data to be signed in S600; the platform forwarding signature in the signature field is used to enable the target MCP service layer or business service interface to verify the binding relationship between the user identity transparent data packet and the signature association field.

[0091] In another implementation, the platform forwarding envelope can be carried by both the request header and the request body. For example, the request header can carry signature association data and the platform forwarding signature, and the request body can carry the user identity pass-through data packet.

[0092] The purpose of this step is to encapsulate the user identity data packet to be forwarded, the context data used for signature verification, and the platform signature result in the same forwarding structure. This makes it easier for the target MCP service layer to forward the entire data packet without parsing the user identity content, and also makes it easier for subsequent business service interfaces to perform integrity verification based on the platform forwarding envelope.

[0093] In one implementation, the user identity transparent data packet includes a data packet version number, an encryption algorithm identifier, a key identifier, a data packet random number, a data packet generation time, and a user identity encrypted payload. When calculating the encrypted digest, the AI ​​Agent platform reads the encryption algorithm identifier, key identifier, data packet random number, data packet generation time, and user identity encrypted payload according to a preset digest field set, and performs normalized serialization on the above fields according to a preset field order to obtain the data to be digested. The normalized serialization includes arranging the fields in ascending order of field name or a preset field order, using preset placeholders to represent null fields, and generating a string using a unified character encoding. The AI ​​Agent platform performs digest calculation on the data to be digested to obtain the encrypted digest.

[0094] In one implementation, when the AI ​​Agent platform generates data to be signed, it combines the ciphertext digest, request identifier, business system identifier, token unique identifier, target service identifier, and target MCP service identifier according to a preset field order, and then performs normalized serialization on the combined fields to obtain the data to be signed. The AI ​​Agent platform signs the data to be signed based on the platform-side signing key to obtain the platform forwarding signature. Thus, the platform forwarding signature simultaneously binds the ciphertext content of the user identity transparent data packet, the current request, the business system source, the session-level temporary token, and the target service invocation object.

[0095] In one implementation, after receiving the platform forwarding envelope, the target MCP service layer or business service interface reads the user identity transparent data packet, signature association data, and platform forwarding signature from the platform forwarding envelope. Following the same digest field set and standardized serialization method as the AIAgent platform, it recalculates the ciphertext digest of the user identity transparent data packet. Then, based on the recalculated ciphertext digest and signature association data, it reconstructs the data to be verified and verifies the platform forwarding signature. If the verification passes, it is determined that the user identity transparent data packet matches the current business system, the current request, the current session authorization, and the current target service; if the verification fails, it refuses to continue processing the user identity transparent data packet.

[0096] In one implementation, the AI ​​Agent platform establishes an independent request-level context for each AI Agent invocation request. This request-level context, indexed by a request identifier, stores the target service identifier, the user identity transparent data packet, and the processing status. The request-level context is only valid within the processing cycle of the current AI Agent invocation request and is released after the platform completes forwarding the envelope, the call fails, or the call times out. The logs generated by the AI ​​Agent platform only include the request identifier, business system identifier, target service identifier, processing status, error code, and timestamp; they do not record the plaintext user identity after decryption of the user identity transparent data packet.

[0097] In one implementation, after receiving the platform forwarding envelope, the target MCP service layer or business service interface reads the user identity transparent data packet, signature association data, and platform forwarding signature from the platform forwarding envelope. The target MCP service layer or business service interface recalculates the ciphertext digest of the user identity transparent data packet according to the same digest field set and normalized serialization rules as the AI ​​Agent platform; then, based on the recalculated ciphertext digest and signature association data, it reconstructs the data to be verified according to the same preset signature field order as the AI ​​Agent platform; finally, it verifies the platform forwarding signature based on the platform-side verification key.

[0098] If the signature verification passes, it confirms that the user identity transparent data packet in the platform forwarding envelope matches the current business system identifier, token unique identifier, target service identifier, request identifier, and target MCP service identifier, and confirms that the user identity transparent data packet has not been replaced or tampered with after being forwarded by the AI ​​Agent platform. If the signature verification fails, it refuses to continue processing the platform forwarding envelope, or refuses to continue forwarding the user identity transparent data packet to the business service interface.

[0099] In one optional implementation, the target MCP service layer only performs integrity verification and forwarding of the platform forwarding envelope, without decrypting the user identity encrypted payload; after the signature is verified, the business service interface determines the decryption key on the business system side according to the key identifier in the user identity transparent data packet, and decrypts the user identity encrypted payload to obtain the user identity plaintext data and perform user-level permission judgment.

[0100] Step S800 is as follows: Determine the target MCP service layer based on the target service identifier, and send the platform forwarding envelope to the target MCP service layer.

[0101] In this step, the AI ​​Agent platform determines the target MCP service layer based on the target service identifier. The target service identifier can correspond to a service routing mapping relationship. The AI ​​Agent platform can query the service routing mapping relationship based on the target service identifier to determine the corresponding target MCP service identifier, and then determine the access address, service call protocol, or interface path of the target MCP service layer based on the target MCP service identifier.

[0102] After identifying the target MCP service layer, the AI ​​Agent platform sends the platform forwarding envelope generated in step S700 to the target MCP service layer. The sending method can be an HTTP request, RPC call, message queue delivery, event call, or other inter-service communication methods. The user identity transparent data packet, signature association data, and platform forwarding signature from the platform forwarding envelope are all sent to the target MCP service layer.

[0103] The technical effect of this step is that it enables the target service identifier to participate in authorization verification, signature binding, and routing forwarding simultaneously. The target service identifier is not only used to select the target MCP service layer, but it has also undergone authorization verification in step S400 and participated in platform forwarding signature in step S600. Therefore, when the platform forwarding envelope is sent to the target MCP service layer, it has already formed a binding relationship with the authorized target service.

[0104] In one implementation, if the AI ​​Agent platform fails to find the corresponding service routing mapping relationship based on the target service identifier, or if the found target MCP service layer access address is unavailable, the AI ​​Agent platform refuses to send the platform forwarding envelope and records the routing failure status corresponding to the request identifier, business system identifier, and target service identifier. If the AI ​​Agent platform times out or fails to send the platform forwarding envelope to the target MCP service layer, it releases the request-level context corresponding to the AI ​​Agent call request and generates an exception log that does not contain the user's identity in plaintext. This avoids continuing to retain the user's identity and pass-through data packets when the target service is unreachable.

[0105] In one implementation, the credential verification data in step S200 includes credential status, business system identifier, signature verification key, and time window parameters.

[0106] Credential status is used to determine whether system-level access credentials are available. Credential status can include available, disabled, revoked, or temporarily locked. If the credential status is not available, the AI ​​Agent platform will refuse to generate a session-level temporary token.

[0107] The business system identifier is used to identify the business system corresponding to the system-level access credential. This business system identifier is subsequently written into the token context and further participates in the generation of data to be signed.

[0108] The signature verification key is used to verify the signature of the first request. The AI ​​Agent platform can generate a local request signature based on the signature verification key and the application timestamp, and compare the local request signature with the first request signature. If they match, it means that the temporary token application request matches the signature verification key of the corresponding business system.

[0109] The time window parameter is used to determine whether the application timestamp falls within the allowed application time range. By setting the time window parameter, the risk of historical temporary token application requests being submitted repeatedly can be reduced.

[0110] This implementation further defines the system-level access credential verification process, requiring that a temporary token application request must simultaneously meet the requirements of credential status, time window, and signature consistency before it can enter the session-level temporary token issuance stage.

[0111] In one implementation, the token context also includes a tenant identifier, a token activation time, and a token expiration time.

[0112] Tenant identifiers are used to distinguish data boundaries between different tenants or different business organizations. The AI ​​Agent platform can determine the tenant identifier based on credential verification data and write the tenant identifier into the token context for subsequent tenant-wide authorization control or log attribution.

[0113] The token activation and expiration times are used to limit the validity period of session-level temporary tokens. The AI ​​Agent platform can determine the token activation and expiration times based on the token generation time and the preset validity period. The preset validity period can be configured according to the system security policy and is not limited to a fixed value.

[0114] The unique token identifier is used to uniquely identify this session-level temporary token. After generating the unique token identifier, the AI ​​Agent platform can write the unique token identifier and the token status to the token status storage area. The token status storage area can be used for subsequent queries to determine whether the token is valid, revoked, or expired.

[0115] This implementation enables session-level temporary tokens to carry not only business system and authorization scope information, but also time boundary and state management capabilities, thereby providing a data foundation for validity verification in step S400.

[0116] In one implementation, step S400 involves validating the session-level temporary token, including parsing the session-level temporary token to obtain the token context to be verified.

[0117] The AI ​​Agent platform queries the token status storage area based on the unique token identifier in the context of the token to be verified to obtain the token status. If the token status is valid, it continues to perform time-based checks and authorized service scope matching; if the token status is invalid, it refuses to generate a platform forwarding envelope.

[0118] The AI ​​Agent platform determines whether the current time is between the token's effective time and its expiration time. If the current time is earlier than the token's effective time or later than its expiration time, it means that the current session-level temporary token should not be used for this AI Agent call request.

[0119] The AI ​​Agent platform also matches the target service identifier with the authorized service scope. The authorized service scope can be a list of service identifiers, a service group, a set of service types, a set of interface permissions, or other data structures representing the allowed access range. If the target service identifier falls within the authorized service scope, the target service identifier passes the authorization verification; otherwise, the platform forwarding envelope is not generated.

[0120] This implementation method enables the AI ​​Agent platform to perform dual judgments on session validity and target service authorization scope before generating the platform forwarding envelope, thereby preventing unauthorized target service calls from continuing into the identity pass-through process.

[0121] In one implementation, the user identity pass-through data packet also includes an encryption algorithm identifier, a key identifier, and a data packet random number.

[0122] The encryption algorithm identifier indicates the type of encryption algorithm used by the business system to generate the encrypted user identity payload. The key identifier indicates the key required by subsequent business service interfaces to decrypt the encrypted user identity payload. The packet random number is used to differentiate the user identity transparent data packets in different requests, thereby reducing the probability of generating duplicate encrypted payloads for the same plaintext user identity data.

[0123] The user identity encrypted payload is the encrypted payload obtained by encrypting the user identity plaintext data using the encryption key on the business system side. The user identity plaintext data may include at least one of the following: user identifier, organization identifier, role identifier, and permission identifier. The AI ​​Agent platform does not hold the encryption key on the business system side, therefore it cannot obtain the user identity plaintext data based on the user identity transparent data packet.

[0124] After receiving the user identity transparent data packet, the AI ​​Agent platform can process the user identity encrypted payload, encryption algorithm identifier, key identifier, and data packet random number as a whole. In other words, the AI ​​Agent platform can perform digest calculation and envelope forwarding on this whole, but it does not parse the user identity content within it.

[0125] This implementation further supports the platform-side processing boundary of "pass-through but not parsing".

[0126] In one implementation, step S500 includes generating a request identifier for the AI ​​Agent invocation request. The request identifier is used to uniquely identify this AI Agent invocation request. The request identifier can be generated by the AI ​​Agent platform, or it can be generated based on the request reception time, session identifier, and random data.

[0127] The AI ​​Agent platform establishes a relationship between the request identifier, the target service identifier, and the user identity transparent data packet within the request-level context. Through this relationship, the AI ​​Agent platform can accurately read the user identity transparent data packet corresponding to the current AI Agent call request when subsequently generating data to be signed or platform forwarding envelopes, thus avoiding data mixing between different requests.

[0128] The AI ​​Agent platform reads the user identity transparent data packet based on this relationship and performs digest calculation on all ciphertext fields or the preset digest field set in the user identity transparent data packet to obtain the ciphertext digest. All ciphertext fields may include the user identity ciphertext payload and the data fields that together with the ciphertext payload constitute the transparent data packet; the preset digest field set can be predefined according to the system implementation.

[0129] The request-level context is used to temporarily store user identity data packets during the AI ​​Agent's request processing cycle. Once the request is processed, the request-level context can be released. This approach eliminates the need for the user identity data packets to be stored permanently by the platform as user identity data.

[0130] In one implementation, in step S600, the AI ​​Agent platform reads the request identifier from the request-level context and determines the target MCP service identifier based on the target service identifier.

[0131] The request identifier is used to bind the platform forwarding signature to a single AI Agent invocation request. The target MCP service identifier is used to identify the MCP service layer or MCP service instance that subsequently receives the platform forwarding envelope. Including the target MCP service identifier in the data to be signed allows the platform forwarding signature to bind both the target service and the target MCP service layer.

[0132] The AI ​​Agent platform combines the ciphertext digest, request identifier, business system identifier, token unique identifier, target service identifier, and target MCP service identifier in a preset field order to obtain the data to be signed. The preset field order can be pre-configured by the system to ensure that the signer and the verifier can construct the data to be signed or verified based on the same order.

[0133] The AI ​​Agent platform processes the data to be signed using the platform-side signature key to obtain the platform-forwarded signature. The platform-side signature key can be a symmetric key or a private key from an asymmetric key. This embodiment does not limit the specific signature algorithm, as long as it enables the target MCP service layer or business service interface to verify the correspondence between the platform-forwarded signature and the data to be verified.

[0134] In one implementation, the signature association data also includes a request identifier and a target MCP service identifier.

[0135] When the AI ​​Agent platform generates the platform forwarding envelope, it writes the user identity transparent data packet as the object to be transparent into the platform forwarding envelope, writes the business system identifier, token unique identifier, target service identifier, request identifier, and target MCP service identifier as signature association data into the platform forwarding envelope, and writes the platform forwarding signature into the platform forwarding envelope.

[0136] The platform forwarding envelope is used to enable the target MCP service layer or business service interface to recalculate the ciphertext digest based on the user's identity and transparently transmit data packets. It then verifies the platform forwarding signature based on the recalculated ciphertext digest and the associated signature data. The target MCP service layer or business service interface can be a subsequent business service interface or a trusted service node with signature verification capabilities.

[0137] This implementation method enables the platform forwarding envelope to have a clear signature verification data structure, avoiding the inability of the target MCP service layer or business service interface to determine which fields should be used to reconstruct the signature verification data.

[0138] In one implementation, the AI ​​Agent platform queries the service routing mapping relationship based on the target service identifier to determine the target MCP service identifier corresponding to the target service identifier.

[0139] The service routing mapping relationship can store the correspondence between the target service identifier and the target MCP service identifier, and can also further store the access address, protocol type, interface path, call timeout or other routing parameters of the target MCP service layer.

[0140] The AI ​​Agent platform determines the access address of the target MCP service layer based on the target MCP service identifier, and sends the platform forwarding envelope to that access address according to the service invocation protocol corresponding to the target MCP service layer. The service invocation protocol can be HTTP, RPC, message queue protocol, or other inter-service invocation protocols.

[0141] The user identity pass-through data packet in the platform forwarding envelope sent to the target MCP service layer is consistent with the user identity pass-through data packet received in step S300. This consistency means that the user identity ciphertext payload and the fields used to construct the ciphertext digest in the user identity pass-through data packet are not modified by the AI ​​Agent platform.

[0142] This implementation further defines how the target service identifier is used in the routing and forwarding process, so that the target service identifier is actually used in authorization verification, signature binding and MCP service layer determination.

[0143] In one implementation, the method further includes an exception control process.

[0144] When a temporary token request fails to be verified, the AI ​​Agent platform records the number of failed requests corresponding to the system-level access credential identifier. If the number of failed requests reaches a preset failure threshold, the AI ​​Agent platform sets the system-level access credential corresponding to that system-level access credential identifier to a temporarily locked state. In the temporarily locked state, the AI ​​Agent platform can reject temporary token request requests initiated based on that system-level access credential identifier.

[0145] When session-level temporary token verification fails or the target service identifier fails authorization verification, the AI ​​Agent platform refuses to generate a platform forwarding envelope. This prevents AI Agent call requests that have not passed session authorization or target service authorization from continuing into the user identity pass-through stage.

[0146] When the platform completes forwarding the envelope, the AI ​​Agent call request fails to process, or the AI ​​Agent call request times out, the AI ​​Agent platform releases the request-level context. After releasing the request-level context, the AI ​​Agent platform no longer retains the user identity transparent data packets temporarily stored in that request-level context.

[0147] The log records generated for AI Agent call requests do not contain the plaintext user identity data after decryption of the user identity transparent data packet. Since the AI ​​Agent platform does not hold the encryption key from the business system side, it typically cannot decrypt the user identity transparent data packet; for log records, only non-plaintext fields such as request identifier, target service identifier, business system identifier, processing status, and error code can be recorded. This implementation further reduces the possibility of the platform side accessing or retaining the user identity plaintext.

[0148] In one implementation, the number of failed applications is counted based on a system-level access credential identifier and a preset statistical time window. The preset statistical time window can be configured according to the system security policy. If the number of failed applications for the same system-level access credential identifier within the preset statistical time window reaches a preset failure threshold, the AI ​​Agent platform sets the system-level access credential corresponding to that system-level access credential identifier to a temporary locked state. The temporary lock state can be automatically released after the preset lock duration expires, or it can be released after the administrator completes security verification.

[0149] In one implementation, when the AI ​​Agent platform generates log records for AI Agent call requests, it uses a log field whitelist method to record the logs. The log field whitelist includes at least one of the following: request identifier, business system identifier, target service identifier, target MCP service identifier, unique token identifier, processing status, error code, and processing timestamp. The log records do not contain the plaintext user identity data after decryption of the user identity transparent transmission data packet; and unless there is a need to locate problems with encrypted transmission, the log records do not store the full text of the encrypted user identity payload. This reduces the risk of the platform retaining user identity data due to log records.

[0150] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

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

Claims

1. A method for layered authentication and user information pass-through in an AI Agent platform, characterized in that, The method, executed by the AI ​​Agent platform, includes: S100, receive a temporary token application request sent by the business system, wherein the temporary token application request carries a system-level access credential identifier, an application timestamp, and a first request signature; S200: Obtain credential verification data based on the system-level access credential identifier, and verify the application timestamp and the first request signature based on the credential verification data. If the verification passes, generate a session-level temporary token and a token context corresponding to the session-level temporary token, and return the session-level temporary token to the business system. The token context includes at least a business system identifier, a unique token identifier, and an authorized service scope. S300, receive the AI ​​Agent call request initiated by the business system based on the session-level temporary token, the AI ​​Agent call request carries the session-level temporary token, the target service identifier and the user identity transparent data packet, the user identity transparent data packet includes the user identity encrypted payload; S400, perform validity verification on the session-level temporary token carried in the AI ​​Agent call request, and if the session-level temporary token verification passes, obtain the corresponding token context based on the session-level temporary token, and perform authorization verification on the target service identifier based on the authorized service scope in the token context; S500, if the target service identifier passes the authorization verification, the user identity transparent data packet is written into the request-level context corresponding to the AI ​​Agent call request, and the digest of the user identity transparent data packet is calculated without decrypting the user identity transparent data packet to obtain the ciphertext digest. S600, generate data to be signed based on the ciphertext digest, the business system identifier, the token unique identifier and the target service identifier, and perform signature processing on the data to be signed to obtain the platform forwarding signature; S700, a platform forwarding envelope is generated based on the user identity transparent data packet, signature association data, and the platform forwarding signature; wherein, the signature association data includes the business system identifier, the token unique identifier, and the target service identifier; S800, determine the target MCP service layer based on the target service identifier, and send the platform forwarding envelope to the target MCP service layer.

2. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 1, characterized in that, In step S200, the credential verification data includes credential status, business system identifier, signature verification key, and time window parameters; The verification of the application timestamp and the first request signature based on the credential verification data includes: Determine whether the system-level access credential corresponding to the system-level access credential identifier is in an available state based on the credential status. Determine whether the application timestamp is within the allowed application time range based on the time window parameter; A local request signature is generated based on the signature verification key and the application timestamp; Compare the local request signature with the first request signature; If the system-level access credential is available, the application timestamp is within the allowed application time range, and the local request signature is consistent with the first request signature, then the temporary token application request is determined to have passed verification.

3. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 1, characterized in that, In step S200, the token context further includes a tenant identifier, a token effective time, and a token expiration time; The generation of the session-level temporary token and the token context corresponding to the session-level temporary token includes: The business system identifier, the tenant identifier, and the authorized service scope are determined based on the credential verification data. The token's effective time and expiration time are determined based on the token's generation time and preset validity period. Generate the unique identifier for the token; The token context is generated based on the business system identifier, the tenant identifier, the authorized service scope, the token effective time, the token expiration time, and the token unique identifier; The session-level temporary token is generated based on the token context, and the unique identifier of the token and the token state are written into the token state storage area.

4. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 3, characterized in that, In step S400, the validity of the session-level temporary token carried in the AI ​​Agent call request is verified, and the authorization verification of the target service identifier is performed based on the authorized service scope in the token context, including: Parse the session-level temporary token to obtain the context of the token to be verified; The token status is obtained by querying the token status storage area based on the unique token identifier in the context of the token to be verified. Determine whether the current time is between the token's effective time and the token's expiration time; Match the target service identifier with the authorized service scope; If the token is in a valid state, the current time is between the token's effective time and its expiration time, and the target service identifier belongs to the authorized service scope, then the session-level temporary token verification is determined to be successful and the target service identifier passes the authorization verification. If the token is invalid, the current time is not between the token's effective time and its expiration time, or the target service identifier is not within the scope of the authorized service, the platform forwarding envelope will not be generated.

5. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 1, characterized in that, In S300, the user identity transparent data packet also includes an encryption algorithm identifier, a key identifier, and a data packet random number; The user identity encrypted payload is an encrypted payload obtained by encrypting the user identity plaintext data based on the encryption key on the business system side. The user identity plaintext data includes at least one of user identifier, organization identifier, role identifier, and permission identifier. The AI ​​Agent platform does not hold the encryption key on the business system side, and after receiving the user identity transparent data packet, it transmits the user identity encrypted payload, the encryption algorithm identifier, the key identifier, and the data packet random number as a whole.

6. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 1, characterized in that, In step S500, the user identity transparent data packet is written into the request-level context corresponding to the AI ​​Agent call request, and a digest calculation is performed on the user identity transparent data packet without decrypting it to obtain a ciphertext digest, including: Generate a request identifier for the AI ​​Agent invocation request; Establish the association between the request identifier, the target service identifier, and the user identity transparent data packet in the request-level context; Read the user identity transparent data packet based on the aforementioned association; The ciphertext digest is obtained by performing a digest calculation on all ciphertext fields or a preset digest field set in the user identity transparent data packet. The request-level context is used to temporarily store the user identity transparent data packet during the processing cycle of the AI ​​Agent call request.

7. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 6, characterized in that, In step S600, data to be signed is generated based on the ciphertext digest, the business system identifier, the token unique identifier, and the target service identifier, including: Read the request identifier from the request-level context; Determine the target MCP service identifier based on the target service identifier; The encrypted digest, the request identifier, the business system identifier, the unique token identifier, the target service identifier, and the target MCP service identifier are combined in a preset field order to obtain the data to be signed; The step of signing the data to be signed to obtain the platform forwarding signature includes: The data to be signed is processed using the platform-side signature key to obtain the platform forwarding signature.

8. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 7, characterized in that, In S700, the signature association data further includes the request identifier and the target MCP service identifier; The process of generating a platform forwarding envelope based on the user identity transparent data packet, signature association data, and the platform forwarding signature includes: Write the user identity transparent data packet as the object to be transparently transmitted into the platform forwarding envelope; The business system identifier, the unique token identifier, the target service identifier, the request identifier, and the target MCP service identifier are written as signature association data into the platform forwarding envelope; Write the platform forwarding signature into the platform forwarding envelope; The platform forwarding envelope is used to enable the target MCP service layer or business service interface to recalculate the ciphertext digest based on the user identity transparent data packet, and to verify the platform forwarding signature based on the recalculated ciphertext digest and the signature association data.

9. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 7, characterized in that, In step S800, determining the target MCP service layer based on the target service identifier and sending the platform forwarding envelope to the target MCP service layer includes: Based on the target service identifier, query the service routing mapping relationship to determine the target MCP service identifier corresponding to the target service identifier; The access address of the target MCP service layer is determined based on the target MCP service identifier; According to the service invocation protocol corresponding to the target MCP service layer, the platform forwarding envelope is sent to the access address; The user identity transparent data packet sent to the platform forwarding envelope of the target MCP service layer is consistent with the user identity transparent data packet received by S300.

10. The layered authentication and user information pass-through method of the AI ​​Agent platform according to claim 1, characterized in that, The method also includes an exception control process associated with the temporary token request, the AI ​​Agent invocation request, and the request-level context; The anomaly control process includes: If the temporary token application request verification fails, the number of application failures corresponding to the system-level access credential identifier is recorded, and when the number of application failures reaches a preset failure threshold, the system-level access credential corresponding to the system-level access credential identifier is set to a temporary locked state. If the session-level temporary token verification fails or the target service identifier fails the authorization verification, the platform forwarding envelope will not be generated. The request-level context is released when the platform forwarding envelope is completed, the AI ​​Agent call request processing fails, or the AI ​​Agent call request processing times out. Specifically, the log records generated for the AI ​​Agent call request do not contain the plaintext of the user identity after the user identity pass-through data packet is decrypted.

Images