An agent tool invocation trusted execution method and system based on double-sided persistent ledger and reconciliation decision

Abstract

This invention discloses a trusted execution method and system for intelligent agent tool calls based on a two-sided persistent ledger and reconciliation decision. The method includes: Step S1, performing local pre-screening for non-deterministic generated features of a large language model to filter out format errors and path traversal attacks; Step S2, performing secondary review and durability preparation based on dynamic permissions, with the control plane abandoning local caching for independent review, writing to the ledger through atomic transactions and returning vouchers; Step S3, executing the tool under control only when holding vouchers; Step S4, performing physically-aware durability commit, updating the ledger to a three-state result; Step S5, making reconciliation decisions to prevent physical duplication, combining the physical idempotency of the tool, forcibly suspending manual reconciliation for non-idempotent tools in unknown states. This invention solves the problems of unreliable side effects and blind retries leading to repeated operations in the prior art, achieving exactly-once execution of side effects, and improving the reliability and auditability of the system.

Description

Technical Field

[0001] This invention relates to the field of interdisciplinary technology of artificial intelligence and distributed systems, and in particular to a trusted execution method and system for intelligent agent tool invocation based on a two-sided persistent ledger and reconciliation decision. Background Technology

[0002] Large language model agents typically need to invoke various tools to generate real external side effects when performing tasks, such as writing to files, calling business system interfaces, executing database queries, or running terminal commands. Once a tool invocation occurs, its impact extends beyond the agent's process itself, becoming an irreversible external fact. However, existing technologies have significant drawbacks:

[0003] Side effects are unreliable and unknowable: Existing intelligent agents typically execute tool calls directly without recording durability credentials, and the success or failure of execution only exists in the process's memory. Once the process crashes or a node fails, it is impossible to prove whether side effects have occurred, nor is it possible to audit them afterward.

[0004] Blind retries lead to duplicate risks: When a tool call times out, existing solutions typically employ a blind retries strategy. If the original call actually executed successfully in the target system, and only the response was lost in the network, blind retries will cause duplicate side effects (such as duplicate database writes and duplicate deductions), resulting in serious business losses.

[0005] Single trust domain: If the execution plane itself is both the execution tool and the recorder of execution facts, then the execution facts and execution actions originate from the same trust domain. When the execution plane fails or is tampered with, the accounts become distorted, lacking independent factual authority. Summary of the Invention

[0006] The present invention aims to solve the above-mentioned technical problems and provides a method and system for trusted execution of intelligent agent tool calls. Through a two-sided architecture of execution plane and control plane and a reconciliation decision mechanism based on persistent ledger, the credibility and security of external side effects are ensured.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0008] In a first aspect, the present invention provides a trusted execution method for agent tool invocation based on a two-sided persistent ledger and reconciliation decision. This method is applied to a two-plane system comprising an execution plane runtime and a control plane service. The execution plane runtime is configured as a zero-trust execution domain, carrying an agent generated based on a large language model; the control plane service is independent of the execution plane runtime, configured as an authoritative trust anchor point, and exclusively possesses the right to write to the persistent action ledger. The method includes:

[0009] Step S1, Local Pre-detection for Generative Text Features: Execute the runtime parsing tool call request generated by the agent, and perform local pre-detection operations for the nondeterministic generated features of the large language model; the pre-detection operations include: using JSON Schema to perform structured validation of the generated parameters to filter out format errors caused by model illusion, normalizing the file path to defend against path crossing attacks, and verifying whether the input volume exceeds a preset resource threshold; if the pre-detection fails, the call is directly short-circuited and no network interaction occurs;

[0010] Step S2, Secondary review and durability preparation based on dynamic permissions: If the local pre-check passes, the execution plane runtime initiates a durability preparation request to the control plane service; the control plane service responds to the request, discards the local permission cache of the execution plane runtime, and performs a secondary independent review based on the latest user permission policy and real-time approval flow status; only when the review passes, a record with a status of "prepared" is written to the action ledger within the same database transaction, and a durability confirmation credential containing a globally unique action identifier and an authorization decision snapshot identifier is returned; if a durability confirmation credential is not obtained, it is strictly forbidden to proceed to the actual execution step;

[0011] Step S3, Controlled Execution: When the execution surface is running, it invokes the real tool to perform operations to generate external side effects only when it holds a valid durability verification credential;

[0012] Step S4, Physical Awareness Durability Commit: During execution, the execution plane initiates a durability commit request to the control plane service based on the actual execution status; the control plane service updates the action ledger to one of three states: success, failure, or unknown; among which, the "unknown" state is specifically used to characterize an intermediate state where it is impossible to confirm whether the side effects in the physical world or external business system have actually occurred due to network interruption or timeout.

[0013] Step S5, Reconciliation decision to prevent physical duplication: In retry or recovery scenarios, query the action ledger and perform differentiated reconciliation decisions based on the physical idempotency attribute of the tool; if the status is "success", retries are prohibited and the output is reused; if the status is "unknown" and the tool attribute is non-idempotent, the decision is to forcibly suspend manual reconciliation to block the double side effects in the physical world caused by automatic retry by the system.

[0014] Furthermore, the specific configuration of the reconciliation decision logic in step S5 is as follows:

[0015] When the query result is "unknown", read the idempotency flag declared during the tool's registration.

[0016] If the tool is marked as "non-idempotent", the system locks the action identifier, enters a suspended state, and triggers a manual audit process until the actual status of the external system is confirmed by a human. Then, the status is updated to "success" or "failure" according to the human's instructions.

[0017] If the tool is marked as "idempotent", the entire process starting from step S1 is allowed to be re-executed according to a preset strategy.

[0018] Furthermore, in step S2, the two independent trials performed by the control plane service within the same transaction include:

[0019] Obtain the parameter summary of this tool call, and dynamically query the current user's final permission list to determine whether the parameter summary has triggered a sensitive operation threshold or an unauthorized operation scope;

[0020] Generate an authorization decision record containing the current timestamp, permission version number, and approval serial number, and bind this record to the action ledger record to achieve atomic association between side effects and authorization basis.

[0021] Furthermore, step S1 also includes a risk classification step:

[0022] Based on the tool's registration information, the risk level of the call is classified as read-only, write-only, or high-risk.

[0023] For high-risk calls, additional confirmation mechanisms are mandatory, including multi-factor authentication or administrator approval.

[0024] Furthermore, it also includes mandatory advancement rules based on the execution characteristics of the agent:

[0025] Once step S3 begins, step S4 must be executed regardless of whether response data is received from the tool.

[0026] If the submission request in step S4 fails, the execution plane will mark this call as pending reconciliation and retry the submission in the background in an idempotent manner to ensure that there are no dangling records in the action ledger that are "started but not yet settled".

[0027] Secondly, the present invention provides a trusted execution system for intelligent agent tool invocation based on a two-sided persistent ledger and reconciliation decision, comprising:

[0028] During execution, the execution plane is used to run large language model agents, perform local preflight, controlled execution, and request initiation operations in the above methods, and does not maintain any final state truth about the execution results.

[0029] The control plane service runs independently of the execution plane. As the authoritative trust anchor of the system, it is used to perform the second independent trial in step S2 and the state settlement in step S4, and exclusively writes to the persistent action ledger.

[0030] The action ledger stores an immutable record of every tool call, including a summary of call parameters, a snapshot of authorization decisions, and the three-state execution results.

[0031] The reconciliation decision-maker is used, according to the logic of claim 2, to trigger a manual intervention mechanism for unknown states of non-idempotent tools during anomaly recovery, in order to prevent business risks caused by automated retries.

[0032] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0033] Fourthly, the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method.

[0034] The beneficial effects of this invention are:

[0035] Trustworthy side effect boundaries: Any tool side effect must be confirmed by the durability of the control plane as a prerequisite, which eliminates unauthorized execution and achieves zero trust in the execution plane.

[0036] Eliminating duplicate side effects: Using the action ledger as the sole source of facts for retry decisions, the reconciliation decision table guides the UNKNOWN result to idempotent resubmission or manual reconciliation, avoiding double writing and business losses caused by blind retries, and ensuring that the semantics of side effects are executed exactly once.

[0037] Low-overhead, fast rejection: The local pre-inspection layer does not generate network round trips, short-circuiting most illegal calls at millisecond cost, significantly reducing control plane load and unnecessary network overhead.

[0038] Full-chain auditability: Each execution is bound to an action identifier, action version, and authorization decision identifier, and can be traced back to the specific authorization basis, parameter summary, and final three-state result, meeting the needs of enterprise-level compliance auditing and post-event accountability. Attached Figure Description

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

[0040] Figure 1 A system composition block diagram provided for embodiments of the present invention; Figure 2 A nine-step trusted execution pipeline flowchart provided for embodiments of the present invention; Figure 3 A flowchart of the reconciliation decision-making process provided in this embodiment of the invention;

[0041] Figure 4 The flowchart illustrates a trusted execution method for invoking intelligent agent tools based on a two-sided persistent ledger and reconciliation decision, as provided in this embodiment of the invention. Detailed Implementation

[0042] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0043] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0044] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0045] Reference Figures 1-4 This embodiment of the invention provides a trusted execution method for agent tool invocation based on a two-sided persistent ledger and reconciliation decision. The method is applied to a two-plane system comprising an execution plane runtime and a control plane service. The execution plane runtime is configured as a zero-trust execution domain, carrying an agent generated based on a large language model. The control plane service is independent of the execution plane runtime, configured as an authoritative trust anchor point, and exclusively holds the right to write to the persistent action ledger. The method includes:

[0046] Step S1, Local pre-detection for generative text features: Execute the tool call request for parsing the agent's generation at runtime, and perform local pre-detection operations for the nondeterministic generated features of the large language model; the pre-detection operations include: using JSON Schema to perform structured validation of the generated parameters to filter out format errors caused by model illusion, normalizing the file path to defend against path crossing attacks, and verifying whether the input volume exceeds the preset resource threshold; if the pre-detection fails, the call is directly short-circuited and no network interaction is generated;

[0047] This step specifically includes: Sub-step S1.1: Noise filtering and structured verification based on robust parsing.

[0048] During runtime, the system performs streaming parsing of the raw text generated by the agent, employing a hybrid parser with higher fault tolerance than standard JSON parsers to handle common formatting noise in large language models. This sub-step not only verifies whether the tool call parameters conform to the JSON Schema structure declared during tool registration, but also performs "illusion noise filtering" for the nondeterministic characteristics of LLM: automatically identifying and removing explanatory text, Markdown tags, or thought chain tags added by the agent outside the code block, retaining only valid structured data. If the parsing finds missing required fields, parameter types conflicting with the Schema definition (e.g., expecting an integer but inputting a string with units), or detects unknown illegal fields generated by the model's "illusion," the system determines that the structure validation has failed, immediately blocks subsequent processes, and generates standardized syntax error feedback in the process's memory, without any network interaction.

[0049] Sub-step S1.2: Semantic specification-based path security anchoring

[0050] For parameters containing file paths, URLs, or resource identifiers, deep semantic-level normalization and defense are performed. This sub-step first resolves relative paths to absolute paths and identifies and eliminates path aliases and symbolic links (such as .. / , . / ), restoring the true resource access intent. Subsequently, the system performs a mathematical intersection operation between the resolved normalized path and the "secure workspace" of the current execution plane to determine whether the path is anchored within an authorized root directory or namespace. This process goes beyond simple string matching, identifying covert path traversal attempts (such as URL encoding obfuscation or long path truncation attacks) by constructing an Abstract Syntax Tree (AST). Once a path is detected to have escaped the predetermined security boundary, it is considered a traversal attack risk, and the call is directly short-circuited and terminated to ensure that maliciously generated path instructions cannot penetrate to the file system or network layer.

[0051] Sub-step S1.3: Structural complexity and computational budget guards

[0052] During runtime, the execution plane performs a multi-dimensional resource risk assessment on the volume of the parsed structured data. This sub-step not only verifies whether the total volume of the input data exceeds a preset transmission threshold (e.g., 10MB), but also introduces a "structural complexity" metric as a defense mechanism. The system recursively calculates the nesting depth and the number of child nodes of the parameter objects to assess the computational overhead of parsing and subsequent serialization. If the input body is detected to have an extremely high nesting depth (e.g., exceeding 100 levels) or abnormal sparsity, this typical adversarial sample or model "infinite generation" pattern will be judged as a denial-of-service attack risk. After confirming that the input volume and complexity are within the computational budget, the pre-check is passed; otherwise, the system forcibly circuit breaks the current call to prevent the execution plane's CPU and memory resources from being exhausted due to excessively large or malformed input.

[0053] Step S2, Secondary review and durability preparation based on dynamic permissions: If the local pre-check passes, the execution plane runtime initiates a durability preparation request to the control plane service; the control plane service responds to the request, discards the local permission cache of the execution plane runtime, and performs a secondary independent review based on the latest user permission policy and real-time approval flow status; only when the review passes, a record with a status of "prepared" is written to the action ledger within the same database transaction, and a durability confirmation credential containing a globally unique action identifier and an authorization decision snapshot identifier is returned; if a durability confirmation credential is not obtained, it is strictly forbidden to proceed to the actual execution step;

[0054] This step specifically involves: Sub-step S2.1: Constructing context-isolated requests based on semantic fingerprints.

[0055] Upon receiving a command that has passed local preflight checks, the execution plane runtime does not directly transmit the original call parameters. Instead, it constructs a tamper-proof "durable preparation request packet." This sub-step first digitally signs the key elements of the tool call—including the tool identifier, the digest hash of the input parameters, a snapshot of the current agent session's context, and the execution plane's lease certificate—generating a unique "semantic fingerprint." This process solidifies the agent's generative intent into an immutable chain of evidence, ensuring that the control plane service's judgment is based on an accurate mapping of the agent's original reasoning intent, rather than data that might be tampered with by middleware during transmission. The execution plane runtime then sends this preparation request containing the semantic fingerprint to the control plane service via a synchronization channel. During this stage, the execution plane strictly maintains "stateless" waiting, meaning it does not retain any temporary authorization assumptions about this request and relies solely on the final conclusion returned by the control plane.

[0056] Sub-step S2.2: Real-time state convergence and parameter-level quadratic independent trial

[0057] Upon receiving a preliminary request, the control plane service immediately initiates a secondary independent adjudication process in "zero-trust" mode, completely eliminating any permission caching or optimistic judgments that may be present during execution plane runtime. The core of this sub-step lies in "real-time state convergence": the control plane service dynamically retrieves the user's latest permission policy version, approval flow status, and resource quota remaining at the current moment, comparing them with the semantic fingerprint in the request packet. The adjudication logic not only verifies whether the user has the right to invoke the tool but also performs "parameter-level granularity verification"—that is, determining whether the input parameters trigger specific sensitive operation thresholds (such as exceeding the transfer limit), whether there is an attempt to escalate privileges, or whether the latest compliance prohibitions are violated. If the adjudication passes, the control plane service generates an "authorization decision snapshot" containing the current timestamp, policy version number, and approval serial number. This snapshot is temporarily stored as legal evidence of the operation. If the adjudication fails, the control plane directly outputs a rejection signal, the process terminates immediately, and no persistent records are generated.

[0058] Sub-step S2.3: Atomized ledger finalization and durable document issuance

[0059] After the second trial is passed, the control plane service enters the core atomic transaction processing phase. This sub-step leverages the ACID properties of database transactions to complete two strongly related actions within the same atomic operation: First, a brand new record is inserted into the persistent action ledger. This record is assigned a globally unique action identifier, and its state is initially locked as "ready." Simultaneously, the identifier of the aforementioned authorization decision snapshot is strongly bound to this record, establishing an atomic association between "side effect occurrence" and "authorization basis." Second, after the transaction is successfully committed, a "durable confirmation credential" is generated based on this action identifier. This credential is not only a pass to enter the execution phase but also the root credential for subsequent commits and reconciliations. If any database anomaly occurs during transaction execution (such as primary key conflicts or connection interruptions), the entire sub-step is rolled back, and no valid credential is generated. The execution plane is only allowed to exit the waiting state and proceed to the next step of actual execution after successfully receiving and verifying the validity of the digital signature of the durable confirmation credential; otherwise, the current call must be permanently terminated, thus fundamentally eliminating the risk of violations such as "execution before authorization" or "unauthorized execution."

[0060] Step S3, Controlled Execution: When the execution surface is running, it invokes the real tool to perform operations to generate external side effects only when it holds a valid durability verification credential;

[0061] This step specifically involves: Sub-step S3.1: Credential anchoring and execution environment isolation.

[0062] Before making an actual call, the execution plane runtime first performs credential anchoring and environment isolation. The system parses the action identifier and authorization decision snapshot identifier from the durability verification credential and loads them into the execution thread's context space. This step constructs a temporary "trusted execution sandbox" to ensure that subsequent tool execution logic cannot access or tamper with global state outside of this credential. The execution plane runtime also verifies the validity period and signature integrity of the credential to prevent it from being intercepted and replayed during transmission. Only after the credential has passed strict verification is the lock on the target tool function pointer released, ready for the call.

[0063] Sub-step S3.2: End-to-end source tracing injection and controlled invocation

[0064] The execution plane initiates a full-chain tracing injection mechanism at runtime, providing controlled encapsulation of tool calls. In the interface calling the actual tool, the execution plane enforces the injection of action identifiers as implicit parameters. For example, it binds these identifiers to the transaction context when calling the database driver, or writes them into a specific Trace-ID request header when initiating an HTTP request. This forced injection ensures that any external side effects generated by the tool—whether it's modification of data records or invocation of downstream services—naturally carry an immutable audit fingerprint. The system then triggers tool execution, but strictly limits the execution scope to the parameter digest declared by the credentials, prohibiting dynamic expansion of permissions or unauthorized access during execution.

[0065] Sub-step S3.3: Side effect boundary verification and atomic triggering

[0066] During tool execution, real-time side effect monitoring and atomic triggering are implemented at runtime. The system monitors the tool's output stream using an interceptor pattern to ensure that any external side effects generated are consistent with pre-authorized intent. Figure 1 Once it is detected that the tool begins to have a substantial impact on the external system, the execution plane immediately marks the current thread as "side effect triggered". If the tool throws an exception or times out during execution, the execution plane captures this state but never rolls back the physical traces that have been generated. Instead, it maintains the intermediate state of "side effect uncertain" to preserve the basis for factual judgment for subsequent durability commit steps, ensuring that every external write is in a controlled and traceable closed loop.

[0067] Step S4, physical awareness durability commit: When the execution plane runs, it initiates a durability commit request to the control plane service based on the actual execution status; the control plane service updates the action ledger to one of the three states: success, failure, and unknown; among them, the "unknown" state is specifically used to characterize the intermediate state where it is impossible to confirm whether the side effects in the physical world or external business system have actually occurred due to network interruption or timeout.

[0068] This step specifically involves: Sub-step S4.1: Executing holographic capture and evidence encapsulation of the surface physical response.

[0069] After completing a tool call, the execution plane does not directly pass a simple success or failure boolean value. Instead, it performs a "holographic capture" process to construct an encapsulation of evidence containing details of the physical response. This sub-step not only extracts the tool's return data but also deeply analyzes the metadata of the communication layer to distinguish between "logical rejection" and "physical transmission failure." The execution plane detects specific signals such as TCP connection resets, application layer timeouts, partial packet reception, or HTTP 5xx gateway errors, encoding these physical anomalies into the metadata fields of the submitted request. By combining and encapsulating the semantic output of the tool with the underlying network transmission state, the execution plane provides the control plane with the panoramic evidence needed to determine the true state of the physical world, ensuring that the control plane can make state decisions based on sufficient on-site information rather than a single conclusion.

[0070] Sub-step S4.2: Semantic adjudication and three-state mapping based on physical state ambiguity

[0071] The control plane service receives a submission request containing encapsulated evidence and performs a semantic ruling with physical awareness. The core of this sub-step lies in the honest mapping of uncertainty in the physical world: the control plane parses metadata; if the evidence shows that the tool returned a clear business logic error (such as invalid parameters or insufficient balance), the state is ruled "failure"; if the evidence shows that a complete and validated business response was obtained, the state is ruled "success." Specifically, if the evidence contains physical failure characteristics such as timeout, network interruption, or lost response, the control plane will not arbitrarily determine failure, but will strictly map the state to "unknown" according to the physical awareness principle of the invention. This mapping mechanism acknowledges the cognitive limitations between observers and observed objects in distributed systems, establishing the physical fact of "inability to confirm whether a side effect has occurred" itself as a legitimate system state that must be persisted.

[0072] Sub-step S4.3: Durability settlement and boundary anchoring of uncertain facts

[0073] After completing semantic adjudication, the control plane service uses database transactions to durablely write the adjudication result into the action ledger, establishing the final boundary of the action. For "unknown" states, this sub-step not only updates the state field but also includes anchoring operations for the "fuzzy boundary": the control plane synchronously writes the specific physical reason for determining "unknown" (such as "response timeout" or "connection interruption") and the current timestamp into the ledger record, thus solidifying the instantaneous physical failure into an immutable historical fact. This durable settlement ensures that the "unknown" state has the same legal effect as "success" and "failure," that is, the system explicitly acknowledges that "not knowing" is also a definite state record. By locking this uncertainty in the ledger through transaction mechanisms, the system prevents subsequent processes from attempting to conceal or obscure this fact through retry mechanisms, mandating that this uncertainty must be eliminated through a dedicated reconciliation process, thereby ensuring the consistency boundary between the business system state and the physical world reality.

[0074] Step S5, Reconciliation decision to prevent physical duplication: In retry or recovery scenarios, query the action ledger and perform differentiated reconciliation decisions based on the physical idempotency attribute of the tool; if the status is "success", retries are prohibited and the output is reused; if the status is "unknown" and the tool attribute is non-idempotent, the decision is to forcibly suspend manual reconciliation to block the double side effects in the physical world caused by automatic retry by the system.

[0075] This step specifically involves: Sub-step S5.1: Ledger status retrieval and physical attribute context loading.

[0076] When the reconciliation decision-maker receives a retry or recovery request, it first performs an atomic search of the persistent action ledger based on the action identifier carried in the request, locking the corresponding call record. This step not only reads the current "three-state" result of the action (success, failure, unknown), but also simultaneously loads the tool's "physical idempotency" attribute tag from the tool registry. By contextually fusing the "state facts of the ledger record" with the "physical attributes of the tool itself," a complete data view required for decision-making is constructed. Based on this, the system determines whether the action has produced a definite result and whether the tool possesses repeatable security at the physical level, thus providing a rigorous logical basis for subsequent differentiated decisions, ensuring that the decisions meet both system consistency requirements and business security constraints.

[0077] Sub-step S5.2: Deterministic reuse and execution blocking based on the "success" final state

[0078] When the retrieved ledger status is clearly "successful," the reconciliation decision logic immediately triggers the "output reuse" branch, strictly blocking any subsequent actual execution attempts targeting that action identifier. The decision-maker directly extracts the historical output summary or complete data persistently stored in the ledger, encapsulates it into a standard response, and returns it directly to the agent without needing to invoke the real tool again. This mechanism utilizes the action ledger as a single trusted source of fact, logically covering the agent's repeated requests, and achieving "exactly once" semantics in task replay or fault recovery scenarios. It fundamentally eliminates the physical double side effects caused by the system retry mechanism, such as duplicate database writes or duplicate execution of business logic.

[0079] Sub-step S5.3: Safety circuit breaking and manual arbitration for non-idempotent uncertainties

[0080] For ambiguous scenarios where the ledger status is "unknown," the decision-maker executes a differentiated risk control strategy based on physical idempotency. If an instrument attribute is detected as "non-idempotent," the system recognizes that performing automated retries at this time carries extremely high business risk (potentially leading to duplicate deductions of funds or duplicate issuance of instructions). Therefore, the decision logic forcibly enters a "safety suspension" mode, immediately locking the action flag, prohibiting any automated process from continuing execution, and generating a high-priority manual audit ticket with detailed context. At this point, the system transfers decision-making power to a human operator, requiring manual verification of the actual physical status of downstream business systems. Only after manual confirmation of the facts and issuance of correction instructions is the ledger status updated or execution allowed to continue, thus building a final line of defense against catastrophic consequences in extreme environments such as network failures or state loss.

[0081] Furthermore, the specific configuration of the reconciliation decision logic in step S5 is as follows:

[0082] When the query result is "unknown", read the idempotency flag declared during the tool's registration.

[0083] If the tool is marked as "non-idempotent", the system locks the action identifier, enters a suspended state, and triggers a manual audit process until the actual status of the external system is confirmed by a human. Then, the status is updated to "success" or "failure" according to the human's instructions.

[0084] If the tool is marked as "idempotent", the entire process starting from step S1 is allowed to be re-executed according to a preset strategy.

[0085] In this embodiment, the reconciliation decision logic is specifically configured as follows: When the system faces a retry or recovery scenario, the reconciliation decision-maker first queries the action ledger based on the action identifier. If the retrieved record status is "unknown," it means that the previous call was interrupted by network interruption or timeout, causing the system to be unable to confirm whether the side effects in the physical world have occurred. At this time, the decision-maker reads the idempotency identifier declared by the tool during registration for differential processing. If the identifier shows that the tool belongs to the "non-idempotent" type (such as sensitive operations such as fund transfer or order creation), it is determined that automatic retry will lead to irreversible physical double side effects. The decision-maker immediately locks the action identifier, blocks any automatic retry process, sets the status to suspended, and triggers a manual audit process to notify the operations and maintenance personnel. The operations and maintenance personnel need to manually verify the actual data of the downstream business system. After confirming the actual status, they issue instructions through the control plane interface, and the system updates the ledger status to "success" or "failure" accordingly. Conversely, if the tool is marked as the "idempotent" type (such as information query or status overwrite), it is determined that repeated execution will not produce data inconsistency. The decision-maker allows the execution plane to be retried according to a preset retry strategy, starting from step S1 (local pre-check) and re-executing the complete nine-step pipeline until a clear success or failure status is obtained and the ledger is updated.

[0086] Furthermore, in step S2, the two independent trials performed by the control plane service within the same transaction include:

[0087] Obtain the parameter summary of this tool call, and dynamically query the current user's final permission list to determine whether the parameter summary has triggered a sensitive operation threshold or an unauthorized operation scope;

[0088] Generate an authorization decision record containing the current timestamp, permission version number, and approval serial number, and bind this record to the action ledger record to achieve atomic association between side effects and authorization basis.

[0089] In this embodiment, the secondary independent trial performed by the control plane service in step S2 specifically includes the following process: First, after receiving the durability preparation request initiated by the execution plane, the control plane service parses the tool call parameter digest, which is a fingerprint information of the parameters generated by the agent. Simultaneously, the control plane service does not rely on any permission cache passed by the execution plane, but directly calls the real-time interface of the permission management system to dynamically query and obtain the latest and final permission list of the current user and the corresponding policy version number.

[0090] Next, the system enters the rule comparison and judgment phase, matching key business fields in the parameter summary (such as fund amount, resource identifier, and operation type) with the obtained final permission list. During this process, the system specifically determines whether the parameter summary triggers a system-preset sensitive operation threshold (e.g., whether a single transfer amount exceeds the limit requiring review), or whether it falls within the scope of operations not authorized by the current user (e.g., attempting to access cross-departmental data resources). Once it is determined that none of the above risks have been triggered, the system considers the judgment passed.

[0091] Finally, the control plane service utilizes database transaction mechanisms to complete two core operations within the same atomic transaction: first, it writes a record with a status of "ready" to the action ledger table, establishing an action identifier; second, it generates an authorization decision record containing the current timestamp, permission version number, and approval serial number, and strongly binds this record to the action ledger record through the action identifier. This atomic writing method ensures that the "ready to execute" fact recorded in the action ledger is inseparable from the "legal basis" recorded in the authorization decision record, thereby achieving an atomic association between external side-effect behaviors and the authorization basis, guaranteeing the integrity and immutability of the evidence chain during subsequent audits.

[0092] Furthermore, step S1 also includes a risk classification step:

[0093] Based on the tool's registration information, the risk level of the call is classified as read-only, write-only, or high-risk.

[0094] For high-risk calls, additional confirmation mechanisms are mandatory, including multi-factor authentication or administrator approval.

[0095] In this embodiment, the risk classification step in step S1 is implemented as follows: After parsing the tool call request and completing basic structured verification during runtime, the execution plane then performs a static risk level determination on the currently invoked tool based on the metadata information pre-entered in the tool registry center. This determination process is performed entirely in local memory, classifying the tool into three levels: "read-only," "write," or "high-risk," according to its inherent attributes. The "read-only" level covers tools that only involve data queries and no resource changes; the "write" level covers tools that involve data modification but not core system architecture or asset transfers; and the "high-risk" level covers tools that involve fund transfers, user deletions, system permission changes, or sensitive data exports, which have a significant impact on business continuity and security.

[0096] For calls identified as "high-risk," the execution plane will forcibly activate blocking logic, suspending subsequent processes and initiating an additional confirmation mechanism as a necessary prerequisite for allowing access. Specifically, the system supports two confirmation paths: first, a multi-factor authentication mechanism, where the execution plane presents an authentication challenge to the requester, requiring a one-time password, biometric signature, or hardware token dynamic code; the block is lifted only after successful verification; second, an administrator approval mechanism, where the system automatically generates an approval request containing contextual information and sends it to a preset administrator terminal via an asynchronous message channel, forcing manual intervention for review. Only after receiving explicit manual approval or completing multi-factor authentication is the risk classification step considered successful, and the pipeline can continue. If confirmation fails or there is no response within a timeout period, the system will directly reject the call and record a security log, thus building a final line of defense against high-risk operations on the local side.

[0097] Furthermore, it also includes mandatory advancement rules based on the execution characteristics of the agent:

[0098] Once step S3 begins, step S4 must be executed regardless of whether response data is received from the tool.

[0099] If the submission request in step S4 fails, the execution plane will mark this call as pending reconciliation and retry the submission in the background in an idempotent manner to ensure that there are no dangling records in the action ledger that are "started but not yet settled".

[0100] In this embodiment, the forced advancement rules for the execution characteristics of the agent are specifically implemented through state machine constraints and asynchronous compensation mechanisms during the execution plane runtime. First, the execution plane runtime implements a strict "one-way advancement" strategy at the code logic level: once the execution flow enters step S3 and actually triggers the call to the tool interface, the system marks the action as "triggered" in the internal context, and ensures through an uninterruptible logical structure that regardless of whether the final performance of step S3 is receiving valid data, throwing a business exception, or timeout due to network failure, the control flow is forced to jump to step S4. It is absolutely prohibited to directly return an error to the agent or terminate the process without completing the durability commit, thereby eliminating the intermediate state of "action has occurred but not requested for accounting".

[0101] Secondly, if the commit request initiated by the execution plane runtime to the control plane service fails due to network partitioning or service unavailability during step S4, the system will immediately initiate a fault tolerance process. The execution plane runtime marks the action identifier as "pending reconciliation" in the local cache and persistently stores the constructed commit content (including the action identifier and the final three-state result) in the local retry queue to ensure that the commit intention is not lost due to process crash.

[0102] Finally, during runtime, the execution plane uses a background daemon thread to monitor the retry queue and periodically resubmits the commit request to the control plane service according to an exponential backoff strategy. Since the commit request contains a globally unique action identifier, the control plane service can filter duplicate commit requests based on the idempotency principle, ensuring state consistency. Through this continuous idempotent retry mechanism, the system guarantees that every record in the action ledger in the "ready" state will eventually be updated to a definite final state, thus completely eliminating the risk of "started but not finalized" records in the system and maintaining the integrity and auditability of the ledger data.

[0103] This embodiment also provides a trusted execution system for agent tool invocation based on a two-sided persistent ledger and reconciliation decision, including:

[0104] During execution, the execution plane is used to run large language model agents, perform local preflight, controlled execution, and request initiation operations in the above methods, and does not maintain any final state truth about the execution results.

[0105] The control plane service runs independently of the execution plane. As the authoritative trust anchor of the system, it is used to perform the second independent trial in step S2 and the state settlement in step S4, and exclusively writes to the persistent action ledger.

[0106] The action ledger stores an immutable record of every tool call, including a summary of call parameters, a snapshot of authorization decisions, and the three-state execution results.

[0107] The reconciliation decision maker is used to trigger a manual intervention mechanism for unknown states of non-idempotent tools during anomaly recovery, preventing business risks caused by automated retries.

[0108] The intelligent agent tool based on a two-sided persistent ledger and reconciliation decision-making system provided in this embodiment calls a trusted execution system. It adopts a strict control plane and execution plane separation architecture, and the specific component composition and functional implementation are as follows:

[0109] The execution plane runtime, acting as the actual managed environment for the intelligent agent, is responsible for hosting the inference loop of the large language model. This component resides in a zero-trust domain, and its primary responsibility is to perform local pre-inspection operations within methods (such as parameter format validation and path security checks), and, after obtaining authorization, to invoke real tools to generate external side effects. It is noteworthy that the execution plane runtime itself does not maintain any final state truth regarding the execution results; it merely acts as the initiator and executor of instructions, without possessing the final say in state determination, thus avoiding factual distortion due to its own failures.

[0110] The control plane service is deployed independently of the execution plane at runtime, forming the authoritative trust anchor for the entire system. It is responsible for core risk control and adjudication logic, specifically including the secondary independent review in execution step S2, which re-verifies tool calls based on the latest user permission policies and approval flow status, and the status finalization in execution step S4. The control plane service has exclusive write rights to the persistent action ledger, ensuring the uniqueness and immutability of the source of fact records.

[0111] The action ledger stores an immutable record of every tool call and is the core of the system's auditing. Each record includes a summary of the call parameters, a snapshot of the associated authorization decision, and a three-state execution result (success, failure, unknown). This design ensures that every side effect is traceable, achieving a strong correlation between behavior and authorization basis.

[0112] The reconciliation decision-maker, acting as a security gatekeeper component of the system, is primarily used for logical judgments during anomaly recovery. When the system faces retry or recovery scenarios, the reconciliation decision-maker queries the action ledger based on specific logic. Particularly in extreme cases where the status is "unknown" and the tool attribute is "non-idempotent," the decision-maker immediately blocks the automated retry process and triggers a manual intervention mechanism. By forcing manual verification of the actual status of the external system, it effectively prevents business risks (such as duplicate deductions) caused by the system blindly retrying, ensuring the consistency of physical world data.

[0113] This embodiment also provides a computer device applicable to the above-described method, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the above-described method as proposed in the above embodiments.

[0114] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0115] This embodiment also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the above embodiments. The storage medium 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.

[0116] In summary, this invention achieves several beneficial effects by constructing a dual-sided architecture that strictly separates the execution plane runtime from the control plane service, and by introducing a closed-loop execution process that includes three-state adjudication and forced advancement rules. First, the local pre-inspection in step S1 and the secondary independent adjudication in step S2 effectively filter out format errors and unauthorized attacks caused by model illusions, ensuring the security and accuracy of tool calls at the source. Second, by atomically binding the authorization decision snapshot and action ledger record within the same database transaction, "authorization leaves a trace," eliminating the time window risk of authorization and execution, and ensuring the integrity and immutability of audit data. Third, addressing the uncertainty of distributed systems, this invention innovatively introduces an "unknown" state and the reconciliation decision logic in step S5, particularly by forcibly triggering manual auditing for non-idempotent tools, fundamentally solving the problem of dual physical side effects (such as duplicate deductions) caused by network failures or timeouts, and ensuring the eventual consistency of business logic. Finally, the forced advancement rules ensure that the execution state is inevitably settled, and the idempotent retry mechanism eliminates dangling records in the system, improving the robustness and reliability of the entire intelligent agent execution system.

[0117] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for trusted execution of agent tool invocations based on a bilateral persistent ledger and reconciliation decisions, characterized in that, The method is applied to a dual-plane system containing an execution plane runtime and a control plane service, wherein the execution plane runtime is configured as a zero-trust execution domain that carries an intelligent agent generated based on a large language model. The control plane service runs independently of the execution plane, is configured as an authoritative trust anchor, and has exclusive write rights to the persistent action ledger; the method includes: Step S1, Local Pre-detection for Generative Text Features: The execution surface parses the tool call request generated by the agent during runtime and performs a local pre-detection operation for the nondeterministic generated features of the large language model; the pre-detection operation includes: using JSON Schema to perform structured validation of the generated parameters to filter out format errors caused by model illusion, normalizing the file path to defend against path crossing attacks, and verifying whether the input volume exceeds a preset resource threshold; if the pre-detection fails, the call is directly short-circuited and no network interaction is generated; Step S2, Secondary review and durability preparation based on dynamic permissions: If the local pre-check passes, the execution plane runtime initiates a durability preparation request to the control plane service; the control plane service responds to the request, discards the local permission cache of the execution plane runtime, and performs a secondary independent review based on the latest user permission policy and real-time approval flow status; only when the review passes, a record with a status of "prepared" is written to the action ledger within the same database transaction, and a durability confirmation credential containing a globally unique action identifier and an authorization decision snapshot identifier is returned; if the durability confirmation credential is not obtained, it is strictly forbidden to enter the actual execution step; Step S3, Controlled Execution: The execution surface only invokes the real tool to perform operations to generate external side effects when it holds a valid durability confirmation credential. Step S4, Physically Aware Durability Commit: The execution plane runtime initiates a durability commit request to the control plane service based on the actual execution status; the control plane service updates the action ledger to one of three states: success, failure, and unknown; wherein, the "unknown" state is specifically used to characterize an intermediate state where it is impossible to confirm whether the side effects in the physical world or external business system have actually occurred due to network interruption or timeout. Step S5, Preventing reconciliation decisions that physically repeat: In retry or recovery scenarios, query the action ledger and perform differentiated reconciliation decisions based on the physical idempotency attribute of the tool; if the status is "success", retries are prohibited and the output is reused; if the status is "unknown" and the tool attribute is non-idempotent, the decision is to forcibly suspend manual reconciliation to block the double side effects in the physical world caused by automatic retry by the system.

2. The method of claim 1, wherein, The specific configuration of the reconciliation decision logic in step S5 is as follows: When the query result is "unknown", read the idempotency flag declared during the tool's registration. If the tool is marked as "non-idempotent", the system locks the action identifier, enters a suspended state, and triggers a manual audit process until the actual status of the external system is confirmed by a human. Then, the status is updated to "success" or "failure" according to the human's instructions. If the tool is marked as "idempotent", the entire process starting from step S1 can be re-executed according to a preset strategy.

3. The method of claim 1, wherein, In step S2, the two independent trials performed by the control plane service within the same transaction include: Obtain the parameter summary of this tool call, and dynamically query the current user's final permission list to determine whether the parameter summary triggers a sensitive operation threshold or an unauthorized operation scope; Generate an authorization decision record containing the current timestamp, permission version number, and approval serial number, and bind this record to the action ledger record to achieve atomic association between side effects and authorization basis.

4. The method of claim 1, wherein, Step S1 also includes a risk classification step: Based on the tool's registration information, the risk level of the call is classified as read-only, write-only, or high-risk. For high-risk calls, an additional confirmation mechanism is mandatory, including multi-factor authentication or administrator approval.

5. The method of claim 1, wherein, It also includes mandatory push rules based on the agent's execution characteristics: Once step S3 begins, step S4 must be executed regardless of whether response data is received from the tool. If the submission request in step S4 fails, the execution surface will mark this call as pending reconciliation and retry the submission in the background in an idempotent manner to ensure that there are no pending records in the action ledger that are "started but not yet settled".

6. An agent tool invocation trusted execution system based on a bilateral persistent ledger and reconciliation decision, characterized by, include: During execution, the execution plane is used to run a large language model agent, perform local pre-detection, controlled execution, and request initiation operations as described in any one of claims 1 to 5, and does not maintain any final state truth about the execution result itself. The control plane service, which runs independently of the execution plane, serves as the authoritative trust anchor of the system. It is used to perform the secondary independent trial in step S2 and the state settlement in step S4, and exclusively writes the action into the persistent ledger. The action ledger stores an immutable record of every tool call, including a summary of call parameters, a snapshot of authorization decisions, and the three-state execution results. The reconciliation decision-maker is used to trigger a manual intervention mechanism for unknown states of non-idempotent tools during anomaly recovery, according to the logic described in claim 2, to prevent business risks caused by automated retries.

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

8. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 5.

Images