Agent execution control method and device, electronic equipment, storage medium and product

Abstract

The present disclosure relates to an agent execution control method and device, electronic equipment, storage medium and product. The method comprises: obtaining a to-be-executed command output by a target agent and a corresponding command execution context; building a controlled execution environment in a host corresponding to the target agent according to the command execution context, and generating an initialized controlled file system view in the controlled execution environment; executing the to-be-executed command in the controlled execution environment based on the initialized controlled file system view; obtaining an updated controlled file system view when the to-be-executed command is executed; determining file system change information according to changes of the updated controlled file system view relative to the initialized controlled file system view; determining execution risk information of the to-be-executed command according to the file system change information; and controlling execution of the to-be-executed command in the host according to the execution risk information. The method significantly improves the risk judgment accuracy of the to-be-executed command.

Description

Technical Field

[0001] This disclosure relates to the field of operating systems, and more particularly to a method, apparatus, electronic device, storage medium, and product for intelligent agent execution control. Background Technology

[0002] With the increasing application of large language models and AI agents in edge computing scenarios, more and more systems are allowing models to directly generate shell commands and attempt to execute them in the local operating system environment. These systems are typically used for tasks such as code generation, building, file organization, environment maintenance, log collection, and system configuration. To ensure execution security, the execution risks are usually assessed before the command is actually executed, often by analyzing the command text.

[0003] However, due to the strong environment dependency and side effect propagation capabilities of shell commands, a seemingly simple command may ultimately affect a target object significantly different from the one judged by the original text due to factors such as variable expansion, wildcard matching, symbolic link jumps, relative path resolution, script indirect calls, changes in the current directory, and differences in user permissions. Therefore, relying solely on the original command text to infer execution risks is likely insufficient in accuracy. Although some related technologies involve pre-running commands in isolated environments such as sandboxes and observing intermediate behaviors such as system calls, file access, or network access during the pre-run to determine execution risks, this method still struggles to directly generate evidence of the final side effects on the host machine's logical path. Consequently, it is difficult to use this as a direct basis for AI command approval, confirmation, or blocking, and since the success of these actions is unknown, the accuracy may still be insufficient. Summary of the Invention

[0004] This disclosure provides an intelligent agent execution control method, apparatus, electronic device, storage medium, and product to at least address the problem of how related technologies can reliably obtain direct evidence of allowing, confirming, or blocking AI commands.

[0005] According to a first aspect of the present disclosure, an intelligent agent execution control method is provided, comprising: acquiring a command to be executed output by a target intelligent agent and its corresponding command execution context; establishing a controlled execution environment in a host machine corresponding to the target intelligent agent based on the command execution context, and generating an initialized controlled file system view in the controlled execution environment; executing the command to be executed in the controlled execution environment based on the initialized controlled file system view; acquiring an updated controlled file system view when the execution of the command to be executed has ended; determining file system change information based on the change of the updated controlled file system view relative to the initialized controlled file system view; determining execution risk information of the command to be executed based on the file system change information; and controlling the execution of the command to be executed in the host machine based on the execution risk information.

[0006] Optionally, the controlled file system view is a controlled union file system view. The initialized controlled file system view includes a lower-level read-only directory and an empty upper-level writable directory. The updated controlled file system view includes the lower-level read-only directory and the updated upper-level writable directory. The step of determining file system change information based on the changes of the updated controlled file system view relative to the initialized controlled file system view includes: determining the logical path that has changed and the change type of the logical path by comparing the updated upper-level writable directory and the lower-level read-only directory, and obtaining the file system change information. The change type includes at least one of the following: addition, modification, deletion, and metadata change.

[0007] Optionally, the command execution context includes a controlled root path, and generating an initialized controlled file system view in the controlled execution environment includes: when the controlled root path is the system root directory, binding the system root directory in read-only mode in the controlled execution environment; and generating an initialized controlled union file system view for each top-level subdirectory under the system root directory to obtain the initialized controlled file system view.

[0008] Optionally, determining the execution risk information of the command to be executed based on the file system change information includes: obtaining risk rule information, wherein the risk rule information includes multiple risk rules and their corresponding risk levels, each risk rule including a preset logical path and a preset change type; performing rule matching processing on the file system change information and the multiple risk rules; and, if a risk rule consistent with the file system change information is matched from the multiple risk rules, determining the execution risk information of the command to be executed based on the risk level corresponding to the matched risk rule, wherein the preset logical path in the matched risk rule is consistent with the changed logical path, and the preset change type in the matched risk rule is consistent with the change type of the changed logical path.

[0009] Optionally, the step of building a controlled execution environment in the host machine corresponding to the target agent according to the command execution context, and generating an initialized controlled file system view in the controlled execution environment, includes: obtaining execution semantics extracted from the command to be executed and the command execution context, wherein the execution semantics are used to describe the constraints that the command must follow when it is actually running in the host machine; building a general controlled execution environment in the host machine; generating a basic controlled file system view in the general controlled execution environment according to the command execution context; and adapting and adjusting the general controlled execution environment and the basic controlled file system view according to the execution semantics to obtain the controlled execution environment and the initialized controlled file system view.

[0010] Optionally, the execution semantics include the call semantics extracted from the command to be executed, the environment semantics extracted from the command execution context, and the working directory semantics. The step of adapting and adjusting the general controlled execution environment and the basic controlled file system view according to the execution semantics to obtain the controlled execution environment and the initialized controlled file system view includes: adapting and adjusting the command load operation mode of the general controlled execution environment according to the call semantics; adapting and adjusting the environment execution context of the general controlled execution environment according to the environment semantics to obtain the controlled execution environment; and adapting and adjusting the directory attributes of the basic controlled file system view according to the working directory semantics to obtain the initialized controlled file system view.

[0011] According to a second aspect of the present disclosure, an intelligent agent execution control device is provided, comprising: an acquisition unit configured to acquire a command to be executed output by a target intelligent agent and its corresponding command execution context; a construction unit configured to construct a controlled execution environment in a host machine corresponding to the target intelligent agent based on the command execution context, and generate an initialized controlled file system view in the controlled execution environment; an execution unit configured to execute the command to be executed in the controlled execution environment based on the initialized controlled file system view; an update unit configured to acquire an updated controlled file system view when the execution of the command to be executed ends; a change determination unit configured to determine file system change information based on the change of the updated controlled file system view relative to the initialized controlled file system view; a risk determination unit configured to determine execution risk information of the command to be executed based on the file system change information; and a control unit configured to control the execution of the command to be executed in the host machine based on the execution risk information.

[0012] Optionally, the controlled file system view is a controlled union file system view. The initialized controlled file system view includes a lower-level read-only directory and an empty upper-level writable directory. The updated controlled file system view includes the lower-level read-only directory and the updated upper-level writable directory. The change determination unit is further configured to determine the logical path that has changed and the change type of the logical path by comparing the updated upper-level writable directory and the lower-level read-only directory, and obtain the file system change information. The change type includes at least one of the following: addition, modification, deletion, and metadata change.

[0013] Optionally, the command execution context includes a controlled root path, and the building unit is further configured to: when the controlled root path is the system root directory, bind the system root directory in read-only mode in the controlled execution environment; and generate an initialized controlled union file system view for each top-level subdirectory under the system root directory to obtain the initialized controlled file system view.

[0014] Optionally, the risk determination unit is further configured to: acquire risk rule information, wherein the risk rule information includes multiple risk rules and their corresponding risk levels, each risk rule including a preset logical path and a preset change type; perform rule matching processing on the file system change information and the multiple risk rules; and, if a risk rule consistent with the file system change information is matched from the multiple risk rules, determine the execution risk information of the command to be executed based on the risk level corresponding to the matched risk rule, wherein the preset logical path in the matched risk rule is consistent with the changed logical path, and the preset change type in the matched risk rule is consistent with the change type of the changed logical path.

[0015] Optionally, the building unit is further configured to: obtain execution semantics extracted from the command to be executed and the command execution context, wherein the execution semantics are used to describe the constraints that the command must follow when it is actually running in the host machine; build a general controlled execution environment in the host machine; generate a basic controlled file system view in the general controlled execution environment according to the command execution context; and adapt and adjust the general controlled execution environment and the basic controlled file system view according to the execution semantics to obtain the controlled execution environment and the initialized controlled file system view.

[0016] Optionally, the execution semantics include the call semantics extracted from the command to be executed, the environment semantics extracted from the command execution context, and the working directory semantics. The building unit is further configured to: adapt and adjust the command load operation mode of the general controlled execution environment according to the call semantics; adapt and adjust the environment execution context of the general controlled execution environment according to the environment semantics to obtain the controlled execution environment; and adapt and adjust the directory attributes of the basic controlled file system view according to the working directory semantics to obtain the initialized controlled file system view.

[0017] According to a third aspect of the present disclosure, an electronic device is provided, comprising: at least one processor; and at least one memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, cause the at least one processor to perform an intelligent agent execution control method according to an exemplary embodiment of the present disclosure.

[0018] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause at least one processor to perform an intelligent agent execution control method according to an exemplary embodiment of the present disclosure.

[0019] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by at least one processor, cause at least one processor to perform an intelligent agent execution control method according to an exemplary embodiment of the present disclosure.

[0020] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: According to the intelligent agent execution control method, device, electronic device, storage medium and product of this disclosure, instead of using the existing command text itself or general behavior sequence as the basis for risk prediction, a controlled execution environment and a controlled file system view are constructed before the actual execution of the command for command pre-running. This allows for the prior acquisition of which host machine logical paths the command will ultimately act on and what file system changes will occur to these logical paths. This elevates the basis for risk judgment of the command to be executed from "text inference" to "evidence of the final target object", thereby significantly improving the accuracy of risk judgment and providing reliable direct evidence for whether or not to allow the command to be executed.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0023] Figure 1 This is a flowchart of an intelligent agent performing a control method according to an exemplary embodiment of the present disclosure.

[0024] Figure 2 This is an execution system architecture diagram of an intelligent agent execution control method according to a specific embodiment of the present disclosure.

[0025] Figure 3 This is a flowchart of an intelligent agent performing a control method according to a specific embodiment of the present disclosure.

[0026] Figure 4 This is a block diagram of an intelligent agent execution control device according to exemplary embodiments of the present disclosure.

[0027] Figure 5 This is a block diagram of an electronic device according to exemplary embodiments of the present disclosure. Detailed Implementation

[0028] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0029] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0030] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0031] In existing engineering practices, there are generally two approaches to security control of AI-generated commands.

[0032] The first approach is static matching based on command text. After receiving the command string, the system first performs word segmentation to extract the basic command name, parameters, and explicit paths. Then, it uses keywords, regular expressions, and blacklists or whitelists of dangerous commands to evaluate the extracted information. For example, if the command contains keywords such as `rm-rf`, `chmod`, `chown`, or `systemctl`, the system directly increases the risk level; or it determines whether the command will reach sensitive directories based on the explicitly stated absolute path. The advantages of this approach are its simplicity, low execution cost, and lack of additional permissions, making it easy to integrate into chat terminals, automated operation and maintenance tools, and AI agent frameworks. The disadvantage is that its judgment results depend on the text itself and are difficult to reflect the final impact of the command in a real-world environment. For example, a dangerous path may not be explicitly stated in the command, but it may still reach sensitive directories after script execution, variable expansion, or permission switching.

[0033] The second approach is to execute commands within a sandbox. Existing sandbox solutions typically utilize mechanisms such as Linux namespaces, containers, virtual machines, or file system snapshots to limit the actual impact of commands on the host environment. This approach primarily addresses the issue of "isolated execution," meaning that even if a command itself is dangerous, its side effects are kept within a controlled environment to avoid directly contaminating the host system. While some technologies involve observing intermediate behaviors such as system calls, file accesses, or network accesses during isolated execution to assess execution risk, this method still struggles to directly establish evidence of the final side effects along the logical path to the host machine. Consequently, it is difficult to use this as a direct basis for allowing, confirming, or blocking AI commands. Furthermore, since the success of these actions is unknown, the accuracy may still be insufficient.

[0034] Hereinafter, with reference to the accompanying drawings, a method, apparatus, electronic device, storage medium, and product for performing control tasks by an intelligent agent according to exemplary embodiments of the present disclosure will be described in detail.

[0035] Figure 1 This is a flowchart of an intelligent agent performing a control method according to an exemplary embodiment of the present disclosure.

[0036] Reference Figure 1 In step 101, the command to be executed output by the target agent and its corresponding command execution context are obtained.

[0037] The command to be executed is a command generated by the agent, such as, but not limited to, shell commands (a command-line interpretation environment used to receive, parse and execute terminal commands), which can be used to perform corresponding operations in the operating system environment, and may include the command itself, command prefix, call chain, startup mode, etc.

[0038] The command execution context is the set of external environment and state in which a command is executed. It is the "conditions given by the environment", such as the controlled root path, the current working directory, and user permissions.

[0039] In the above concepts, the controlled root path is the root directory set for the controlled runtime of a command. It is used to replace the real system root directory, so that the command can only be executed within the scope of that root directory, thereby limiting the executable scope of the command.

[0040] The current working directory is a specific directory under the controlled root directory, used to specify the exact location in the file system where commands are executed. Since commands are essentially used to process data, and data is carried by files, the file system can be considered the object of the command's action, and the command must specify the specific file path it processes. This specific file path can include absolute paths and relative paths. Absolute paths start from the root directory, while relative paths start from the current working directory. For example, for the absolute path ` / home / xxx / file.txt`, if the current working directory is ` / home / xxx`, then the corresponding relative path is `file.txt`.

[0041] User permissions refer to the identity of the account that runs the command, and the file access and system operation permissions that identity possesses. File access permissions include, but are not limited to, read, write, and execute permissions, while system operation permissions include, but are not limited to, process creation permissions, directory access permissions, resource access permissions, and account operation permissions.

[0042] In step 102, a controlled execution environment is built on the host machine corresponding to the target agent according to the command execution context, and an initialized controlled file system view is generated in the controlled execution environment.

[0043] Controlled execution environments, including but not limited to sandboxes, containers, virtual machines, system snapshots, or other execution environments with state isolation and reclaimability, can provide an isolated pre-running environment for commands to be executed. This allows the commands to be pre-run before they actually run on the host machine, preventing them from directly affecting the real host machine.

[0044] As examples, typical methods for setting up a sandbox include: 1. Creating an isolated directory or container runtime environment; 2. Restricting commands to an independent root file system view through methods such as namespaces or chroot (change root). Furthermore, the sandbox method destroys the isolated environment after executing commands, thereby reducing the direct damage to the host machine caused by dangerous commands.

[0045] A controlled file system view is a temporary file system runtime environment that is actually entered and run during command pre-running, and which is as close as possible to the real file system path relationships.

[0046] In step 103, in a controlled execution environment, the command to be executed is executed based on the initialized controlled file system view.

[0047] This step executes the command pre-run described above. During the pre-run, operations are performed on the initialized controlled file system view, causing changes to that view.

[0048] In step 104, after the execution of the command to be executed has ended, an updated view of the controlled file system is obtained.

[0049] This step retrieves the changed view.

[0050] In step 105, file system change information is determined based on the changes in the updated controlled file system view relative to the initialized controlled file system view.

[0051] This step directly obtains changes to the host machine's file system by comparing changes in the controlled file system view, reducing reliance on interpreting intermediate access actions during command execution, such as, but not limited to, what files were opened, what paths were attempted to be written, and which system calls were invoked.

[0052] In step 106, the execution risk information of the command to be executed is determined based on the file system change information.

[0053] Execution risk information can be viewed as an evidence-based interpretation of risk given before the formal execution of an order.

[0054] As an example, to control the execution of commands to be executed, in addition to using execution risk information as a basis, other auxiliary means can be configured. Other auxiliary means include, but are not limited to, degradation strategies and auditing: when the pre-running link is unavailable, execution is abnormal, or observation results are insufficient, degradation control can be performed according to preset security policies to reduce the risk of losing control boundaries in the absence of reliable evidence; key audit information during command processing can also be recorded for subsequent backtracking and strategy optimization.

[0055] In step 107, the execution of the command to be executed on the host machine is controlled based on the execution risk information.

[0056] At this step, the exemplary embodiments of this disclosure form a closed loop from command pre-running, file system change observation, risk assessment to actual execution control. As an example, the above-mentioned steps in this closed loop can be kept in series during actual execution, or they can be adjusted to a parallel or pipelined manner according to actual implementation needs, and this disclosure does not impose any restrictions on this.

[0057] The intelligent agent execution control method according to the exemplary embodiments of this disclosure does not use the existing command text itself or general behavior sequence as the basis for risk prediction. Instead, before the actual execution of the command, it constructs a controlled execution environment and a controlled file system view for command pre-running. This allows it to obtain in advance which host machine logical paths the command will ultimately affect and what file system changes will occur to these logical paths. This elevates the basis for risk judgment of the command to be executed from "text inference" to "evidence of the final target object", thereby significantly improving the accuracy of risk judgment and providing reliable direct evidence for whether to allow the command to be executed.

[0058] As an example, this method can be deployed in a local host scenario and includes client-server interaction in the system architecture. The client side can be an interactive terminal, a shell main program, or an AI Agent scheduling module; the server side can be a controlled service component and its execution unit. In scenarios where the client process is not suitable for directly constructing a controlled execution environment, the controlled service component can take over the relevant operations in the form of a privileged service process or a daemon process. The client submits a pre-run request (which may include the command to be executed) and the relevant command execution context through a local inter-process communication mechanism, which is then received and processed by the server-side controlled service component. Alternatively, systemd (system daemon process), RPC (Remote Procedure Call), message queues, or other controlled proxy mechanisms can be used to implement controlled requests and execution of privileged operations by non-privileged processes; this disclosure does not impose any limitations on this.

[0059] The following section will provide further information regarding file system change details.

[0060] Optionally, the controlled file system view is a controlled union file system view. The initialized controlled file system view includes a lower-level read-only directory and an empty upper-level writable directory. The updated controlled file system view includes a lower-level read-only directory and an updated upper-level writable directory. Step 105 includes: by comparing the updated upper-level writable directory and the lower-level read-only directory, determining the changed logical path and the change type of the logical path, and obtaining file system change information. The change type includes at least one of the following: addition, modification, deletion, and metadata change. Since the lower-level directory (root directory) remains read-only and the upper-level directory inherits the write and deletion changes generated during the pre-run, after the pre-run is completed, the corresponding logical path-level side effects can be easily extracted by comparing the upper and lower levels. These side effects include, but are not limited to, logical path-level additions, modifications, deletions, and metadata changes, thereby obtaining logical path-level change results that are closer to the host machine's cognitive approach, forming structured side effect evidence that can be used for risk assessment of the command to be executed. Meanwhile, this construction method uses the actual host root directory as a read-only underlying layer, and uses a temporary upper-level directory to handle write changes. This ensures that commands run as close to the actual path relationships as possible during pre-running, while limiting and converging side effects within an observable temporary layer. Therefore, it maintains the authenticity of path semantics, avoids directly polluting the host environment, and supports subsequent differential extraction, thus guaranteeing the observability of side effects. It should be understood that a union file system view is a file system view built based on union file system technology, including but not limited to OverlayFS (Overlay Filesystem) technology.

[0061] As an example, if the changed logical path exists in the upper-level writable directory but not in the lower-level read-only directory, the change type is determined to be "addition"; if the changed logical path exists in both the upper and lower levels, the change type is determined to be "modification"; if the changed logical path appears as a deletion in the union file system view, the change type is determined to be "deletion"; if the changed logical path does not change the path itself but its metadata, the change type is determined to be "metadata change". Metadata includes, but is not limited to, attribute fields such as file permissions, owner identifier, and group identifier, and may also include deletion flags, hierarchical mount identifiers, etc.

[0062] As an example, metadata changes can be used to further identify changes related to file or directory control attributes. For instance, attribute fields in the metadata of an upper-level writable directory and a lower-level read-only directory can be compared. If the value of any field in the attribute field is inconsistent, it can be determined that the control attribute has changed.

[0063] As an example, the change path of the upper-level writable directory relative to the lower-level read-only directory can be normalized into a logical path relative to the controlled root path, forming a structured set of logical path-level side effects.

[0064] Different scenarios can be distinguished depending on whether the controlled root path is the system root directory. For ordinary controlled root path scenarios, optionally, the step 102 of generating an initialized controlled file system view in the controlled execution environment includes: when the controlled root path is not the system root directory, using the controlled root path as the lower-level read-only directory and the temporary directory as the empty upper-level writable directory to obtain an initialized controlled file system view.

[0065] For the system root directory scenario, optionally, step 102, generating an initialized controlled file system view in the controlled execution environment, includes: binding the system root directory in read-only mode in the controlled execution environment when the controlled root path is the system root directory; and generating an initialized controlled union file system view for each top-level subdirectory under the system root directory, thus obtaining the initialized controlled file system view. Since different Linux operating systems such as Debian, Ubuntu, and CentOS have different mounting methods, directly performing a single union mount on the entire system root directory may cause compatibility issues. By first binding the system root directory in read-only mode and then establishing controlled union file system views for each top-level subdirectory, compatibility with different operating systems can be improved, and the commands to be executed can maintain operating conditions as close as possible to the real environment during pre-running, obtaining the root directory structure and path semantics of the real host machine as much as possible.

[0066] For risk assessment based on logical path-level file system change information (including the aforementioned changed logical paths and the change types of those logical paths), step 106 optionally includes: obtaining risk rule information, wherein the risk rule information includes multiple risk rules and their corresponding risk levels, and each risk rule includes a preset logical path and a preset change type; performing rule matching processing on the file system change information and the multiple risk rules; and, if a risk rule consistent with the file system change information is matched from the multiple risk rules, determining the execution risk information of the command to be executed based on the risk level corresponding to the matched risk rule, wherein the preset logical path in the matched risk rule is consistent with the changed logical path, and the preset change type in the matched risk rule is consistent with the change type of the changed logical path. By directly using logical path-level file system change information as rule matching input to generate execution risk information for the command to be executed, the output results are more stable, easier to interpret, easier to audit, and more suitable as the basis for determining execution actions before actual execution, thus improving the controllability of the command to be executed before actual execution.

[0067] As an example, different risk levels can correspond to different execution actions, which may include at least one of the following in ascending order of risk level: allow execution, require confirmation, or block execution.

[0068] As an example, the following risk rules can be configured.

[0069] 1. Regarding / etc / Write and delete operations under the specified path are all considered high-risk and will be blocked.

[0070] 2. Regarding / home / Write and delete operations under the specified path are classified as medium risk and require user confirmation.

[0071] 3. Regarding / tmp / Write and delete operations under the specified path are considered low-risk and can be executed directly.

[0072] As an example, in addition to the risk level, the execution risk information may also include other information, such as explanatory information about the risk, and this disclosure does not limit this.

[0073] The following section will further introduce the construction of the controlled execution environment and the controlled file system view.

[0074] In building a controlled execution environment, related technologies typically involve statically writing the command execution context of the command to be executed into the environment to set the controlled root path, working directory, and user permissions. The exemplary embodiments of this disclosure can use this method to build a controlled execution environment and generate an initialized controlled file system view using the methods of the aforementioned embodiments. However, if the command to be executed depends on specific startup methods, prefixes, or call links, the execution results in the controlled execution environment may differ from those in the real environment, leading to missed side effects.

[0075] To address the issue of missed side effect detection under the aforementioned special circumstances, step 102 may optionally include: obtaining execution semantics extracted from the command to be executed and the command execution context, wherein the execution semantics describe the constraints that the command must adhere to during actual execution on the host machine; building a general controlled execution environment on the host machine; generating a basic controlled file system view in the general controlled execution environment based on the command execution context; and adapting and adjusting the general controlled execution environment and the basic controlled file system view according to the execution semantics to obtain a controlled execution environment and an initialized controlled file system view. By first building a general controlled execution environment and generating a basic controlled file system view within it, and then adapting and adjusting the built environment and view according to the execution semantics of the command to be executed and its command execution context, a controlled execution environment and a controlled file system view can be constructed that neither directly pollutes the host environment nor fails to maintain the true execution semantics as much as possible. This enables dynamic configuration of the environment and view based on the specific semantics of the command to be executed, thereby effectively reducing the execution semantic deviation caused by the default configuration of the controlled execution environment, reducing the risk of missed side effect detection due to semantic deviation, and improving the consistency between pre-run results and actual execution results. It should be understood that the extraction of execution semantics can be performed between steps 101 and 102.

[0076] Optionally, execution semantics include invocation semantics extracted from the command to be executed, environment semantics extracted from the command execution context, and working directory semantics.

[0077] Among these execution semantics, invocation semantics is a set of rules used to define the startup method and process relationship of a command to be executed. It can be extracted from the command's call chain, prefix, startup entry point, and parent process information, including but not limited to command startup prefixes, privilege escalation markers (e.g., sudo), call subject, process type, execution mode, and start / stop method. Invocation semantics can be used to adjust the command payload execution mode of the basic controlled execution environment (payload refers to the command to be executed and its parameters, scripts, data, etc.; execution mode refers to the way the command is loaded, started, and scheduled), replicating the original startup logic of the command and reducing the risk of deviations in command execution results and process behavior due to different startup methods. As an example, the sudo prefix in a command can be identified, and the literal form of sudo can be removed during pre-running, but the privilege escalation semantics are not discarded; instead, execution is simulated according to the corresponding privilege semantics, thereby observing side effects that more closely resemble real high-privilege execution.

[0078] Environment semantics is a set of rules used to define the external environment in which a command to be executed runs. These rules include, but are not limited to, environmental constraints such as run identity, access permissions, environment variables, resource limits, network configuration, and basic path rules. Environment semantics can be used to modify the default configuration of a general controlled execution environment, adjust its execution context, align the controlled execution environment with the real execution environment, and reduce command-line behavior anomalies caused by inconsistencies in permissions, identities, and variables.

[0079] Working directory semantics is a set of rules used to define the directory attributes of a file system view, including but not limited to directory read / write permissions, ownership, and path resolution rules. Working directory semantics can be used to adjust the directory attributes of the underlying controlled file system view, aligning them with the directory attributes of the file system in the actual execution environment. This ensures that operations on the controlled file system are executable and helps extract more realistic file system change information in subsequent steps. For example, directory attributes can be modified, such as the owner / group and permission bits, to maintain consistency with the real environment as much as possible. Special directory semantics can also be preserved; for example, directories like ` / tmp` often have special permission semantics in the real system, and these semantics should be retained during pre-running. Otherwise, some commands that can create temporary files in the real environment may not be able to do so in pre-running. Permissions of upper-level writable directories can also be adjusted. For example, making the upper-level writable directory that receives changes during pre-running writable directory writable by the actual executing user ensures that any additions, modifications, or deletions made by commands are actually recorded in the observable upper-level writable directory, rather than failing due to insufficient permissions.

[0080] Accordingly, step 102 involves adapting and adjusting the general controlled execution environment and the basic controlled file system view according to execution semantics to obtain the controlled execution environment and the initialized controlled file system view. This includes: adapting and adjusting the command load operation mode of the general controlled execution environment according to call semantics, and adapting and adjusting the environment execution context of the general controlled execution environment according to environment semantics to obtain the controlled execution environment; and adapting and adjusting the directory attributes of the basic controlled file system view according to working directory semantics to obtain the initialized controlled file system view.

[0081] Next, combine Figure 2 and Figure 3 This disclosure introduces a smart agent execution control method based on specific embodiments.

[0082] This specific embodiment proposes a controlled pre-running side effect observation and execution control method for AI-generated commands, where the command to be executed is an AI-generated command. This method takes the premise that "it is difficult to determine the final side effects of AI-generated commands based solely on text," and follows a main thread of "first constructing a controlled file system view, then extracting a logical path-level side effect set, and finally performing execution control based on the side effect results." It forms a complete processing chain around command acquisition, execution semantic recognition, controlled file system view construction, side effect extraction, risk rule matching, and actual execution control.

[0083] In this specific embodiment, the method is primarily applied to AI interactive command-line scenarios on local host terminals. In this scenario, the system receives shell commands generated by the AI ​​model. Before actual execution, it constructs a controlled execution environment and a controlled file system view based on namespace isolation and union file system mechanisms to pre-run the AI-generated command. The main purpose of this pre-run is not to obtain the final business result, but to observe the potential file system side effects of the command on the host machine's logical path while preserving the actual execution semantics as much as possible. The system then outputs the corresponding execution control results based on the side effect set and risk rule configuration.

[0084] The execution system of this specific embodiment is as follows: Figure 2 As shown, the process can be divided into two parts: the client side and the server side. Functionally, the client side mainly includes: a command acquisition and normalization unit, a sandbox scheduling unit, an execution control and interaction decision-making unit, and a real execution unit. The server side mainly includes: a privileged daemon process unit, a sandbox worker unit, a controlled pre-run unit, a side effect observation unit, a risk assessment unit, and a logging and security audit unit. Each functional unit works in sequence and collaboratively. First, the client side receives AI-generated commands, organizes the context, and triggers the pre-run (sending a pre-run request to the server). Then, the server side constructs the controlled execution environment, completes the pre-run, extracts side effects, assesses the risk level, records the pre-run log, and returns the pre-run control results to the client side. Finally, the client side displays risk information to the user. If the risk information indicates that user confirmation is required and user confirmation is received, or if the risk information indicates that direct execution is permitted, the command is executed in the host machine's real execution environment. This forms a complete processing chain: "command input - controlled pre-run and observation - automated risk assessment - actual execution."

[0085] like Figure 3 As shown, the intelligent agent execution control method of this specific embodiment includes the following steps.

[0086] Step S1: Obtain the AI-generated command and execution context.

[0087] The system obtains the AI-generated shell command to be executed, the current working directory, the controlled root path, and the current calling environment information. The AI-generated command may include relative paths, absolute paths, script calls, and the sudo prefix, all of which affect execution semantics.

[0088] Step S2: Identify execution semantics.

[0089] The system performs execution semantic recognition on AI-generated commands or execution contexts to determine the execution semantics that should be maintained as much as possible during this pre-run. For example, it can identify specific prefixes of AI-generated commands to determine the invocation semantics; it can also identify file system directory attributes of the execution context to determine the working directory semantics.

[0090] Step S3: Determine the pre-run call path.

[0091] If the current process has the conditions to construct a controlled execution environment, it can directly enter the pre-run process; if the current process does not have the corresponding conditions, the pre-run request can be handed over to the server-side controlled service component for processing through the local inter-process communication mechanism. This controlled service component can be a privileged service process or a daemon process running on the local host, and it determines the execution semantics that need to be maintained for this pre-run based on the request context.

[0092] Step S4: Construct a controlled file system view.

[0093] The system creates temporary directories within an independent, isolated, and controlled execution environment and constructs a controlled file system view based on a union file system. Specifically, the controlled execution environment can be constructed by combining mount namespaces, union file system views, and isolated execution tools. For ordinary controlled root path scenarios, the system treats the controlled root path as the lower-level read-only directory and the temporary directory as the upper-level writable directory (i.e., the working directory), constructing a single union view. For system root directory scenarios, the system first binds the system root directory in read-only mode, then creates union views for each top-level subdirectory individually. This avoids compatibility issues caused by performing a single union mount on the entire system root directory and improves the observability of system-level command side effects.

[0094] Step S5: Maintain semantic consistency.

[0095] After mounting and namespace setup are completed, the system executes the command load according to the execution semantics determined in step S2. To ensure that the pre-run results are as consistent as possible with the actual execution results, the system can further adjust the directory attributes of the controlled file system view, as well as the environment execution context and command load execution mode of the controlled execution environment, thereby reducing the risk of missed side effects due to deviations in pre-run semantics.

[0096] Step S6: Execute the pre-run command and obtain the basic results.

[0097] The system executes AI-generated commands within the controlled file system view and switches the current working directory to a path corresponding to the real environment. After the pre-run, the system obtains the exit code, standard output, and standard error output, and uses the relevant execution results as auxiliary information for subsequent analysis.

[0098] Step S7: Extract the set of logical path-level side effects.

[0099] The system scans the upper-level writable directories of the controlled union file system view and identifies the following change types by combining the status of the lower-level read-only directories: 1. Paths that exist in the upper level but not in the lower level are recorded as new changes; 2. Paths that exist in both the upper and lower levels are considered modified / changed. 3. The path that appears as a deletion effect in the combined view is denoted as the deletion change; 4. When necessary, it can further identify changes related to file or directory control attributes.

[0100] After identification, the system normalizes each change path into a logical path relative to the controlled root path, forming a structured set of side effects.

[0101] Step S8: Perform rule matching based on the set of side effects.

[0102] The system performs rule matching based on each logical path and its corresponding change type in the structured side effect set to obtain the corresponding risk level.

[0103] Step S9: Generate execution control results.

[0104] The system generates an execution control result based on the matching result of step S8. This control result includes at least one of allowing execution, requiring confirmation, or blocking execution; when necessary, the system may also generate corresponding explanatory information at the same time.

[0105] Step S10: Execute or block.

[0106] If the control result allows direct execution, or if execution is permitted after user confirmation, the AI-generated command is executed in the real environment; if the control result is blocking or the user rejects the command, execution is terminated. In either case, the system records logs and audit information for this command processing.

[0107] Furthermore, to facilitate the unified organization of context information, pre-run inputs and outputs, side effect evidence, risk assessment results, and execution control conclusions during command processing, this specific embodiment also designs a series of key data structures. These data structures are not dependent on a specific programming language but are used to logically support the complete processing chain of commands from generation, pre-run, observation, evaluation to control.

[0108] 1. Command execution context.

[0109] This is used to store the basic input information for processing an AI-generated command, serving as a unified input for pre-run, risk assessment, and audit logs. The command execution context describes in which directory, identity, and session the command was generated and is ready to be executed, thus providing a basis for subsequent pre-run environment construction and side effect interpretation.

[0110] 2. Pre-run request and pre-run result.

[0111] This is used to represent a pre-run task and its return results. The pre-run request is used to send the command to be executed and its running conditions to the controlled execution environment or the server-side controlled service component; the pre-run result is used to receive the execution status, output information and side effect observation results returned by the pre-run, thereby providing direct input for subsequent risk assessment.

[0112] 3. Side effects.

[0113] Side effect records, used to represent a single file or directory, are the smallest unit of evidence in the risk assessment phase. Each side effect item corresponds to a single addition, modification, or deletion on a specific path during the pre-run process. The system aggregates multiple side effect items to form a complete set of side effects, and then uses this set for rule matching and risk interpretation.

[0114] 4. Risk assessment results, i.e., execution risk information.

[0115] Used to represent the analysis results of the risk assessment phase, it serves as an intermediate judgment carrier before the side effect observation results enter the execution control. Each risk assessment result corresponds to the system's comprehensive analysis of a set of side effects from a pre-run. The system generates risk level and explanatory information based on path characteristics and change types, and then passes the result to the subsequent control decision-making stage.

[0116] 5. Control the outcome of decisions.

[0117] Used to represent the final execution control action, it serves as the final control vehicle before the risk assessment results enter actual execution. Each control decision corresponds to the system's execution conclusion for a command processing flow. The system combines the risk assessment results, system status, and current strategy to generate actions such as allowing execution, requiring confirmation, or blocking execution, and drives subsequent user interactions and the actual execution flow accordingly.

[0118] Through the above structural design, the system can transform the originally scattered execution phenomena into unified, comparable, and evaluable data objects, providing stable input for risk assessment and interactive confirmation.

[0119] It should be understood that in the Linux environment, the relevant underlying technologies are already quite mature, for example: - Lightweight namespace isolation based on Bubblewrap (a lightweight controlled execution tool that can be used to construct controlled execution environments); - A file system view based on OverlayFS that is writable at the upper level and read-only at the lower level; - Local inter-process communication based on Unix Domain Socket (a local inter-process communication mechanism for efficient communication between processes on the same host); - Obtain the user identity of the peer process based on SO_PEERCRED (a proprietary socket option name for Linux / Unix systems); - A one-time, recyclable isolated execution environment is formed based on mount namespace (a mount namespace mechanism used to isolate the mount point and file system view seen by the process) and unshare (unshare command).

[0120] These technologies have been used in controlled execution, file system isolation, permission proxy, and local service architecture, respectively. However, existing systems have not combined them into a complete chain for "risk assessment of AI-generated commands." That is, they have not constructed a pre-running environment that closely resembles the real permissions and path view before actual execution, extracted the real side effects of commands, and then used this as the basis for execution decisions.

[0121] Figure 4 This is a block diagram of an intelligent agent execution control device according to exemplary embodiments of the present disclosure. (Refer to...) Figure 4 The device includes an acquisition unit 401, a setup unit 402, an execution unit 403, an update unit 404, a change determination unit 405, a risk determination unit 406, and a control unit 407.

[0122] The acquisition unit 401 is configured to acquire the command to be executed output by the target agent and its corresponding command execution context.

[0123] The setup unit 402 is configured to set up a controlled execution environment in the host machine corresponding to the target agent according to the command execution context, and generate an initialized controlled file system view in the controlled execution environment.

[0124] Execution unit 403 is configured to execute commands to be executed in a controlled execution environment, based on an initialized controlled file system view.

[0125] Update unit 404 is configured to acquire an updated controlled file system view after the execution of the pending command has finished.

[0126] The change determination unit 405 is configured to determine file system change information based on the changes of the updated controlled file system view relative to the initialized controlled file system view.

[0127] The risk determination unit 406 is configured to determine the execution risk information of the command to be executed based on file system change information.

[0128] Control unit 407 is configured to control the execution of commands to be executed in the host machine based on execution risk information.

[0129] The intelligent agent execution control device according to the exemplary embodiments of this disclosure does not use the existing command text itself or general behavior sequence as the basis for risk assessment. Instead, before the command is actually executed, it constructs a controlled execution environment and a controlled file system view for command pre-running. This allows it to obtain in advance which host machine logical paths the command will ultimately affect and what file system changes will occur to these logical paths. This elevates the risk assessment basis of the command to be executed, "text inference," to "evidence of the final target object," thereby significantly improving the accuracy of risk assessment and providing reliable direct evidence for whether or not to allow the command to be executed.

[0130] Optionally, the controlled file system view is a controlled union file system view. The initial controlled file system view includes a lower-level read-only directory and an empty upper-level writable directory. The updated controlled file system view includes a lower-level read-only directory and an updated upper-level writable directory. The change determination unit 405 is further configured to determine the changed logical path and the change type of the logical path by comparing the updated upper-level writable directory and the lower-level read-only directory, thereby obtaining file system change information. The change type includes at least one of the following: addition, modification, deletion, and metadata change. Since the lower-level directory (root directory) remains read-only and the upper-level directory inherits the write and deletion changes generated during the pre-run, after the pre-run is completed, the corresponding logical path-level side effects can be easily extracted by comparing the upper and lower levels. These side effects include, but are not limited to, logical path-level additions, modifications, deletions, and metadata changes. This yields logical path-level change results that are closer to the host machine's cognitive approach, forming structured side effect evidence that can be used for risk assessment of commands to be executed. Meanwhile, this construction method uses the real host root directory as a read-only lower layer and takes over the write changes through a temporary upper-level directory. This allows commands to run as close to the real path relationship as possible during pre-running, while limiting and converging side effects into an observable temporary layer. Therefore, it can maintain the authenticity of path semantics, avoid directly polluting the host environment, and support subsequent differential extraction, thus ensuring that side effects are observable.

[0131] Optionally, the command execution context includes a controlled root path, and the setup unit 402 is further configured to: when the controlled root path is the system root directory, bind the system root directory in read-only mode within the controlled execution environment; and generate an initialized controlled union file system view for each top-level subdirectory under the system root directory. Since different Linux operating systems such as Debian, Ubuntu, and CentOS have different mounting methods, directly performing a single union mount on the entire system root directory may cause compatibility issues. By first binding the system root directory in read-only mode and then establishing controlled union file system views for each top-level subdirectory, compatibility with different operating systems can be improved, and the command to be executed can maintain operating conditions as close as possible to the real environment during pre-running, obtaining the root directory structure and path semantics of the real host machine as much as possible.

[0132] Optionally, the risk determination unit 406 is further configured to: acquire risk rule information, wherein the risk rule information includes multiple risk rules and their corresponding risk levels, each risk rule including a preset logical path and a preset change type; perform rule matching processing on the file system change information and the multiple risk rules; and, if a risk rule consistent with the file system change information is matched from the multiple risk rules, determine the execution risk information of the command to be executed based on the risk level corresponding to the matched risk rule, wherein the preset logical path in the matched risk rule is consistent with the changed logical path, and the preset change type in the matched risk rule is consistent with the change type of the changed logical path. By directly using the logical path-level file system change information as rule matching input to generate the execution risk information of the command to be executed, the output results are more stable, easier to interpret, easier to audit, and more suitable as the basis for determining the execution action before actual execution, thus improving the controllability of the command to be executed before actual execution.

[0133] Optionally, the setup unit 402 is further configured to: obtain execution semantics extracted from the command to be executed and the command execution context, wherein the execution semantics are used to describe the constraints that the command must follow when it actually runs in the host machine; build a general controlled execution environment in the host machine; generate a basic controlled file system view in the general controlled execution environment according to the command execution context; and adapt and adjust the general controlled execution environment and the basic controlled file system view according to the execution semantics to obtain a controlled execution environment and an initialized controlled file system view. By first building a general controlled execution environment and generating a basic controlled file system view in it, and then adapting and adjusting the built environment and view according to the execution semantics of the command to be executed and its command execution context, a controlled execution environment and a controlled file system view that neither directly pollutes the host environment nor fails to maintain the true execution semantics as much as possible can be constructed. This enables dynamic configuration of the environment and view for the specific command to be executed, thereby effectively reducing the execution semantic deviation caused by the default configuration of the controlled execution environment, reducing the risk of missed side effects due to semantic deviation, and improving the consistency between the pre-run results and the actual execution results.

[0134] Optionally, execution semantics includes call semantics extracted from the command to be executed, environment semantics extracted from the command execution context, and working directory semantics. The building unit 402 is further configured to: adapt and adjust the command load operation mode of the general controlled execution environment according to the call semantics; adapt and adjust the environment execution context of the general controlled execution environment according to the environment semantics to obtain a controlled execution environment; and adapt and adjust the directory attributes of the basic controlled file system view according to the working directory semantics to obtain an initialized controlled file system view. Call semantics can be used to adjust the command load operation mode of the basic controlled execution environment, replicating the original startup logic of the command and reducing the risk of deviations in command execution results and process behavior due to different startup modes. Environment semantics can be used to modify the default configuration of the general controlled execution environment, adjust its environment execution context, align the controlled execution environment with the real execution environment, and reduce command line behavior anomalies caused by inconsistencies in permissions, identities, and variables. Working directory semantics can be used to adjust the directory attributes of the underlying controlled file system view, aligning the directory attributes of the controlled file system view with the directory attributes of the file system in the actual execution environment. This ensures that operations on the controlled file system can be performed and helps to extract file system change information that is closer to the real situation in subsequent steps.

[0135] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0136] According to embodiments of this disclosure, an electronic device may be provided. Figure 5This is a block diagram of an electronic device 500 according to an embodiment of the present disclosure. The electronic device includes at least one memory 501 and at least one processor 502. The at least one memory stores a set of computer-executable instructions 5011 and an operating system 5012. When the set of computer-executable instructions 5011 is executed by the at least one processor 502, an intelligent agent execution control method according to an embodiment of the present disclosure is executed.

[0137] As an example, electronic device 500 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 500 is not necessarily a single electronic device, but may be a collection of any devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 500 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0138] In electronic device 500, processor 502 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 502 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0139] The processor 502 can execute instructions or code stored in memory, and the memory 501 can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transmission protocol.

[0140] The memory 501 may be integrated with the processor 502, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 501 may include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 501 and the processor 502 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 502 to read files stored in the memory 501.

[0141] In addition, the electronic device 500 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0142] According to embodiments of this disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the processor to perform the intelligent agent execution control method of the present disclosure. Examples of computer-readable storage media include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0143] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions, which, when executed by a processor, implement the intelligent agent execution control method of this disclosure.

[0144] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0145] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for controlling the execution of an intelligent agent, characterized in that, include: Obtain the command to be executed output by the target agent and its corresponding command execution context; Based on the command execution context, a controlled execution environment is built in the host machine corresponding to the target agent, and an initialized controlled file system view is generated in the controlled execution environment; In the controlled execution environment, the command to be executed is executed based on the initialized controlled file system view; If the command to be executed has finished, obtain an updated view of the controlled file system; Based on the changes in the updated controlled file system view relative to the initialized controlled file system view, determine file system change information; Based on the file system change information, determine the execution risk information of the command to be executed; Based on the execution risk information, the execution of the command to be executed is controlled within the host machine.

2. The intelligent agent execution control method as described in claim 1, characterized in that, The controlled file system view is a controlled union file system view. The initialized controlled file system view includes a lower-level read-only directory and an empty upper-level writable directory. The updated controlled file system view includes the lower-level read-only directory and the updated upper-level writable directory. The step of determining file system change information based on the changes in the updated controlled file system view relative to the initialized controlled file system view includes: By comparing the updated upper-level writable directory and the lower-level read-only directory, the logical path that has changed and the type of change of the logical path are determined, and the file system change information is obtained. The type of change includes at least one of the following: addition, modification, deletion, and metadata change.

3. The intelligent agent execution control method as described in claim 2, characterized in that, The command execution context includes a controlled root path, and the generation of an initialized controlled file system view in the controlled execution environment includes: When the controlled root path is the system root directory, the system root directory is bound in read-only mode in the controlled execution environment; For each top-level subdirectory under the system root directory, an initialized controlled union file system view is generated to obtain the initialized controlled file system view.

4. The intelligent agent execution control method as described in claim 2, characterized in that, The step of determining the execution risk information of the command to be executed based on the file system change information includes: Obtain risk rule information, wherein the risk rule information includes multiple risk rules and their corresponding risk levels, and each risk rule includes a preset logical path and a preset change type; The file system change information and the multiple risk rules are subjected to rule matching processing; If a risk rule that matches the file system change information is found among the multiple risk rules, the execution risk information of the command to be executed is determined based on the risk level corresponding to the matched risk rule. The preset logical path in the matched risk rule is consistent with the changed logical path, and the preset change type in the matched risk rule is consistent with the change type of the changed logical path.

5. The intelligent agent execution control method as described in claim 1, characterized in that, The step of establishing a controlled execution environment on the host machine corresponding to the target agent according to the command execution context, and generating an initialized controlled file system view in the controlled execution environment, includes: Obtain the execution semantics extracted from the command to be executed and the command execution context, wherein the execution semantics are used to describe the constraints that the command must follow when it is actually running in the host machine; A general-purpose controlled execution environment is established in the host machine; Based on the command execution context, a basic controlled file system view is generated in the general controlled execution environment; Based on the execution semantics, the general controlled execution environment and the basic controlled file system view are adapted and adjusted to obtain the controlled execution environment and the initialized controlled file system view.

6. The intelligent agent execution control method as described in claim 5, characterized in that, The execution semantics include call semantics extracted from the command to be executed, environment semantics extracted from the command execution context, and working directory semantics. The step of adapting and adjusting the general controlled execution environment and the basic controlled file system view according to the execution semantics to obtain the controlled execution environment and the initialized controlled file system view includes: Based on the invocation semantics, the command load operation mode of the general controlled execution environment is adapted and adjusted, and based on the environment semantics, the environment execution context of the general controlled execution environment is adapted and adjusted to obtain the controlled execution environment; Based on the semantics of the working directory, the directory attributes of the basic controlled file system view are adapted and adjusted to obtain the initialized controlled file system view.

7. An intelligent agent execution control device, characterized in that, include: The acquisition unit is configured to acquire the command to be executed output by the target agent and its corresponding command execution context; The setup unit is configured to set up a controlled execution environment in the host machine corresponding to the target agent according to the command execution context, and generate an initialized controlled file system view in the controlled execution environment; An execution unit is configured to execute the command to be executed based on the initialized controlled file system view in the controlled execution environment; The update unit is configured to acquire an updated view of the controlled file system after the execution of the command to be executed has ended; The change determination unit is configured to determine file system change information based on the changes of the updated controlled file system view relative to the initialized controlled file system view; The risk determination unit is configured to determine the execution risk information of the command to be executed based on the file system change information; The control unit is configured to control the execution of the command to be executed in the host machine based on the execution risk information.

8. An electronic device, characterized in that, include: At least one processor; At least one memory that stores computer-executable instructions. Wherein, when the computer-executable instructions are executed by the at least one processor, they cause the at least one processor to execute the agent execution control method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, they cause the at least one processor to perform the agent execution control method as described in any one of claims 1 to 6.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by at least one processor, they cause the at least one processor to perform the agent execution control method as described in any one of claims 1 to 6.

Images