An agent lifecycle state change management method and device

Abstract

The application relates to the technical field of agent state management, and provides an agent life cycle state change management method and device, which comprises the following steps: receiving a state change request for a target agent, checking the legality of the state change request based on a preset state migration matrix; in response to the passing of the checking, performing signature endorsement on a state change digest corresponding to the state change request, generating a state change event; in the same transaction, updating a current state record based on the state change event, and synchronously flipping at least two mutually exclusive state publishing objects, wherein the updated current state record contains reference information pointing to the state change event. The application realizes tamper-proofing, illegal migration prevention, multi-semantic accurate expression and internal and external state consistency of state change.

Description

Technical Field

[0001] This application relates to the field of intelligent agent state management technology, and more specifically, to a method and apparatus for managing intelligent agent lifecycle state changes. Background Technology

[0002] Currently, in intelligent agent, automated service, API account, device certificate, or digital identity systems, entities typically maintain states such as enabled, disabled, deleted, and expired. State fields are generally stored in business databases, authentication centers, gateway configuration libraries, or identity management backends. When an entity needs to be disabled, the administrator, automated scripts, or governance system modify this field, and the gateway or business system then determines whether to allow the entity to continue accessing resources based on the field value. Other solutions use certificate revocation lists, online certificate status queries, status lists, blacklists, or token revocation lists to indicate whether a credential has expired. When verifying credentials, the verifier can retrieve the revocation list, query online interfaces, or read status bits to determine whether the credential can still be used. These solutions can express whether something has been revoked or not, and can also improve the credibility of revocation results through signed publications. Additionally, some systems write identity status changes to audit logs, operation logs, blockchain digests, transparent logs, or security event platforms. These logs can record the time, operator, values ​​before and after the modification, and reason for a status modification action, for post-event investigation and compliance auditing. However, ordinary state fields are mainly maintained by backend services or databases. Administrators, scripts, compromised services, or malicious insiders may directly rewrite these fields, making paused or revoked entities available again. Existing revocation lists typically only express revocation or non-revocation, making it difficult to simultaneously express different semantics such as active, paused, permanent revocation, and tombstone archiving in the agent's lifecycle. Ordinary state machines have weak constraints; revoked entities may be changed back to active, and active or paused entities may be directly deleted or archived, leading to breaks in state history. State change logs, current state tables, and external revocation publications are usually written separately, which may result in situations where the log has been written but the external system still shows it as available, or where the external bitmap has been flipped but there is a lack of evidence of state changes. When relying solely on online query interfaces, external verifiers can only trust the interface's immediate return, making it difficult to independently prove whether the state seen at a particular moment is the authoritative state. If erroneous revocations are handled by directly reverting to the original state, it will disrupt the audit chain; if no compensation mechanism is provided, it will affect the continued operation of normal entities. Scenarios such as batch revocation, hardware anchor failure, and temporary sub-agent expiration will generate a large number of state changes, and ordinary logs or manual background operations cannot guarantee idempotency, order, verifiability, and regulatory traceability. Summary of the Invention

[0003] To address the problems of easily tampered state fields and inconsistencies between internal and external states in existing technologies, this application proposes a method and apparatus for managing state changes throughout the lifecycle of an intelligent agent, which achieves anti-tampering, anti-illegal migration, accurate multi-semantic expression, and consistency between internal and external states.

[0004] Firstly, a method for managing the lifecycle state changes of an intelligent agent is provided, which may include: Receive a state change request for the target intelligent agent, and verify the legality of the state change request based on a preset state transition matrix; Upon successful verification, a signature endorsement is performed on the state change digest corresponding to the state change request, and a state change event is generated. Within the same transaction, the current state record is updated based on the state change event, and at least two mutually exclusive state publications are simultaneously flipped, wherein the updated current state record contains reference information pointing to the state change event.

[0005] In one possible implementation, the preset state transition matrix is ​​configured to prohibit transitions from an irreversible state to a reversible state, and to prohibit skipping the irreversible state and directly entering the final state. The at least two mutually exclusive state publishers include a first state publisher and a second state publisher. The same agent shares the same bit order in the first state publisher and the second state publisher, and the first state publisher and the second state publisher satisfy mutual exclusion constraints.

[0006] In one possible implementation, the irreversible state includes the undo state, the final state includes the tombstone state, and the reversible state includes the active state and the paused state. The first status publication is a cancel bitmap, and the second status publication is a pause bitmap; When entering the pause state, the bit value corresponding to the pause bitmap is set to a first preset value while the bit value corresponding to the cancel bitmap is kept at a second preset value; When entering the cancel state, the bit value corresponding to the cancel bitmap is set to the first preset value and the bit value corresponding to the pause bitmap is cleared; When entering the tombstone state, the bit value corresponding to the cancel bitmap is kept at the first preset value and the bit value corresponding to the pause bitmap is kept at the second preset value.

[0007] In one possible implementation, the validity of the state change request is verified based on a preset state transition matrix, including: Based on the current state and the target state in the state change request, it is determined whether the migration belongs to the allowed set. The allowed set includes active state migrating to paused or revoked state, paused state migrating to active or revoked state, and revoked state migrating to tombstone state. Revoked state reverting to active state is prohibited, tombstone state migrating to any state is prohibited, and active or paused state migrating directly to tombstone state is prohibited.

[0008] In one possible implementation, after verifying the legality of the state change request based on a preset state transition matrix and before performing a signature endorsement on the state change digest corresponding to the state change request, the method further includes: authorization and evidence verification. Match the corresponding authorized materials according to the triggering party type in the status change request, and verify whether the upstream evidence referenced in the status change request is valid.

[0009] In one possible implementation, the state change event includes the state before the change, the state after the change, the reason code, the triggering party type, the authorization digest, the event hash of the associated event, the signature endorsement, the event sequence number, the hash of the preceding event, the hash of the current event, and the filing receipt; the filing receipt is issued by the server after the event is written.

[0010] In one possible implementation, the reference information includes the event sequence number and event hash of the state change event; The current state record is not used as an independent source of facts, but only points back to the corresponding state change event through the event sequence number and the event hash.

[0011] In one possible implementation, the method further includes: In response to the detection of an erroneous revocation of the status change, instead of reverting to the original status, a compensation event is generated and a new identity credential is reissued after the authorization conditions are met; The cancellation fact corresponding to the original state record is retained in the state event chain.

[0012] In one possible implementation, the method further includes: A state proof package is generated, which includes the current state record, an event chain fragment of the state change event, a bitmap proof of the state publication, an archive receipt, and an authorization digest, for external verification parties to trace the legality of the state change.

[0013] Secondly, a device for managing the lifecycle state changes of an intelligent agent is provided, the device may include: The request entry module is configured to receive state change requests for the target intelligent agent. The state verification module is configured to verify the legality of the state change request based on a preset state transition matrix; The signature endorsement module is configured to perform a signature endorsement on the change digest corresponding to the state change request in response to successful verification, and generate a state change event. The transaction processing module is configured to update the current state record based on the state change event within the same transaction, and synchronously flip at least two mutually exclusive state publications; the updated current state record contains reference information pointing to the state change event.

[0014] This application provides a method and apparatus for managing state changes throughout the lifecycle of an intelligent agent. The method includes receiving a state change request for a target intelligent agent and verifying the legality of the state change request based on a preset state transition matrix. Upon successful verification, a signature endorsement is performed on the state change digest corresponding to the state change request, generating a state change event. Within the same transaction, the current state record is updated based on the state change event, and at least two mutually exclusive state publications are simultaneously flipped. The updated current state record contains reference information pointing to the state change event. This application achieves tamper-proof state changes, prevention of unauthorized transitions, accurate multi-semantic expression, and consistency between internal and external states. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a method for managing the lifecycle state changes of an intelligent agent, provided in an embodiment of this application; Figure 2 A schematic diagram of an agent lifecycle state matrix and a two-bitmap mapping provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an intelligent agent lifecycle state change management device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The terms "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The terms "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but does not exclude other elements or objects. The terms "connection," "coupled," or "linked," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0018] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0019] Figure 1 This is a flowchart illustrating a method for managing the lifecycle state changes of an intelligent agent, as provided in an embodiment of this application. Figure 1 As shown, the method may include: Step S110: Receive a state change request for the target intelligent agent and verify the legality of the state change request based on a preset state transition matrix.

[0020] Receive state change requests from triggers such as registrants, governance systems, regulatory interfaces, automated rules, hardware anchor state linkage modules, or lifecycle automated tasks. These requests may include: the target agent's identity number, target state, trigger type, reason code, upstream evidence reference, and idempotency flag.

[0021] Step S120: In response to successful verification, perform signature endorsement on the state change digest corresponding to the state change request and generate a state change event.

[0022] When a state transition is valid, check whether the triggering party has the authority to initiate the state change. For manual governance actions, verify the authorized signature or approval summary; for regulatory orders, verify the regulatory channel or authorized materials; for hardware anchor failures, verify the anchor status proof; for automated tasks, verify the rule version and task source.

[0023] Subsequently, the state change summary is signed. The signature input must at least cover the agent's identity number, current state, target state, reason code, trigger type, evidence citation, idempotency flag, and state matrix version.

[0024] For regulatory-mandated revocation, hardware anchor failure, and batch revocation, the signature should also cover the batch number or authorization source. The signature key can take various forms, including device identity, hardware anchor, governance signature key, lifecycle management key, trusted execution environment, or hardware security module. State change events can include: pre-change state, post-change state, reason code, reason details summary, trigger type, authorization summary, associated events, signature endorsement, event sequence number, previous hash, event hash, and filing receipt.

[0025] Next, the state change is written as a state change event. When writing the event, the event sequence number of each agent and the preceding hash are concatenated, and the server issues an entry receipt. The preceding hash and the event hash form a chain-like anti-tampering structure; any modification to an intermediate event will cause subsequent hashes to mismatch, thus preventing event insertion or tampering. The entry receipt is issued by the server after the event is written, providing a timestamp of the event write and proof of its existence.

[0026] Step S130: In the same transaction, update the current state record based on the state change event, and simultaneously flip at least two mutually exclusive state publications.

[0027] The updated current state record contains references to the state change event.

[0028] The system stores the current lifecycle state of each agent, along with the event sequence number, event hash, reason code, and update time of the most recent state event. The current state record only stores the event sequence number and event hash as reference information pointing back to the state change event, not as an independent source of fact. This means that any direct tampering with the state fields will be exposed during comparison with the event chain, thus preventing silent state tampering.

[0029] In one embodiment, the preset state transition matrix in step S110 is configured to prohibit transitions from irreversible states to reversible states, and to prohibit skipping irreversible states and directly entering the final state.

[0030] At least two mutually exclusive state publishers may include a first state publisher and a second state publisher. The same agent shares the same bit order in the first state publisher and the second state publisher, and the first state publisher and the second state publisher satisfy the mutual exclusion constraint.

[0031] like Figure 2As shown, irreversible states include the REVOKED state, final states include the TOMBSTONED state, and reversible states include the ACTIVE state and the SUSPENDED state. The first state publication is a REVOKED bitmap, and the second state publication is a SUSPENDED bitmap. An agent can only enter the TOMBSTONED state after entering the REVOKED state, upon the expiration of the retention period, the fulfillment of regulatory archiving, or the automatic archiving conditions. After tombstoneization, the agent's identity becomes unusable, the identity number is not reused, public verification results still show as unusable, and historical state events and audit proofs are retained.

[0032] When entering the pause state, set the bit value corresponding to the pause bitmap to the first preset value and keep the bit value corresponding to the undo bitmap to the second preset value; when entering the undo state, set the bit value corresponding to the undo bitmap to the first preset value and clear the bit value corresponding to the pause bitmap; when entering the tombstone state, keep the bit value corresponding to the undo bitmap to the first preset value and the bit value corresponding to the pause bitmap to the second preset value.

[0033] For example, the specific rules for flipping the corresponding bit order in the undo bitmap and pause bitmap according to the target state are as follows: if the target state is paused, set the corresponding bit of the pause bitmap to 1 and keep the undo bit to 0; if the target state is active and the current state is paused, clear the corresponding bit of the pause bitmap; if the target state is undo, set the corresponding bit of the undo bitmap to 1 and clear the corresponding bit of the pause bitmap; if the target state is tombstone, keep the corresponding bit of the undo bitmap to 1 and the corresponding bit of the pause bitmap to 0.

[0034] The above approach, through transaction atomicity guarantees and failure rollback mechanisms, achieves the effect of avoiding inconsistencies such as events being written but the external state remaining unchanged.

[0035] Step S110, which verifies the legality of the state change request based on a preset state transition matrix, includes: Determine whether the migration belongs to the allowed set based on the current state and the target state in the state change request. The allowed set may include: active state migrating to paused or revoked state, paused state migrating to active or revoked state, and revoked state migrating to tombstone state; and prohibiting revoked state from being restored to active state, tombstone state from migrating to any state, and active or paused state directly migrating to tombstone state.

[0036] If the migration is not within the allowed matrix, such as a revoked state returning to an active state, an active state directly entering a tombstone state, or a tombstone state being reactivated, the request is directly rejected and an illegal migration result that cannot be retried is returned. In this case, the system does not write state events, update the state table, or flip the bitmap. This embodiment, through the strong constraints of the state matrix, fundamentally prevents the possibility of an expired identity being illegally restored and used.

[0037] In this embodiment, the system sets a dual-bitmap mutual exclusion invariant: the revocation bit and pause bit of the same identity cannot be 1 simultaneously. It should be understood that the reason this application uses a dual-bitmap instead of a single state field is that the dual-bitmap allows external verifiers to independently determine the state without querying the internal database, and the mutual exclusion constraint prevents semantic conflicts. When interpreting the state, the external verifier follows the rule of prioritizing the revocation bit; the verifier checks the revocation bit first, then the pause bit. If the revocation bit is 1, regardless of the pause bit value, the agent is directly determined to be unusable; if the revocation bit is 0, the pause bit is then checked. If the pause bit is 1, the agent is determined to be paused; if both bits are 0, the agent is determined to be usable. This priority mechanism ensures the absolute priority of permanent invalidation semantics, preventing revoked identities from being mistakenly judged as usable due to residual pause bits.

[0038] Maintain revocation and pause bitmaps, and publish them via content delivery network, object storage, vetting channels, or verification service interfaces after signing with the state publication signer. Revocation and pause bitmaps can be published separately or within the same state publication package. Each state publication (revocation or pause bitmap) can include: bitmap text, publication sequence number, issuance time, validity period, publication signature, signature key identifier, and optional timestamp or proof. Periodically issue signed and validated publications, even without new state changes, enabling verifiers to determine if the publication channel is blocked or under attack based on the publication update frequency. Output the current state, state publication, state bitmap position, signature, validity period, and necessary proof to the verifier.

[0039] On the verification side, after receiving the agent's identity credential, the verifier reads the revocation bitmap identifier, pause bitmap identifier, and bit sequence from the credential. First, it verifies the signature and validity period of the revocation bitmap. If the revocation bit is 1, it is directly determined to be unusable. If the revocation bit is 0, it then verifies the pause bitmap. If the pause bit is 1, it is determined to be paused; if both bits are 0, it is determined to be usable. This application achieves the effect of accurately expressing multiple semantic states of the lifecycle and preventing semantic conflicts in external verification through dual-bitmap mutual exclusion logic and the revocation bit priority interpretation rule.

[0040] Furthermore, after verifying the legality of the state change request based on a preset state transition matrix and before performing a signature endorsement on the state change digest corresponding to the state change request, this application also includes an authorization and evidence verification mechanism, including: The system matches the corresponding authorized materials based on the triggering party type in the status change request and verifies the validity of the upstream evidence cited in the status change request. The triggering party type can include: registrant, governance system, regulatory interface, automated rules, and hardware anchor status linkage module. Upstream evidence is cited in the form of event hash, audit number, governance resolution summary, regulatory instruction summary, or hardware anchor status proof, and does not expose sensitive plaintext in public status publications.

[0041] During verification, differentiated authorization material matching logic is employed for different triggering party types. For example, when the triggering party type is a registrant, the system verifies the signature of the management private key held by the registrant or the multi-signature approval digest; when the triggering party type is a regulatory interface, the system verifies the signature of the instruction issued through the dedicated regulatory channel and the scope of authorization; when the triggering party type is a hardware anchor status linkage module, the system verifies the status failure certificate reported by the hardware anchor and the measurement report issued by the trusted execution environment. This authorization material matching mechanism, which is strongly bound to the triggering party's identity, ensures that any status change request has a clear source of authorization, preventing unauthorized operations.

[0042] Upstream evidence includes at least one of the following: anomaly event evidence summary, governance resolution summary, regulatory instruction summary, hardware anchor state proof, agent behavior audit report summary, and third-party security assessment report summary. Upstream evidence is cited in the form of content-addressed hashes. When verifying the validity of upstream evidence referenced by an evidence citation, the method further includes: retrieving the corresponding original evidence text from a trusted evidence storage based on the content-addressed hash in the evidence citation; calculating the hash value of the original evidence text and comparing it with the content-addressed hash; if they match, the upstream evidence is valid.

[0043] The aforementioned content-addressed hash is generated using cryptographic hash algorithms such as SHA-256 or Keccak-256 to calculate the original evidence text. Upon receiving a state change request, the system extracts the content-addressed hash carried within it and initiates a retrieval request to a trusted evidence storage facility. This trusted evidence storage facility can be a distributed storage network, a consortium blockchain node with access control, or a dedicated secure database. After retrieving the original evidence text, the system recalculates its hash value locally and rigorously compares it with the hash value carried in the request. It should be understood that this content-addressed referencing method allows the authenticity of state change events to be verified without carrying the complete original evidence text, significantly reducing the storage overhead of the state event chain. Simultaneously, due to the collision resistance of hash values, any minor alteration to the original evidence text will result in a hash value mismatch, thus achieving tamper-proof referencing and deduplicated storage of evidence.

[0044] To establish a robust anti-tampering defense, authorization and evidence verification generate clearly defined verification result types and processing methods. Authorization verification produces two results: authorization passed or authorization failed; evidence verification produces three results: evidence valid, evidence invalid, or evidence missing.

[0045] When authorization verification passes and evidence verification is valid, the system continues to execute signature endorsement and subsequent transaction operations. When authorization verification fails, the system rejects the state change request, returns an authorization failure reason code, and does not execute signature endorsement, write to the state event, or flip the bitmap. When evidence verification is invalid or evidence is missing, the system rejects the state change request, returns an evidence verification failure reason code, and similarly does not execute subsequent operations. Failed state change requests are not written to the state event chain, but the system records a verification failure log, including a request summary, failure reason, and timestamp, for audit traceability.

[0046] This embodiment achieves strong verification of the basis for state changes through clearly categorized verification result processing logic. Subsequent processes are strictly blocked upon verification failure, ensuring that only requests with both legitimate authorization and genuine evidence can trigger state changes, thus preventing unauthorized operations or illegal state changes based on forged evidence from the outset. Simultaneously, by recording verification failure logs, complete clues are preserved for security auditing and attack tracing, further enhancing the system's security traceability.

[0047] In a specific embodiment, a state change event may include: the state before the change, the state after the change, the reason code, the triggering party type, the authorization digest, the event hash of the associated event, the signature endorsement, the event sequence number, the hash of the preceding event, the hash of the current event, and the filing receipt; the filing receipt is issued by the server after the event is written. Reference information may include: the event sequence number and event hash of the state change event; wherein, the current state record is not used as an independent source of fact, but only points back to the corresponding state change event through the event sequence number and event hash.

[0048] If any step in the generation of a state change event, the update of the current state record, or the flipping of a state publication fails within the same transaction, the entire transaction is rolled back to maintain consistency between the state change event, the current state record, and the state publication.

[0049] Furthermore, when appending state change events, a chain-like anti-tampering structure based on hash pointers is constructed. The event sequence number is a monotonically increasing integer used to identify the chronological order of events within the agent's lifecycle. The preceding event hash is the current event hash of the previous state change event, which is a digest obtained by cryptographically hashing all core fields of this event (including the preceding event hash). This chain-like structure of preceding and current event hashes means that any minor alteration to a historical event will cause a change in the current event hash, leading to a mismatch in the current event hashes of all subsequent events. Therefore, attackers cannot insert, delete, or modify any intermediate events without disrupting the entire chain, thus establishing a defense-in-depth against tampering. The filing receipt is issued by the server after the event is successfully written to persistent storage and includes a trusted timestamp and proof of the event's existence. External verifiers or auditors can independently confirm that the state change event was indeed recorded by the system at a specific point in time by verifying the signature of the filing receipt, preventing the server from denying it afterward.

[0050] The saved current state record can include: agent ID, current state, most recent state event sequence number, most recent state event hash, reason code, update time, and state matrix version.

[0051] It should be understood that the current state record only stores the event sequence number and event hash as reference information to indicate the state change event, and does not serve as an independent source of fact. This means that the current state record is essentially a cached view for faster queries, and its reliability depends entirely on the state event chain. If a backend administrator or a compromised service directly modifies the state fields in the current state record, the verifier will immediately detect the mismatch when comparing the hash of the most recent state event in the current state record with the actual hash of the corresponding event in the state event chain, thus exposing the tampering. This design eliminates the possibility of silent state tampering from a fundamental mechanism.

[0052] During transaction execution, atomicity is guaranteed through database-local transactions or a strictly ordered outbox mode. If any step in the generation of a state change event, the update of the current state record, or the flipping of a state publication fails, the entire transaction is rolled back. For example, if a write fails due to a network partition while flipping the bitmap, the entire transaction will be rolled back, and previously generated state change events and updated current state records will be undone. This embodiment uses a transaction rollback mechanism to prevent inconsistent states such as events being written but the bitmap not being flipped, ensuring that the state publication seen by the external verifier strictly corresponds to the internal state event chain, thus avoiding the security risk of inconsistencies between internal and external states.

[0053] In some embodiments, in response to detecting an erroneous revocation status change, instead of reverting to the original status, a compensation event is generated and a new identity credential is reissued after the authorization conditions are met; the revocation fact corresponding to the original status record is retained in the status event chain.

[0054] When the system detects that a revocation operation has been confirmed as an erroneous revocation, such as due to a false triggering of an upstream anomaly alarm or a misjudgment by the governance system, the system will not directly change the original identity from the revoked state back to the active state. This is because directly reverting to the original state would disrupt the continuity of the audit chain, and it would be impossible to distinguish between malicious tampering and legitimate correction during subsequent auditing. Therefore, the system employs a compensation event mechanism, generating a compensation event of type REVOCATION_RETRACTED and writing it into the state event chain. The revocation of the original identity, along with its associated authorization summary and evidence citations, is fully preserved in the state event chain. After the authorization conditions are met, the system reissues a new identity credential for the affected entity, and the original identity number is no longer reused. This mechanism, which avoids reverting to the original state but instead uses compensation events and a new identity, preserves the complete historical change trajectory, reduces the difficulty of dispute resolution, and ensures the tamper-proof nature of the audit chain.

[0055] It should be noted that for mishandling in a paused state, the system can be restored to an active state through a legitimate pause recovery path, and the reason for recovery and authorization summary will be retained.

[0056] Furthermore, when stronger proof is required, a state proof package can be generated for regulatory purposes, dispute resolution, or internal review. The complete composition of a state proof package can include: the current state record, a fragment of the state change event chain, the hash of the most recent state event, the state bitmap position, the signature of the state publication, the filing receipt, evidence citations, authorization digests, and timestamps. In other words, the state proof package combines the state bitmap result with the state change event chain, the filing receipt, the timestamp, and the authorization digest, enabling the verifier to not only know the current state but also how the state was entered.

[0057] Starting with the target agent's identity number, the auditors read the aforementioned data and re-verify the state matrix, event hash chain, state publication signature, and bitmap interpretation rules to determine whether state changes are legal, whether they have been illegally reversed, and whether there are inconsistencies between events and publications. By combining multi-dimensional evidence to generate a state proof package, the interpretability and external verification capabilities of regulatory evidence collection are improved.

[0058] It should be understood that the state proof package can be tailored to different scenarios. In ordinary resource entry verification scenarios, only the current state and bitmap proof are needed for rapid verification; in enterprise internal audit scenarios, state event chain fragments can be attached for traceability; in regulatory investigation scenarios, authorization digests, filing receipts, and upstream evidence hashes need to be attached to provide a complete evidence chain. This tailorable feature allows the state proof package to flexibly adapt to verification needs with different trust levels and performance requirements.

[0059] In a preferred embodiment, the state change digest further includes a random number; before performing a signature endorsement on the state change digest, the method further includes: A unique transaction identifier is generated by combining a random number with an idempotent identifier from the state change request. The global transaction record is then queried based on the unique transaction identifier. If a completed transaction record with the same identifier exists, the processing result corresponding to that completed transaction record is returned directly without repeating the signature endorsement, state event generation, and state publication flipping operations.

[0060] Specifically, in a distributed, multi-instance lifecycle management system, network retransmissions or concurrent duplicate commits may occur. To achieve precise idempotent control across nodes, the state change request carries an idempotent identifier generated by the client, and the system introduces a high-entropy random number when constructing the state change digest. The random number and the idempotent identifier are combined according to a preset concatenation rule to generate a globally unique transaction identifier. Before performing signature endorsement, the system first queries the global transaction record based on this unique transaction identifier. If the query finds a match, it means that the transaction has been successfully processed, and the system directly returns the state change event and proof information corresponding to the completed transaction record from the cache or database, without triggering subsequent time-consuming operations such as signature endorsement, event generation, and bitmap flipping.

[0061] It should be understood that relying solely on idempotent identifiers in a distributed environment may lead to misjudgments due to hash collisions or defects in generation rules. By introducing random numbers for combination, the unpredictability and global uniqueness of the unique transaction identifier are guaranteed from a cryptographic perspective. This effectively avoids repeated state changes and bitmap flips caused by network retransmissions or concurrent repeated submissions, and ensures the atomicity and consistency of state changes.

[0062] In a preferred embodiment, at least two mutually exclusive state publications each have an independent version number and publication timestamp; when synchronously flipping at least two mutually exclusive state publications in the same transaction, the method further includes: writing the hash value of the state change event into the metadata field of the state publication to establish a verifiable association between the state publication and the state change event; and an external verifier verifies whether the state publication is generated based on the latest state change event by comparing the event hash in the metadata of the state publication with the hash of the state change event.

[0063] Among them, the undo bitmap and the pause bitmap are two independent state publications, each maintaining a monotonically increasing independent version number and publication timestamp.

[0064] When the transaction processing module executes the same transaction, in addition to flipping the bit values ​​in their respective bitmap text, it also writes the event hash of the state change event that triggered the flip into the metadata field of the state publication. After obtaining the state publication, the external verifier not only verifies its publication signature and validity period, but also extracts the event hash from the metadata and compares it with the hash of the latest state change event obtained from the state event chain module. If they match, it proves that the state publication was indeed generated based on the latest state change event; if they do not match, it indicates that the state publication may have been maliciously replaced or delayed in its publication. This embodiment establishes a verifiable cryptographic association between the publication and the event chain by embedding the hash value of the state change event in the state publication metadata, enabling the external verifier to independently verify the timeliness and authenticity of the state publication, preventing the state publication from being maliciously replaced or delayed in its publication, and improving the credibility of state verification.

[0065] like Figure 3 As shown, this embodiment provides a device for managing the lifecycle state changes of an intelligent agent. The device includes: a request entry module 310, a state verification module 320, a signature endorsement module 330, and a transaction processing module 340. The modules communicate and coordinate with each other via an internal bus or service call interface, collectively forming the core framework for verifiable state change management.

[0066] The request entry module 310 is configured to receive state change requests for the target intelligent agent.

[0067] The request entry module serves as the unified interface between the system and external triggers, receiving state change requests from triggers such as registrants, governance systems, regulatory interfaces, automatic rules, hardware anchor state linkage modules, or lifecycle automatic tasks. This request includes the target agent's identity number, target state, trigger type, reason code, upstream evidence reference, and idempotency identifier. Upon receiving the request, the request entry module performs protocol parsing and format validation, and then passes the parsed structured data to the state validation module.

[0068] The status verification module 320 is configured to verify the legality of status change requests based on a preset status transition matrix.

[0069] Upon receiving a structured request, the state verification module first extracts the target agent's identity number and reads the agent's current state from the current state recording module. Then, based on the current state and the target state in the request, the state verification module queries a preset state transition matrix to determine if the transition belongs to the allowed set. If the transition is not within the allowed matrix, the state verification module directly rejects the request and returns a non-retryable illegal transition result, without triggering the subsequent signature endorsement module. It should be understood that the state verification module also works in conjunction with the authorization and evidence verification module. When a state transition is legal, the authorization and evidence verification module checks whether the triggering party has the authority to initiate the state change and verifies the validity of the upstream evidence. Only when both the state matrix verification and the authorization evidence verification pass will the state verification module send a release signal to the signature endorsement module. This multi-level verification mechanism ensures that only completely legal requests can enter the signature process, preventing illegal operations at the source.

[0070] The signature endorsement module 330 is configured to perform a signature endorsement on the change digest corresponding to the state change request in response to successful verification, and generate a state change event.

[0071] Specifically, upon receiving the clearance signal, the signature endorsement module extracts the state change digest and signs it using signature keys such as device identity, hardware anchor, governance signature key, lifecycle management key, trusted execution environment, or hardware security module. The signature input must at least cover the agent's identity number, current state, target state, reason code, trigger type, evidence reference, idempotency flag, and state matrix version. After signing, the signature endorsement module generates a state change event containing fields such as the state before the change, the state after the change, the reason code, the authorization digest, the event sequence number, the preceding hash, the event hash, and the filing receipt, and then passes this event to the transaction processing module.

[0072] The transaction processing module 340 is configured to update the current state record based on the state change event within the same transaction, and synchronously flip at least two mutually exclusive state publications; the updated current state record contains reference information pointing to the state change event.

[0073] The transaction processing module is responsible for maintaining consistency among state change events, current state records, and state publications. Internally, the module ensures atomicity through either local database transactions or a strictly ordered outbox mode. In local database transaction mode, event appending, record updating, and bitmap flipping are bound within the same database transaction; failure in any step triggers a complete rollback. In strictly ordered outbox mode, state change events are first written to the event log, then background processes consume events in strict order and perform state record updates and bitmap flipping. If these operations fail, they are retried in a compensation queue. This transactional guarantee mechanism avoids inconsistencies such as events being written but bitmaps not being flipped, ensuring that the state publications seen by external verifiers strictly correspond to the internal state event chain. This embodiment achieves tamper-proof state changes and internal / external consistency through the collaborative execution of verification, signature, and transactional synchronous updates by various modules.

[0074] In one example, the complete state change process under different trigger types will be described in detail below, taking into account a specific intelligent agent management scenario.

[0075] Scenario 1: Abnormal Pause and Resumption. An agent triggers a high-risk anomaly while accessing external resources, generating an evidence digest for the anomaly event. The governance system, acting as the trigger, initiates a state change request from an active state to a paused state. Upon receiving this request, the system first verifies that the transition belongs to the allowed set based on a preset state transition matrix; if the verification passes, the authorization and evidence verification module matches the corresponding governance authorization materials based on the trigger type (government system) and verifies the validity of the anomaly event evidence digest referenced by the upstream evidence. After all verifications pass, the signature endorsement module performs a signature endorsement on the state change digest, generating a state change event. Within the same transaction, the system updates the current state record to a paused state and simultaneously flips the corresponding bit value in the pause bitmap to 1, while maintaining the corresponding bit value in the revocation bitmap at 0. After the repair is completed and verified, the governance agent initiates a recovery request from the paused state to an active state. The system clears the corresponding bit value in the pause bitmap and writes it into the recovery state event. Before recovery, the verifier sees the pause bit as 1; after recovery, both the revocation and pause bits are 0. This scenario achieves rapid isolation and secure recovery of abnormal agents through complete verification and transactional flipping.

[0076] Scenario 2: Revocation after hardware anchor failure. A hardware anchor or anchor access credential bound to an agent is confirmed to be invalid. The system first initiates a pause operation according to the policy, stopping the agent from actively providing services. If recovery is not possible within the review period, the lifecycle manager, as the trigger, initiates a state change request from the paused state to the revocation state. After verifying the legality of the migration, the system verifies the anchor state certificate reported by the hardware anchor state linkage module, signs and endorses the state change summary, and writes it into the state change event. Within the same transaction, the system sets the corresponding bit in the revocation bitmap to 1 and clears the corresponding bit in the pause bitmap. Upon seeing the revocation bit set to 1, the verifier directly determines that the agent is unusable and no longer interprets it according to the pause logic. This scenario ensures the absolute priority of permanent failure semantics through the revocation bit priority interpretation rule.

[0077] Scenario 3: Temporary Sub-Agent Expiration. A temporary sub-agent created by the parent agent reaches its expiration date. The automatic lifecycle task, acting as the trigger, initiates a state change request from the active state to the revoked state based on the expiration reason, and records the expiration in the parent agent's relevant event chain. After verifying the migration's legitimacy, confirming the automatic task rule version and task origin, the system performs signature endorsement, event writing, and bitmap flipping. Subsequently, the system transitions from the revoked state to the tombstone state according to the retention policy. This process does not allow temporary sub-agents to directly transition from the active state to the tombstone state; they must pass through the irreversible revoked state. This scenario prevents state history breaks through the non-skip constraint of the state matrix.

[0078] Scenario 4: Batch Revocation. A registered entity, anchor source, or namespace is confirmed to pose a systemic risk. The system generates a batch revocation task, performing state matrix verification, signature endorsement, state event writing, and bitmap flipping for each agent within the scope. When the same batch is submitted repeatedly, the system queries the global transaction record based on a unique transaction identifier generated by combining the idempotent identifier in the state change request with a random number. If a completed transaction record with the same identifier exists, the existing result is returned directly without regenerating state events. This scenario, through idempotent control and bucketed bitmap publishing, is suitable for scenarios where a large number of agents simultaneously pause, revoke, or archive.

[0079] It should be understood that the above scenarios are illustrative only, not restrictive. Under different trigger types, the system matches different authorization materials and evidence citations. For example, the governance system matches governance resolution summaries, the hardware anchor linkage module matches hardware anchor status proofs, and automatic tasks match rule versions and task sources.

[0080] Furthermore, the technical solution of this application can also be implemented with the following alternatives or extensions. Signature endorsement can be completed directly by a hardware anchor, or by a short-lifecycle signature key endorsed by the hardware anchor. The dual-state bitmap can use two independent publications, or two logical bitmaps within the same publication package, or it can use a single-state encoded bitmap, a sparse Merkle state tree, a Verkle state tree, a combination of CRL and online query, etc. State publications can be published via CDN, object storage, consortium nodes, regulatory channels, timestamp services, or notarization services. The state matrix can add observation states, disputed states, frozen states, or pending review states according to industry, but the irreversible semantics of revocation and tombstones are retained as strong constraints. The state proof package can be tailored according to the scenario; ordinary resource entry only requires the current state and bitmap proof, internal enterprise audits add state event chain fragments, and regulatory investigations add authorization summaries, filing receipts, and upstream evidence hashes. Batch revocation can use online batch processing, offline batch processing, bucketed parallel publishing, incremental push, or emergency regulatory channels. Compensation for erroneous revocations can be achieved by reissuing a new identity, reissuing new credentials, adding a mapping record to the compensation event, or using a dispute marker authorized by regulators, but it will not directly restore the original revoked object to active status. The validity period of the status bitmap can be set to a minute-level, hour-level, or even shorter emergency window based on industry risk; in highly sensitive scenarios, mandatory real-time queries can be required.

[0081] This application also provides an electronic device, such as... Figure 4 As shown, it includes a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440.

[0082] Memory 430 is used to store computer programs; When the processor 410 executes the program stored in the memory 430, it performs the following steps: Receive a state change request for the target intelligent agent, and verify the legality of the state change request based on a preset state transition matrix; Upon successful verification, a signature endorsement is performed on the state change digest corresponding to the state change request, and a state change event is generated. Within the same transaction, the current state record is updated based on the state change event, and at least two mutually exclusive state publications are simultaneously flipped, wherein the updated current state record contains reference information pointing to the state change event.

[0083] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0084] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0085] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0086] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0087] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 1 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0088] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the intelligent agent lifecycle state change management methods described in the above embodiments.

[0089] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the intelligent agent lifecycle state change management methods described in the above embodiments.

[0090] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0092] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0093] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0094] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0095] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A method for managing the lifecycle state changes of an intelligent agent, characterized in that, The method includes: Receive a state change request for the target intelligent agent, and verify the legality of the state change request based on a preset state transition matrix; Upon successful verification, a signature endorsement is performed on the state change digest corresponding to the state change request, and a state change event is generated. Within the same transaction, the current state record is updated based on the state change event, and at least two mutually exclusive state publications are simultaneously flipped, wherein the updated current state record contains reference information pointing to the state change event.

2. The method according to claim 1, characterized in that, The preset state transition matrix is ​​configured to prohibit transitions from irreversible states to reversible states, and to prohibit skipping irreversible states and directly entering the final state. The at least two mutually exclusive state publishers include a first state publisher and a second state publisher. The same agent shares the same bit order in the first state publisher and the second state publisher, and the first state publisher and the second state publisher satisfy mutual exclusion constraints.

3. The method according to claim 2, characterized in that, The irreversible state includes the canceled state, the final state includes the tombstone state, and the reversible state includes the active state and the paused state. The first status publication is a cancel bitmap, and the second status publication is a pause bitmap; When entering the pause state, the bit value corresponding to the pause bitmap is set to a first preset value while the bit value corresponding to the cancel bitmap is kept at a second preset value; When entering the cancel state, the bit value corresponding to the cancel bitmap is set to the first preset value and the bit value corresponding to the pause bitmap is cleared; When entering the tombstone state, the bit value corresponding to the cancel bitmap is kept at the first preset value and the bit value corresponding to the pause bitmap is kept at the second preset value.

4. The method according to claim 3, characterized in that, The validity of the state change request is verified based on a preset state transition matrix, including: Based on the current state and the target state in the state change request, it is determined whether the migration belongs to the allowed set. The allowed set includes active state migrating to paused or revoked state, paused state migrating to active or revoked state, and revoked state migrating to tombstone state. Revoked state reverting to active state is prohibited, tombstone state migrating to any state is prohibited, and active or paused state migrating directly to tombstone state is prohibited.

5. The method according to claim 3, characterized in that, After verifying the legality of the state change request based on a preset state transition matrix and before performing a signature endorsement on the state change digest corresponding to the state change request, the method further includes: authorization and evidence verification. Match the corresponding authorized materials according to the triggering party type in the status change request, and verify whether the upstream evidence referenced in the status change request is valid.

6. The method according to claim 5, characterized in that, The status change event includes the status before the change, the status after the change, the reason code, the triggering party type, the authorization digest, the event hash of the associated event, the signature endorsement, the event sequence number, the hash of the preceding event, the hash of the current event, and the filing receipt; The filing receipt is issued by the server after the event is written.

7. The method according to claim 1, characterized in that, The reference information includes the event sequence number and event hash of the state change event; The current state record is not used as an independent source of facts, but only points back to the corresponding state change event through the event sequence number and the event hash.

8. The method according to claim 1, characterized in that, The method further includes: In response to the detection of an erroneous revocation of the status change, instead of reverting to the original status, a compensation event is generated and a new identity credential is reissued after the authorization conditions are met; The cancellation fact corresponding to the original state record is retained in the state event chain.

9. The method according to claim 1, characterized in that, The method further includes: A state proof package is generated, which includes the current state record, an event chain fragment of the state change event, a bitmap proof of the state publication, an archive receipt, and an authorization digest, for external verification parties to trace the legality of the state change.

10. A device for managing the lifecycle state changes of an intelligent agent, characterized in that, The device includes: The request entry module is configured to receive state change requests for the target intelligent agent. The state verification module is configured to verify the legality of the state change request based on a preset state transition matrix; The signature endorsement module is configured to perform a signature endorsement on the change digest corresponding to the state change request in response to successful verification, and generate a state change event. The transaction processing module is configured to update the current state record based on the state change event within the same transaction, and synchronously flip at least two mutually exclusive state publications; the updated current state record contains reference information pointing to the state change event.

Images