A method and apparatus for operation execution control across heterogeneous agents

Abstract

The application relates to the technical field of artificial intelligence security, and provides a cross-heterogeneous-agent operation execution control method and device, which comprises the following steps: converting an operation to be executed received from a heterogeneous agent into a standardized operation event in a unified format; obtaining a minimum feature context stripped of complete original data based on the standardized operation event; performing the operation to be executed based on the minimum feature context in an isolated deduction environment, and converting a generated state difference into a state change graph; and generating an execution control strategy for a real execution environment based on the standardized operation event, the minimum feature context and the state change graph. The application can identify cross-framework-agent action risks before real side effects occur, and realizes unified deduction and accurate control.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence security technology, and more specifically, to a method and apparatus for operation execution control across heterogeneous intelligent agents. Background Technology

[0002] With the widespread application of intelligent agent systems driven by large language models in scenarios such as browser operation, file reading and writing, code execution, and external interface calls, the security risks of intelligent agents have evolved from the risks of simple text output to the risks of side effects caused by continuous actions in the real environment. Existing technologies typically employ methods such as prompt word filtering, tool call whitelists, API gateways, or single sandbox isolation for security protection. However, different intelligent agent frameworks, models, and tool protocols express the same type of action in significantly different ways, making it difficult for existing security solutions to form a unified runtime security view across frameworks and models, and thus only allowing for local judgments within their respective frameworks. At the same time, the real risks of intelligent agent actions often stem from the combined effects of actions with user goals, session context, permission boundaries, and preceding states. Ordinary sandboxes can only isolate system resources but cannot deduce business consequences, API gateways can only verify interface parameters but cannot predict continuous state changes across steps, and manual approval relies on personal experience due to the lack of visual evidence of state differences.

[0003] The aforementioned deficiencies make it difficult for existing solutions to accurately predict and uniformly manage changes in files, external network connections, expanded permissions, and changes in business status before real side effects occur. This makes it easy to generate false alarms or missed reports, and fails to meet the security operation requirements of complex intelligent agent systems. Summary of the Invention

[0004] The purpose of this application is to provide a method and apparatus for operation execution control across heterogeneous intelligent agents, which realizes the standardization and normalization of the actions to be performed by heterogeneous intelligent agents, the minimum feature context projection, the state difference inference under isolated environment, and the graph-based fine execution control.

[0005] Firstly, a method for operation execution control across heterogeneous intelligent agents is provided, which may include: It converts the operations to be executed received from heterogeneous intelligent agents into standardized operation events in a unified format; Based on the standardized operation events, a minimal feature context for inference is obtained, wherein the minimal feature context is a non-sensitive summary feature stripped of the complete original data; In the isolated simulation environment, the operation to be executed is performed based on the minimum feature context, and the resulting state differences are converted into a state change map. Based on the standardized operation events, the minimum feature context, and the state change graph, an execution control strategy is generated for the real execution environment to control the execution of the operation to be executed in the real execution environment.

[0006] In one possible implementation, based on the standardized operation events, a minimal feature context for inference is obtained, including: Based on the operation type indicated by the standardized operation event, determine the corresponding context projection rule; According to the context projection rules, the user target, permission boundary and resource summary are extracted from the original data associated with the operation to be executed to obtain the minimum feature context; The minimum feature context does not include the complete session data and complete tool return data in the original data.

[0007] In one possible implementation, within an isolated simulation environment, the operation to be executed is performed based on the minimal feature context, including: A simulation unit is determined based on the action type, risk level, and resource category in the minimal feature context of the standardized operation event; The operation to be executed is performed or the operation to be executed is simulated in the simulation unit to generate simulation execution results.

[0008] In one possible implementation, the state differences are converted into a state change graph, specifically including: By comparing the internal state snapshots of the operation to be executed before and after execution in the isolated simulation environment, the changed entities and the operational relationships between entities are identified, and a state change map is generated. In the state change graph, nodes represent entities whose resources or states are affected by the operation to be performed, and edges represent the operational relationships between entities.

[0009] In one possible implementation, nodes or edges in the state change graph are marked with operation impact attributes that characterize the degree of side effects of the operation to be performed on the real execution environment; The operational impact attributes include at least one of the following: reversibility index, sensitivity index, and external impact range index.

[0010] In one possible implementation, the method further includes: Based on the operation impact attributes, an operation causal path representing the operation transmission logic is generated; The causal path of the operation is associated with the state change graph.

[0011] In one possible implementation, an execution control policy is generated for the actual execution environment, including: Based on the operation influence attributes in the state change graph and the predefined policy rules, an execution control policy is output. The execution control strategy includes line release, desensitization release, parameter rewriting, output rewriting, manual approval, isolation execution, blocking, delayed release, or secondary deduction. The strategy rules are stored in the rule engine in the form of condition-action pairs. The condition part references the node metadata or edge metadata in the state change graph, and the action part specifies the disposal decision of the output.

[0012] In one possible implementation, the method further includes: Obtain the actual execution result of the operation to be executed in the real execution environment; The actual execution results are compared with the simulated execution results, and a difference vector is calculated; the difference vector includes at least the differences in result content, differences in state changes, and differences in performance. Based on the difference vector, identify the source of the difference; the source of the difference includes incomplete simulation, changes in the actual business status, changes in permission boundaries, changes in external interface returns, or deviations in model parameter selection. Using the difference vector and difference source, update the context projection rule of the minimum feature context, the configuration of the isolation inference environment, or the risk score parameters of the execution control strategy.

[0013] In one possible implementation, after converting the state differences generated by the execution into a state change graph, the method further includes: The state change map is incrementally compressed and stored. The incremental compression storage includes: for multiple consecutive operations to be executed under the same session identifier, the state change map generated by each operation to be executed is stored as an incremental map, and the incremental map only records the changes in the state change map of the current operation relative to the previous operation; the incremental map uses a node addition set, a node deletion set, an edge addition set, an edge deletion set, and an attribute modification list to encode state differences.

[0014] Secondly, a cross-heterogeneous intelligent agent operation execution control device is provided, the device may include: The conversion unit is used to convert the operations to be executed received from heterogeneous intelligent agents into standardized operation events in a unified format; The acquisition unit is used to acquire the minimum feature context for inference based on the standardized operation event, wherein the minimum feature context is a non-sensitive summary feature stripped of the complete original data; An execution unit is used to execute the operation to be executed based on the minimum feature context in an isolated simulation environment; The conversion unit is also used to convert the state differences generated by the execution into a state change map; The generation unit is used to generate an execution control strategy for the real execution environment based on the standardized operation events, the minimum feature context, and the state change map, so as to control the execution of the operation to be executed in the real execution environment.

[0015] This application provides a method and apparatus for operation execution control across heterogeneous intelligent agents. The method converts operations to be executed received from heterogeneous intelligent agents into standardized operation events in a unified format. Based on the standardized operation events, a minimal feature context for inference is obtained, where the minimal feature context is a non-sensitive summary feature stripped of the complete original data. In an isolated inference environment, the operations to be executed are performed based on the minimal feature context, and the resulting state differences are converted into a state change graph. Based on the standardized operation events, the minimal feature context, and the state change graph, an execution control strategy for the real execution environment is generated to control the execution of the operations to be executed in the real execution environment. This application can identify cross-framework intelligent agent action risks before real side effects occur, achieving unified inference and precise control. Attached Figure Description

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

[0017] Figure 1 This application provides a schematic diagram of the structure of a cross-heterogeneous intelligent agent operation execution control system. Figure 2 A flowchart illustrating an operation execution control method for cross-heterogeneous intelligent agents provided in an embodiment of this application; Figure 3 A schematic diagram of the structure of an operation execution control device for cross-heterogeneous intelligent agents provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0019] like Figure 1 As shown, the execution of the cross-heterogeneous intelligent agent operation execution control method of this application relies on a cross-heterogeneous intelligent agent operation execution control system (hereinafter referred to as "the system") located before the actual execution environment of the heterogeneous intelligent agent, which consists of the following eight functional layers: Heterogeneous Access Layer: Used to access operations to be executed from different intelligent agent frameworks (such as LangChain, AutoGPT), different model runtimes, and different tool protocols (such as MCP protocol, Shell command line, browser automation protocol).

[0020] Standard Action Event Layer: Located after the heterogeneous access layer, it is used to convert various operations to be executed received by the heterogeneous access layer into standardized operation events in a unified format.

[0021] Minimal Context Projection Layer: Located after the Standard Action Event Layer, it is used to generate a minimal feature context (i.e., illusion context) based on standardized action events. This context contains only the non-sensitive summary features required for inference.

[0022] Shadow Execution Layer: Located after the minimum context projection layer, it is used to execute or simulate the operation to be executed in an isolated simulation environment and generate simulation execution results.

[0023] State Change Map Layer: Located after the Shadow Execution Layer, it is used to convert the state differences generated by shadow execution into a structured state change map.

[0024] Release gate layer: Located after the state change graph layer, it is used to execute control strategies based on standardized operation events, minimal feature context, and state change graph output.

[0025] Real Execution Layer: Located after the release gate layer, it is used to perform permitted operations in the real system environment according to the execution control policy.

[0026] Differential Flow Layer: Located between the actual execution layer and the minimum context projection layer, shadow execution layer, and release gate layer, it forms a closed-loop feedback path to align the actual execution results with the shadow inference results and calibrate the configuration parameters of each layer.

[0027] The above eight functional layers work together in accordance with the operation link of "action entry → standardization → projection → shadow execution → mapping → adjudication → real execution → calibration" to form a complete closed loop of cross-heterogeneous intelligent agent operation execution control.

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

[0029] Example 1 Figure 2 This is a flowchart illustrating a cross-heterogeneous intelligent agent operation execution control method provided in an embodiment of this application. This method constructs a full-link security governance framework from heterogeneous action access to controlled execution. For example... Figure 2 As shown, the method may include: Step S100 converts the operations to be executed received from the heterogeneous intelligent agent into standardized operation events in a unified format.

[0030] Heterogeneous agents refer to agents implemented based on different frameworks (such as LangChain, AutoGPT), different models (such as GPT-4, Claude, Llama), or different tool protocols (such as MCP, Shell, browser automation).

[0031] Because these agents differ in their representation, parameter structure, and event format for the same type of operation (such as clicking or reading a file), for example, a file reading operation might be encapsulated as a Shell command, Python function call, or HTTP request in different frameworks, it's difficult to create a unified view for security control of the raw instructions. Therefore, this step uses a pre-defined adapter to map various heterogeneous operations to be executed into standardized operation events containing unified field definitions. The operation to be executed is the specific action that the agent plans to perform in the real system environment; this operation has not yet been actually executed and is in a "proposed execution" state. Operations to be executed may include, but are not limited to: Shell commands, file reading, file writing, browser clicks, web form submissions, database queries, database updates, MCP tool calls, external API requests, memory writes, multi-agent message sending, or business backend operations.

[0032] In practice, the heterogeneous access layer first identifies the protocol type and data format of each operation to be executed. Specifically, the system maintains an adapter registry, which stores the corresponding adapter class name, version number, and input / output mode using the protocol type (such as MCP, LangChain, Shell, BrowserAutomation) as the key. When an operation to be executed is received, the system looks up the adapter based on the protocol header or metadata fields carried by the operation. If the lookup is successful, the corresponding adapter is instantiated or invoked.

[0033] Then, the parsing method of the adapter instance is called to parse the operation data to be executed into an intermediate representation object. This intermediate representation object can contain three basic fields: a candidate set of action types (such as normalized from candidate words such as click, tap, press, etc.), a set of parameter key-value pairs (such as {element:"#submitBtn"}), and a source frame identifier (such as LangChain).

[0034] Subsequently, the standard action event layer uses a configurable field mapping table to map fields in the intermediate representation object to predefined fields in the standardized action event. The field mapping table supports regular expression matching and wildcard replacement. For example, for the action type field, the mapping table defines the rule: / click|tap|press / → "browser_click", thus unifying semantically identical but differently named action types across different frameworks into the same standard action type value "browser_click". For the parameter field, the mapping table defines: element → target_resource_id, mapping "element" in the original parameter to the "target resource identifier" in the standardized action event. If there are fields in the intermediate representation object that cannot be mapped (such as extended parameters specific to a certain framework), the key and value of that field are stored in JSON format in the "extended field" container of the standardized action event, with an "unmapped flag" appended for subsequent auditing or manual analysis.

[0035] A standardized operation event is a data structure with a uniform format. As shown in Table 1, a standardized operation event can contain at least the following fields.

[0036] Table 1

[0037] After standardized operation events are generated, they are written to a circular buffer, which uses the session identifier as the partition key. The size of the circular buffer is configurable (by default, each session retains the most recent 100 events) for subsequent duplicate action detection and deduplication: if an event is detected in the buffer that is exactly the same as the current event (the action type, target resource, and parameter summary are all the same) and the time interval is less than 1 second, it is considered a duplicate action and can be directly blocked or merged.

[0038] Through an adapter registry and a configurable field mapping table, zero-code extension access to different intelligent agent frameworks is achieved. New frameworks only need to register the adapter to be processed uniformly. The circular buffer supports efficient deduplication and action frequency control, avoiding repeated inference of the same action and reducing computational overhead. At the same time, standardized action events provide a unified input interface for subsequent inference, solving the problem of strong binding between framework-embedded security control and specific frameworks in existing technologies.

[0039] Step S200: Based on standardized operation events, obtain the minimum feature context for inference, which is the non-sensitive summary feature stripped of the complete original data.

[0040] Specifically, during security simulations, directly transmitting complete session history, file content, or tool return results to the isolated environment not only wastes computing resources but may also lead to secondary exposure of sensitive information in the untrusted environment. Therefore, this step employs an on-demand projection mechanism, dynamically extracting the minimum dataset necessary for the simulation based on the business intent indicated by standardized operational events. This minimum feature context retains key semantic information such as user objectives, permission boundaries, resource structure summaries, and login status, but removes highly sensitive raw data such as specific passwords, tokens, and complete document content. In other words, the minimum feature context is a non-sensitive summary feature stripped of the complete raw data, aiming to minimize the exposure of sensitive data in the shadow environment while ensuring the information required for the simulation.

[0041] This design, while ensuring the isolated simulation environment has sufficient information for consequence prediction, fundamentally reduces the risk of data leakage, achieving a balance between security and availability. It should be understood that the specific extraction rules for the minimum feature context can be dynamically adjusted according to the operation type, with its core being the dual constraints of "minimization" and "non-sensitivity."

[0042] Step S300: In the isolated simulation environment, the operation to be executed is performed based on the minimum feature context, and the state differences generated by the execution are converted into a state change map.

[0043] The isolated simulation environment is a shadow environment that is logically isolated from the real production environment but behaviorally simulates it. It can be a lightweight rule engine, a virtual file system, a headless browser instance, or a database transaction copy, etc. The isolated simulation environment is a logically isolated layer preceding the real execution environment. It is not a typical sandbox (which emphasizes isolation), but rather emphasizes understanding and simulating the consequences of actions, unifying actions, context, permissions, and risks into decidable runtime objects. Executing operations in this isolated simulation environment is not for generating real business value, but rather for observing potential side effects in advance. The system compares snapshots of the environment's state before and after the simulation, identifies changed entities and their relationships, and structures this into a state change graph. In this graph, nodes represent affected resources or state entities (such as files, accounts, network addresses, memory entries, etc.), and edges represent operational relationships between entities (such as read, write, send, delete, etc.). By transforming discrete, black-box execution logs into a structured, white-box graph representation, this application makes previously invisible potential risks computable and traceable, providing an intuitive semantic basis for subsequent accurate decision-making.

[0044] Step S400: Based on standardized operation events, minimal feature context, and state change graph, generate an execution control strategy for the real execution environment to control the execution of the operation to be executed in the real execution environment.

[0045] Specifically, the generation of execution control strategies does not rely on a single-dimensional judgment, but integrates information from three dimensions: the attributes of the operation itself (standardized operation events), the background of the operation subject (minimum feature context), and the expected consequences of the operation (state change graph). This multi-dimensional fusion adjudication mechanism can identify complex scenarios that appear harmless individually but pose a high risk when combined. The generated execution control strategies include, but are not limited to, allowing, de-identifying, rewriting parameters, rewriting outputs, manual approval, isolation execution, blocking, delayed release, or secondary simulation, among other handling methods. The system selects the minimum intervention measure based on the risk level of the simulation results, avoiding both the accidental damage to normal business caused by simple blocking and the security risks brought about by blindly allowing operations. Finally, the strategy is deployed to the real execution environment to precisely control the actual operation of the operation to be executed, thereby realizing a security paradigm shift from "post-event auditing" to "pre-event prevention."

[0046] Through the coordinated operation of steps S100 to S400, this embodiment establishes a complete closed-loop control system for cross-heterogeneous intelligent agent operation execution. Standardized operation events solve the heterogeneity compatibility problem, minimal feature context solves the problem of inference data security and efficiency, state change graphs solve the problem of side effect visualization and structuring, and multi-dimensional execution control strategies solve the problem of fine-grained management. This series of technical means works together to enable the system to accurately perceive and intervene in potential risks before real side effects occur, effectively improving the operational security and controllability of the intelligent agent system in complex business scenarios.

[0047] Example 2 In some embodiments, the process of obtaining the minimum feature context in step S200 is refined. As one implementation, obtaining the minimum feature context for inference based on standardized operation events includes: Step 1: Determine the corresponding context projection rule based on the operation type indicated by the standardized operation event; specifically, the minimum context projection layer reads the action type field in the standardized operation event and obtains the corresponding context projection rule from the local configuration or policy registry.

[0048] Step 2: According to the context projection rules, extract the user target, permission boundary and resource summary from the original data associated with the operation to be executed to obtain the minimum feature context; wherein, the minimum feature context does not contain the complete session data and complete tool return data in the original data.

[0049] Specifically, for different types of operations, the system executes different extraction logic to ensure that the projected context can still support accurate risk inference while stripping away sensitive content.

[0050] When the action type is file read or file write, the resource digest only contains the file type, path range, sensitive field type, and write target. The file type is obtained from the file extension of the target resource identifier (e.g., .txt, .json). The path range is obtained from the directory path prefix of the target resource identifier (e.g., / etc / or / home / user / ). The sensitive field type is obtained by calling a sensitive information scanner to perform regular expression matching on the first 512 bytes of the target file. The sensitive information scanner is pre-configured with matching rules for personally identifiable information (e.g., ID card number, mobile phone number), credentials (e.g., API key, password), internal addresses, or trade secrets. The write target (for write operations) is obtained by parsing the parameter digest field in the standardized operation event, such as the target location of the "content" field contained in the parameters. Choosing the first 512 bytes as the scan window is a trade-off based on extensive engineering practice, as the sensitive header information of most configuration files, certificate files, or structured documents is distributed within this range. This mechanism significantly reduces I / O overhead while ensuring a high detection rate, reflecting a deep adaptation between the projection rules and the underlying storage characteristics.

[0051] When the action type is a browser click or a web form submission, the resource digest only contains the page source URL, login status, target button label, form field names, and the data types that may be submitted. In this scenario, the system does not record the specific form content or the complete cookie value, but focuses on the structural characteristics of the interaction behavior. The page source URL is obtained from the browser context of the current session (e.g., by reading the URL of the current page via the CDP protocol). The target button label and form field names are obtained by parsing the parameter digest field in the standardized action event. Login status is obtained by checking whether a valid session identifier (such as sessionid or token) exists in the cookie storage of the current session. This check not only verifies the non-empty state of the identifier, but also combines expiration verification to confirm the activity of the session, thereby providing accurate authentication status input to the inference environment without exposing the real session credentials.

[0052] When the action type is an external API request, the resource digest only contains the target domain, HTTP method, request parameter keys, authentication method, and return data type. A strict key-value separation strategy is employed here: the target domain and HTTP method are parsed from the target resource identifier field in the standardized action event (e.g., extracting the domain from the URL). The authentication method is read from the credential status field in the standardized action event (e.g., Bearer Token, Basic Auth, or none) without reading the specific token value. The request parameter keys are obtained from the key set of the parameter digest field (only the key name is retained, not the value). This approach allows the simulation environment to identify the API call intent and data flow, but it cannot reconstruct the actual transmitted business data, fundamentally eliminating the risk of data theft in API call simulations.

[0053] When the action type is memory write, the resource digest only contains the memory scope identifier (e.g., short-term memory, long-term memory, vector database index) and the persistence level (e.g., temporary in memory, persistent on disk). The memory scope identifier is parsed from the target resource identifier field and is used to distinguish between short-term working memory and long-term knowledge base; the persistence level is read from the expected side effects field in the standardized operation event. Since the risk level of memory contamination is strongly correlated with its lifecycle, using the persistence level as a key digest feature enables the system to distinguish between temporary debugging information and permanent knowledge writes during the deduction phase, thereby matching security control strategies of different intensities.

[0054] In addition to the resource summary mentioned above, the minimal feature context also includes the following fields, which are obtained directly from normalized operation events or system caches: User Goal Summary: Copied directly from the User Goal Summary field in standardized operation events to maintain consistency in intent delivery. The User Goal Summary is a concise textual description or structured representation of the user's overall intent, generated by the upstream natural language understanding module, and used to help the inference layer understand the business context of the operation.

[0055] Session state: obtained by querying the set of session variables in the current session context, such as session creation time, list of operations performed, etc.

[0056] Permission boundaries: The system reads permissions from the local cache using the calling entity identifier (a unique identifier for the agent instance initiating the operation, typically extracted from the authentication header or session metadata of the original operation, used for subsequent permission queries and audit traceability) and the session identifier as keys. If the cache is not found, a query is initiated to the permission registry center to ensure the real-time nature and accuracy of authentication information. The permission registry center returns a list of operation types and a whitelist of resource paths that the entity is allowed to execute under this session.

[0057] Login status: Check if there is an unexpired access token in the token store of the current session. If it exists and has not expired, it is "logged in"; otherwise, it is "not logged in" or "expired".

[0058] Historical Risk Score: Read from the risk score cache using the session identifier as the key. This risk score cache stores the weighted average of the risk scores for the most recent 10 operations, with weights decaying over time and the most recent operation having the highest weight (e.g., a weight vector of [0.3, 0.2, 0.15, 0.1, 0.1, 0.05, 0.05, 0.03, 0.02, 0.01]). The calculation formula is as follows:

[0059] in, For the first The risk score for this operation (attached when output from the release gate layer) For preset weights, and The (most recent) weight is the highest.

[0060] Credit status: Query from the user credit database, which stores the number of historical violations (such as the number of operations blocked in the past 30 days) and credit rating (levels A, B, C, and D) with the calling entity identifier as the key.

[0061] Policy rules: obtained from the policy registry. The policy registry is indexed by action type and resource category, and returns the corresponding inference rules (such as whether to allow simulated execution) and de-identification policies (such as using masking de-identification for password fields).

[0062] The aggregation of these multi-source heterogeneous data forms a three-dimensional inference context, enabling the isolated environment to simulate complex decision-making conditions in the real environment.

[0063] To prevent the minimum feature context itself from becoming a source of leakage, this application can perform mandatory desensitization processing on all original data in the minimum feature context before storage: when the string type value exceeds 50 characters, only the first 20 characters are retained and the last four bits of the hash value are appended (e.g., if the original string length is 100, then the first 20 characters + "..." + the last 4 bits of the hash are taken); for numeric type values, only the numeric range range identifier is retained (e.g., "0-10", "10-100", ">100"); Boolean values ​​are directly retained.

[0064] For strings, preserving prefixes maintains data readability and some semantic matching capabilities (such as file path prefixes and error code prefixes), while the appended hash suffix provides a unique identifier, allowing different entities to be distinguished during the deduction process, but preventing the original content from being reconstructed. For numerical values, range-based processing (such as converting specific amounts to a range of 1000-5000) preserves order-of-magnitude information to support the triggering of threshold-based rules, while erasing precise values ​​to prevent the leakage of sensitive financial or statistical data.

[0065] Example 3 This embodiment further describes the execution of the operation to be performed in step S300 within the isolated simulation environment, based on the minimum feature context, including: Step 1: The shadow execution layer first determines a simulation unit based on the action type, risk level, and resource category in the minimal feature context of the standardized operation event; among them, the expected side effect field represents the inherent static risk attributes of the current operation itself, such as whether it involves data deletion, permission change, or external network transmission.

[0066] Step 2: Execute the operation to be executed or simulate the operation in the simulation unit to generate simulation execution results.

[0067] The core of this mechanism lies in breaking the limitations of traditional security solutions that rely on a single sandbox or fixed execution environment. It achieves on-demand allocation of simulation resources through multi-dimensional feature matching. Specifically, the action type determines the basic environment required for simulation (e.g., file operations correspond to a file system, and web page operations correspond to a browser), the resource category limits the configuration range of the environment (e.g., internal databases and external APIs have different isolation levels), and the risk level serves as a key knob for adjusting the simulation depth, ensuring that the system can achieve the optimal balance between security and performance when facing massive heterogeneous requests.

[0068] To support the dynamic selection process described above, this application establishes a quantitative risk assessment system. The risk level in step 1 above can be obtained through the following methods: Extract the baseline risk value from the expected side effects field in the standardized operation event (e.g., a baseline value of 80 for "file deletion" and 20 for "file read"), and then combine it with the historical risk score (the risk-weighted average of the last 10 operations) in the minimum feature context to calculate the comprehensive risk level value: Risk level = min(100, α) Expected side effect baseline value + (1 α) Historical risk score); where α is a preset weighting coefficient (usually 0.6), indicating that the expected side effects of the current operation are more important than historical risks.

[0069] Resource categories are obtained directly from the resource summary of the minimal feature context (e.g., file, browser, api, memory).

[0070] Determining Simulation Units: The system maintains a simulation unit pool, managed using an LRU (Least Recently Used) strategy. The system prioritizes retrieving idle units from the pool that match the required resource category and risk level. If no idle units are available and the pool size has not reached its limit, a new unit is created. If the pool is full, the least recently used unit is released. Units are not immediately destroyed after execution; instead, their state is reset and they are returned to the pool for reuse by subsequent similar requests, reducing creation overhead. The simulation unit pool can contain various types of simulation units (as shown in Table 2). The selection rules based on risk level and resource category are as follows: Table 2

[0071] Rule inference only matches expected state changes based on a predefined rule table without actually running the operation code. For example, for the "file_read" action, rule inference simply returns "read successful, no state change", without actually opening the file.

[0072] Furthermore, based on the calculated risk level values, a tiered strategy can be implemented. Specifically: If the risk level value is lower than the first preset threshold, the above-mentioned rule deduction or type deduction can be used as the simulation deduction unit. In the rule deduction, the expected state change is matched only according to the predefined rule table without actually running the operation code. If the risk level value is higher than the second preset threshold, the deep simulation deduction unit is used.

[0073] This traffic splitting design reflects the engineering mindset of defensive expansion. For low-risk operations, rule deduction completes the security verification of most regular requests with millisecond-level response speed and extremely low resource overhead, avoiding unnecessary performance loss caused by deep simulation. For high-risk operations, although deep simulation consumes more computing resources, it can provide conclusive evidence of execution consequences through realistic or high-fidelity environment reproduction, preventing security decision errors caused by simulation distortion.

[0074] It should be understood that the specific values ​​of the first and second preset thresholds can be configured according to the security tolerance of the business scenario, and an intermediate level can also be set between the two, using a lightweight sandbox or a simplified simulator as a transition to achieve smoother resource scheduling.

[0075] When deep simulation is triggered, the system selects a suitable deep simulation inference unit from the candidate pool. The deep simulation inference unit is selected from at least one of the following: de-identified file systems, virtual browsers, API simulators, shadow MCP tools, database transaction copies, containers, microvirtual machines, WebAssembly sandboxes, tool proxies, or decoy resources. These units cover the main resource types and interaction patterns that the agent may access. For example, containers and microvirtual machines provide strong operating system-level isolation, suitable for executing untrusted code; WebAssembly sandboxes provide lightweight instruction-level isolation, suitable for running compiled logic modules; decoy resources are used to actively detect potential malicious scanning or injection behaviors.

[0076] For several typical deep simulation scenarios, this application provides specific construction and implementation methods to ensure a balance between isolation and realism. The construction methods for simulation units include: For database transaction replicas, an idle connection is obtained from the database connection pool, a transaction is started, operations are executed, but the transaction is not committed; after the operation is completed, a rollback is performed to undo all data changes. For read-only queries, a normal connection is used directly, without starting a transaction. In this process, "starting a transaction" and "rollback" are key timing constraints for ensuring data security. During the simulation phase, the system utilizes the database's inherent transaction isolation features to run operations in an independent logical view. This verifies the correctness of SQL syntax, constraint conflicts, and permission validity, while also ensuring through forced rollback that no write operations are persisted to the production database, thus achieving a realistic simulation with zero side effects.

[0077] For file-related operations, the simulation unit is constructed as follows: For de-identified file systems, a virtual file tree with the same structure as the target path but with de-identified file content is created in a temporary directory. The de-identified copy is generated by reading the original file, replacing fields matching the sensitive information regular expression with "[REDACTED]", and then writing it to the temporary directory. The ingenuity of this construction method lies in the separation of structure preservation and content replacement. Many intelligent agent scripts rely on specific directory levels or filename patterns to function correctly; completely randomizing the path would cause inference failure; while directly copying the original file would pose a risk of sensitive data leakage. Therefore, the system precisely replicates the directory topology and metadata (such as file size and modification time) in the temporary space, replacing only the file body with a de-identified copy containing placeholders or forged data. This satisfies the semantic dependencies of program execution while completely cutting off the outflow path of sensitive information.

[0078] For browser interactive operations, the simulation unit is constructed as follows: For the virtual browser, a headless browser instance is launched and a de-identified snapshot of the target page is loaded (i.e., only the DOM structure is retained, and all scripts and external links are removed), simulating clicks or form submissions. Using a headless instance eliminates the overhead of graphics rendering, allowing the simulation to be executed efficiently and concurrently on the server side. Loading the de-identified snapshot instead of accessing the real URL in real time avoids additional load on external services or being blocked by the target's risk control system during the simulation process. It also prevents malicious scripts that might exist on the page from probing the simulation environment. The snapshot retains the DOM structure and form elements, sufficient to verify the validity of click, submission, and other interactive logic, while removing cookies, tokens, and user privacy data, ensuring the purity and security of the simulation environment.

[0079] The API simulator returns simulated responses based on pre-recorded API response samples or the OpenAPI specification. For external APIs that are not predefined, the system uses a lightweight proxy to forward requests to the real API but logs the response, while blocking writes to production data.

[0080] Example 4 The process of converting state differences into state change maps in step S300 and its storage optimization mechanism are further refined. Converting state differences into state change maps specifically includes: By comparing the internal state snapshots of the operation to be executed before and after execution in the isolated simulation environment, the entities that have changed and the operational relationships between them are identified, generating a state change graph. Nodes in the state change graph represent entities whose resources or states are affected by the operation to be executed, and edges represent the operational relationships between entities.

[0081] The steps for generating internal state snapshots are as follows: the system calls the snapshot generation function before and after the simulation unit is executed to generate the corresponding internal state snapshots. For the de-identified file system, the snapshot contains the path, size, modification time, and content hash value of each file in the virtual file tree; for the virtual browser, the snapshot contains the current URL, the structure hash of the DOM tree, cookie storage, and local storage content; for database transaction replicas, the snapshot contains the number of rows in the affected tables and the hashes of key fields.

[0082] By comparing the two snapshots, the following was identified: Node: The affected entity, including files, directories, network addresses, accounts, cookies, tokens, database records, business objects, memory entries, external interfaces, approval objects, or output fragments. Each node has a unique node ID and type label.

[0083] Edges: Operational relationships between entities, including read, write, send, delete, overwrite, login, authorization, disclosure, pollution, trigger, rollback, or dependency relationships. For example, if a file node changes from "not present" to "present", an edge is added from "empty" to "created" for that file; if a cookie node's value changes after an operation, an edge is added to "overwrite".

[0084] As can be seen, the internal state snapshot does not refer to a single dimension of runtime parameters, but rather encompasses a collection of heterogeneous data from multiple sources, including file system metadata, process environment variables, network connection handles, database transaction logs, and memory object references. The system uses a differential algorithm to compare and infer snapshots before and after the simulation, abstracting the discrete underlying changes into a semantic-level graph structure.

[0085] For example, when a configuration file is modified in the simulation environment and subsequently read by a network sending process, the state change graph will not only generate nodes representing the file and nodes representing network connections, but also a "read" edge from the file to the network connection and a "write" edge from the operation subject to the file. Compared to traditional linear logs, this structured representation can intuitively present the chain reactions and topological dependencies caused by operations, providing a computable graph theory foundation for subsequent risk assessment.

[0086] To support refined execution control strategies, a multi-dimensional risk metadata annotation mechanism can be introduced during the state change graph construction process, including: Nodes or edges in the state change graph are marked with operation impact attributes that characterize the degree of side effects of the operation to be executed on the real execution environment; these operation impact attributes may include at least one of reversibility indicators, sensitivity indicators, and external impact range indicators. These attributes are obtained not based on human experience, but on automated detection and matching logic.

[0087] Reversibility metric: This is determined by querying whether the target resource supports transactional operations or rollback mechanisms, with values ​​of "fully reversible," "conditionally reversible," or "irreversible." For example, for database write operations, the system checks whether it is within an uncommitted transaction or whether a corresponding compensation SQL exists; if so, it is marked as reversible.

[0088] Sensitivity metrics: These are obtained by calling a sensitive information scanner to evaluate entity content in real time. The scanner has a built-in regular expression library and machine learning classification model, which can classify node content into three levels of sensitivity: low, medium, and high. For example, nodes containing ID card numbers, private keys, or salary fields are identified as highly sensitive.

[0089] External impact scope indicator: This is determined by comparing the target network address with a pre-defined internal domain name whitelist. If the target domain name is not in the whitelist, the corresponding edge or node is marked as having external impact. For example, if the entity is a network address and the target domain name is not in the pre-defined internal domain name whitelist, it is marked as having external impact.

[0090] For example, for file deletion operations, the reversibility metric is determined to be 'irreversible'; for database UPDATE operations executed within a transaction, it is determined to be 'conditionally reversible'; for configuration file reading, the sensitivity metric is determined to be 'highly sensitive'; and for sending data to the external domain api.unknown.com, the external impact metric is determined to be 'yes'.

[0091] Furthermore, based on the labeled operational impact attributes, this application further reveals the underlying logic of risk transmission. The method also includes: Step 1: Based on the operation impact attributes, generate an operation causal path representing the operation transmission logic. The causal path is a directed acyclic graph (DAG), starting from the triggering action and tracing back along the edges to all affected nodes. For example, a "file write" operation will cause a change in the "file node", which in turn will cause a change in the "output node", forming the path: write operation → file node (state change) → output node (containing file content).

[0092] Step 2: Associate the causal path of the operation with the state change graph.

[0093] In some embodiments, a credibility score for the causal path can also be calculated: for each generated operational causal path, the system also calculates a credibility score. The calculation formula is: Credibility = (1 Path ambiguity coefficient) × average evidence strength × path length decay factor credibility = (1 Path ambiguity coefficient) × average evidence strength × path length attenuation factor; The path ambiguity coefficient is calculated by statistically analyzing whether there are branch nodes (nodes with an out-degree greater than 1) and merging nodes (nodes with an in-degree greater than 1) on the path: Path ambiguity coefficient = 0.2 × (number of branch nodes + number of merging nodes), with a maximum of 0.5.

[0094] Average evidence strength is the average completeness of evidence fragment references for each edge on the path. Evidence fragment references point to line numbers in log files or state difference records generated by the isolated simulation environment. Completeness is determined by checking whether the evidence fragment contains specific operation parameters, timestamps, and execution return values, with a completeness value ranging from 0 to 1.

[0095] Path length attenuation factor = It is used to punish excessively long causal chains.

[0096] Only when the confidence level is greater than a preset threshold (e.g., 0.7) will the causal path be output to the decision reason of the release gate layer as interpretable evidence; for causal paths with confidence levels below the threshold, they will be marked as "to be verified" and re-evaluated after the actual execution results are aligned.

[0097] The generation of the aforementioned causal path employs a graph traversal algorithm (such as breadth-first search or depth-first search). Starting from the initial node triggering the operation, it traces all reachable state-change nodes along the edges and filters out critical risk links based on the operation impact attributes of the nodes. For example, in a complex operation and maintenance scenario, the agent first modifies the local agent configuration (node ​​A, reversible), then restarts the agent service (node ​​B, irreversible), and finally reports state data including the hostname to an external monitoring platform using the new configuration (node ​​C, external impact + sensitive). The system automatically generates a causal path "A→B→C" and associates this path as a whole with the state change graph.

[0098] Considering that an agent session typically involves multiple consecutive operation steps, storing a complete state change graph for each operation would cause storage space to grow linearly with the session length, severely impacting the efficiency of audit backtracking. Therefore, this application proposes an efficient graph storage optimization scheme.

[0099] As one implementation method, after generating the state change map, incremental compression can be performed on the map, including: For multiple consecutive operations to be executed under the same session identifier, the system can perform incremental compression on the state change graph. The state change graph generated by each operation is stored as an incremental graph, which only records the graph changes of the current operation relative to the previous operation. The incremental graph adopts an edit distance-based representation method: using node addition sets, node deletion sets, edge addition sets, edge deletion sets, and attribute modification lists to encode state differences.

[0100] To prevent excessively long incremental chains from causing performance degradation in reconstruction, this application designs an adaptive full reconstruction triggering mechanism. As one implementation method, when the size of the incremental graph exceeds three times the size of the original graph, a full reconstruction is triggered, the current state snapshot is used as the new baseline graph, and the incremental chain is reset. The choice of three times as the threshold is a balance point derived from a large number of engineering tests: when the incremental accumulation is too large, its volume may exceed the full graph, and too many difference terms need to be merged during reconstruction, resulting in increased read latency; at this time, although a full snapshot consumes instantaneous I / O, it can reset the accumulated error and restore the baseline access capability of O(1). When querying the complete state change graph at any point in time, the system only needs to load the most recent baseline graph and apply the subsequent k incremental graphs in sequence, with a reconstruction complexity of O(k), where k is the number of incremental graphs. Since k is usually much smaller than the total number of operations in the session and is limited to a small range after triggering full reconstruction, this mechanism ensures that even in complex sessions lasting several hours and containing thousands of operations, auditors can still backtrack the system state at any time with millisecond-level latency. This strategy, which combines incremental compression with adaptive reconstruction, significantly reduces storage costs and transmission bandwidth usage in long-session scenarios while ensuring the integrity and traceability of historical states. It provides key technical support for the large-scale deployment of enterprise-level intelligent agent security audit systems.

[0101] Example 5 This embodiment further refines the process of generating an execution control strategy for the real execution environment in step S400. As one implementation, the gate release layer is the core decision-making component. Its inputs include standardized operation events, minimal feature context, and a state change graph (containing metadata of nodes / edges, and may also include causal paths). It generates an execution control strategy, including: Based on the operational impact attributes in the state change graph and predefined policy rules, an execution control policy is output. Specifically, this step is the core decision-making step that transforms the structured risk evidence generated in the preceding steps into specific control instructions. The system no longer relies on simple judgments from a single dimension, but instead matches the operational impact attributes of nodes in the state change graph, such as reversibility, sensitivity, and scope of external influence, with the predefined condition-action rules in the policy registry. The output execution control policy covers a variety of refined handling methods, including but not limited to release, de-identified release, parameter rewriting, output rewriting, manual approval, isolation execution, blocking, delayed release, or secondary deduction.

[0102] The above approach enables the system to select the most appropriate intervention method based on the specific form of risk. For example, operations involving only sensitive data reading but not external transmission can be de-identified and allowed, while operations involving irreversible external writing will trigger manual approval or block, thereby maximizing business continuity while ensuring security. Predefined policy rules are stored in the rule engine as a set of rules in the form of condition-action pairs. The condition part references node metadata or edge metadata in the state change graph, and the action part specifies the specific handling decision. This rule definition method based on graph semantics allows the policy to perceive the topological relationships and transmission paths between operations, rather than simply matching isolated tool call names.

[0103] To transform abstract risk perception into deterministic engineering decisions, this application establishes a multi-level adjudication mechanism based on risk scores. This includes: First, the following feature vectors are extracted from the state change graph: The five dimensions quantify the potential harm of the current operation from five aspects: highest sensitivity level, number of irreversible operations, number of external impact scope markers, number of nodes requiring approval, and number of edges marked as "no" (reversible). These dimensions assess data sensitivity, difficulty in mitigating consequences, impact boundary diffusion, mandatory compliance requirements, and operational rigidity. Highest sensitivity level: The maximum value of the sensitivity index of all nodes in the graph (low=1, medium=2, high=3).

[0104] Number of irreversible operations: The number of edges whose reversibility is marked as "irreversible".

[0105] Number of external influence scope markers: The number of edges whose external influence scope index is "yes".

[0106] Number of nodes requiring approval: The number of nodes marked as "requires manual approval".

[0107] Number of irreversible edges: The number of edges whose reversibility is marked as "no".

[0108] Let the eigenvector be .

[0109] Secondly, the feature vector is weighted and fused with historical risk scores, credit status (with values ​​A=0.1, B=0.3, C=0.6, D=0.9) from the minimum feature context, and the expected side effect field from standardized operational events (predefined values ​​mapped to 0-1) to calculate a comprehensive risk score. The weighting coefficients for this fusion are pre-stored in a configuration file. This fusion process comprehensively considers static operational attributes, dynamic session context, and the subject's credit status. The configurability of the weighting coefficients allows operations personnel to flexibly adjust the influence of each factor according to the security tolerance of the business scenario. For example, the weight of the external impact range can be reduced in an intranet testing environment, while the weight of the number of irreversible operations can be increased in a production trading environment.

[0110] Finally, a basic execution control strategy is output based on the comprehensive risk score.

[0111] Specifically, the comprehensive risk score is compared with a first risk threshold (e.g., 30) and a second risk threshold (e.g., 70), where the first risk threshold is lower than the second risk threshold. If the overall risk score is less than the first risk threshold, the output execution control policy is "allow". If the overall risk score falls between the first and second risk thresholds, further check whether there are external impact range markers or irreversible operation markers in the state change graph. If so, output "Manual Approval"; otherwise, output "De-sensitized Release". If the overall risk score is greater than the second risk threshold, then "Block" is output.

[0112] In addition to automated adjudication, this application also retains a priority intervention channel for expert rules. When a rule in the rule set precisely matches the action type and target resource identifier of the current standardized operational event, the output based on the risk score is overridden, and the output of the matching rule takes precedence. This precise matching rule is typically used to address known high-risk vulnerability exploits, specific compliance injunctions, or emergency circuit breaker scenarios, and its priority is higher than that of general risk scoring models. Each precise matching rule also includes a conditional expression and an action expression. The conditional expression references node metadata or edge metadata in the state change graph, and the action expression specifies the type of execution control strategy and optional parameter rewriting rules or output rewriting rules. This design ensures that the system, while possessing adaptive risk assessment capabilities, does not lose its adherence to deterministic security bottom lines, preventing known high-risk operations from being mistakenly allowed due to model bias or improper weight configuration.

[0113] In some embodiments, for business scenarios requiring data leakage prevention but not suitable for complete blocking, this application provides dynamic rewriting capabilities. One implementation includes: When the output execution control strategy is "parameter rewrite" or "output rewrite", the desensitization strategy configuration file is read from the real system environment based on the nodes marked as high sensitivity level in the state change graph. This configuration file can be stored in YAML format and is used to specify the desensitization operations to be performed on specific types of sensitive fields, including masking, replacing with pseudo values, truncating or removing. By parsing the configuration file, the original parameters in standardized operation events are replaced according to the de-identification strategy to generate a new operation object. For example, if the original parameters are {"username":"alice","password":"123456"}, after de-identification they become {"username":"alice","password":"***"}, and this new operation object is then passed to the actual execution environment for execution. During this process, the operation content of parameter rewriting, the original parameter fragments, and the de-identified parameter fragments are recorded in the adjudication reason field and included in the audit log.

[0114] This mechanism achieves dynamic protection that ensures "data is available but not visible," satisfying the agent's need to obtain necessary information to complete tasks while completely cutting off the path for sensitive plaintext to flow into an uncontrollable environment.

[0115] When risks are in an ambiguous area requiring human judgment, the system enhances the accuracy of approval decisions through visualization. As one implementation method, when the control strategy involves manual approval, the state change graph is converted into a visual approval interface, which displays the following content in tabular or graphical form: Action type, target resource identifier, key nodes and edges in the state change graph, reversibility identifier and sensitivity level of each node, external influence range identifier of each edge, and suggested approval actions; Receive input from approvers and determine the final execution control strategy based on the input: allow, block, or rewrite parameters.

[0116] The approval interface also provides a "View Simulated Evidence" button, which displays details of the state differences in the isolation simulation environment before and after execution. These differences are presented as side-by-side comparative text or highlighted HTML. This design addresses the information asymmetry problem in traditional approval processes, where "only parameters are seen, not consequences," allowing approvers to select "Release," "Block," or "Parameter Rewrite" on the interface and fill in their approval comments. After receiving the approver's input, the system determines the final execution control strategy based on that input.

[0117] To ensure the machine readability of the policy output and the executability of downstream systems, the execution control policy can be output in the form of a structured object, which at least includes a policy type field (policy_type), a reason field (reason), a key evidence field (evidence), and a rollback flag field (rollback_flag). Optionally, it may also include an object field (rewritten_operation). Wherein: policy_type: String, with a value that can be one of the above-mentioned disposal decisions.

[0118] reason: string, such as "Overall risk score 65, there is external influence, manual approval required".

[0119] evidence: a string array that references the corresponding node ID or edge ID in the state change graph, such as ["node_123","edge_456"].

[0120] `rollback_flag`: A boolean value determined by whether there is an edge in the state change graph that is marked as "yes" for invertibility. It is set to true if there is at least one edge that is either "fully invertible" or "conditionally invertible," otherwise it is false.

[0121] rewritten_operation: An object containing the rewritten operation object when the strategy type is "parameter rewrite" or "output rewrite".

[0122] In some embodiments, during actual operation, multiple rules may be triggered simultaneously with the same priority. To avoid behavioral uncertainty caused by decision conflicts, this application introduces a systematic conflict resolution mechanism. One implementation includes: When multiple rules in the rule set match and have the same priority, the following conflict resolution process based on the conflict matrix is ​​executed: First, each rule has a predefined priority (an integer, with higher values ​​indicating higher priority). If priorities differ, the higher-priority rule is used. If priorities are the same, the matching rule is mapped to a conflict matrix according to the strategy type specified in its action section. The rows and columns of the conflict matrix represent strategy types. For example, if the conflict matrix is ​​an N×N table, N represents the number of strategy types (including allow, de-identify allow, parameter rewrite, output rewrite, manual approval, isolation execution, blocking, delayed release, and secondary deduction). Matrix elements predefine how to resolve combinations of two strategies, including: using a stricter strategy, using a more lenient strategy, manual adjudication, or performing a secondary deduction.

[0123] Specifically, the conflict matrix transforms abstract policy conflicts into deterministic table lookup operations. For example: If the matching rule contains both "block" and "manual approval", then "block" (stricter) is selected according to the conflict matrix definition, because blocking represents a higher degree of security confidence and should not be downgraded due to the existence of the approval channel; If both "de-identification and release" and "parameter rewriting" are included, the conflict matrix is ​​defined as a combined execution: first execute parameter rewriting, then execute de-identification and release. This sequential combination ensures that the data undergoes multiple purification processes before flowing out, achieving a finer protection granularity than a single strategy. If both "isolated execution" and "delayed release" are included, the conflict matrix is ​​defined as sequential execution: first isolated execution, then delayed release (i.e., after isolated execution is completed, wait for a specified time before returning the result). This is suitable for scenarios that require observing the aftereffects of execution or preventing timing attacks.

[0124] By using a predefined conflict matrix, the system solidifies complex strategic games into predictable engineering logic, ensuring the consistency and compliance of control behavior.

[0125] However, for rare combinations that cannot be resolved using the aforementioned conflict matrix, this application provides a fallback arbitration mechanism based on machine learning. As one implementation, for combinations that cannot be resolved using the conflict matrix (such as the simultaneous occurrence of "allow" and "block" without predefined definitions), an arbitration model is invoked. This arbitration model is a logistic regression classifier, and its input features include: the number of conflicting rules, the strategy type combination encoding, the current session's historical risk score, and the operation type encoding. In other words, the input is the conditional feature vector corresponding to the conflicting rules, and the output is the final strategy type. The strategy type output by the arbitration model, along with the resolution process log, is written to the audit record.

[0126] The arbitration model uses historical rulings as training samples and is updated offline weekly. When the conflict matrix cannot be resolved, the model is invoked in real time to output the final policy type, and the current ruling result is stored as a new sample in the training set.

[0127] Logistic regression classifiers are chosen as arbitration models because of their strong interpretability and low computational cost. They can learn implicit policy preferences based on historical ruling samples and make probabilistically optimal decisions when rules are missing.

[0128] Example 6 Based on Examples 1 to 5, this example further constructs a closed-loop feedback mechanism between deduction and execution, enabling the system to have the ability to continuously learn and evolve.

[0129] As one implementation method, after controlling the execution of the operation to be executed in the real execution environment, the real execution layer performs the following steps: Step 1: Obtain the actual execution result of the operation to be executed in the real execution environment.

[0130] Specifically, the actual execution layer executes actions permitted by the release gate (i.e., policies of "allow," "de-identify and allow," "parameter rewrite," or "output rewrite") in the real system environment and records the actual execution results. For the "isolated execution" policy, the action is executed in an isolated environment (such as within a container); for the "block" policy, no operation is performed, and a safe alternative is returned (such as "operation blocked by security policy"). That is, the actual execution layer records the standard output, standard error, return code, execution time, and state changes before and after the actual execution (captured, if possible, through transaction snapshots or audit hooks). For database operations, a read-only transaction can be opened to capture the number of affected rows.

[0131] Step 2: Compare the actual execution results with the simulated execution results and calculate the difference vector; the difference vector can include at least the differences in result content, state changes, and performance. Specifically, the difference backflow layer compares the actual execution results with the simulated execution results (shadow execution results). The comparison is performed by converting both the actual and simulated execution results into JSON structures (e.g., {"exit_code":0,"stdout":"...","state_changes":{...}}), then comparing values ​​field by field, recording inconsistent field paths and value differences, and counting the number of differences. Simultaneously, it compares the predicted state changes in the state change graph with the actual state changes. The difference vector is defined as:

[0132] The number of content differences refers to the number of fields with different values ​​in the JSON comparison, while the number of state change differences is the symmetrical difference between the set of real state change nodes and the set of shadow state change nodes. The necessity of using JSON structured comparison lies in the fact that the output of an agent often contains nested objects, arrays, and unordered key-value pairs. Direct text comparison is prone to generating numerous false alarms due to field order adjustments, differences in whitespace characters, or timestamp changes. By recursively traversing the JSON key path, the system can accurately locate the smallest data unit where semantic changes occur. For example, it can identify that the "response.data.user.token" field is empty in the simulation environment but has a valid value in the real environment. This fine-grained difference localization is a prerequisite for subsequent accurate attribution and rule correction. Furthermore, dividing the difference dimensions into three categories—result content, state change, and performance—allows the system to distinguish between different types of problems such as "data inconsistency," "unreproducible side effects," and "response timeout," providing multi-dimensional evidence to support the identification of the source of the difference.

[0133] Step 3: Identify the source of the difference based on the difference vector.

[0134] Specifically, the system identifies the sources of discrepancies based on the discrepancy vector and a pre-built discrepancy classifier (a decision tree model). The classifier's input features include: action type, the field path where the discrepancy occurs, and the shadow execution unit type. The classifier outputs possible sources of discrepancies, including: incomplete simulation (e.g., the mock response structure does not match the real API), changes in the actual business state (e.g., the database is modified by other processes during execution), changes in permission boundaries (e.g., the token expires during the waiting period), changes in external interface returns (e.g., the external API returns different error codes), and biases in model parameter selection (e.g., different model parameters are used during shadow execution).

[0135] Step 4: Using the difference vector and difference source, update the context projection rules of the minimum feature context, the configuration of the isolated inference environment, or the risk score parameters of the execution control strategy.

[0136] Specifically, using the difference vector and difference source, update: Projection rules for minimal feature context: Adjust the projection range or sensitive field scanning rules.

[0137] Configuration of the isolated simulation environment: For example, for the API simulator, add new response samples; for the virtual browser, update the page structure cache, etc.

[0138] Risk scoring parameters for implementing control strategies: If differences caused by "changes in external interface returns" occur frequently, increase the weighting coefficient of external impact in the risk score.

[0139] Meanwhile, the system can also support rollbackable execution: for real execution marked as rollbackable, the real execution layer records a snapshot of the current state or starts a database / file system transaction before executing the action, and does not immediately commit the transaction after the action is executed, but waits for the confirmation signal from the differential backflow layer.

[0140] If the number of state change differences in the difference vector calculated by the difference backflow layer exceeds a preset difference tolerance threshold (e.g., 3), a rollback operation is triggered, undoing all side effects of the actual execution. The difference tolerance threshold is dynamically calculated based on the action type, resource category, and historical deviation distribution. For example, for file read operations, the tolerance threshold is set to 0 (no state change differences are allowed); for file write operations, the tolerance threshold is set to 2 (a small number of metadata differences are allowed).

[0141] In one specific implementation, the formula for calculating the difference tolerance threshold can be: Tolerance threshold = Base threshold × (1 + Historical deviation rate); The basic threshold is preset according to the action type: 0 for file reading, 2 for file writing, and 1 for API call; the historical deviation rate is the proportion of the difference vectors that exceed the current threshold in the past 10 similar operations.

[0142] As can be seen, by aligning real and shadow results, this application allows the system to continuously detect deviations between the simulated and real environments, and accordingly calibrate context projection, risk rules, shadow tools, and release strategies, thereby improving the accuracy of subsequent inferences. The rollback mechanism further reduces the irreversible losses that may result from misjudgments.

[0143] Furthermore, this application pre-defines differentiated rule correction strategies for different types of operations to ensure the correctness and effectiveness of the evolution direction. These rule correction strategies include: (1) For file operations, if the source of the deviation is "missed sensitive field type identification", then add new regular expression rules or classification samples to the sensitive information scanner, and expand the range of sensitive field type extraction in the resource summary from 512 bytes to 2048 bytes. This correction logic is based on the fact that in actual engineering, the sensitive header information of some configuration files or log files may appear in a deeper offset position. Although the initial 512-byte window can cover most scenarios, it will miss some files when facing specific format files. Dynamically expanding the scanning range is an adaptive means to improve the detection rate without significantly increasing I / O overhead.

[0144] (2) For browser-based operations, if the source of the deviation is "login state judgment error", the method of checking the existence of the login state will be expanded from only checking the Cookie validity period to checking both the Token signature and the associated permission bits. This is because the security mechanisms of modern Web applications are becoming increasingly complex, and the existence of Cookie alone is no longer sufficient to represent the true authentication state. Introducing signature verification and permission bit verification can enable the projection rules to keep up with the evolution of identity authentication protocols.

[0145] (3) For external API operations, if the source of the deviation is "return data type mismatch", the return data type field in the resource summary will be upgraded from an enumeration type (such as JSON / XML) to a Schema fragment containing an example response structure. Enumeration types can only describe the top-level format of the data and cannot express nested structures and field constraints, while Schema fragments preserve the contract details of the interface, enabling the deduction environment to more accurately simulate the data parsing and validation logic and reduce deduction failures caused by incorrect data structure assumptions.

[0146] To ensure the controllability and traceability of the rule evolution process, this application implements strict version management for the revised rules. This application stores the revised projection rules in a rule version repository, along with the current rule's version number and timestamp, allowing the latest version to be used preferentially in subsequent deductions. Therefore, each rule adjustment is not a simple overwrite of the old version, but rather the generation of a new version snapshot.

[0147] Example 7 Building upon Examples 1 to 6, this example further refines the end-to-end audit recording and tamper-proof playback mechanism. As one implementation method, the method also includes step S600: audit recording and playback. This step aims to transform the discrete data generated in the aforementioned stages into a structured chain of evidence with legal validity and engineering traceability value, thereby meeting enterprise-level compliance requirements and providing data support for continuous system optimization.

[0148] During the audit log assembly phase, the system assembles the following information into a complete audit log to construct a multi-dimensional reconstruction of the decision-making process: Standardized operation events (complete, including all fields), a summary of the minimal feature context (i.e., the anonymized context to avoid storing sensitive information), a serialized representation of the state change map (using Protocol Buffers or JSON format), the disposal decisions and justifications for the execution control policy, the actual execution results (anonymized), and the difference vector and calibration update log.

[0149] Among them, standardized operational events record "who triggered what action under what intent," serving as the starting point for tracing; the summary of the minimal feature context preserves a snapshot of the environment during the deduction, used to verify the rationality of the decision-making basis at that time, while avoiding compliance risks caused by storing complete sensitive data; the serialized representation of the state change graph (such as JSON-LD or Protobuf format) accurately solidifies the side effect topology identified during the deduction phase, serving as core evidence to explain "why the decision was made"; the disposal decisions and adjudication reasons of the execution control strategy clarify the system's control behavior and the rule hit or model reasoning process behind it; and the actual execution results serve as the endpoint of the closed loop, used for post-event comparison of the deduction accuracy.

[0150] By organically combining the above information, a single audit record becomes not only an operation log but also a self-contained, independently verifiable security decision-making unit. To ensure the credibility and non-repudiation of audit data, the audit replay index of the audit record can be stored in a blockchain, a signed log, or a remote audit service. Specifically: for heavily regulated scenarios such as finance and healthcare, consortium blockchains or private blockchains can be used as storage media, leveraging the distributed consensus and immutability of blockchain to provide judicial-grade electronic evidence for cross-organizational and cross-entity intelligent agent collaboration; for high-throughput enterprise internal operation and maintenance scenarios, digitally signed append-only log files can be used to maximize write performance and query efficiency while ensuring tamper resistance; for multi-tenant SaaS platforms, independent remote audit services can be accessed, and through physical isolation and dedicated personnel operation and maintenance, tenant administrators can be prevented from deleting or modifying audit records themselves. This diversified storage selection strategy allows this application to flexibly adapt to a full spectrum of needs, from lightweight development and testing to heavyweight production compliance.

[0151] Regarding data integrity protection, this application introduces a cryptographic-level anti-tampering mechanism. As one implementation, each audit record contains an auto-incrementing sequence number or hash chain pointer to support immutable retrospective traceability. Specifically, the hash chain pointer refers to the cryptographic hash value (such as SHA-256) of the previous audit record's content contained in the metadata of the current audit record. This chain structure ensures that any modification to a historical record will cause the hash verification of all subsequent records to fail, thus mathematically guaranteeing the integrity of the audit sequence. The auto-incrementing sequence number provides a monotonically increasing logical clock, which can assist in determining the order of operations even in a distributed environment. When auditors need to verify whether records within a certain period have been tampered with, they only need to recalculate the hash chain and compare it with the stored value; any minor modification will be detected immediately. This mechanism transforms the traditional "trust administrator" model into a "trust mathematical proof" model, significantly improving the credibility of audit data.

[0152] In terms of post-event tracing and link reconstruction, this application provides efficient retrieval and restoration capabilities. As one implementation method, upon receiving an audit query request, the system retrieves the corresponding audit records based on the session identifier or time range and reconstructs the operation execution link in chronological order. Specifically, when writing audit records, the system simultaneously constructs an inverted index with the session identifier as the key and a time-series index with the timestamp as the key, supporting millisecond-level multi-dimensional retrieval. During link reconstruction, the system not only displays the summary information of each audit record in sequence but also, in conjunction with an incremental compression mechanism, applies the incremental graph of the serialized state change map sequentially, dynamically reconstructing a complete system state view at any point in time. For example, when investigating a data breach, security analysts can quickly locate the relevant operation sequence through the session ID, view the state difference graph before and after each operation, the reasoning for the ruling at the time, and the actual execution feedback. They can also drill down through the graph nodes to view specific anonymized parameters and simulated evidence. This seamless penetration capability from macro-level links to micro-level evidence greatly shortens the time for root cause analysis of incidents and provides an intuitive visual basis for verifying the effectiveness of execution control strategies. Through the coordinated operation of the above-mentioned assembly, storage, anti-tampering and reconstruction mechanisms, this embodiment extends the operation execution control across heterogeneous intelligent agents from real-time security protection to post-event compliance auditing and continuous evolution, forming a complete security governance closed loop.

[0153] In a specific example, to more clearly illustrate the application value of this application in actual business scenarios, this embodiment provides a comprehensive application scenario of enterprise intelligent agent operation and maintenance diagnosis and external data interaction, illustrating the collaborative working process of the above steps.

[0154] In this application scenario, the enterprise operations and maintenance personnel issue an instruction to the intelligent agent: "Help me check the connection anomaly of a certain business system and compile the diagnostic results." To complete this task, the intelligent agent plans a series of cross-framework continuous action sequences: (1) read the local configuration file to obtain the database connection parameters; (2) call the external API interface to perform connection tests; (3) open the browser to access the business management backend to view the real-time connection status; (4) summarize the troubleshooting results and send them to the operations and maintenance personnel through an instant messaging tool.

[0155] Without adopting the solution proposed in this application, traditional security mechanisms typically only perform isolated whitelist verification or keyword filtering for each action, making it difficult to identify combined risks. For example, configuration files may contain plaintext passwords or internal IP addresses, which, if directly read and passed to subsequent processes, can easily lead to credential leakage; the management backend page may contain high-risk buttons such as "restart service" or "reset connection," which the agent may accidentally trigger due to semantic misunderstanding when parsing the page, resulting in production accidents; if the final diagnostic results are not anonymized and directly released, sensitive internal topology information or error logs may flow to uncontrollable external channels. These risks stem from the lack of unified extrapolation of the consequences of actions and the lack of refined control from a global perspective.

[0156] After adopting the cross-heterogeneous intelligent agent operation execution control method provided in this application, the above action sequence will undergo a complete security governance closed loop before entering the actual execution environment. This includes: In step S100, the heterogeneous access layer converts Shell commands, API requests, browser operations, and message sending instructions into standardized operation events in a unified format through an adapter. Regardless of whether the underlying layer is based on Python scripts, HTTP protocol, or WebDriver, all actions are normalized into structured objects containing standard fields such as action type, target resource identifier, parameter summary, and expected side effects, thereby shielding the semantic differences between different tool frameworks.

[0157] For example, operation 1 has an action type of file_read, a target resource identifier of / etc / app / config.ini, and a parameter digest of {"encoding":"utf-8"}. Operation 2 has an action type of api_call, a target resource of https: / / api.internal.com / health. Operation 3 has an action type of browser_click, a target resource of https: / / admin.internal.com / status, and a parameter digest of {"element":"#statusTab"}. Operation 4 has an action type of output_generate.

[0158] Subsequently, in step S200, the minimum context projection layer generates a minimum feature context for each standardized operation event. For file reading actions, the system does not copy the complete configuration file content, but extracts only the file type, path range, and writing target according to file class projection rules. It also uses a sensitive information scanner to identify sensitive field types such as "password" and "secret_key" in the file header through regular expression matching, but does not retain the specific field values. For browser access actions, the system only projects the page source URL, login status, and target button label, without transmitting complete cookie or token credentials. For API call actions, it only retains the target domain name, HTTP method, and parameter key set, stripping away the specific authentication token and business data.

[0159] Continuing the previous example, for operation 1, the resource digest only contains the file type "ini", the path range " / etc / app / ", and the sensitive field type "db_password" found by scanning the first 512 bytes, with the target being empty. For operation 2, the resource digest contains the domain name "api.internal.com", the method "GET", the parameter key name "[]", the authentication method "Bearer Token", and the return data type "JSON". For operation 3, the resource digest contains the page URL, the existence of login status (checking the cookie, a valid sessionid was found, indicating login), the target button label "statusTab", and the form field name "[]". The minimum feature context also includes historical risk score (the user has good credit, historical risk score of 15), permission boundaries (allowed to read configuration files under " / etc / app / "), etc.

[0160] In step S300, the shadow execution layer dynamically selects an isolated simulation environment and executes the simulation based on the risk level. Given that file reading involves sensitive fields and API calls involve external interactions, the system determines that the risk level is higher than a preset threshold and automatically selects a deep simulation unit. Specifically, for file reading, a desensitized file system is built in a temporary directory, creating a virtual copy with the same structure as the original file but with placeholders replacing the content, allowing the agent to parse the configuration format normally but not obtain real credentials; for API connection testing, an API simulator is started, returning preset status codes and delay data to verify the correctness of the call logic without generating real traffic; for browser access, a headless browser instance is started and a desensitized snapshot of the target page is loaded. This snapshot retains the DOM structure and form elements for interactive verification but removes dynamic scripts and real session data. During the simulation, the system keenly detected two key risk points: first, the simulated reading result of the configuration file contained field nodes marked as highly sensitive; second, the management backend snapshot contained a button labeled "RestartService," and the operation associated with this button was marked as irreversible in the graph.

[0161] The resulting state differences are then converted into a state change graph. In this graph, the configuration file node is marked as "highly sensitive", the restart button node is marked as "irreversible operation", and the edge pointing from the diagnostic result node to the external instant messaging interface is marked as "external influence range".

[0162] Continuing the previous example, Operation 1 has a low risk level (expected base side effect value of 20, historical risk of 15, and overall risk of 17). The de-identified file system is selected: a de-identified copy of config.ini is created in the temporary directory, replacing db_password=123456 with db_password=[REDACTED], and then a simulated read is performed, returning the de-identified content. Operation 2 has a medium risk level (expected base side effect value of 40, and overall risk of 35). The API simulator is selected, and the pre-recorded health check response returns {"status":"ok","latency_ms":120}. Operation 3 has a medium risk level (45). A virtual browser is selected, loading a de-identified snapshot of the background page (only the DOM structure is retained, and all scripts are removed). After execution, the status change graph shows: Operation 1 generates a "file read" edge, from the configuration file node to the output buffer node, marking reversibility as "fully reversible" (the read operation does not change the original file), and sensitivity as "medium" (because it contains the de-identified password field). Operation 2 generates a "network request" edge, marking the external impact scope as "internal domain" (does not trigger external markers). Operation 3 generates a "page browsing" edge and discovers a "restart service" button (sensitive operation) on the backend page. The node of this button is marked as "requires approval" in the graph.

[0163] Finally, in step S400, the release gate generates a refined execution control strategy based on the state change map.

[0164] The system extracts feature vectors from the graph, including sensitivity level, number of irreversible operations, and external impact markers, and calculates a comprehensive risk score by combining these with the session history risk score. Since the score falls between the first and second risk thresholds and includes external impacts and irreversible markers, the system does not simply block the task but instead outputs a combined response decision: For file reading operations, a "de-sensitization and allow" strategy is implemented, allowing the agent to obtain the configuration structure but automatically masking sensitive field values; For browser access actions, implement the "parameter rewriting" and "isolation execution" strategies, force the interaction mode to be limited to read-only viewing, and disable all button click events involving state changes; For the final result sending action, given its simultaneous sensitivity and external impact attributes, the system triggers a "manual approval" process and converts the status change graph into a visual approval interface, highlighting the sensitive field summary contained in the diagnostic report and the target address to be sent, so that the operation and maintenance personnel can confirm whether to allow the external release of the anonymized version.

[0165] In addition, standardized operational events, minimal context summaries, serialized representations of state change graphs, decision reasons, and actual execution results throughout the decision-making process are all assembled into audit records and written into an audit replay index with hash chain pointers to support post-event tamper-proof traceability and compliance review.

[0166] As can be seen from the complete application process described above, this application, when facing complex intelligent agent tasks involving cross-framework and multiple steps, can break down tool barriers through standardization and normalization, ensure the security of inference data through minimal context projection, expose potential side effects in advance through deep simulation in isolated environments, and achieve a dynamic balance of "ensuring both security and business" through a refined strategy driven by state change graphs. Compared with the isolated, static, and coarse-grained protection methods in existing technologies, the technical solution demonstrated in this embodiment significantly improves the operational security and controllability of intelligent agent systems in real production environments, fully verifying the inventive value and practical prospects of this application. It should be understood that the above operation and maintenance diagnosis scenario is only an illustrative example. In other embodiments, this application is also applicable to various intelligent agent application scenarios involving cross-system interaction and sensitive data processing, such as code generation and submission, data analysis and report export, customer service and work order processing, as long as the end-to-end governance logic from heterogeneous action normalization to controlled execution is met, it should be covered within the protection scope of this application.

[0167] Example 8 Corresponding to the above method, embodiments of this application also provide an operation execution control device for heterogeneous intelligent agents, such as... Figure 3 As shown, the device includes: The conversion unit 310 is used to convert the operation to be executed received from the heterogeneous intelligent agent into a standardized operation event of a unified format; The acquisition unit 320 is used to acquire the minimum feature context for inference based on the standardized operation event, wherein the minimum feature context is a non-sensitive summary feature stripped of the complete original data; Execution unit 330 is used to execute the operation to be executed based on the minimum feature context in an isolated simulation environment; The conversion unit 310 is also used to convert the state differences generated by the execution into a state change map; The generation unit 340 is used to generate an execution control strategy for the real execution environment based on the standardized operation event, the minimum feature context and the state change map, so as to control the execution of the operation to be executed in the real execution environment.

[0168] The functions of each functional unit of the cross-heterogeneous intelligent agent operation execution control device provided in the above embodiments of this application can be implemented through the above method steps. Therefore, the specific working process and beneficial effects of each unit in the cross-heterogeneous intelligent agent operation execution control device provided in the embodiments of this application will not be repeated here.

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

[0170] Memory 430 is used to store computer programs; When the processor 410 executes the program stored in the memory 430, it performs the following steps: It converts the operations to be executed received from heterogeneous intelligent agents into standardized operation events in a unified format; Based on the standardized operation events, a minimal feature context for inference is obtained, wherein the minimal feature context is a non-sensitive summary feature stripped of the complete original data; In the isolated simulation environment, the operation to be executed is performed based on the minimum feature context, and the resulting state differences are converted into a state change map. Based on the standardized operation events, the minimum feature context, and the state change graph, an execution control strategy is generated for the real execution environment to control the execution of the operation to be executed in the real execution environment.

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

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

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

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

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

[0176] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the operation execution control method for cross-heterogeneous intelligent agents as described in any of the above embodiments.

[0177] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the operation execution control method for cross-heterogeneous intelligent agents described in any of the above embodiments.

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

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

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

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

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

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

Claims

1. A method for operation execution control across heterogeneous intelligent agents, characterized in that, The method includes: It converts the operations to be executed received from heterogeneous intelligent agents into standardized operation events in a unified format; Based on the standardized operation events, a minimal feature context for inference is obtained, wherein the minimal feature context is a non-sensitive summary feature stripped of the complete original data; In the isolated simulation environment, the operation to be executed is performed based on the minimum feature context, and the resulting state differences are converted into a state change map. Based on the standardized operation events, the minimum feature context, and the state change graph, an execution control strategy is generated for the real execution environment to control the execution of the operation to be executed in the real execution environment.

2. The method as described in claim 1, characterized in that, Based on the standardized operation events, the minimum feature context for inference is obtained, including: Based on the operation type indicated by the standardized operation event, determine the corresponding context projection rule; According to the context projection rules, the user target, permission boundary and resource summary are extracted from the original data associated with the operation to be executed to obtain the minimum feature context; The minimum feature context does not include the complete session data and complete tool return data in the original data.

3. The method as described in claim 2, characterized in that, In the isolated simulation environment, the operation to be executed is performed based on the minimum feature context, including: A simulation unit is determined based on the action type, risk level, and resource category in the minimal feature context of the standardized operation event; The operation to be executed is performed or the operation to be executed is simulated in the simulation unit to generate simulation execution results.

4. The method as described in claim 1, characterized in that, Converting state differences into a state change map specifically includes: By comparing the internal state snapshots of the operation to be executed before and after execution in the isolated simulation environment, the changed entities and the operational relationships between entities are identified, and a state change map is generated. In the state change graph, nodes represent entities whose resources or states are affected by the operation to be performed, and edges represent the operational relationships between entities.

5. The method as described in claim 4, characterized in that, The nodes or edges in the state change graph are marked with operation influence attributes that characterize the degree of side effects of the operation to be performed on the real execution environment; The operational impact attributes include at least one of the following: reversibility index, sensitivity index, and external impact range index.

6. The method as described in claim 5, characterized in that, The method further includes: Based on the operation impact attributes, an operation causal path representing the operation transmission logic is generated; The causal path of the operation is associated with the state change graph.

7. The method as described in claim 5, characterized in that, Generate execution control policies for the actual execution environment, including: Based on the operation influence attributes in the state change graph and the predefined policy rules, an execution control policy is output. The execution control strategy includes line release, desensitization release, parameter rewriting, output rewriting, manual approval, isolation execution, blocking, delayed release, or secondary deduction. The strategy rules are stored in the rule engine in the form of condition-action pairs. The condition part references the node metadata or edge metadata in the state change graph, and the action part specifies the disposal decision of the output.

8. The method as described in claim 3, characterized in that, The method further includes: Obtain the actual execution result of the operation to be executed in the real execution environment; The actual execution results are compared with the simulated execution results, and a difference vector is calculated; the difference vector includes at least the differences in result content, differences in state changes, and differences in performance. Based on the difference vector, identify the source of the difference; the source of the difference includes incomplete simulation, changes in the actual business status, changes in permission boundaries, changes in external interface returns, or deviations in model parameter selection. Using the difference vector and difference source, update the context projection rule of the minimum feature context, the configuration of the isolation inference environment, or the risk score parameters of the execution control strategy.

9. The method as described in claim 1, characterized in that, After converting the state differences generated by the execution into a state change map, the method further includes: The state change map is incrementally compressed and stored. The incremental compression storage includes: for multiple consecutive operations to be executed under the same session identifier, the state change map generated by each operation to be executed is stored as an incremental map, and the incremental map only records the changes in the state change map of the current operation relative to the previous operation; the incremental map uses a node addition set, a node deletion set, an edge addition set, an edge deletion set, and an attribute modification list to encode state differences.

10. A cross-heterogeneous intelligent agent operation execution control device, characterized in that, The device includes: The conversion unit is used to convert the operations to be executed received from heterogeneous intelligent agents into standardized operation events in a unified format; The acquisition unit is used to acquire the minimum feature context for inference based on the standardized operation event, wherein the minimum feature context is a non-sensitive summary feature stripped of the complete original data; An execution unit is used to execute the operation to be executed based on the minimum feature context in an isolated simulation environment; The conversion unit is also used to convert the state differences generated by the execution into a state change map; The generation unit is used to generate an execution control strategy for the real execution environment based on the standardized operation events, the minimum feature context, and the state change map, so as to control the execution of the operation to be executed in the real execution environment.

Images