Intelligent agent credential verification method and system, storage medium and product

Abstract

The application discloses an intelligent agent credential verification method and system, a storage medium and a product, relates to the technical field of intelligent agent identity management, and comprises the following steps: obtaining identity metadata of a container instance initiating an authentication request, injecting the identity metadata into the authentication request to obtain a target authentication request; performing joint verification based on the identity metadata, intelligent agent special credentials and a user identifier in the target authentication request to generate a verification result; and issuing an access token bound with the identity metadata to the intelligent agent according to the verification result. The application realizes environment identity enhancement of the authentication request by injecting container identity metadata, realizes security control that credentials can be used only after passing multi-dimensional verification by joint verification, and realizes the use restriction that tokens are valid only in authorized containers by issuing access tokens bound with identity metadata, thereby improving the security of intelligent agent access to a business system.

Description

Technical Field

[0001] This application relates to the field of intelligent agent identity governance technology, and in particular to an intelligent agent credential verification method, system, storage medium and product. Background Technology

[0002] As enterprise-grade generative AI agents are deployed at scale in scenarios such as office collaboration and process automation, these agents frequently need to access internal business systems using employee credentials. Traditional solutions typically reuse employee single sign-on credentials or configure business-specific credentials for the agent, allowing it to authenticate and obtain access authorization as a proxy. In a containerized deployment environment, the agent runs in dynamically scheduled and elastically scalable container instances. Its network requests are sent through the container network interface, and the authentication server performs identity verification based on the credential information carried in the request.

[0003] However, existing authentication mechanisms do not verify the agent's operating environment. Once credentials are leaked, they can be migrated to any container instance and misused, which fails to meet the security requirements of enterprises for agent access. Summary of the Invention

[0004] The main purpose of this application is to provide a method, system, storage medium and product for verifying agent credentials, which aims to solve the technical problem that existing authentication mechanisms cannot meet the security requirements of enterprises for access to agents.

[0005] To achieve the above objectives, this application proposes a method for verifying agent credentials, the method comprising: Obtain the identity metadata of the container instance that initiated the authentication request, and inject the identity metadata into the authentication request to obtain the target authentication request; A joint verification is performed based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request to generate a verification result. Based on the verification result, an access token bound to the identity metadata is issued to the intelligent agent.

[0006] In one embodiment, the step of obtaining the identity metadata of the container instance that initiated the authentication request, and injecting the identity metadata into the authentication request to obtain the target authentication request includes: The authentication request is decrypted to obtain the decrypted authentication request; Based on the source network information in the decrypted authentication request, query the runtime interface of the container instance to obtain the identity metadata of the container instance, wherein the identity metadata includes at least one of container identity identifier, namespace, host identity identifier, image identity identifier and creation time; The identity metadata is written into the request header extension field of the decrypted authentication request according to a preset standardized format; The authentication request after the data is written is re-encrypted to obtain the target authentication request.

[0007] In one embodiment, the step of performing joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request to generate a verification result includes: Perform validity verification on the agent-specific credentials in the target authentication request; After the validity verification is passed, the attribution relationship between the agent-specific credential and the user identifier is verified. After the attribution verification is passed, the identity metadata carried in the target authentication request is extracted, and the identity metadata is compared with the container identity identifier pre-bound to the smart agent's special credentials. If the consistency comparison passes, a first verification result indicating that the characterization verification has passed is generated; If any check fails, the subsequent checks are terminated, and a second check result representing the check failure is generated.

[0008] In one embodiment, the step of verifying the attribution relationship between the agent-specific credential and the user identifier includes: Obtain the binding information recorded when the agent-specific credential is generated, wherein the binding information includes the authorized user identifier corresponding to the agent-specific credential; The user identifier in the target authentication request is matched with the authorized user identifier in the binding information to obtain the matching result; If the matching result indicates that the user identifier matches the authorized user identifier, the attribution relationship verification is deemed successful.

[0009] In one embodiment, the step of issuing an access token bound to the identity metadata to the agent based on the verification result includes: If all verification results pass, an initial access identifier is generated, and the container identity identifier and image identity identifier of the current container instance are embedded in the initial access identifier to obtain an access token bound to the identity metadata. If any of the verification results fail, the access token will not be generated, and the authentication event corresponding to the target authentication request will be recorded as an abnormal event.

[0010] In one embodiment, before the steps of obtaining the identity metadata of the container instance that initiated the authentication request, injecting the identity metadata into the authentication request, and obtaining the target authentication request, the method further includes: In response to an explicit authorization operation initiated by the identity platform, a special credential for the intelligent agent is generated; The agent-specific credentials are pre-bound to the user's user identifier and the agent's container namespace, and the corresponding audit logs are recorded. All internal network authentication domain names are uniformly resolved to the service address of the proxy component; When the proxy component receives an authentication request, it blocks authentication requests that do not carry container identity identifiers.

[0011] In one embodiment, after the step of issuing an access token bound to the identity metadata to the intelligent agent based on the verification result, the method further includes: Receive a business access request carrying the access token, and extract the container identity embedded in the access token; Obtain the current identity metadata of the container instance that initiated the business access request; The container identity identifier is compared with the current identity metadata to obtain the comparison result; Based on the comparison results, the service access request can be allowed or denied.

[0012] Furthermore, to achieve the above objectives, this application also proposes an intelligent agent credential verification system, which includes: The acquisition module is used to acquire the identity metadata of the container instance that initiated the authentication request, inject the identity metadata into the authentication request, and obtain the target authentication request. The verification module is used to perform joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request, and generate a verification result. The publishing module is used to publish an access token bound to the identity metadata to the intelligent agent based on the verification result.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the intelligent agent credential verification method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the intelligent agent credential verification method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application obtains the identity metadata of the container instance initiating the authentication request, injects the identity metadata into the authentication request to obtain the target authentication request, performs joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request, and generates a verification result. Based on the verification result, an access token bound to the identity metadata is issued to the agent. It is understood that by injecting container instance identity metadata into the authentication request, the authentication request can carry the identity information of the container runtime environment initiating the request, solving the problem that the authentication server cannot identify the request source environment, and realizing environmental identity enhancement for agent authentication requests. By performing joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request, the authentication server can further verify the binding relationship between the credentials and the user, and between the credentials and the container environment, in addition to verifying the validity of the credentials, achieving security control that credentials can only be used after passing multi-dimensional verification. By issuing access tokens bound to identity metadata to agents, the tokens are associated with specific container instances. Subsequent business access can be verified based on the identity metadata bound to the token and the identity metadata of the current container environment. This solves the problem of token abuse across containers and restricts the use of tokens to be valid only within authorized containers, thereby meeting the security requirements of enterprises for agent access. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the intelligent agent credential verification method of this application. Figure 2 A schematic diagram of the verification result generation process provided by the intelligent agent credential verification method of this application; Figure 3 A schematic diagram of the attribution relationship verification process provided for the intelligent agent credential verification method of this application; Figure 4 This is a flowchart illustrating Embodiment 2 of the intelligent agent credential verification method of this application; Figure 5 This is a schematic diagram of the module structure of the intelligent agent credential verification system according to an embodiment of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: to obtain the identity metadata of the container instance that initiates the authentication request, and to inject the identity metadata into the authentication request to obtain the target authentication request; A joint verification is performed based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request to generate a verification result. Based on the verification result, an access token bound to the identity metadata is issued to the intelligent agent.

[0023] As enterprise-grade generative AI agents are deployed at scale in scenarios such as office collaboration and process automation, these agents frequently need to access internal business systems using employee credentials. Traditional solutions typically reuse employee single sign-on credentials or configure business-specific credentials for the agent, allowing it to authenticate and obtain access authorization as a proxy. In a containerized deployment environment, the agent runs in dynamically scheduled and elastically scalable container instances. Its network requests are sent through the container network interface, and the authentication server performs identity verification based on the credential information carried in the request.

[0024] However, existing authentication mechanisms do not verify the agent's operating environment. Once credentials are leaked, they can be migrated to any container instance and misused, which fails to meet the security requirements of enterprises for agent access.

[0025] This application obtains the identity metadata of the container instance initiating the authentication request, injects the identity metadata into the authentication request to obtain the target authentication request, performs joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request, and generates a verification result. Based on the verification result, an access token bound to the identity metadata is issued to the agent. It is understood that by injecting container instance identity metadata into the authentication request, the authentication request can carry the identity information of the container runtime environment initiating the request, solving the problem that the authentication server cannot identify the request source environment, and realizing environmental identity enhancement for agent authentication requests. By performing joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request, the authentication server can further verify the binding relationship between the credentials and the user, and between the credentials and the container environment, in addition to verifying the validity of the credentials, achieving security control that credentials can only be used after passing multi-dimensional verification. By issuing access tokens bound to identity metadata to agents, the tokens are associated with specific container instances. Subsequent business access can be verified based on the identity metadata bound to the token and the identity metadata of the current container environment. This solves the problem of token abuse across containers and restricts the use of tokens to be valid only within authorized containers, thereby meeting the security requirements of enterprises for agent access.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an intelligent agent credential verification system capable of performing the above functions. The following description uses an intelligent agent credential verification system as an example to illustrate this embodiment and the subsequent embodiments.

[0027] Based on this, embodiments of this application provide a method for verifying agent credentials, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the intelligent agent credential verification method of this application.

[0028] In this embodiment, the agent credential verification method includes steps S10 to S30: Step S10: Obtain the identity metadata of the container instance that initiated the authentication request, inject the identity metadata into the authentication request, and obtain the target authentication request; It should be noted that in a containerized deployment environment, the agent runs within a container instance. When the agent needs to access an internal network business system, the container instance initiates an authentication request. In traditional technologies, a proxy component is deployed on the host machine to intercept and forward authentication requests initiated by the agent. Upon receiving the authentication request, the proxy component decrypts it and forwards it to the authentication server for identity verification. However, existing proxy components only transmit the authentication request, and the request only carries the agent's unique credentials and user identifier, without including information about the runtime environment of the container instance initiating the request. This prevents the authentication server from identifying the source environment of the authentication request. Therefore, this application addresses the issue of the authentication server's inability to identify the source environment of the authentication request by not only forwarding the request after the proxy component intercepts it, but also obtaining the identity metadata of the container instance initiating the request before forwarding and injecting this identity metadata into the authentication request. The identity metadata refers to information that uniquely identifies the runtime environment of the container instance initiating the authentication request, and may include at least one of the following: container identity identifier, namespace, host machine identity identifier, image identity identifier, and creation time. A container identity is a unique identifier assigned to a container instance upon creation. A namespace refers to the logical group to which a container instance belongs. A host identity is the identifier of the physical machine or virtual machine running the container instance. An image identity is the identifier of the image on which the container instance is based. Creation time refers to the startup time of the container instance. A target authentication request is an authentication request injected with identity metadata, enabling downstream authentication servers to identify the container runtime environment from which the request originates.

[0029] Understandably, by adding the acquisition and injection of identity metadata to the proxy component, the authentication request, which originally only carried credential information, can now carry the runtime environment information of the container instance that initiated the request. This solves the problem that the authentication server cannot identify the environment from which the request originates, and enhances the environment identity of the agent's authentication request.

[0030] In one feasible implementation, the steps of obtaining the identity metadata of the container instance that initiated the authentication request, injecting the identity metadata into the authentication request, and obtaining the target authentication request include steps S21 to S24: Step S21: Decrypt the authentication request to obtain the decrypted authentication request; Step S22: Based on the source network information in the decrypted authentication request, query the runtime interface of the container instance to obtain the identity metadata of the container instance. The identity metadata includes at least one of the following: container identity identifier, namespace, host identity identifier, image identity identifier, and creation time. Step S23: Write the identity metadata into the extended field of the request header of the decrypted authentication request according to a preset standardized format; Step S24: Re-encrypt the authentication request after writing the data to obtain the target authentication request.

[0031] It should be noted that decryption refers to parsing the encrypted message of the authentication request, removing the transport layer encryption, and obtaining the plaintext authentication request content. The decrypted authentication request may contain the credentials submitted by the agent, the user identifier, and the source network information of the request message. Source network information refers to the network-level identification information of the container instance initiating the authentication request, which may include the container instance's source network address and network namespace information. The runtime interface refers to the program query interface provided by the container runtime, through which relevant information about the container instance can be queried. The container identity identifier is the unique identifier assigned to the container instance upon creation; the namespace refers to the logical group identifier to which the container instance belongs; the host identity identifier is the identifier of the physical machine or virtual machine running the container instance; the image identity identifier is the identifier of the image on which the container instance is based; and the creation time refers to the container instance's startup timestamp. The preset standardized format refers to the pre-defined writing specifications for request header extension fields, which may include field names, field order, and encoding methods. Request header extension fields refer to the extended areas in the Hypertext Transfer Protocol (HTTP) request header used to carry additional information. A post-written authentication request refers to an authentication request in which identity metadata has been written to the extended fields of the request header but has not yet been re-encrypted.

[0032] Optionally, when the proxy component queries the runtime interface of the container instance, it passes the source network address in the decrypted authentication request as a query parameter to the runtime interface. The runtime interface finds the corresponding container instance based on the source network address, returns the detailed information of the container instance, and extracts the identity metadata from the returned detailed information.

[0033] For example, the decrypted authentication request may include the source network address and network namespace of the request message. The source network address is passed to the container runtime interface for reverse lookup to obtain the container ID, namespace name, host machine ID, image version number, and creation time of the container instance. This information is then written into the extended header fields of the decrypted authentication request in key-value pair format, following the order of field names: container identity, namespace, host machine identity, image identity, and creation time. After writing, the authentication request is re-encrypted to obtain the target authentication request.

[0034] Understandably, by first decrypting the authentication request to obtain the source network information, then using the source network information to reverse query the container runtime interface to obtain identity metadata, and finally writing the identity metadata into the request header extension field and re-encrypting it, the injection operation does not affect the original content of the authentication request. It only adds the environment identity information of the container instance to the request header extension field, and this information comes from the container runtime interface. The container instance itself cannot forge or tamper with it, thus providing a reliable environment identity basis for subsequent joint verification.

[0035] Step S20: Perform joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request to generate a verification result; It should be noted that in traditional technologies, after receiving an authentication request, the authentication server only verifies the validity of the credentials carried in the request, i.e., checks whether the credentials are valid or have been revoked. Once the credential verification is successful, an access token is issued, without verifying the ownership relationship between the credentials and the user, or the container runtime environment from which the request originated. However, in this embodiment, after receiving the target authentication request, the authentication server not only verifies the validity of the credentials but also performs a joint verification based on the identity metadata, agent-specific credentials, and user identifier carried in the target authentication request. The agent-specific credentials refer to an identity credential independently generated for the agent, and this agent-specific credential is isolated from the user terminal credentials. The agent-specific credential is pre-bound to the authorized user's user identifier and the agent's container namespace during generation. The user identifier is a unique identifier for the employee using the agent within the identity platform. Joint verification refers to cross-validating the identity metadata, agent-specific credentials, and user identifier, which may include verifying the validity of the credentials, verifying the ownership relationship between the credentials and the user, and verifying whether the container environment from which the request originated is consistent with the container environment pre-bound to the credentials. The verification results include a first verification result and a second verification result. The first verification result indicates that all joint verifications passed, while the second verification result indicates that at least one item in the joint verification failed.

[0036] Understandably, by jointly verifying identity metadata, agent-specific credentials, and user identifiers, the authentication server can not only verify the validity of the credentials but also further verify whether the credentials were used by an authorized user and whether the authentication request originated from an authorized container runtime environment. This multi-layered, progressive verification method ensures that the authentication request passes verification only when all three conditions—credential validity, user matching, and container environment consistency—are met simultaneously. This solves the problem of credentials being migrated and misused after leaving the authorized user and authorized container, achieving secure control that credentials can only be used after passing multi-dimensional verification.

[0037] In one feasible implementation, refer to Figure 2, Figure 2 This is a schematic diagram of the verification result generation process provided by the intelligent agent credential verification method of this application. The steps for generating the verification result include steps S31 to S35, which involve joint verification based on the identity metadata, intelligent agent-specific credentials, and user identifier in the target authentication request. Step S31: Verify the validity of the agent-specific credentials in the target authentication request; Step S32: After the validity verification passes, verify the attribution relationship between the agent's special credentials and the user identifier; Step S33: After the ownership relationship verification is passed, extract the identity metadata carried in the target authentication request and compare the identity metadata with the container identity identifier pre-bound to the agent's special credentials. Step S34: If the consistency comparison passes, generate the first verification result that the characterization verification has passed; Step S35: If any verification fails, terminate the subsequent verification and generate a second verification result indicating the verification failure.

[0038] It should be noted that validity verification refers to the authentication server's verification of the agent-specific credential's own status, which may include checking whether the credential is valid, revoked, or frozen. Attribution verification refers to the authentication server verifying whether an authorization binding relationship exists between the agent-specific credential and the user currently using the credential, i.e., whether the credential was requested by the user through an explicit authorization operation. The pre-bound container identity identifier refers to the container namespace identifier authorized for use by the credential, recorded by the authentication server when the agent-specific credential is generated. This binding relationship is established when the employee performs an explicit authorization operation and is associated with the credential and stored on the authentication server. Consistency comparison refers to comparing the container namespace in the identity metadata injected by the proxy component in the target authentication request with the pre-bound container namespace when the credential is generated, confirming whether the container instance currently initiating the authentication request belongs to the authorized container namespace. The first verification result indicates that all joint verifications pass, and the authentication server can issue an access token accordingly. The second verification result indicates that at least one item in the joint verification fails, and the authentication server refuses authentication accordingly.

[0039] For example, after receiving a target authentication request, the authentication server extracts the agent-specific credential from the request, queries the credential's status information, and checks whether it is valid and has not been revoked or frozen. After confirming the credential's validity, the authentication server obtains the binding information recorded when the credential was generated. This binding information includes the authorized user identifier corresponding to the credential and the authorized container namespace. The authentication server matches the user identifier carried in the target authentication request with the authorized user identifier in the binding information. If they match, the attribution verification is successful. After the attribution verification is successful, the authentication server extracts the container namespace carried in the extended header field of the target authentication request and compares it with the container namespace pre-bound to the credential. If they match, a first verification result is generated.

[0040] For example, if the agent-specific credentials in the target authentication request have expired, the authentication server terminates subsequent verification and directly generates a second verification result. If the credentials are valid but the user identifier does not match the authorized user identifier in the binding information, it indicates that the credentials are being used by an unauthorized user, and the authentication server terminates subsequent verification and generates a second verification result. If both of the first two verifications pass, but the container namespace injected by the proxy component in the target authentication request is inconsistent with the container namespace pre-bound to the credentials, it indicates that the credentials are being used in an unauthorized container instance, and the authentication server generates a second verification result.

[0041] Understandably, by breaking down joint verification into three progressive steps—validity verification, attribution verification, and consistency comparison—and terminating subsequent verifications if any step fails, the authentication server can perform multi-dimensional security verification of authentication requests in a layered manner. This avoids continuing unnecessary container environment comparisons when the credentials themselves are invalid or the user does not match. This verification method ensures that the first verification result, indicating successful verification, is generated only when all three conditions—valid credentials, matching user, and consistent container environment—are met simultaneously, thus achieving fine-grained security control over credential usage scenarios.

[0042] In one feasible implementation, refer to Figure 3 , Figure 3 This application provides a schematic diagram of the ownership verification process for the agent credential verification method. The steps for verifying the ownership relationship between the agent-specific credential and the user identifier include steps S321 to S323: Step S321: Obtain the binding information recorded when the agent-specific credential is generated, wherein the binding information includes the authorized user identifier corresponding to the agent-specific credential; Step S322: Match the user identifier in the target authentication request with the authorized user identifier in the binding information to obtain the matching result; Step S323: If the matching result indicates that the user identifier and the authorized user identifier are consistent, the attribution relationship verification is confirmed to be successful.

[0043] It should be noted that binding information refers to the authorization information associated with the agent-specific credential recorded by the authentication server when it is generated. This information may include the authorized user identifier corresponding to the credential. The authorized user identifier is the unique identifier of the employee who applied for and generated the credential through an explicit authorization operation. Matching involves comparing the user identifier carried in the target authentication request with the authorized user identifier in the binding information character by character to determine whether they point to the same user. The matching result includes both consistent and inconsistent results. Passing the attribution verification means that the matching result indicates that the user identifier in the target authentication request matches the authorized user identifier, indicating that the user currently using the credential to initiate the authentication request is the authorized user of that credential.

[0044] For example, after the validity verification passes, the authentication server queries the binding information recorded when the agent's special credential was generated based on the credential number, and extracts the authorized user identifier from the binding information. The authentication server compares the user identifier carried in the target authentication request with the extracted authorized user identifier. If the two identifiers are exactly the same, a matching result with consistent representation is generated, and the attribution relationship verification is confirmed to have passed.

[0045] Understandably, by matching the user identifier in the target authentication request with the authorized user identifier recorded when the credentials are generated, the authentication server can verify whether the user currently using the credentials is the authorized user of those credentials. This prevents the credentials from being used by unauthorized users, ensures that the user of the credentials is consistent with the authorized user, and establishes a user-level verification basis for subsequent consistency comparisons in the container environment.

[0046] Step S30: Based on the verification result, issue an access token bound to the identity metadata to the intelligent agent.

[0047] It should be noted that the access token is a credential issued by the authentication server to the agent, which can be used for subsequent access to the business system. The agent must present this token to prove its identity when accessing the business system. In traditional technology, the authentication server issues an access token to the agent after verifying the validity of the credentials. This token is only associated with the credentials and does not contain information about the container runtime environment that initiated the request. Therefore, once the token is stolen, it can be ported to any container for use. In this embodiment, the authentication server decides whether to issue an access token based on the result of the joint verification. If the verification result is the first verification result, that is, all joint verifications pass, the authentication server generates an access token and embeds the container identity identifier and image identity identifier of the current container instance into the access token, resulting in an access token bound to the identity metadata. If the verification result is the second verification result, that is, at least one of the joint verifications fails, the authentication server refuses to generate an access token and records the authentication event as an abnormal event. Among them, after the container identity identifier is embedded in the token, the token is associated with the specific container instance that initiated the authentication request. Subsequent use requires verification of whether the current container environment is consistent with the environment information bound in the token.

[0048] Understandably, by binding the issuance of access tokens to identity metadata, the tokens are associated not only with credentials and users, but also with specific container instances. When verifying the tokens, subsequent business systems can extract the container identity embedded in the tokens and compare it with the container environment from which the current request originated. This further prevents the tokens from being migrated to other containers and abused, thus implementing the restriction that the tokens are only valid within authorized containers and improving the overall security of intelligent agents accessing business systems.

[0049] In one feasible implementation, the step of issuing an access token bound to the identity metadata to the agent based on the verification result includes steps S41 to S42: Step S41: If all verification results pass, generate an initial access identifier and embed the container identity identifier and image identity identifier of the current container instance into the initial access identifier to obtain an access token bound to the identity metadata. Step S42: If any verification result fails, refuse to generate an access token and record the authentication event corresponding to the target authentication request as an abnormal event.

[0050] It should be noted that a "full pass" verification result means that all three verification steps in the joint verification—validity verification, attribution verification, and consistency comparison—pass, i.e., the first verification result. A "fail any step" verification result means that at least one of the three steps in the joint verification fails, i.e., the second verification result. The container identity identifier of the current container instance refers to the unique identifier of the container instance that initiated this authentication request, and the image identity identifier refers to the unique identifier of the image on which this container instance is based. Embedding refers to writing the container identity identifier and image identity identifier as additional fields of the access token into the token structure, thus associating the token with a specific container instance. This association cannot be changed after the token is issued. The authentication event corresponding to the target authentication request refers to the relevant information in the entire process from the agent initiating the authentication request to the authentication server generating the verification result, including at least one of the following: credential identifier, user identifier, container identity identifier, verification time, and verification failure item.

[0051] Optionally, the authentication server writes the container identity and image identity into the extended fields of the access token and digitally signs the access token to prevent tampering. Abnormal events are recorded in at least one of the following ways: writing to the audit log, pushing to the security event management platform, and sending notifications to authorized users.

[0052] For example, if all federated verifications pass, the authentication server generates an access token, extracts the container number and image version number injected by the proxy component from the target authentication request, writes the container number and image version number into the extended fields of the access token, digitally signs the token, and obtains an access token bound to the identity metadata. This access token is then returned to the agent. If the validity verification fails in the federated verification, the authentication server refuses to generate an access token, records the credential identifier, user identifier, container number, verification time, and failed verification items of this authentication request as an abnormal event, and sends an abnormal login notification to the authorized user.

[0053] Understandably, by embedding the container identity and image identity into the access token when all verifications pass, the token is bound to the specific container instance that initiated the authentication request. Subsequent business systems can then identify whether the token has been used across containers by comparing the container identity in the token with the container identity from which the current request originated. Simultaneously, by refusing to issue the token and logging the exception event when verification fails, the authentication server can audit and trace failed authentication actions, providing a basis for subsequent security analysis and credential revocation, thereby improving the overall security of credential usage.

[0054] In one feasible implementation, before the steps of obtaining the identity metadata of the container instance that initiated the authentication request, injecting the identity metadata into the authentication request, and obtaining the target authentication request, steps S01 to S04 are included: Step S01: In response to the explicit authorization operation initiated by the identity platform, generate agent-specific credentials; Step S02: Pre-bind the agent's special credentials with the user's user identifier and the agent's container namespace, and record the corresponding audit logs; Step S03: Resolve all intranet authentication domain names to the service address of the proxy component. Step S04: When the proxy component receives an authentication request, it blocks authentication requests that do not carry the container identity identifier.

[0055] It's important to note that explicit authorization refers to an employee proactively initiating authorization for an agent through the enterprise's unified identity platform. For example, this involves selecting an agent on the identity platform and granting it access to a specified business system. Agent-specific credentials are identity certificates generated by the authentication server in response to this authorization operation. These credentials are exclusively for agent use and are isolated from employee terminal credentials in terms of storage space, validity period, permission scope, and audit policies. User terminal credentials are the personal identity credentials used by employees for single sign-on on their daily office terminals. Pre-binding refers to associating the agent-specific credentials with the employee's user identifier and the container namespace of the agent's container instance during the generation of the credentials, establishing a correspondence between the credentials and a specific user and container environment at creation time. Audit logs record the entire explicit authorization process, including information such as the authorizer, authorization time, authorized object, and authorization scope. These logs are immutable and provide a basis for subsequent attribution verification. Internal network authentication domains refer to the domain addresses used for identity authentication within an enterprise. Unified resolution refers to modifying the resolution target of each internal network authentication domain to the service address of the proxy component, so that authentication request traffic initiated by the agent is redirected to the proxy component and cannot be bypassed. Container identity refers to information that can identify a container instance in a network request, such as the container ID. Blocking means that when the proxy component detects that the authentication request does not carry a container identity, it directly discards the request and returns an error response.

[0056] For example, an employee accesses the agent management page on the enterprise office platform, selects the agent to be authorized, specifies the accessible business systems and authorization period for that agent, and clicks confirm to trigger an explicit authorization operation. The identity platform sends the authorization request to the authentication server, which generates a dedicated agent credential completely isolated from the employee's terminal credentials. Simultaneously, it pre-binds this credential to the employee's user identifier and the container namespace where the agent resides, and generates an audit log recording the authorizing person, authorization time, and authorization scope. Meanwhile, the system administrator uniformly modifies the DNS records of all intranet authentication domains to the service network address of the proxy component. Afterwards, when an agent initiates an authentication request, the request first reaches the proxy component. The proxy component checks whether the request carries the container identity identifier; requests without the container identity identifier are directly blocked, and only requests carrying a valid container identity identifier are processed for subsequent identity metadata retrieval and injection.

[0057] Understandably, by completing preparatory work such as credential generation, pre-binding, domain convergence, and blocking of illegal requests before the authentication process begins, not only is an initial binding relationship established between credentials, users, and the container environment, providing a basis for subsequent attribution verification and consistency comparison, but also all authentication traffic is forcibly redirected to the proxy component, and requests with unknown identities are blocked, ensuring that subsequent identity metadata injection and joint verification can cover all legitimate authentication requests, thereby building a secure and controllable pre-process environment for the entire authentication process.

[0058] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 Therefore, after the step of issuing an access token bound to the identity metadata to the intelligent agent based on the verification result, the method further includes steps A10 to A40: Step A10: Receive a business access request carrying an access token and extract the container identity embedded in the access token; Step A20: Obtain the current identity metadata of the container instance that initiated the business access request; Step A30: Compare the container identity identifier with the current identity metadata to obtain the comparison result; Step A40: Based on the comparison results, allow or deny the business access request.

[0059] It should be noted that a business access request refers to a resource access request initiated by an agent after obtaining an access token, carrying that token with it, to the business system. When requesting access to the business system, the agent attaches the access token to the business access request and sends it along with the request. The container identity embedded in the token refers to the container identity and image identity of the current container instance, which are written into the token's extended fields by the authentication server when the access token is issued. Current identity metadata refers to the identity metadata of the container instance initiating the business access request, which the proxy component obtains in real time, in the same manner as the authentication request, when the agent initiates the business access request. Comparison refers to comparing the consistency of the container identity embedded in the token with the container identity in the current identity metadata, and comparing the consistency of the image identity embedded in the token with the image identity in the current identity metadata. The comparison result can include both consistent and inconsistent results. "Allow" means the comparison result indicates that the container identity embedded in the token matches the current identity metadata, and the business access request is allowed. "Reject" means the comparison result indicates that the two are inconsistent, and the business access request is blocked.

[0060] Optionally, the method for obtaining container identity metadata for business access requests may include the business system extracting the current identity metadata injected by the proxy component from the extended fields of the request header after receiving the business access request. The business system then compares the container identity identifier and image identity identifier embedded in the token with the container identity identifier and image identity identifier in the current identity metadata, respectively. If both comparisons match, the comparison result is determined to be consistent.

[0061] For example, after obtaining an access token bound to its identity metadata, the agent initiates a business access request to the business system, carrying the access token in the request. The proxy component intercepts this business access request, retrieves the identity metadata of the current container instance in the same manner as the authentication request, and writes the current identity metadata into the request header extension field of the business access request. Upon receiving the business access request, the business system extracts the container number and image version number embedded in the access token, and simultaneously extracts the current container number and current image version number injected by the proxy component from the request header extension field. The business system compares the container number in the token with the current container number, and the image version number in the token with the current image version number. If both comparisons match, the business access request is allowed; if either comparison does not match, the business access request is rejected.

[0062] Understandably, by embedding the container identity and image identity into the token during issuance, and then having the business system compare and verify the identity information in the token with the identity information of the current container environment during subsequent business access, the token's usage is restricted to the container instance bound to it at the time of issuance. Even if the token is stolen during transmission and an attacker uses it in other container instances, the comparison will fail because the identity metadata of the current container instance is inconsistent with the container identity embedded in the token, and the business access request will be rejected. This effectively prevents the abuse of the token across containers and further enhances the security of the agent's access to the business system.

[0063] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the intelligent agent credential verification method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0064] This application also provides an intelligent agent credential verification system; please refer to [link / reference]. Figure 5 The intelligent agent credential verification system includes: The acquisition module 101 is used to acquire the identity metadata of the container instance that initiated the authentication request, inject the identity metadata into the authentication request, and obtain the target authentication request. Verification module 102 is used to perform joint verification based on identity metadata, agent-specific credentials and user identifier in the target authentication request, and generate verification results; The publishing module 103 is used to publish an access token bound to the identity metadata to the intelligent agent based on the verification result.

[0065] The agent credential verification system provided in this application, employing the agent credential verification method described in the above embodiments, can solve the technical problem that existing authentication mechanisms cannot meet the security requirements of enterprises for agent access. Compared with the prior art, the beneficial effects of the agent credential verification system provided in this application are the same as those of the agent credential verification method provided in the above embodiments, and other technical features of the agent credential verification system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0066] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0067] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0068] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the agent credential verification method in the above embodiments.

[0069] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0070] The aforementioned computer-readable storage medium may be included in the agent credential verification system; or it may exist independently and not be assembled into the agent credential verification system.

[0071] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the agent credential verification system, enable the agent credential verification system to: obtain the identity metadata of the container instance that initiated the authentication request, inject the identity metadata into the authentication request, and obtain the target authentication request; A joint verification is performed based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request to generate a verification result. Based on the verification result, an access token bound to the identity metadata is issued to the agent.

[0072] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0073] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0074] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0075] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described agent credential verification method. This solves the technical problem that existing authentication mechanisms cannot meet the security requirements of enterprises for agent access. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the agent credential verification method provided in the above embodiments, and will not be elaborated upon here.

[0076] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the agent credential verification method described above.

[0077] The computer program product provided in this application can solve the technical problem that existing authentication mechanisms cannot meet the security requirements of enterprises for access to intelligent agents. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the intelligent agent credential verification method provided in the above embodiments, and will not be repeated here.

[0078] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for verifying agent credentials, characterized in that, The agent credential verification method includes: Obtain the identity metadata of the container instance that initiated the authentication request, and inject the identity metadata into the authentication request to obtain the target authentication request; A joint verification is performed based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request to generate a verification result. Based on the verification result, an access token bound to the identity metadata is issued to the intelligent agent.

2. The agent credential verification method as described in claim 1, characterized in that, The steps of obtaining the identity metadata of the container instance that initiated the authentication request, injecting the identity metadata into the authentication request, and obtaining the target authentication request include: The authentication request is decrypted to obtain the decrypted authentication request; Based on the source network information in the decrypted authentication request, query the runtime interface of the container instance to obtain the identity metadata of the container instance, wherein the identity metadata includes at least one of container identity identifier, namespace, host identity identifier, image identity identifier and creation time; The identity metadata is written into the request header extension field of the decrypted authentication request according to a preset standardized format; The authentication request after the data is written is re-encrypted to obtain the target authentication request.

3. The agent credential verification method as described in claim 1, characterized in that, The step of performing joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request to generate a verification result includes: Perform validity verification on the agent-specific credentials in the target authentication request; After the validity verification is passed, the attribution relationship between the agent-specific credential and the user identifier is verified. After the attribution verification is passed, the identity metadata carried in the target authentication request is extracted, and the identity metadata is compared with the container identity identifier pre-bound to the smart agent's special credentials. If the consistency comparison passes, a first verification result indicating that the characterization verification has passed is generated; If any check fails, the subsequent checks are terminated, and a second check result representing the check failure is generated.

4. The agent credential verification method as described in claim 3, characterized in that, The step of verifying the attribution relationship between the agent-specific credentials and the user identifier includes: Obtain the binding information recorded when the agent-specific credential is generated, wherein the binding information includes the authorized user identifier corresponding to the agent-specific credential; The user identifier in the target authentication request is matched with the authorized user identifier in the binding information to obtain the matching result; If the matching result indicates that the user identifier matches the authorized user identifier, the attribution relationship verification is deemed successful.

5. The agent credential verification method as described in claim 1, characterized in that, The step of issuing an access token bound to the identity metadata to the intelligent agent based on the verification result includes: If all verification results pass, an initial access identifier is generated, and the container identity identifier and image identity identifier of the current container instance are embedded in the initial access identifier to obtain an access token bound to the identity metadata. If any of the verification results fail, the access token will not be generated, and the authentication event corresponding to the target authentication request will be recorded as an abnormal event.

6. The agent credential verification method as described in claim 1, characterized in that, Before the steps of obtaining the identity metadata of the container instance that initiated the authentication request, injecting the identity metadata into the authentication request, and obtaining the target authentication request, the method further includes: In response to an explicit authorization operation initiated by the identity platform, a special credential for the intelligent agent is generated; The agent-specific credentials are pre-bound to the user's user identifier and the agent's container namespace, and the corresponding audit logs are recorded. All internal network authentication domain names are uniformly resolved to the service address of the proxy component; When the proxy component receives an authentication request, it blocks authentication requests that do not carry container identity identifiers.

7. The agent credential verification method as described in claim 1, characterized in that, After the step of issuing an access token bound to the identity metadata to the intelligent agent based on the verification result, the method further includes: Receive a business access request carrying the access token, and extract the container identity embedded in the access token; Obtain the current identity metadata of the container instance that initiated the business access request; The container identity identifier is compared with the current identity metadata to obtain the comparison result; Based on the comparison results, the service access request can be allowed or denied.

8. A smart agent credential verification system, characterized in that, The intelligent agent credential verification system includes: The acquisition module is used to acquire the identity metadata of the container instance that initiated the authentication request, inject the identity metadata into the authentication request, and obtain the target authentication request. The verification module is used to perform joint verification based on the identity metadata, agent-specific credentials, and user identifier in the target authentication request, and generate a verification result. The publishing module is used to publish an access token bound to the identity metadata to the intelligent agent based on the verification result.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the agent credential verification method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the agent credential verification method as described in any one of claims 1 to 7.

Images