Identity and access management method, system and equipment for multi-agent cross-domain interaction scene and medium

Abstract

The invention relates to the technical field of identity and access management, in particular to an identity and access management method, device and equipment for a multi-agent cross-domain interaction scene and a medium, and the method comprises the steps: building and managing the whole life cycle identity of an agent from building to decommissioning; in response to a task request submitted by a user, signing and issuing a short-term access authorization bound with the signing and issuing identity of the entrance agent and the task for the entrance agent executing the task; when the ingress agent needs to call other services to complete the task, establishing and recording an auditing delegation chain which is from the ingress agent to the target service and contains a permission transfer relationship; the cross-domain access behavior of the agent is verified and continuously monitored, through the mechanism, the identity source, the permission range and the delegation path of the agent instance in the task execution process can be identified, fine-grained and traceable access control is achieved, long-term voucher abuse, permission diffusion and unauthorized access are prevented, and the service life of the agent instance is prolonged. And the security and reliability of multi-agent cross-domain cooperation are improved.

Description

Technical Field

[0001] This invention relates to the field of identity and access management technology, and in particular to an identity and access management method, apparatus, device and medium for multi-agent cross-domain interaction scenarios. Background Technology

[0002] With the widespread application of multi-agent systems, a large number of agents with autonomous decision-making and collaborative capabilities are deployed in different operating platforms, organizational boundaries, and trust domains. In scenarios such as data analysis, process automation, and intelligent operation and maintenance, agents not only need to interact with users, but also need to collaborate across domains and call external tools and services to achieve complex tasks. This kind of cross-domain, dynamic, and collaborative interaction mode poses new challenges to identity management and access control. Traditional identity and access management methods are no longer suitable for the security and control needs in multi-agent scenarios.

[0003] Currently, identity and access management methods for multi-agent cross-domain interactions have several limitations: On the one hand, existing methods typically treat agents as single, static "application accounts" or "client identities," lacking differentiation and full lifecycle management of agent software blueprints, published entities, and running instances. This makes it impossible to accurately trace the identity source and state changes of specific agent instances in cross-domain collaboration. On the other hand, in task-driven dynamic collaboration, existing authorization mechanisms are mostly pre-configured static permissions or long-term credentials, unable to support short-term authorization of minimum permissions issued on demand based on task context. Furthermore, when delegating permissions between agents, there is a lack of complete recording and auditing capabilities for the delegation chain, resulting in opaque permission transfer processes and difficulty in effective supervision. In addition, most solutions still focus on identity authentication at the initial access stage, lacking continuous verification and real-time security monitoring of agent cross-domain operations. This makes it impossible to achieve closed-loop security control and compliance response in dynamic environments. These shortcomings restrict the reliable implementation and large-scale application of multi-agent systems in security-sensitive and high-compliance scenarios.

[0004] The information disclosed in this background section is intended only to enhance the understanding of the general background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and medium for identity and access management in multi-agent cross-domain interaction scenarios, thereby effectively solving the problems in the background art.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: an identity and access management method for multi-agent cross-domain interaction scenarios, comprising the following steps: Establish and manage the full lifecycle identity of an intelligent agent from creation to retirement, wherein the full lifecycle identity at least distinguishes between software blueprints, published entities, and running instances; In response to a task request submitted by a user, a short-term access authorization is issued to the entry agent that executes the task, and the entry agent's identity and task are bound together. When the entry agent needs to call other services to complete a task, an auditable delegation chain containing permission transfer relationships is established and recorded from the entry agent to the target service; Based on the full lifecycle identity, the short-term access authorization, and the auditable delegation chain, the cross-domain access behavior of the intelligent agent is verified and continuously monitored.

[0007] Furthermore, the intelligent agent establishes and manages its full lifecycle identity from creation to retirement, wherein the full lifecycle identity at least distinguishes between software blueprints, publishing entities, and running instances, specifically including: Receive the registration information of the intelligent agent software blueprint submitted by the intelligent agent builder, and assign a software blueprint identifier to the software blueprint; In response to a release request for the software blueprint, a release identifier is generated, and the release identifier is associated with the publisher information and security assessment certificate; In response to the agent instance creation request initiated by the runtime environment, a runtime instance identifier is generated for the agent, and an agent identity credential corresponding to the runtime instance identifier is issued based on the software blueprint identifier.

[0008] Furthermore, in response to a user-submitted task request, a short-term access authorization is issued to the entry agent executing the task, binding the entry agent's identity and the task. Specifically, this includes: Parse the task request submitted by the user or upstream entity, determine the resource scope, operation type and time constraints required to complete the task, and generate an access scope description; Provide an interactive mechanism for the user or upstream entity to confirm or modify the access scope description, and record the final authorization result after obtaining user confirmation; Based on the confirmed access scope description, a short-term access token is issued to the entry agent that executes the task, and the short-term access token is bound to its identity and the task request. The permissions of the short-term access token are limited to the access scope description.

[0009] Furthermore, when the entry agent needs to invoke other services to complete a task, an auditable delegation chain containing permission transfer relationships is established and recorded from the entry agent to the target service, specifically including: When the entry agent determines that it needs to call other agents or external systems, it initiates a delegation request to the delegation management service. The delegation request includes at least the delegate identifier, the target resource identifier, and the operation type. Verify that the operation involved in the delegation request is within the overall permissions authorized by the short-term access token; If the verification is successful, an agency certificate is generated for the delegate, and delegation link information including the delegator identifier, the delegate identifier, the target resource, the operation type, and the time limit is recorded to form the auditable delegation chain.

[0010] Furthermore, the establishment of the auditable delegation chain also includes dynamic validity verification of the delegation chain: Before generating the proxy credential, the identity status of the entry agent and the validity of its short-term access authorization are queried in real time. If the query result indicates that the identity status of the entry agent is abnormal or the short-term access authorization has expired, the establishment process of the auditable delegation chain will be terminated.

[0011] Furthermore, the real-time query includes: Obtain the identity credential of the entry agent, and extract the running instance identifier of the entry agent from the identity credential; Based on the running instance identifier, query the current lifecycle state bound to the entry agent; Obtain the unique identifier for the short-term access authorization; Based on the unique identifier, query the current revocation status and remaining validity period of the short-term access token; The authenticity of the obtained lifecycle status and the revocation status and remaining validity period of the short-term access token are verified.

[0012] Furthermore, the dynamic validity check also includes context-based policy evaluation: Retrieve the security policy associated with the currently assigned task, target resource, or related trust domain; Based on the security policy, assess the conditions under which the auditable delegation chain is permitted to be established in the current context; If the evaluation results do not meet the conditions, the validity check is deemed to have failed.

[0013] Furthermore, based on the full lifecycle identity, the short-term access authorization, and the auditable delegation chain, the cross-domain access behavior of the intelligent agent is verified and continuously monitored, specifically including: When the target domain receives an access request, it verifies the validity of the identity credentials of the agent that initiated the access request, the short-term access token, and the proxy credentials. Based on the cross-domain trust policy, the integrity of the auditable delegation chain is verified, and the current access operation is confirmed to be within the authorization scope recorded by the auditable delegation chain. After successful verification and confirmation, the access request is allowed to be executed, and the access event is recorded in the audit log.

[0014] Furthermore, it also includes: During the execution of the task by the intelligent agent, its resource access behavior and the status of the auditable delegation chain are continuously monitored; When monitoring detects that the access behavior exceeds the scope of the short-term access authorization or the authorization defined by the auditable delegation chain, or identifies an abnormal behavior pattern, an alarm is triggered and at least one of the following actions is taken: revoking the relevant access credentials or terminating the operation of the smart agent.

[0015] This invention also includes an identity and access management system for multi-agent cross-domain interaction scenarios, using the method described above, comprising: The multi-intelligent identity lifecycle management module is used to establish and manage the full lifecycle identity of an intelligent agent from creation to retirement. The full lifecycle identity at least distinguishes between software blueprints, published entities, and running instances. The access and authorization management module is used to respond to the task request submitted by the user and issue a short-term access authorization to the entry agent that executes the task, and the entry agent's identity and task binding are associated with the entry agent. The delegation and link management module is used to establish and record an auditable delegation chain from the entry agent to the target service, which includes permission transfer relationships, when the entry agent needs to call other services to complete a task; The cross-domain access verification and monitoring module is used to verify and continuously monitor the cross-domain access behavior of the intelligent agent based on the full lifecycle identity, the short-term access authorization, and the auditable delegation chain.

[0016] The present invention also includes a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described above.

[0017] The present invention also includes a storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described above.

[0018] The beneficial effects of this invention are as follows: By constructing a full lifecycle identity system that links intelligent agent blueprints, published entities, and running instances, coupled with a short-term access authorization mechanism based on task context and an auditable delegation chain that can fully record the permission transfer path, unified, fine-grained, and traceable access control capabilities are achieved for multi-agent dynamic collaboration and cross-domain call scenarios. This technical solution accurately identifies the identity source, permission scope, and delegation relationship of any intelligent agent instance during the execution of a specific task, ensuring that intelligent agents access external resources only within the necessary scope and authorized time. This effectively reduces the risks of long-term credential abuse, permission diffusion, and unauthorized access. Simultaneously, the delegation chain mechanism makes the multi-level transfer of permissions during cross-domain calls transparent and structured, supporting audit backtracking and compliance checks. Continuous verification and dynamic monitoring further form a security closed loop, enabling the system to promptly detect and respond to abnormal call behaviors. Attached Figure Description

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

[0020] Figure 1 A flowchart illustrating the identity and access management method for multi-agent cross-domain interaction scenarios; Figure 2 A flowchart for establishing and recording an auditable delegation chain, including permission transfer relationships, from the entry agent to the target service; Figure 3 A flowchart for dynamically validating the delegation link; Figure 4 A flowchart for real-time querying; Figure 5 A flowchart for a multi-agent identity lifecycle management method; Figure 6 A flowchart for a multi-agent cross-domain access and delegation control method; Figure 7 A schematic diagram of the overall architecture of an identity and access management system for multi-agent cross-domain interaction scenarios; Figure 8 This is a schematic diagram of the structure of a computer device. Detailed Implementation

[0021] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0022] like Figures 1 to 6 As shown: An identity and access management method for multi-agent cross-domain interaction scenarios, comprising the following steps: S10: Establish and manage the full lifecycle identity of an agent from creation to retirement. The full lifecycle identity must at least distinguish between software blueprints, published entities, and running instances. S20: In response to a task request submitted by a user, issue a short-term access authorization to the entry agent that executes the task, and bind the entry agent's identity and task. S30: When the entry agent needs to call other services to complete a task, establish and record an auditable delegation chain from the entry agent to the target service, which includes permission transfer relationships; S40: Based on full lifecycle identity, short-term access authorization, and an auditable delegation chain, it verifies and continuously monitors the cross-domain access behavior of smart agents.

[0023] First, a blueprint identity is generated for the agent during its creation. This blueprint identity includes information such as signature, public key, and functional declaration. A publishing entity identity is generated during the blueprint's version building to record the version number, trust signature, and publishing metadata. When the publishing entity deploys and starts a running instance, an independent instance identity is further generated for the running instance, establishing a static and traceable binding relationship between the blueprint, publishing, and instance identities. After a user submits a task request, the entry agent responsible for handling the task is identified. Based on the task context and the entry instance's identity, a short-term access authorization bound to the task is generated and issued. This authorization includes the scope of accessible resources, call restrictions, lifespan, and signature information, ensuring that the agent performs necessary operations with minimal privileges only within the task's lifecycle. When the entry agent needs to call other agents or external services... Upon task completion, a delegation node is constructed based on the entry instance identity, short-term authorization content, and call target. As the call chain expands, the permission transfer relationship is recorded level by level, forming a structured and auditable delegation chain. Each node in the delegation chain records the source instance, target service, call purpose, permission type, and timestamp. A directed acyclic structure is preferred, and the information is written to an immutable log system to ensure the completeness and traceability of the cross-domain delegation path. During task execution, each cross-domain access is jointly verified based on the full lifecycle identity, short-term access authorization, and delegation chain information. This includes checking identity consistency, authorization validity, and whether the call conforms to the propagation path of the delegation chain. Continuous monitoring is also performed, identifying abnormal access through behavioral analysis. If necessary, authorization can be immediately revoked or the instance frozen to ensure the security and controllability of the entire task execution process.

[0024] By constructing a full lifecycle identity system that links intelligent agent blueprints, published entities, and running instances, coupled with a short-term access authorization mechanism based on task context and an auditable delegation chain that can fully record the permission transfer path, unified, fine-grained, and traceable access control capabilities are achieved for multi-agent dynamic collaboration and cross-domain call scenarios. This technical solution accurately identifies the identity source, permission scope, and delegation relationship of any intelligent agent instance during the execution of a specific task, ensuring that intelligent agents access external resources only within the necessary scope and authorized time, thereby effectively reducing the risks of long-term credential abuse, permission diffusion, and unauthorized access. Simultaneously, the delegation chain mechanism of this invention makes the multi-level transfer of permissions during cross-domain calls transparent and structured, supporting audit backtracking and compliance checks; continuous verification and dynamic monitoring further form a security closed loop, enabling the system to promptly detect and respond to abnormal call behaviors.

[0025] By establishing a full lifecycle identity management mechanism for intelligent agents, the system achieves precise differentiation and traceability of the identities of intelligent agents at each stage from design to operation, effectively solving the problem of coarse-grained identity management in traditional methods. At the same time, the introduction of task-based short-term access authorization and auditable delegation chains ensures that intelligent agents can obtain the minimum required permissions in cross-domain collaboration and makes the permission transfer process transparent and traceable. In addition, combined with continuous access behavior verification and monitoring, abnormal behavior can be detected and responded to in a timely manner, thereby building a closed-loop security control system in multi-agent cross-domain interaction scenarios and improving the overall security and compliance of the system.

[0026] As a preferred embodiment of the above, in step S10, the intelligent agent establishes and manages its full lifecycle identity from creation to retirement. The full lifecycle identity at least distinguishes between software blueprints, publishing entities, and running instances, specifically including: S11: Receive the registration information of the intelligent agent software blueprint submitted by the intelligent agent builder, and assign a software blueprint identifier to the software blueprint; S12: In response to a release request for the software blueprint, generate a release identifier and associate the release identifier with the releaser information and security assessment certificate; S13: In response to the agent instance creation request initiated by the runtime environment, generate a runtime instance identifier for the agent, and issue an agent identity credential corresponding to the runtime instance identifier based on the software blueprint identifier.

[0027] First, a blueprint registration mechanism is provided. Builders can submit the functional description, dependent environment, integrity verification data, and builder identity information of their intelligent agent software blueprint through the blueprint registration interface. After format and integrity verification, a unique software blueprint identifier is generated and written to trusted storage along with the blueprint registration record to ensure non-repudiation. Based on this, when a publisher submits a release request based on a blueprint, the release request includes the blueprint identifier, version number, build configuration, publisher information, and security assessment certificate. After verifying release permissions and the validity of the security assessment, a unique release identifier is generated and linked to the publisher information, security assessment certificate, and corresponding... The blueprint identifier is bound to form a traceable record of the published entity, providing a basis for subsequent instance verification. Subsequently, when an instance creation request is initiated in the runtime environment, the legality of the creation operation is first checked, and a unique runtime instance identifier is generated for the agent. Based on the previous blueprint identifier and published identifier, an identity credential is issued for the runtime instance to prove the legitimate source of the instance and its association. The identity credential may include the instance identifier, association link, validity period, and system signature to support independent verification in cross-domain environments. A complete identity link from blueprint to published to instance is formed, providing a trusted foundation for subsequent task binding authorization, permission delegation records, and cross-domain access monitoring.

[0028] In step S20, in response to the task request submitted by the user, a short-term access authorization is issued to the entry agent executing the task, binding the entry agent's identity and the task. This specifically includes: S21: Parse the task request submitted by the user or upstream entity, determine the resource scope, operation type and time constraints required to complete the task, and generate an access scope description. S22: Provide an interactive mechanism for users or upstream entities to confirm or modify the access scope description, and record the final authorization result after obtaining user confirmation; S23: Based on the confirmed access scope description, issue a short-term access token to the entry agent that executes the task, which is bound to its identity and task request. The permissions of the short-term access token are limited to the access scope description.

[0029] First, the task content undergoes semantic parsing and structuring. Through task type matching, natural language recognition, or template parsing, the required data domains, callable services, permitted operation types, and access time limits are determined to complete the task. This generates an access scope description that describes the available permissions for this task. This description may include fields such as the set of accessible resources, operation permissions, call count limits, validity period parameters, and optional data sensitivity tags. Subsequently, this access scope description is returned to the user or upstream entity through a visual editing interface, conversational interface, or API, providing an interactive mechanism for modifying or confirming the access scope. This allows users to reduce unnecessary permissions, shorten validity periods, or add required capabilities. Ensure the scope of authorization complies with the principle of least privilege. After the user confirms the access scope description, the final authorization result is recorded as task metadata. Based on this, a short-term access token is issued to the entry agent instance undertaking this task, according to its instance identity, task identity, and the confirmed access scope. This token contains the entry instance's unique identifier, task identity, access scope description, issuance time, expiration time, and system signature or verifiable structure. It can also be set with an extremely short validity period, a maximum number of calls, or a single-use limit to prevent abuse of long-term credentials. After user confirmation, a short-term access token bound to the task is issued to the entry agent instance, allowing it to operate only within this scope during task execution. The token automatically expires upon expiration.

[0030] In this embodiment, in step S30, as Figure 2 When the entry agent needs to call other services to complete a task, an auditable delegation chain containing permission transfer relationships is established and recorded from the entry agent to the target service, specifically including: S31: When the entry agent determines that it needs to call other agents or external systems, it initiates a delegation request to the delegation management service. The delegation request shall at least include the delegate identifier, the target resource identifier and the operation type. S32: Verify whether the operation involved in the delegation request is within the overall permissions authorized by the short-term access token; S33: If the verification passes, an agency certificate is generated for the delegate and the delegation chain information, including the delegator's identifier, the delegate's identifier, the target resource, the operation type and time limit, is recorded to form an auditable delegation chain.

[0031] In this embodiment, to achieve auditable management of permission transfer during cross-domain collaboration, when the entry agent determines that it needs to call other agents or external systems to complete part of the operation while executing a task, the entry agent first initiates a delegation request to the delegation management service. This request includes at least the identifier of the delegate, the identifier of the target resource, and the type of operation to be performed. In a preferred embodiment, the request may also include extended information such as the purpose of the operation, the sensitivity level, the expected execution time limit, and whether secondary delegation is allowed, so that the system can express and audit the delegation behavior in a more granular way. After receiving the request, the delegation management service verifies the legality of the request based on the short-term access token held by the entry agent. This includes checking whether the target resource is within the scope of the token authorization, whether the operation type is within the allowed operation list, whether the current time is within the token's validity period, whether the number of calls or operation limits of the token have been exceeded, and whether the task constraints or delegation depth have been violated. Security rules such as degree restrictions are implemented. Once verification is successful, a proxy credential is generated for the delegated party. This credential represents the specific operations that the delegated party can perform in this delegation chain using the delegator's permissions. Its content includes fields such as delegator identifier, delegated party identifier, target resource scope, allowed operation type, permission validity period, and whether the proxy permission can be further delegated. It is protected by the system through digital signatures or verifiable credential formats to ensure that it cannot be forged or tampered with in cross-domain scenarios. At the same time, the above delegation relationship is recorded as a delegation chain node. The delegation chain node includes at least the delegator identifier, delegated party identifier, proxy permission content, timestamp, proxy credential fingerprint, and permission validity period. It is appended to the delegation chain structure corresponding to the task. In the preferred implementation, this structure adopts a directed acyclic graph model and can be stored in an immutable audit log or transparent log system, thereby completely recording the path of permission being passed outward from the entry agent.

[0032] In step S30, such as Figure 3 Establishing an auditable delegation chain also includes dynamically validating the delegation chain: S34: Before generating the proxy credentials, query the identity status of the entry agent and the validity of its short-term access authorization in real time; S35: If the query result indicates that the identity status of the entry agent is abnormal or the short-term access authorization has expired, then the process of establishing the auditable delegation chain will be terminated.

[0033] In this implementation, to ensure the security and auditability of permission transfer during the delegation chain construction process, a dynamic validity verification mechanism is introduced before generating the proxy credential. Specifically, after the entry agent submits a delegation request to the delegation management service, containing the delegate identifier, target resource identifier, and operation type, the delegation management service first queries the entry agent's running instance identifier in real time to determine its identity status. This checks whether the instance is still running normally, whether it has been suspended by the administrator, whether it has been automatically frozen due to detected abnormal behavior, or whether it has entered isolation mode due to a running failure. The accuracy of the status judgment can be improved by combining the health monitoring data and security monitoring information of the running nodes. Subsequently, the short-term validity verification mechanism is applied to the credentials held by the entry agent. The validity of the short-term access token is verified, including checking whether the token has expired, whether the signature is correct, whether it has been revoked or added to the blacklist, whether the authorized task ID matches, whether the number of calls has been exhausted, and whether the token has been marked as invalid due to task cancellation or security policy triggering. In the preferred implementation, replay attack checks and task consistency checks are also performed to further improve the credibility of authorization verification. Only when the identity status of the entry agent is normal and the short-term access token is valid will the delegation management service continue to generate proxy credentials for the delegate and write the delegation link information into the auditable delegation chain. Otherwise, the establishment of the delegation chain will be terminated immediately, no proxy credentials will be generated, and the reason for failure can be written into the audit log or a security response can be triggered.

[0034] As a preferred embodiment of the above, in step S34, such as Figure 4 Real-time queries include: S341: Obtain the entry agent's identity credential and extract the running instance identifier of the entry agent from the agent's identity credential; S342: Based on the running instance identifier, query the current lifecycle state bound to the entry agent; S343: A unique identifier for obtaining short-term access authorization; S344: Based on the unique identifier, query the current revocation status and remaining validity period of a short-term access token; S345: Verify the authenticity of the lifecycle status and the revocation status and remaining validity period of the short-term access token obtained from the query.

[0035] In this implementation, to ensure that the entry agent status and short-term access authorization information obtained before the establishment of the delegation chain are authentic, valid, and verifiable, the identity credentials and short-term access authorization of the entry agent are queried and verified in steps during dynamic validity verification: When the entry agent issues a delegation request, the delegation management service first parses the running instance identifier from the agent identity credentials attached to the request. This identity credential can be a verifiable credential, JWT, or other signed structured credential. After the credential is parsed, the system also verifies its digital signature to ensure that the instance identifier has not been forged or tampered with. Subsequently, based on the running instance identifier, the system queries the identity service and the runtime environment management system for the current lifecycle status of the entry agent. The lifecycle status can include running, suspended, frozen, terminated, or abnormal, and can be combined with the instance's health monitoring data, behavior monitoring records, and node status feedback to generate a unified status view, thereby ensuring the accuracy and timeliness of the status judgment. Next, the unique identifier of the short-term access token is extracted from the delegation request or token structure, and the current revocation status and remaining validity period of the token are queried in the authorization management system accordingly. This includes whether the token has been revoked, expired, has any abnormal usage records, has been blacklisted, or has been automatically marked as invalid due to task cancellation. After obtaining the instance lifecycle status and token status, the authenticity of the above information is verified, including whether the source of the status information is trustworthy, whether the signature timestamp is consistent, whether the query results have been tampered with, and whether there are any logical contradictions between the lifecycle status and the token status, such as the instance being terminated but the token still showing as valid. Only when the instance status is normal and the short-term access token is still valid and has not been revoked will the system allow the generation of proxy credentials to continue and the delegation chain information to be written to the delegation chain. Conversely, if the lifecycle status is abnormal or the token is invalid, the establishment process of the delegation chain will be terminated immediately, and an audit log may be recorded or a security response may be triggered.

[0036] In this embodiment, in step S30, the dynamic validity verification further includes context-based policy evaluation: A341: Obtain the security policy associated with the currently assigned task, target resource, or related trust domain; A342: Based on the security policy, assess the conditions under which an auditable delegation chain is permitted in the current context; A343: If the evaluation results show that the conditions are not met, the validity check is deemed to have failed.

[0037] First, security policies associated with the current delegated task, target resource, or related trust domain are obtained from the platform-level security policy library, resource attribute policy library, trust domain agreement policy library, and task template constraints. These policies may include resource sensitivity labels, allowed delegation depth, allowed cross-domain scope, prohibited operation types, task risk level thresholds, and trusted execution node restrictions, and are expressed using a unified policy model. Then, a context description object for the current delegation is constructed, including the task type and purpose, task risk level, the trust domain to which the entry agent and the delegate belong, the sensitivity level of the target resource, the current depth of the delegation chain, and other relevant information. Information such as the security status of the environment and system load is then processed by the policy engine, which performs matching and condition judgment based on the above policies and context to assess whether to allow the continued establishment of the delegation chain in the current context. If the policy evaluation result shows that the conditions required by the policy are not met, such as the resource is marked as accessible only in this domain but the delegate is located in another trusted domain, or the delegation chain depth has reached the upper limit specified by the policy, or the task is currently in a high-risk state and the policy explicitly prohibits cross-domain delegation, then even if the identity of the entry agent and the short-term authorization are both legal and valid, the validity check will be determined to fail, thereby terminating the process of generating proxy credentials and writing delegation chain nodes.

[0038] As a preferred embodiment of the above, in step S40, based on full-lifecycle identity, short-term access authorization, and an auditable delegation chain, the cross-domain access behavior of the intelligent agent is verified and continuously monitored, specifically including: S41: When the target domain receives an access request, it verifies the validity of the identity credentials, short-term access token, and proxy credentials of the intelligent agent that initiated the access request. S42: Based on the cross-domain trust policy, verify the integrity of the auditable delegation chain and confirm that the current access operation is within the authorization scope recorded by the auditable delegation chain; S43: After successful verification and confirmation, the access request is allowed to proceed, and the access event is recorded in the audit log.

[0039] The target domain first extracts the identity credentials, short-term access token, and any accompanying proxy credentials submitted by the accessing entity from the request message, and then performs integrity and validity checks on each of them. This includes verifying the signature validity of the identity credentials, whether the runtime instance identifier matches the credential content, and whether the identity credentials have been revoked; verifying the signature, validity period, revocation status, task binding relationship, and whether there are any abnormal uses or blacklisted markings on the short-term access token; and verifying whether the proxy credentials were issued by the superior delegating entity, whether their scope of authority covers the current access type, and whether the proxy credential chain is consistent with the delegation chain record. After completing the credential verification, the target domain further performs integrity checks on the auditable delegation chain based on a cross-domain trust policy, including checking whether there is any connection from the entry agent to the delegation chain. The system checks whether the current access agent's continuous links are all valid, whether the delegation chain structure is complete and tamper-proof, whether the delegation chain depth meets the policy's allowed range, whether cross-trust domain jumps are permitted by the policy, and whether the current access operation strictly falls within the authorized resources and operation scope recorded in the delegation chain. Only after both credential verification and delegation chain verification pass can the target domain allow the access operation to be executed. After the access is completed, the relevant access event is written to the audit log. The log contains information such as the running instance identifier, task identifier, short-term access token identifier, proxy credential identifier, accessed resources and operation type, access timestamp, and delegation chain node fingerprint. In preferred cases, the log is written to a transparent log system or an immutable storage medium to ensure the credibility of future audits and post-event traceability.

[0040] Step S40 further includes: S44: During the execution of tasks by the intelligent agent, continuously monitor its resource access behavior and the status of the auditable delegation chain; S45: When monitoring detects that the access behavior exceeds the authorization scope defined by the short-term access authorization or the auditable delegation chain, or identifies an abnormal behavior pattern, an alarm is triggered and at least one of the following actions is performed: revoking the relevant access credentials or terminating the operation of the agent.

[0041] Specifically, the target domain immediately activates the monitoring engine after executing an access operation. This engine collects access behavior data from the agent in real time through event triggering, periodic polling, or threshold detection. This data includes the accessed resource identifier, access type, access frequency, access time interval, whether the proxy credential is still valid, the remaining validity period of the short-term access token, whether any nodes in the delegation chain have expired or been revoked, and whether the delegation chain structure is broken or inconsistent. In the preferred method, the monitoring engine constructs an access behavior context for each access, which includes a task identifier, agent instance identifier, delegation chain node fingerprint, resource sensitivity level, and historical behavior summary. This context is used to determine whether the access behavior exceeds the resource or operational scope permitted by the short-term access authorization. For example, a short-term token may only allow reading certain resources. Data resources monitoring will detect write or delete operations as unauthorized behavior. The monitoring engine will continuously verify the delegation chain's status; if the delegation chain fails during task execution, the current access subject is considered to lack legitimate authorization. Furthermore, it will detect agent behavior patterns, such as sudden increases in access frequency, access targets inconsistent with task semantics, and behavior distributions significantly deviating from historical characteristics—all of which can be identified as potential abnormal behavior. When unauthorized behavior, delegation chain failure, or abnormal behavior patterns are detected, a security alert will be immediately triggered, and at least one security action will be taken, including revoking the agent's short-term access token, revoking its proxy credentials, freezing or terminating the agent's running instance, blocking the current access operation, refreshing the delegation chain, or adding the agent to the risk control list.

[0042] For the implementation of the multi-agent identity lifecycle management method, refer to... Figure 5 This embodiment takes the process of a single agent in the system from creation to retirement as an example to illustrate the multi-agent identity lifecycle management method. The method is mainly completed by the multi-agent identity lifecycle management module and the identity discovery and verification module in collaboration. The process includes steps S101 to S105. S101: Agent Blueprint Registration and Usage Definition During the agent construction phase, the builder submits an agent blueprint registration request through the identity and access management system. The request includes: (1) Agent name and version information; (2) The category to which the agent belongs (e.g., conversational agent, decision-making agent, tool agent, etc.). (3) Description of the intended use and business boundaries of the intelligent agent; (4) The main types of external resources relied upon (such as database access, API interface, file storage, etc.).

[0043] The multi-agent identity lifecycle management module assigns a unique software template identifier, TemplateID, and creates a basic identity record. At this point, the agent is in the "draft / design" state.

[0044] S102: Identity Registration and Verification Binding in the Release Phase When a builder believes that a certain intelligent agent blueprint can be discovered and used by other entities in the ecosystem, it initiates a publication request to the identity and access management system, with the following appended: (1) Template ID; (2) Publisher information, which should include at least the organization identifier and the publishing platform identifier; (3) Optional safety assessment results, performance assessment conclusions or other supporting materials.

[0045] The multi-agent identity lifecycle management module associates the blueprint identifier, publisher information, and evaluation materials to generate a PublishID, and updates the agent status to "available / published". The evaluation and verification management module performs format and integrity checks on the received evaluation materials, and then binds them to the corresponding PublishID for use in subsequent trust assessments.

[0046] S103: Instance Creation and AgentID Issuance When an agent needs to be launched in a certain runtime environment, that runtime environment submits an instance creation request to the identity and access management system through an interface. The request includes: (1) The corresponding PublishID; (2) Operating environment identifiers, including at least platform identifiers and node identifiers; (3) A brief description of the instance’s purpose (e.g., for a specific task or user).

[0047] The multi-agent identity lifecycle management module generates a unique instance identifier (InstanceID) for each instance and issues agent identity credentials (AgentID) to the instance according to system policies. These credentials may include: (1) InstanceID; (2) The associated PublishID and TemplateID; (3) ExpireInfo (validity period information); (4) AuthorizationID, the runtime environment identifier authorized for use; (5) OtherInfo, the signature or other verification information of the identity and access management system.

[0048] The identity discovery and verification module registers the AgentID to the identity directory so that other components can query and verify it in subsequent interactions.

[0049] S104: Operational Status Maintenance and Identity Discovery During the operation of the intelligent agent, the operating environment can periodically or when its state changes to report status information to the identity and access management system, including: (1) The current state of the instance (including at least running-1, paused-0, and abnormal-2); (2) Recent activity time; (3) Whether the current AgentID still needs to be retained.

[0050] The multi-agent identity lifecycle management module updates the status corresponding to the InstanceID based on the reported information and synchronizes the relevant information in the identity discovery and verification module. When other agents or systems need to interact with the instance, they can query the current status through the InstanceID or AgentID and decide whether to initiate interaction based on the status information.

[0051] S105: Suspension and Retirement Process When an instance is no longer needed, or when the runtime environment detects a risk requiring the agent to be taken offline, a pause or decommissioning request can be sent to the identity and access management system via an interface. Upon receiving the request, the multi-agent identity lifecycle management module will: (1) Update the instance status to "paused" or "retired"; (2) Mark the access token and proxy credential associated with the instance as invalid and notify the credential and key management module to perform the revocation operation; (3) Retain audit logs and historical assessment records related to this instance for subsequent analysis and accountability.

[0052] Through the above steps, this embodiment realizes complete identity lifecycle management for intelligent agents from design, release, instantiation to retirement, so that each intelligent agent instance has a clear, verifiable identity record in multi-domain and multi-platform environments.

[0053] For the implementation of multi-agent cross-domain access and delegation control methods, refer to... Figure 6 This embodiment uses the example of "an entry-level intelligent agent completing a task for a user and calling other intelligent agents and external systems in the process" to illustrate a method for cross-domain access and delegation control by multiple intelligent agents. This method is mainly completed collaboratively by an access and authorization management module, a delegation and link management module, a federated trust and cross-domain policy management module, and a monitoring and compliance module. The process includes steps S201 to S205.

[0054] S201: Determining Authorization Objectives and Access Scope A user submits a task request to the entry agent Agent_A through a specific entry application, such as "Analyze the sales data of the past week and generate a report for me". The entry agent runtime environment forwards the request to the access and authorization management module, and module 130 performs the following operations: (1) Parse user requests and identify the data types, target systems and operation types that may be involved (e.g., reading the sales database, calling the report service, etc.). (2) Based on the pre-configured policy template, the parsing results are converted into an access scope description, including: ① Resource scope (e.g., limited to a specific dataset within a particular business system); ② Operation scope (read-only, write-only, or read-write, etc.); ③ Time range (e.g., the authorization is valid during the execution of this task); ④ Output a description of the access scope to be authorized for user confirmation.

[0055] Users can review and modify the access scope in the interface (such as narrowing the data access scope or shortening the authorization time). After confirmation, the access and authorization management module records the authorization result.

[0056] S202: Initial Authorization and Short-Term Token Issuance After the user confirms authorization, the access and authorization management module is accessed. (1) Generate an access token Token_A that is bound to the agent's identity and access scope based on the authorization result and Agent_A's AgentID; (2) Set the validity period, number of uses, list of accessible resources, and allowed operation types of Token_A; (3) Securely distribute Token_A to the runtime environment where Agent_A is located, and register the status of the token in the credential and key management module for subsequent verification and revocation.

[0057] At this point, Agent_A can use Token_A to access relevant resources within this organization or domain.

[0058] S203: Cross-Domain Delegation and Link Recording During task execution, if Agent_A determines that its own capabilities are insufficient or that it needs to invoke external intelligent agents Agent_B, Agent_C, or a third-party system, it will initiate a delegation request to the delegation and link management module. This request includes: (1) The identifier of the delegating party (e.g., AgentID of Agent_A); (2) The identifier of the delegate (such as AgentID of Agent_B or external service identifier). (3) Expected target resource and operation type; (4) Limitations on delegation duration or maximum number of calls.

[0059] The delegation and link management module processes requests as follows: (1) Based on the delegation request and the original scope of authorization description, check whether the proposed delegation of access is still within the permitted overall scope; (2) If the delegation is valid, an associated proxy token DelegationToken_B is generated to authorize Agent_B to perform operations on behalf of Agent_A or the user within a limited scope; (3) Record the delegation link formed by “User→Agent_A→Agent_B (→Target System)” in the delegation link storage. The recorded content includes information such as delegation time, scope, and status. (4) Deliver DelegationToken_B to the runtime environment where Agent_B is located.

[0060] In scenarios requiring multi-level delegation (e.g., Agent_B delegating to Agent_C), the delegation and link management module can recursively include more nodes to form a multi-level delegation link, while recording the authorization source and restrictions of each level.

[0061] S204: Target Domain Access Authentication and Policy Enforcement When Agent_B or other delegated parties access the target system, the access control component of the target system or its domain performs the following actions: Verify the validity of the identity credentials and DelegationToken_B carried in the received access request, including: (1) Check the token signature and validity period; (2) Check the token status in the credential and key management module to confirm that it has not been revoked; (3) Query Agent_B's identity information and status through the identity discovery and verification module; (4) Obtain the cross-domain policy applicable to this access scenario through the Federal Trust and Cross-Domain Policy Management module, including local domain policy and foreign domain policy; (5) Based on the delegation link record, check whether the access path is complete, whether the delegation scope covers the current operation, and whether there are loops or conflicts. (6) If all verifications pass, access is allowed and corresponding operations are performed, while an access event record is sent to the monitoring and compliance module.

[0062] The monitoring and compliance module records the above events as audit logs, and can highlight sensitive operations when necessary.

[0063] S205: Operational Monitoring and Anomaly Handling Throughout the entire process of the intelligent agent performing its task, the monitoring and compliance module continuously monitors the following information: (1) The types and frequency of resources accessed by the agent; (2) Changes in the delegation process (addition, modification, cancellation); (3) Whether there are access attempts or abnormal behavior patterns that exceed the authorized scope.

[0064] When the monitoring and compliance module identifies anomalies based on preset rules or detection models, for example: (1) An intelligent agent accesses a large amount of sensitive data in a short period of time; (2) The length of a certain delegation chain is abnormal or the structure is complex; (3) An intelligent agent performs an operation during an unauthorized time period; This may trigger one or a combination of the following processing actions: (1) Suspend or revoke the relevant access token; (2) Notify the delegation and link management module to converge or revoke the relevant delegation relationships; (3) Notify the identity lifecycle management module to mark the relevant agent instance as "required for review" status; (4) Send alarm information to the system administrator or responsible person.

[0065] Through the above steps, this embodiment realizes fine-grained control of access permissions, traceable management of delegation relationships, and continuous security monitoring during the operation period in the process of cross-domain interaction of multi-agents, so that the entire multi-agent ecosystem can still meet the requirements of security, controllability and compliance in complex cross-domain scenarios.

[0066] This invention also includes an identity and access management system for multi-agent cross-domain interaction scenarios, using the method described above, comprising: The multi-intelligent identity lifecycle management module is used to establish and manage the full lifecycle identity of intelligent agents from creation to retirement. The full lifecycle identity can at least distinguish between software blueprints, published entities and running instances. The access and authorization management module is used to respond to user-submitted task requests and issue short-term access authorizations that bind the identity and task to the entry agent for executing the task. The delegation and link management module is used to establish and record an auditable delegation chain from the entry agent to the target service, which includes permission transfer relationships, when the entry agent needs to call other services to complete a task. The cross-domain access verification and monitoring module is used to verify and continuously monitor the cross-domain access behavior of smart agents based on full lifecycle identity, short-term access authorization, and auditable delegation chain.

[0067] For the implementation of the overall system architecture, refer to Figure 7This embodiment provides an overall architecture for an identity and access management system for multi-agent cross-domain interaction scenarios. The system is deployed in a network environment that supports the operation of multiple agents and includes at least a multi-agent operating environment, an external business system, and the identity and access management system of this invention.

[0068] In a preferred embodiment, the overall system architecture includes: 1. Multiple agent runtime environments (e.g., agent platform A, agent platform B, third-party agent hosting platform, etc.) are used to host different types of agent instances; 2. Multiple business systems or service providers (such as internal enterprise application systems, third-party API service providers, etc.) serve as target resource domains accessed by the intelligent agent; 3. Identity and Access Management System, used to uniformly manage agent identities, access permissions, and delegation relationships during cross-domain interactions among multiple agents.

[0069] The identity and access management system can be deployed on a standalone server cluster, or as a cloud service, microservice cluster, or containerized system. Its internal components include, but are not limited to, the following functional modules: 1. Multi-agent identity lifecycle management module Used for creating and maintaining identity records for agents in a multi-agent system. This module includes at least: (1) Identity registration submodule, used to assign unique identifiers to intelligent agent software blueprints, intelligent agent publishing entities and intelligent agent running instances, and to establish association relationships; (2) The state management submodule is used to maintain the different states of the intelligent agent, such as "draft", "released", "running", "paused" and "retired", and update the corresponding metadata; (3) Metadata storage submodule, used to store identity-related usage descriptions, creator information, security attributes, etc.

[0070] 2. Identity Discovery and Verification Module This module provides the ability to query and verify the identity of intelligent agents. It includes at least the following: (1) Identity Directory Submodule, which is used to receive query requests and return the current identity information and status according to the agent identifier; (2) Declaration verification submodule, used to verify the identity declaration, attribute declaration or credentials submitted by the agent to confirm their authenticity and completeness.

[0071] 3. Access and Authorization Management Module This module is used to manage access authorization and user consent for multiple agents when performing tasks. It includes at least: (1) Authorization strategy submodule, used to generate access scope descriptions based on preset policies and user intent; (2) Token issuance submodule, used to issue short-term access tokens based on the authorization result, and record the scope and validity period of the token; (3) Consent Management Submodule, used to record the authorization, revocation and history of user or upstream entity’s authorization of specific agent behavior.

[0072] 4. Delegation and Link Management Module This module is used to manage delegation relationships between agents and between users and agents. It includes at least the following: (1) Delegation modeling submodule, used to model the relationships of "representing whom", "within what scope" and "performing which operations" as delegation entries; (2) Link recording submodule, used to record the delegation link in chronological order, such as "user → agent 1 → agent 2 → target system"; (3) The cancellation and convergence submodule is used to uniformly cancel or converge relevant assignments when the strategy changes or risks occur.

[0073] 5. Assessment and Certification Management Module Used for maintaining evaluation results and supporting documentation related to intelligent agents and their operating environment. This module can: (1) Receive security assessment results, performance assessment results, etc. from internal or third parties; (2) Bind the evaluation results to the agent's identity; (3) Provide inquiry services for evaluation and certification to other entities that need to establish a trust relationship.

[0074] 6. Credentials and Key Management Module This module is used to manage various credentials and cryptographic keys related to authentication and access control. It includes: (1) Key generation and update submodule, used to generate and rotate keys for intelligent agents and system components; (2) Secure storage submodule, used to store key materials using a software key library or hardware security module (HSM); (3) The credential management submodule is used to manage the issuance and revocation of access tokens, identity credentials, and agent credentials.

[0075] 7. Federal Trust and Cross-Domain Policy Management Module Used to establish and maintain federated trust relationships between different organizational domains and platform domains. This module includes at least: (1) Trust relationship configuration submodule, used to configure mutual trust levels and policy mapping rules between different organizations; (2) Cross-domain policy engine submodule, which is used to comprehensively evaluate the local domain policy and the external domain policy in cross-domain access scenarios and give the final authorization decision suggestion.

[0076] 8. Monitoring and Compliance Module This module is used for continuous monitoring of identity usage and access behavior of multiple agents and for generating audit logs. It includes: (1) Behavior log submodule, used to collect events such as sensitive operations, cross-domain access, and policy changes initiated by the intelligent agent; (2) Risk detection submodule, used to identify abnormal behavior and trigger alarms according to preset rules or models; (3) Compliance Reporting Submodule, used to generate audit reports that meet regulatory requirements.

[0077] 9. Security Integration and Communication Protection Module This module provides security for communication between agents and the identity and access management system, as well as between agents and target systems. It can achieve the following: (1) Communication encryption and integrity protection; (2) Access layer identity verification and rate limiting control; (3) Policy-based request filtering and interception.

[0078] The above modules can be implemented as software program code and stored in a storage medium for execution by a processor, or they can be implemented through dedicated hardware or a combination of hardware and software. This invention does not limit the specific implementation method.

[0079] Compared with the prior art, the present invention has at least the following beneficial effects: (1) Unified multi-agent identity modeling and lifecycle management.

[0080] This invention uses a multi-agent identity lifecycle management module and an identity discovery and verification module to perform hierarchical modeling and state tracking of agent software blueprints, published entities, and running instances, so that each agent instance has clear and verifiable identity information in cross-domain interactions, avoiding confusion between agents and traditional technology clients or user accounts.

[0081] (2) Fine-grained cross-domain authorization and delegation control capabilities.

[0082] This invention, through the access and authorization management module and the delegation and link management module, realizes the scoped authorization and link tracking of the actions represented by intelligent agents. It can accurately express "who they represent", "within what resources and operation range", and "within what time interval" to perform operations, providing an auditable and revocable authorization basis for multi-agent collaboration.

[0083] (3) Enhanced cross-domain mutual trust and proof capabilities.

[0084] This invention introduces an evaluation and certification management module and a federated trust and cross-domain policy management module, which can bind agent traceability information, security assessment results and third-party certifications to their identities, and establish interoperable trust relationships between different organizations and platforms, thereby improving the interpretability and credibility of multi-agent cross-domain interaction processes.

[0085] (4) Ensure operational security and compliance in accordance with the zero-trust principle.

[0086] This invention extends authentication and access control from single authentication to end-to-end monitoring through a monitoring and compliance module and a security integration and communication protection module. It supports behavior-based access control and anomaly detection, enabling rapid response and handling when violations or risky behaviors are detected, thus meeting the audit and accountability requirements of high-risk or regulated scenarios.

[0087] (5) Good engineering scalability and compatibility.

[0088] This invention adopts a layered architecture, and each module can be integrated with existing IAM infrastructure (such as OAuth / OIDC, traditional PKI, etc.). It can also gradually introduce identity and access management capabilities for multiple agents, which facilitates smooth evolution and large-scale deployment without significantly modifying the existing system.

[0089] Please see Figure 8 The diagram shows a structural schematic of a computer device provided in an embodiment of this application. An embodiment of this application provides a computer device 400, including a processor 410 and a memory 420. The memory 420 stores a computer program executable by the processor 410. When the computer program is executed by the processor 410, it performs the method described above.

[0090] This application embodiment also provides a storage medium 430, on which a computer program is stored, and the computer program is executed by a processor 410 to perform the above method.

[0091] The storage medium 430 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0092] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. "A plurality of" means two or more, unless otherwise explicitly specified.

[0093] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0094] In the description of this specification, the references to terms such as "one 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 the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0095] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0096] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0097] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0098] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0099] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for identity and access management in multi-agent cross-domain interaction scenarios, characterized in that, Includes the following steps: Establish and manage the full lifecycle identity of an intelligent agent from creation to retirement, wherein the full lifecycle identity at least distinguishes between software blueprints, published entities, and running instances; In response to a task request submitted by a user, a short-term access authorization is issued to the entry agent that executes the task, and the entry agent's identity and task are bound together. When the entry agent needs to call other services to complete a task, an auditable delegation chain containing permission transfer relationships is established and recorded from the entry agent to the target service; Based on the full lifecycle identity, the short-term access authorization, and the auditable delegation chain, the cross-domain access behavior of the intelligent agent is verified and continuously monitored.

2. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 1, characterized in that, An intelligent agent establishes and manages its full lifecycle identity from creation to retirement. This full lifecycle identity at least distinguishes between software blueprints, released entities, and running instances, specifically including: Receive the registration information of the intelligent agent software blueprint submitted by the intelligent agent builder, and assign a software blueprint identifier to the software blueprint; In response to a release request for the software blueprint, a release identifier is generated, and the release identifier is associated with the publisher information and security assessment certificate; In response to the agent instance creation request initiated by the runtime environment, a runtime instance identifier is generated for the agent, and an agent identity credential corresponding to the runtime instance identifier is issued based on the software blueprint identifier.

3. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 1, characterized in that, In response to a user-submitted task request, a short-term access authorization is issued to the entry agent executing the task, binding the entry agent's identity and the task. Specifically, this includes: Parse the task request submitted by the user or upstream entity, determine the resource scope, operation type and time constraints required to complete the task, and generate an access scope description; Provide an interactive mechanism for the user or upstream entity to confirm or modify the access scope description, and record the final authorization result after obtaining user confirmation; Based on the confirmed access scope description, a short-term access token is issued to the entry agent that executes the task, and the short-term access token is bound to its identity and the task request. The permissions of the short-term access token are limited to the access scope description.

4. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 1, characterized in that, When the entry agent needs to invoke other services to complete a task, an auditable delegation chain containing permission transfer relationships is established and recorded from the entry agent to the target service, specifically including: When the entry agent determines that it needs to call other agents or external systems, it initiates a delegation request to the delegation management service. The delegation request includes at least the delegate identifier, the target resource identifier, and the operation type. Verify that the operation involved in the delegation request is within the overall permissions authorized by the short-term access token; If the verification is successful, an agency certificate is generated for the delegate, and delegation link information including the delegator identifier, the delegate identifier, the target resource, the operation type, and the time limit is recorded to form the auditable delegation chain.

5. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 4, characterized in that, The establishment of the auditable delegation chain also includes dynamic validity verification of the delegation chain: Before generating the proxy credential, the identity status of the entry agent and the validity of its short-term access authorization are queried in real time. If the query result indicates that the identity status of the entry agent is abnormal or the short-term access authorization has expired, the establishment process of the auditable delegation chain will be terminated.

6. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 5, characterized in that, The real-time query includes: Obtain the identity credential of the entry agent, and extract the running instance identifier of the entry agent from the identity credential; Based on the running instance identifier, query the current lifecycle state bound to the entry agent; A unique identifier for obtaining the short-term access authorization; Based on the unique identifier, query the current revocation status and remaining validity period of the short-term access token; The authenticity of the obtained lifecycle status and the revocation status and remaining validity period of the short-term access token are verified.

7. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 5, characterized in that, The dynamic validity check also includes context-based policy evaluation: Retrieve the security policy associated with the currently assigned task, target resource, or related trust domain; Based on the security policy, assess the conditions under which the auditable delegation chain is permitted to be established in the current context; If the evaluation results do not meet the conditions, the validity check is deemed to have failed.

8. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 4, characterized in that, Based on the full lifecycle identity, the short-term access authorization, and the auditable delegation chain, the cross-domain access behavior of the intelligent agent is verified and continuously monitored, specifically including: When the target domain receives an access request, it verifies the validity of the identity credentials of the agent that initiated the access request, the short-term access token, and the proxy credentials. Based on the cross-domain trust policy, the integrity of the auditable delegation chain is verified, and the current access operation is confirmed to be within the authorization scope recorded by the auditable delegation chain. After successful verification and confirmation, the access request is allowed to be executed, and the access event is recorded in the audit log.

9. The identity and access management method for multi-agent cross-domain interaction scenarios according to claim 8, characterized in that, Also includes: During the execution of the task by the intelligent agent, its resource access behavior and the status of the auditable delegation chain are continuously monitored; When monitoring detects that the access behavior exceeds the scope of the short-term access authorization or the authorization defined by the auditable delegation chain, or identifies an abnormal behavior pattern, an alarm is triggered and at least one of the following actions is taken: revoking the relevant access credentials or terminating the operation of the smart agent.

10. An identity and access management system for multi-agent cross-domain interaction scenarios, characterized in that, include: The multi-intelligent identity lifecycle management module is used to establish and manage the full lifecycle identity of an intelligent agent from creation to retirement. The full lifecycle identity at least distinguishes between software blueprints, published entities, and running instances. The access and authorization management module is used to respond to the task request submitted by the user and issue a short-term access authorization to the entry agent that executes the task, and the entry agent's identity and task binding are associated with the entry agent. The delegation and link management module is used to establish and record an auditable delegation chain from the entry agent to the target service, which includes permission transfer relationships, when the entry agent needs to call other services to complete a task; The cross-domain access verification and monitoring module is used to verify and continuously monitor the cross-domain access behavior of the intelligent agent based on the full lifecycle identity, the short-term access authorization, and the auditable delegation chain.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-9.

12. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images