An evidence binding and non-destructive replay audit system and method for agent tool invocation side effects

Abstract

The application discloses an evidence binding and non-destructive replay audit system and method for agent tool call side effects. The system generates a call tuple before tool call, obtains runtime tool call boundary evidence and tool capability evidence, generates and freezes an expected side effect declaration, forms a pre-call evidence snapshot; during or after call execution, actual side effects are collected and attributed, normalized to form an expected side effect atom set and an actual side effect atom set, and a side effect difference record is generated. The system binds the pre-call evidence snapshot, actual side effects, difference record, boundary evidence, tool capability evidence and call tuple into a side effect evidence binding object, and performs replay, simulated replay or non-destructive verification based on the object; for irreversible external actions, real execution is not repeated. The scheme improves the attributability, verifiability and accountability of agent tool call side effects.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence agent security, tool invocation governance, runtime boundary control, external side effect auditing, evidence binding, and trusted replay verification, and in particular to an evidence binding and non-destructive replay auditing system and method for agent tool invocation side effects.

[0002] The intelligent agent referred to in this application can be an execution entity built based on a large language model, multimodal model or other artificial intelligence model, capable of calling external tools, connectors, interfaces, services, plugins, application programming interfaces or workflows. Background Technology

[0003] With the development of large-scale intelligent agent technology, intelligent agents have gradually evolved from systems that simply generate text into runtime execution entities capable of calling external tools and changing the state of external systems. For example, intelligent agents can call database tools, file tools, email tools, calendar tools, ticketing systems, code repositories, permission systems, payment systems, enterprise office systems, or third-party application programming interfaces (APIs).

[0004] The aforementioned tool calls typically produce not only return results but may also generate external side effects. These external side effects include, but are not limited to, writing to files, modifying database records, sending emails or messages, creating work orders, changing permissions, submitting transactions, triggering task scheduling, creating schedules, initiating code commits, or calling third-party systems to create external state changes.

[0005] Existing tool call governance solutions primarily focus on whether the tool is authorized to be called, whether the call parameters conform to the interface pattern, whether call logs are saved, and whether execution results are recorded. These solutions can provide entry point control to some extent, but they are difficult to prove what external state changes a particular tool call actually caused, and it is also difficult to determine whether the actual external state changes fall within the scope of side effects allowed before the call.

[0006] In scenarios involving chained tool calls or collaborative execution of multiple tools by intelligent agents, attributing side effects becomes more challenging. The output of a single tool call may trigger the execution of downstream tools, multiple tool calls may affect the same external resource within a similar time window, and connectors may also modify the state of external systems due to implicit behaviors. Simply logging tool call data makes it difficult to verifiablely link side effect facts to specific tools, boundary evidence, tool capability evidence, and specific call tuples.

[0007] Furthermore, some side effects are irreversible, such as sending real emails, financial transactions, privilege escalation, data deletion, external approval submissions, code submissions, and cloud resource modifications. Simply repeating the original tool calls during the audit phase may trigger irreversible external actions again, potentially exacerbating the damage. Therefore, replay, simulated replay, or non-destructive verification based on frozen evidence is necessary.

[0008] Therefore, there is an urgent need for an evidence binding and non-destructive replay auditing technology for the side effects of intelligent agent tool calls. This technology binds the side effects that are allowed to occur before the call, the side effects that actually occur after the call, the difference results, runtime tool call boundary evidence, tool capability evidence, and call tuples into verifiable evidence objects, and performs secure replay auditing based on these evidence objects. Summary of the Invention

[0009] Purpose of the invention This application aims to address the problems of invisible, non-attributable, non-comparable, non-binding, and non-securely replayable actual side effects during intelligent agent tool invocation.

[0010] Specifically, this application addresses at least the following technical issues: how to declare and freeze the side effects allowed by the target tool call before the call is made; how to detect actual external state changes during and / or after the execution of the target tool call; how to unify side effects from different sources and in different formats into comparable side effect atoms; how to bind expected side effects, actual side effects, differential results, runtime tool call boundary evidence, tool capability evidence, and call tuples into verifiable evidence; and how to perform replay auditing without repeating irreversible external actions.

[0011] Technical solution To address the aforementioned issues, this application provides an evidence binding and non-destructive replay auditing system for side effects of intelligent agent tool calls. The system includes a call identifier injection and context determination module, a boundary and capability evidence acquisition module, an expected side effect declaration and freezing module, an actual side effect discovery and attribution module, a side effect atomic comparison module, an evidence binding object generation module, a non-destructive replay auditing module, and an anomaly handling module.

[0012] The Invocation Identifier Injection and Context Determination module generates an Invocation tuple before the tool invocation request enters the tool execution environment, and writes the Invocation Identifier, Trace Identifier, or Connector Injection Identifier into the target tool adapter, connector request, external system acknowledgment field, or audit context, so that changes in external state during or after execution can be attributed to this tool invocation.

[0013] The boundary and capability evidence acquisition module acquires runtime tool invocation boundary evidence and tool capability evidence associated with the target tool invocation request. Runtime tool invocation boundary evidence may include tool invocation boundary credentials (TBC), permission snapshots, policy snapshots, capability boundary tokens, or combinations thereof. Tool capability evidence may include tool descriptors, tool manifests, interface patterns, capability declarations, side-effect capability declarations, or their summaries.

[0014] The expected side effect declaration and freeze module generates an expected side effect declaration before the tool invocation is executed. The expected side effect declaration limits the allowed external state changes during this tool invocation and can originate from tool capability evidence, runtime tool invocation boundary evidence, agent invocation plan, user authorization instructions, security policies, historical invocation templates, or side effect capability declarations provided by the tool adapter. Before the invocation, this module freezes the expected side effect declaration, runtime tool invocation boundary evidence, tool capability evidence, and invocation tuple, generating a pre-invocation evidence snapshot.

[0015] The actual side effect discovery and attribution module collects actual side effect discovery results during and / or after tool call execution. These results characterize changes in external system status, resource status, permission status, message status, transaction status, or task status caused by the current tool call, and are attributed to the current tool call through call identifiers, trace identifiers, external receipt identifiers, connector injection identifiers, time windows, or resource status change paths.

[0016] The side effect atomization comparison module normalizes the expected side effect declarations and actual side effect discovery results into expected side effect atom sets and actual side effect atom sets, respectively. It then compares them through dimensions such as object, operation, scope, quantity, time window, before and after state summary, evidence source, and confidence level to generate side effect difference records.

[0017] The evidence binding object generation module generates a side effect evidence binding object. This object binds at least the pre-invocation evidence snapshot, the actual side effect discovery results, the side effect difference record, the runtime tool invocation boundary evidence, the tool capability evidence, and the invocation tuple, thus forming a verifiable association between the side effect facts and the invocation boundary, the tool capability declaration, and the specific invocation context.

[0018] The non-destructive replay auditing module binds the boundaries, capabilities, parameters, strategies, and environment of the object recovery or simulated call based on the side effect evidence. It performs replay, simulated replay, or non-destructive verification in sandbox environment, shadow environment, read-only verification environment, simulated connector, interface stub, historical state snapshot logic replay environment, or rollbackable transaction verification environment, and outputs the replay verification results. When irreversible external actions are involved, the real external state change operation is not repeated.

[0019] Beneficial effects 1. This application treats external state changes generated by intelligent agent tool calls as independent audit objects, rather than simply recording tool call entry points, call parameters, or tool return results; 2. This application freezes the expected side effect declaration, runtime tool call boundary evidence, tool capability evidence, and call tuple before the tool is invoked, so that the scope of allowed side effects before the call has a verifiable evidentiary basis; 3. This application improves the reliability of side effect attribution by attributing external system logs, receipts, resource status differentials, and connector probe results to specific tool calls through call identifiers, trace identifiers, or connector injection identifiers; 4. This application achieves unified comparison between different tools and different external systems by atomicating side effects, and forms a structured difference record based on difference types such as consistency, missing, out of bounds, scope expansion, undeclared side effects, and insufficient evidence; 5. This application binds expected side effects, actual side effects, difference records, boundary evidence, tool capability evidence, and invocation tuples as side effect evidence binding objects, thereby improving the completeness, traceability, and tamper resistance of audit evidence; 6. This application supports non-destructive replay verification and uses the principle of not repeating the actual execution of irreversible external actions as an audit constraint, enabling high-risk tool call scenarios such as emails, transactions, permissions, approvals, code submissions, and cloud resource changes to complete consistency verification in a secure environment.

[0020] Terminology Explanation Side effects refer to changes in external state caused or potentially caused by the invocation of intelligent agent tools, including changes in external system state, resource state, permission state, message state, transaction state, task state, or audit state. The text results returned by the tool do not necessarily constitute side effects; they are only included in the scope of side effect auditing in this application when they cause changes in external state or provide evidence of such changes. Expected side effect declaration: This refers to the data structure used to limit the external state changes allowed during the execution of the target tool call. This declaration may include object type, object identifier, operation type, scope, maximum number, time window, reversibility, idempotency, and manual confirmation requirements. Actual side effect discovery results: refer to the facts of external state changes collected during or after the execution of the target tool based on external system logs, receipts, snapshot differentials, connector probes, etc. Side effect atom: refers to the smallest structured unit used to uniformly compare side effect facts, which may include side effect subject, object type, object identifier, operation type, external system identifier, occurrence time, state summary before and after execution, source of evidence and confidence level; Side effect evidence binding object: refers to a verifiable evidence object formed by binding the pre-call evidence snapshot, actual side effect discovery results, side effect difference records, runtime tool call boundary evidence, tool capability evidence, and call tuple; Boundary Description: The core protected objects of this application are the expected side effect statement, the actual side effect discovery results, the side effect atom set, the side effect difference record, the side effect evidence binding object, and the non-destructive replay verification; this application does not take the propagation permission control before data enters the target input slot in the chained tool call as an essential feature, and such propagation permission control can be implemented by other mechanisms; Non-destructive replay verification refers to the auditing process that verifies whether side effects meet expectations without repeating irreversible external actions, using sandboxes, shadow environments, read-only interfaces, interface stubs, historical state snapshot logic replay, external receipt verification, or rollbackable transaction verification. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the overall system structure provided in the embodiments of this application; Figure 2 A flowchart illustrating the side effect declaration, discovery, comparison, and binding process provided for embodiments of this application; Figure 3 This is a schematic diagram of the structure of the side effect evidence binding object provided in the embodiments of this application; Figure 4 A flowchart of replay auditing and non-destructive verification provided for embodiments of this application; Figure 5 A flowchart illustrating the classification and treatment of side effects differences provided in the embodiments of this application. Explanation of reference numerals in the attached figures

[0022] 100. Call Identifier Injection and Context Determination Module; 110. Boundary and Capability Evidence Acquisition Module; 120. Expected Side Effect Declaration and Freezing Module; 130. Evidence Freezing Module; 140. Actual Side Effect Discovery and Attribution Module; 150. Side Effect Atomization Comparison Module; 160. Evidence Binding Object Generation Module; 170. Non-Destructive Replay Audit Module; 180. Anomaly Handling Module; 200. Tool Invocation Request; 210. Invocation Tuple Determination and Invocation Identifier Injection; 220. Runtime Tool Invocation Boundary Evidence; 230. Tool Capability Evidence; 240. Expected Side Effect Declaration; 250. Pre-Invocation Evidence Snapshot; 260. Actual Side Effect Discovery Results; 270. Expected Side Effect Atom Set; 280. Actual Side Effect Atom Set; 290. Side Effect Difference Record; 300. Side effect evidence binding object; 305. Pre-call evidence snapshot summary; 310. Expected side effect summary; 320. Actual side effect summary; 330. Side effect difference summary; 340. Boundary evidence summary; 350. Tool capability evidence summary; 360. Call tuple summary; 370. Replay condition summary; 380. Signature and timestamp; 390. Pre-binding summary; 400. Replay audit module; 410. Sandbox or shadow environment; 420. Simulate connector or interface stub; 430. Replay read-only verification or snapshot logic; 440. Replay side effect results; 450. Replay verification results; 500. Side effect difference classifier; 510. Consistency or missing data determination; 520. Out-of-bounds or scope expansion determination; 530. Unstated side effect determination; 540. Risk level determination; 545. Insufficient evidence determination; 550. Blocking, rolling back, or compensating; 560. Manual approval, replanning, or alert; 570. Boundary evidence or tool isolation. Detailed Implementation

[0023] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the described embodiments are for illustrative purposes only and are not intended to limit the scope of protection of this application. Features in the various embodiments can be combined with each other unless otherwise specified.

[0024] Example 1: System Overall Structure like Figure 1 As shown, in one embodiment, the system includes a call identifier injection and context determination module 100, a boundary and capability evidence acquisition module 110, an expected side effect declaration and freezing module 120, an evidence freezing module 130, an actual side effect discovery and attribution module 140, a side effect atomic comparison module 150, an evidence binding object generation module 160, a non-destructive replay audit module 170, and an exception handling module 180.

[0025] The call identifier injection and context determination module 100 is used to receive the tool call request 200 and generate a call tuple 210. The call tuple 210 may include at least one of the following: agent identifier, session identifier, task identifier, model identifier, executor version, target tool identifier, target tool version, connector identifier, call identifier, call parameter summary, user authorization summary, runtime policy summary, execution environment summary, upstream call identifier, and downstream call identifier.

[0026] The boundary and capability evidence acquisition module 110 is used to acquire runtime tool call boundary evidence 220 and tool capability evidence 230. Runtime tool call boundary evidence 220 is used to define the resource, operation, capability, scope, and side effect boundaries of this tool call. Tool capability evidence 230 is used to characterize the target tool's interface capabilities and side effect capabilities during the call.

[0027] The Expected Side Effect Declaration and Freeze module 120 is used to obtain expected side effect declarations 240. The Evidence Freeze module 130, which can be a submodule or associated module of the Expected Side Effect Declaration and Freeze module 120, is used to generate a pre-invocation evidence snapshot 250 before the target tool is executed. The Actual Side Effect Discovery and Attribution module 140 is used to collect actual side effect discovery results during and / or after the target tool's execution 260. The Side Effect Atomization Comparison module 150 is used to generate side effect difference records 290. The Evidence Binding Object Generation module 160 is used to generate side effect evidence binding objects 300. The Non-Destructive Replay Audit module 170 is used to generate replay verification results 450. The Anomaly Handling module 180 is used to trigger blocking, rollback, compensation, manual approval, replanning, alarms, or tool isolation in the event of an anomaly.

[0028] Example 2: Calling Identifier Injection and Attribution Basis Before the target tool call request 200 enters the tool execution environment, the call identifier injection and context determination module 100 generates a call identifier, trace identifier, or connector injection identifier and writes it into the target tool adapter, connector request, external system receipt field, or audit context.

[0029] In one implementation, the invocation identifier can be written into the connector request header, request body, external task metadata, Webhook callback context, external system audit fields, or connector session. When the external system returns a receipt, event log, or status change record, the system can attribute the actual side effect discovery result 260 to the specific tool invocation based on the aforementioned identifier.

[0030] When multiple tool calls simultaneously affect the same resource, the system can also set the attribution confidence level by combining the call time, connector session, external receipt, call chain node identifier, and resource state change path. If the attribution confidence level is lower than the threshold, the system will mark the corresponding side effect as insufficient evidence or pending verification, instead of directly acknowledging it as consistent.

[0031] Example 3: Declaration of Expected Side Effects The expected side effect statement 240 is used to limit the external state changes that are allowed to occur during this tool invocation. This statement can be generated from the tool capability evidence 230, the runtime tool invocation boundary evidence 220, the agent invocation plan, the user authorization instructions, the runtime security policy, the historical invocation template, or the side effect capability statement provided by the tool adapter.

[0032] The expected side effect statement 240 may include the side effect object type, object identifier, object scope, operation type, quantity limit, time window, reversibility, idempotency, permission to send external messages, permission to commit external transactions, permission to change permissions, resource consumption limit, data write range, data deletion range, network access range, and manual confirmation requirements.

[0033] For example, when a user instructs an agent to "generate an email draft but not send it," anticipated side effect statement 240 could allow the creation of an email draft and prevent sending the email, modifying email settings, or sending external notifications to unauthorized contacts. When the target tool is a ticketing tool, anticipated side effect statement 240 could allow the creation of a ticket within a specified project and restrict the scope of external notifications and attachments.

[0034] Example 4: Pre-call evidence snapshot Pre-invocation evidence snapshot 250 is used to record the key evidence state before the target tool is executed. This snapshot may include at least the following: invocation tuple summary, runtime tool invocation boundary evidence summary, tool capability evidence summary, expected side effect statement summary, invocation input summary, user authorization summary, runtime policy summary, execution environment summary, timestamp, and signature information.

[0035] The generation of the pre-invocation evidence snapshot 250 can employ digest algorithms, digital signatures, trusted timestamps, append-only logs, Merkle trees, immutable storage, or a combination thereof. By freezing the data before invocation, the audit phase can confirm the applicable boundaries, capabilities, parameters, and expected side effects of the target tool during execution, rather than relying on post-execution tool declarations or logs generated afterward.

[0036] If the tool descriptor, tool list, interface pattern, side effect capability declaration, runtime tool call boundary evidence 220, call parameters, user authorization, or runtime policy changes after freezing, the frozen expected side effect declaration 240 is marked as invalid, and the system regenerates the pre-call evidence snapshot 250.

[0037] Example 5: Actual Side Effect Discovery The Actual Side Effect Discovery and Attribution module 140 collects actual side effect discovery results 260 during and / or after the execution of the target tool. Actual side effect discovery results 260 can characterize database record additions, modifications, or deletions; file creation, modification, or deletion; email, SMS, or notification sending; external task creation; schedule creation; work order status changes; changes in permissions, roles, or access control lists; changes in fund, order, transaction, or approval status; code commits; deployment task triggering; or third-party application interface submissions, etc.

[0038] The actual side effect discovery and attribution module 140 can collect actual side effect discovery results 260 through tool execution receipts, external system event logs, resource status snapshot differences before and after execution, database change logs, file system events, message sending records, network request records, Webhook events, permission change records, transaction submission records, task scheduling records, code repository submission records, third-party service audit logs, or connector probes.

[0039] To attribute actual side effects to a single tool call, the system can use call identifiers, trace identifiers, external receipt identifiers, time windows, resource state change paths, connector injection identifiers, or call chain node identifiers. If multiple tool calls simultaneously affect the same resource, the system can combine call time, connector session, external system receipts, and resource state change paths for attribution, and set confidence levels for the attribution results.

[0040] Example 6: Side Effect Atomization and Difference Comparison like Figure 2 As shown, the side effect atomization comparison module 150 normalizes the expected side effect declaration 240 and the actual side effect discovery result 260 into the expected side effect atom set 270 and the actual side effect atom set 280, respectively. Side effect atoms are used to represent the smallest comparable side effect fact.

[0041] In one embodiment, a side effect atom includes the side effect subject, object type, object identifier or object scope, operation type, external system identifier, occurrence time, pre-execution state summary, post-execution state summary, source of evidence, attribution identifier, and confidence level. By atomizing side effects, side effects generated by different tools or different external systems can be compared at a unified semantic level.

[0042] The side effect atomization comparison module 150 generates side effect difference records 290 based on the expected side effect atom set 270 and the actual side effect atom set 280. Difference types can include consistency, missing, out of bounds, object mismatch, operation mismatch, scope expansion, quantity exceeding limit, time window aberration, undeclared side effect, insufficient evidence, and attribution conflict.

[0043] Example 7: Risk Level Determination and Anomaly Handling Side effect difference record 290 can further include risk level. Risk level can be determined based on factors such as the sensitivity of the side effect object, the degree of irreversibility of the operation, the extent of the scope expansion, the degree of exceeding the limit, whether it crosses the runtime tool call boundary evidence 220, whether it is inconsistent with the tool capability evidence 230, and whether it involves external submission, privilege escalation, fund transactions, message sending, data deletion, or user identity associated data.

[0044] Risk levels can be categorized as low, medium, high, and severe, or numerical scoring can be used. For side effects with insufficient evidence, the system can mark them as risks requiring review, rather than directly classifying them as consistent or out of bounds, to avoid drawing over-conclusions when the chain of evidence is incomplete.

[0045] When the risk level reaches a preset threshold, the anomaly handling module 180 can trigger actions such as blocking subsequent tool calls, rolling back reversible side effects, generating compensation operations, requesting manual approval, reducing the agent's privileges, marking runtime tool call boundary evidence as invalid, isolating the target tool or connector, triggering intelligent weight planning, generating alarms, or submitting audit records.

[0046] Example 8: Binding objects to side effect evidence like Figure 3 As shown, the side effect evidence binding object 300 is used to bind the pre-call evidence snapshot summary 305, the expected side effect summary 310, the actual side effect summary 320, the side effect difference summary 330, the boundary evidence summary 340, the tool capability evidence summary 350, the call tuple summary 360, the replay condition summary 370, the signature and timestamp 380, and the pre-binding summary 390.

[0047] Example 9: Replay Auditing and Non-Destructive Verification like Figure 4 As shown, the non-destructive replay audit module 400 performs replay auditing based on the side effect evidence binding object 300. The non-destructive replay audit module 400 can verify the integrity of the side effect evidence binding object 300, and restore or simulate runtime tool call boundary evidence 220, tool capability evidence 230, call parameters, user authorization, and runtime policies during the call.

[0048] Replay auditing can be performed in a sandbox or shadow environment 410, a simulated connector or interface stub 420, or a read-only verification or snapshot logic replay 430, and will obtain replay side effect results 440. The system compares the replay side effect results 440 with the expected side effect statements 240 and the actual side effect discovery results 260, and outputs the replay verification results 450.

[0049] For irreversible external actions, such as sending emails, external notifications, privilege escalation, data deletion, fund transactions, approval submissions, code submissions, or external task triggers, the non-destructive replay audit module 400 does not repeat the actual external action. Instead, it performs non-destructive verification through simulated submissions, shadow writing, read-only interface verification, interface stub returns, historical state snapshot logic replay, or external system receipt verification.

[0050] Example 10: Classification and Management of Differences in Side Effects like Figure 5 As shown, the side effect difference classifier 500 can perform consistency or missing determination 510, out-of-bounds or scope expansion determination 520, undeclared side effect determination 530, risk level determination 540, and insufficient evidence determination 545 on the side effect difference record 290.

[0051] When the difference type is consistent and the risk level is below the threshold, the system can write the side effect evidence binding object 300 to the audit log and allow the process to continue. When the difference type is missing, the system can request the target tool to retry, trigger the compensation process, or submit for manual review. When the difference type is insufficient evidence, the attribution confidence is below the threshold, or the actual side effect discovery result 260 lacks external receipts, status differences, event logs, connector injection identifiers, or time window matching evidence, the system will not directly determine it as conforming to the expected side effect statement 240, but may trigger manual approval, replanning, or alarm 560.

[0052] When the difference type is out of bounds, scope expansion, or undeclared side effects, the system can trigger blocking, rollback, or compensation 550, or trigger manual approval, replanning, or alarm 560. When the difference result indicates that the runtime tool call boundary evidence 220 is invalid, the tool capability evidence 230 is inconsistent with the actual side effects, involves irreversible external actions, or the connector produces implicit side effects, the system can perform boundary evidence or tool isolation 570, including marking the boundary evidence as invalid, isolating the target tool, suspending the connector, reducing the agent's privileges, triggering tool description re-verification, or requiring the regeneration of the expected side effect declaration 240.

[0053] After the action is completed, the system can write back the action, result, triggering conditions and related evidence summary to the side effect evidence binding object 300 and the audit log to support subsequent integrity verification, difference tracing and non-destructive replay audit.

[0054] Example 11: Email Tool Invocation Scenario In the email tool invocation scenario, the user instructs the agent to draft an email but not send it. Before invoking the email tool, the system generates an expected side effect declaration 240, which allows creating an email draft but prohibits sending the email, modifying email settings, or adding unauthorized contacts.

[0055] The evidence freezing module 130 generates a pre-call evidence snapshot 250 from the email tool descriptor summary, email tool interface pattern summary, side effect capability declaration summary, runtime tool call boundary evidence 220, call tuple 210, and expected side effect declaration 240. After the email tool is executed, the actual side effect discovery and attribution module 140 reads the email system receipts and audit logs.

[0056] If the actual side effect discovery result 260 indicates that only a draft was created, then the side effect difference record 290 is marked as consistent. If the actual side effect discovery result 260 indicates that the email has been sent, then the side effect difference record 290 is marked as an undeclared side effect with a high risk level. The exception handling module 180 can block subsequent email tool calls and submit the side effect evidence binding object 300 for auditing.

[0057] Example 12: Database Update Scenario In a database update scenario, an agent is authorized to update the memo field of a customer record. Expected side effects declaration 240 can be configured to specify the object type as a customer record, the object identifier as the specified customer, the operation type as an update, the allowed field as the memo field, and the maximum number of allowed fields as one record.

[0058] If the actual side effect discovery and attribution module 140 finds through the database change log that both the remarks field and the credit limit field have been modified, the side effect atomic comparison module 150 will mark the modification of the remarks field as consistent, and mark the modification of the credit limit field as undeclared side effect, operation out of bounds, or scope expansion.

[0059] The evidence binding object generation module 160 generates a side effect evidence binding object 300 from the database change log summary, the field status summary before and after execution, the runtime tool call boundary evidence summary, the tool capability evidence summary, the call tuple summary, and the difference record summary. Auditors or the audit system can use this object to confirm the allowed field range, the actual changed fields, and the reasons for the differences at that time.

[0060] Example 13: Chained Tool Call Scenario In a chained tool invocation scenario, an agent may sequentially invoke a search tool, a customer relationship management tool, and a messaging tool. The system can generate a call tuple 210, a pre-call evidence snapshot 250, and a side effect evidence binding object 300 for each tool invocation, and form a chain association through upstream call identifiers, downstream call identifiers, or call chain node identifiers.

[0061] If the expected side effect declaration 240 of a search tool is empty or only allows read-only access, but the actual side effect discovery result 260 shows that a database write occurred, the system can mark this side effect as an undeclared side effect of the search tool call. If a customer relationship management tool is allowed to update customer notes but actually triggers an external message sending, the system can mark it as a cross-tool boundary side effect.

[0062] Through the above method, this application can distinguish abnormal writes by read-only tools, scope expansion by write tools, unauthorized sending by message tools, and indirect side effects caused by downstream tools being affected by upstream output in multi-toolchain calls.

[0063] Example 14: Deployment Method and Intra-family Boundaries The system described in this application can be deployed in an agent runtime, tool gateway, model context protocol gateway, connector security agent, enterprise application programming interface gateway, audit service, cloud security control plane, private agent platform, or a combination thereof.

[0064] In one deployment approach, the system resides within the agent's runtime, uniformly intercepting, freezing, discovering, comparing, and binding all tool invocation requests. In another deployment approach, the system exists as an external tool gateway or connector agent, capable of managing external state changes resulting from tool invocations even if the agent itself is unaware of the side-effect evidence binding process.

[0065] This application can work in conjunction with mechanisms for generating, freezing, matching, executing, recalculating, and solidifying evidence of Tool Invocation Boundary Certificates (TBCs). It can also work with mechanisms for solidifying and detecting contamination of tool descriptors, tool lists, interface patterns, capability statements, and side effect capability statements. Furthermore, it can work with data propagation permissions and side effect path control mechanisms for chained tool invocations. These collaborations do not alter the core protected objects of this application: expected side effect statements, actual side effect discovery results, side effect atomic sets, side effect difference records, side effect evidence binding objects, and non-destructive replay verification.

Claims

1. A system for evidence binding and non-destructive replay auditing of side effects of intelligent agent tool calls, characterized in that, include: The system comprises a module for injecting an identifier and determining the context, a module for obtaining boundary and capability evidence, a module for declaring and freezing expected side effects, a module for discovering and attributing actual side effects, a module for atomic comparison of side effects, a module for generating evidence binding objects, a module for non-destructive replay auditing, and an exception handling module. The module for injecting an identifier and determining the context receives a tool invocation request initiated by an agent for a target tool, generates a call tuple corresponding to the current tool invocation request before the request enters the tool execution environment, and writes the call identifier, trace identifier, or connector injection identifier into the target tool adapter, connector request, external system receipt field, or audit context. The module for obtaining boundary and capability evidence acquires runtime tool invocation boundary evidence and tool capability evidence associated with the tool invocation request. The tool capability evidence at least characterizes the target tool's interface capabilities and side effect capabilities during invocation. The module for declaring and freezing expected side effects generates an expected side effect declaration before the tool invocation request is executed, and processes the expected side effect declaration, the runtime tool invocation boundary evidence, the tool capability evidence, and the actual side effect discovery and attribution. The tuple is used to freeze the data and generate a pre-call evidence snapshot. The expected side effect declaration is used to limit the external state changes allowed by this tool call. The actual side effect discovery and attribution module is used to collect and attribute actual side effect discovery results based on the call identifier, trace identifier, or connector injection identifier during and / or after the execution of the tool call request. The actual side effect discovery results are used to characterize at least one change in external system state, resource state, permission state, message state, transaction state, or task state. The side effect atomicity comparison module is used to normalize the expected side effect declaration and the actual side effect discovery results into expected side effect atomic sets and actual side effect atomic sets, respectively, and generate side effect difference records based on the expected side effect atomic sets and the actual side effect atomic sets. The evidence binding object generation module is used to generate a side effect evidence binding object, which binds at least the pre-call evidence snapshot, the actual side effect discovery results, the side effect difference record, the runtime tool call boundary evidence, the tool capability evidence, and the call tuple. The non-destructive replay auditing module is used to perform replay, simulated replay, or non-destructive verification based on the runtime tool call boundary evidence, tool capability evidence, call parameters, call identifier, trace identifier, runtime policy, and execution environment when the side effect evidence is bound to the object for recovery or simulation. It outputs a replay verification result characterizing whether the actual side effect conforms to the expected side effect declaration. Specifically, when the actual side effect discovery result, replay auditing process, or replay side effect result involves email sending, external notification, privilege escalation, data deletion, fund transactions, approval submission, code submission, cloud resource changes, external task triggering, or other irreversible external actions, the non-destructive replay auditing module does not repeat the actual external state change operation. Instead, it performs verification through at least one of the following methods: simulated submission, shadow writing, read-only interface verification, interface stub return, historical state snapshot logic replay, external system receipt verification, change plan verification, or rollbackable transaction verification. The exception handling module is used to trigger exception handling actions when the side effect difference record or the replay verification result indicates that the actual side effect exceeds the expected side effect declaration, crosses the runtime tool call boundary evidence, is inconsistent with the tool capability evidence, or the evidence integrity verification fails.

2. The system according to claim 1, characterized in that, The call tuple includes at least one of the following: agent identifier, session identifier, task identifier, model identifier, executor version, target tool identifier, target tool version, connector identifier, call identifier, trace identifier, connector injection identifier, call parameter summary, call time, user authorization summary, runtime policy summary, execution environment summary, upstream call identifier, downstream call identifier, or call chain node identifier; the connector injection identifier is written into at least one of the following: connector request header, request body, external system audit context, receipt association field, task metadata, or connector session identifier.

3. The system according to claim 1, characterized in that, The expected side effect declaration includes at least one of the following: side effect object type, object identifier, object scope, operation type, quantity limit, time window, reversibility identifier, idempotency identifier, external message sending permission, external transaction commit permission, permission change permission, resource consumption limit, data writing range, data deletion range, network access range, code commit range, task triggering range, or manual confirmation requirement. The expected side effect declaration is frozen before the target tool is executed. When the runtime tool call boundary evidence, tool capability evidence, call parameters, user authorization, runtime policy, tool description, connector configuration, or execution environment changes, the frozen expected side effect declaration is marked as invalid or to be re-declared.

4. The system according to claim 1, characterized in that, The pre-call evidence snapshot includes at least one of the following: expected side effect declaration summary, runtime tool call boundary evidence summary, tool capability evidence summary, call tuple summary, call input summary, user authorization summary, runtime policy summary, execution environment summary, freeze timestamp, signature information, freeze subject identifier, or snapshot version identifier; the pre-call evidence snapshot is solidified through digest calculation, digital signature, trusted timestamp, append-only log, Merkle tree, immutable storage, or a combination thereof.

5. The system according to claim 1, characterized in that, The actual side effect discovery and attribution module collects the actual side effect discovery results through at least one of the following: tool execution receipts, external system event logs, resource status snapshot differences before and after execution, database change logs, file system events, message sending records, network request records, Webhook events, permission change records, transaction submission records, task scheduling records, code repository submission records, third-party service audit logs, or connector probes. The actual side effect discovery results are attributed to the current tool call request by at least one of the following: call identifier, tracking identifier, external receipt identifier, time window, resource status change path, connector injection identifier, connector session, or call chain node identifier. When multiple tool calls affect the same external resource, attribution confidence is generated based on call time, connector session, external receipt, resource status change path, and call chain node identifier.

6. The system according to claim 1, characterized in that, The side effect atoms in the expected side effect atom set and the actual side effect atom set include at least one of the following: side effect subject, object type, object identifier, object scope, operation type, external system identifier, occurrence time, pre-execution state summary, post-execution state summary, source of evidence, attribution identifier, and confidence level. The side effect difference record includes at least one of the following difference types: consistent, missing, out of bounds, object mismatch, operation mismatch, scope expansion, quantity exceeding limit, time window abnormality, undeclared side effect, insufficient evidence, or attribution conflict. The risk level is determined based on at least one of the following: side effect object sensitivity, operation irreversibility, scope expansion degree, quantity exceeding limit degree, whether it crosses the runtime tool call boundary evidence, whether it is inconsistent with the tool capability evidence, and attribution confidence level.

7. The system according to claim 1, characterized in that, The side effect evidence binding objects include at least one of the following: expected side effect summary, actual side effect summary, side effect difference summary, runtime tool call boundary evidence summary, tool capability evidence summary, call tuple summary, call input summary, call output summary, runtime policy summary, execution environment summary, actual side effect discovery path summary, replay condition summary, replay environment summary, timestamp, signature information, prior binding summary, call identifier, trace identifier, or connector injection identifier; multiple side effect evidence binding objects form an audit chain through prior binding summaries.

8. The system according to claim 1, characterized in that, The non-destructive replay auditing module is used to obtain replay side effect results in a sandbox environment, shadow environment, read-only verification environment, simulated connector, interface stub, historical state snapshot logic replay environment, or rollbackable environment; the replay verification result is generated based on at least one of the following: comparison between expected side effect declaration and replay side effect result, comparison between actual side effect discovery result and replay side effect result, comparison between expected side effect declaration and actual side effect discovery result, integrity verification of pre-call evidence snapshot, or integrity verification of side effect evidence binding object.

9. The system according to claim 1, characterized in that, When the actual side effects are discovered or the replay audit process involves sending emails, external notifications, privilege escalation, data deletion, fund transactions, approval submissions, code submissions, cloud resource changes, external task triggers, or other irreversible external actions, the non-destructive replay audit module does not repeat the irreversible external actions. Instead, it performs non-destructive verification through at least one of the following methods: simulated submission, shadow writing, read-only interface verification, interface stub return, historical state snapshot logic replay, external system receipt verification, change plan verification, or rollbackable transaction verification.

10. The system according to claim 1, characterized in that, The abnormal handling actions include at least one of the following: blocking subsequent tool calls, rolling back reversible side effects, generating compensation operations, requesting manual approval, reducing agent privileges, marking runtime tool call boundary evidence as invalid, isolating the target tool or connector, triggering intelligent weight planning, generating alarms, submitting audit logs, or requiring the regeneration of expected side effect statements.

11. The system according to claim 1, characterized in that, When the attribution confidence of the actual side effect discovery result is lower than a preset threshold, or when the actual side effect atom lacks at least one of the following evidence: external receipt, state difference, event log, connector injection identifier, or time window matching, the side effect atomization comparison module will mark the corresponding difference type as insufficient evidence or pending review, instead of directly determining it as conforming to the expected side effect statement.

12. A method for evidence binding and non-destructive replay auditing of side effects of intelligent agent tool invocation, characterized in that, include: The system receives a tool invocation request initiated by an agent for a target tool. Before the tool invocation request enters the tool execution environment, it generates a call tuple corresponding to the current tool invocation request and writes the call identifier, trace identifier, or connector injection identifier into the target tool adapter, connector request, external system receipt field, or audit context. It also obtains runtime tool invocation boundary evidence and tool capability evidence associated with the tool invocation request. Before the tool invocation request is executed, it generates an expected side effect statement and freezes the expected side effect statement, the runtime tool invocation boundary evidence, the tool capability evidence, and the call tuple to generate a pre-invocation evidence snapshot. During and / or after the execution of the tool invocation request, actual side effect discovery results are collected and attributed based on the invocation identifier, tracing identifier, or connector injection identifier; the expected side effect declaration and the actual side effect discovery results are normalized into expected side effect atomic sets and actual side effect atomic sets, respectively; a side effect difference record is generated based on the expected side effect atomic sets and the actual side effect atomic sets; a side effect evidence binding object is generated, which binds at least the pre-invocation evidence snapshot, the actual side effect discovery results, the side effect difference record, the runtime tool invocation boundary evidence, the tool capability evidence, and the invocation tuple; based on the side effect evidence binding object, the runtime tool invocation boundary evidence, tool capability evidence, invocation parameters, invocation identifier, tracing identifier, runtime policy, and execution environment at the time of invocation are restored or simulated, and replay, simulated replay, or non-destructive verification is performed, outputting the replay verification result; wherein, when the actual side effect discovery result, the replay audit process, or the replay side effect result involves irreversible external actions, the real external state change operation is not repeated, but non-destructive verification is performed.

13. The method according to claim 12, characterized in that, The collection and attribution of actual side effect findings includes: collecting external state changes through tool execution receipts, external system event logs, resource state snapshot differences before and after execution, database change logs, file system events, message sending records, permission change records, transaction submission records, code repository submission records, or connector probes; attributing the external state changes to the current tool call request through call identifiers, tracing identifiers, external receipt identifiers, time windows, resource state change paths, connector injection identifiers, or call chain node identifiers; generating attribution confidence when multiple tool calls affect the same external resource; and marking the corresponding side effect difference record as insufficient evidence or pending verification when the attribution confidence is lower than a preset threshold.

14. The method according to claim 12, characterized in that, Performing replay, simulated replay, or non-destructive verification includes: verifying the integrity of pre-call evidence snapshots, side effect difference records, runtime tool call boundary evidence, tool capability evidence, and call tuples based on the side effect evidence binding object; obtaining replay side effect results in sandbox environments, shadow environments, read-only verification environments, simulated connectors, interface stubs, or historical state snapshot logic replay environments; when irreversible external actions involving email sending, external notifications, privilege escalation, data deletion, fund transactions, approval submissions, code submissions, cloud resource changes, or external task triggers are involved, the irreversible external actions are not repeated, but replay verification results are generated through at least one of the following methods: simulated submission, shadow writing, read-only interface verification, interface stub return, historical state snapshot logic replay, external system receipt verification, change plan verification, or rollbackable transaction verification.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 12 to 14.

Images