Terminal system cooperative security continuous auditing method and system based on large model agent

Abstract

The application relates to the technical field of network security and artificial intelligence, in particular to a terminal system cooperative security continuous auditing method and system based on a large model agent, wherein the terminal system cooperative security continuous auditing system based on the large model agent comprises a terminal security continuous auditing subsystem used for a terminal security continuous auditing step; a system log intelligent polling analysis subsystem used for performing a system log intelligent analysis step; and a large model security decision and cooperation engine used for carrying out reasoning and decision of a large language model agent and performing a bidirectional cooperative linkage step. The application can realize a bidirectional automatic reasoning chain of "system abnormality linkage terminal deep digging" and "terminal abnormality pulling system track", break a security island, and generate a complete evidence chain report from an application layer entrance to a terminal system layer.

Description

Technical Field

[0001] This invention relates to the field of interdisciplinary technology of network security and artificial intelligence, and in particular to a method and system for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents. Background Technology

[0002] In the current network security defense system, host security auditing (such as Host Intrusion Detection System (HIDS) and Endpoint Detection and Response (EDR)) and system log analysis (such as Security Information and Event Management System (SIEM) and Security Operations Center (SOC)) constitute the two core technical pillars. However, with the continuous evolution and increasing complexity of network attack methods, existing security defense methods face a series of increasingly severe technical challenges.

[0003] I. Terminal detection relies on manual labor and has rigid rules.

[0004] Traditional HIDS / EDR systems primarily rely on static rules and signature-based threat detection, lacking effective identification capabilities for unknown threats that evade known characteristics (such as slow APT attacks and zero-day vulnerabilities). More critically, once an alert is generated, security analysts still need to manually log into the host to perform forensic operations such as `ls`, `lsof`, and hash value calculations, resulting in low response efficiency. Traditional systems lack autonomous reasoning capabilities, unable to autonomously determine the next steps in investigation when faced with suspicious behavior, and struggle to cope with "alert fatigue" caused by large-scale alerts.

[0005] II. System log auditing lacks contextual understanding and the ability to identify low-frequency attacks.

[0006] Traditional log auditing platforms rely on regular expressions or frequency thresholds to trigger alerts. When attackers use methods such as "slow brute-force attacks," "multi-IP credential stuffing," or exploit "logic privilege escalation vulnerabilities," a single access may not trigger the threshold, making it easy to miss alerts. Furthermore, traditional systems treat logs as isolated events, lacking continuous tracking of individual IP addresses or user behavior patterns. This results in numerous scattered alerts failing to form a complete attack narrative, further exacerbating alert fatigue.

[0007] Third, terminal and system audits are disconnected and lack closed-loop coordination.

[0008] Endpoint security products and system log auditing platforms are architecturally isolated, resulting in poor data flow. Although some solutions attempt to integrate alarm data from both, they have failed to create a closed-loop automated reasoning chain of "system anomaly → in-depth endpoint investigation" or "endpoint anomaly → retrieval of system trajectory".

[0009] In recent years, Large Language Models (LLMs) have received widespread attention in the field of cybersecurity. However, existing research has mostly focused on the intelligent transformation of single scenarios, and has not yet proposed a systematic solution that deeply integrates continuous terminal auditing with intelligent analysis of system logs and achieves bidirectional collaborative linkage through LLM agents.

[0010] In summary, the existing security defense system has significant deficiencies in terms of terminal self-inspection capabilities, system context association capabilities, and terminal-system collaborative linkage capabilities, and urgently needs improvement. Summary of the Invention

[0011] This application aims to at least solve the technical problems existing in the prior art, and to provide a method and system for continuous auditing of collaborative security of terminal systems based on large model intelligent agents.

[0012] In a first aspect, the present invention provides a method for continuous collaborative security auditing of terminal systems based on large-model intelligent agents, the method comprising:

[0013] Endpoint security continuous audit steps: Periodically collect the current operating status data of the terminal host, and compare the current operating status data with the historical health status baseline through state differential filtering; a large language model intelligent agent based on the ReAct inference framework generates tool invocation instructions that conform to the predetermined schema definition based on the abnormal change data; after verification by a security sandbox, execute the tool invocation instructions to obtain terminal investigation evidence; based on the terminal investigation evidence, query an external threat intelligence platform, and use a comprehensive judgment decision matrix to qualitatively classify the threat;

[0014] The intelligent analysis steps of system logs are as follows: periodically poll to obtain system logs and parse them into standardized structures; manage and maintain the behavioral trajectory and semantic baseline of accessing entities through long short-term memory; input the current system logs and historical semantic baselines into the big language model for intent recognition and detect abnormal behavior; when suspicious clues are identified, trigger the big language model agent to actively perform multi-dimensional source tracing queries on the log database.

[0015] Two-way collaborative steps: When the intelligent system log analysis step detects an anomaly, it sends a trigger command to the continuous endpoint security audit step through the collaborative engine to collect cross-domain data; when the continuous endpoint security audit step detects an anomaly, it sends a trigger command to the intelligent system log analysis step through the collaborative engine to trace back historical events; and integrates to generate a complete evidence chain report across system levels.

[0016] By adopting the above technical solution:

[0017] On the terminal side: The ReAct inference framework empowers the LLM agent with the ability to dynamically generate investigation instructions based on clues discovered on-site, and a security sandbox ensures the security of these instructions, realizing a closed-loop decision-making process from "alarm only" to "alarm + autonomous judgment + secure evidence collection". Meanwhile, state difference denoising reduces the amount of large model input data by more than 95%, effectively reducing token overhead and inference latency, and improving the feasibility of the solution.

[0018] On the system log side: By overcoming the limitations of frequency thresholds through LLM semantic understanding and establishing entity behavior baselines by combining long short-term memory management, it is able to identify covert attacks that do not use signatures.

[0019] Collaborative side: It realizes a two-way automated reasoning chain of "deep investigation of terminal through system anomalies" and "retrieval of system trajectory from terminal anomalies", breaking down security silos and generating a complete evidence chain report from the application layer entry point to the terminal system layer.

[0020] Optionally, in the continuous auditing step for terminal security, the state differential filtering specifically includes:

[0021] Using the combination of key entity fields as comparison tuples, the current running state is compared with the historical baseline by attribute-level differential comparison; if there is a comparison tuple in the current state that does not belong to any comparison tuple in the historical baseline, it is determined to be a newly added entity; if the comparison tuple matches but the corresponding attribute has changed, it is determined to be a tampered entity.

[0022] By adopting the above technical solution, the judgment rules for anomaly detection are clearly defined into two categories: "newly added entities" and "tampered entities." The comparison tuples are based on combinations of key entity fields (such as the process's `(path, cmdline)`) instead of a single identifier. Compared to traditional solutions that rely solely on process names or PIDs for comparison, attribute-level differential analysis avoids false alarms caused by "a legitimate process restarting and its PID changing, triggering an alarm," while also capturing tampering behavior such as "a process with the same name being replaced by a malicious program but its path remaining unchanged." Each audit cycle only requires comparing the changed difference set data, eliminating the need for a full rescan, significantly reducing the input load of large models.

[0023] Optionally, the state differential filtering further includes a two-layer whitelist filtering:

[0024] The first layer is a static administrator whitelist, which filters known legitimate entities by matching paths, wildcards, and fixed SHA256 signatures.

[0025] The second layer is an AI-driven dynamic learning whitelist, which adds entities that have been judged to be harmless and have no network outreach behavior in multiple consecutive audit cycles to a dynamic whitelist with a set lifespan.

[0026] If the hash value of an entity in the whitelist changes, the whitelist filtering of that entity will be forcibly revoked.

[0027] Maintain a grayscale event buffer. When the host triggers high-risk behavior, trace back the entity data that was filtered by the two-layer whitelist within a preset time period.

[0028] By adopting the above technical solution, a two-layer whitelist mechanism is introduced on the basis of differential filtering, solving the dilemma of the traditional single static whitelist: if the whitelist is too lenient, it will miss detections; if it is too strict, it will have too many false positives. The first layer, the static administrator whitelist, accurately matches known legitimate programs through paths, wildcards, and SHA256 signatures. The second layer, the AI ​​dynamic learning whitelist, automatically identifies changes that are harmless and have no network external connection behavior over multiple consecutive periods. After setting the TTL, it adaptively adds to the whitelist, making the whitelist coverage evolve from purely manual maintenance to self-learning expansion, significantly reducing manual maintenance costs. On this basis, when the entity hash in the whitelist changes, the filtering is forcibly revoked to prevent malicious replacement, while maintaining a gray-scale event buffer. When a host triggers high-risk behavior, the filtered data is traced back, achieving a technical balance of "reducing false positives without sacrificing the ability to detect missed detections".

[0029] Optionally, the security sandbox verification specifically includes:

[0030] The tool invocation instructions are converted into parameterized arrays for execution to prevent string injection attacks;

[0031] Equipped with a command regular expression whitelist, allowing only commands that match the preset regular expression pattern to be executed;

[0032] Block commands that include write, delete, or tamper operations, and intercept redirection characters, pipe characters, and command connectors.

[0033] The reason traditional security products cannot achieve AI-driven autonomous forensics by adopting the above technical solutions is fundamentally due to the inability to trust AI-generated instructions. This can lead to large models potentially exhibiting hallucinations in extreme cases, outputting destructive commands such as `rm`, `kill`, and `chmod`. This solution mitigates this risk layer by layer through three lines of defense: parameterized array execution prevents shell string injection attacks; a command regular expression whitelist only allows safe commands that conform to preset patterns; and dangerous feature blocking directly intercepts redirection characters, pipe characters, command concatenation characters, and write / delete commands. These three lines of defense are independent and indispensable, ensuring that even if the LLM output is abnormal, the instructions cannot cause damage to the target host.

[0034] Optionally, the long short-term memory management specifically includes:

[0035] The behavior trajectory of each accessing entity is continuously aggregated using the client IP address or account ID as the key;

[0036] The semantic behavior baseline text generated by the large language model through analysis of entity historical data is stored in a vector database as long-term memory.

[0037] The complete request chain of an entity within the most recent preset time period is cached in a key-value database as a short-term working context.

[0038] By adopting the above technical solution, the traditional "isolated event" handling method in log auditing is upgraded to "entity behavior modeling". A vector database stores the semantic behavior baseline text generated by LLM as long-term memory, while a key-value database caches the complete request chain within the most recent preset time period as short-term working context. Long-term memory provides the system with a "normal behavior profile" for each entity, while short-term memory provides a real-time comparison context for the sliding window. The collaboration between the two allows detection to no longer rely on fixed thresholds, but rather on anomaly judgment based on the entity's own behavioral logic.

[0039] Optionally, the intent recognition includes: inputting the current log slice and the historical semantic baseline of the entity into a large language model, performing deviation analysis through semantic understanding, and identifying logical unauthorized access, slow credential stuffing, or sensitive interface probing behaviors.

[0040] By employing the above technical solution, the current behavior and semantic baseline are jointly input into the LLM for deviation analysis. This allows for the semantic identification of behaviors that deviate from the entity's baseline of "normally only viewing its own information," thus determining it as a horizontal privilege escalation attempt. Similarly, slow credential stuffing attacks and sensitive interface probing, such as traversing hidden paths like .git, can be captured by semantic understanding before triggering the threshold.

[0041] Optionally, the proactive multi-dimensional source tracing query of the log database includes: the large language model agent autonomously constructing query conditions, initiating multi-round correlation aggregation queries to the system log database containing target entities and time ranges, and reconstructing the attacker's complete behavioral chain.

[0042] By adopting the above technical solution, after identifying suspicious clues, the LLM agent autonomously constructs database query conditions that include target data tables, entity constraints, time range conditions, and return quantity limits. Through multiple rounds of correlation and aggregation, it assembles scattered log records into a complete attack narrative, realizing an automated closed loop from "discovering anomalies" to "restoring the full picture of the attack," significantly shortening emergency response time.

[0043] Optionally, in the bidirectional collaborative linkage step, the step of sending a trigger command to the terminal when an anomaly is detected by the intelligent analysis of system logs specifically includes:

[0044] Extract suspicious IP addresses and port numbers corresponding to abnormal behavior;

[0045] The collaboration engine automatically matches the backend terminal host group that carries the corresponding business.

[0046] The terminal security continuous audit steps are instructed to initiate immediate specific data collection, focusing on investigating network sockets and associated processes established with the suspicious IPs.

[0047] By adopting the above technical solution, when the system logs detect abnormal API calls, the collaborative engine automatically extracts suspicious IPs and ports, matches them with the backend host clusters carrying the service, and breaks through the limitations of conventional audit cycles to initiate real-time specific data collection. The terminal AI, carrying prior knowledge that "this IP exhibits abnormal behavior," targets and investigates abnormal child processes of network sockets established with this IP, web application processes (such as Tomcat / Node.js), and abnormal kernel module loading, achieving rapid capture of silent memory malware and fileless attacks.

[0048] Optionally, in the bidirectional collaborative linkage step, the step of sending a trigger command to the system when an anomaly is detected by the continuous terminal security audit step specifically includes:

[0049] Extract the creation time, hash fingerprint, and executed commands of abnormal processes or files in the terminal;

[0050] The collaborative engine instructs the system log intelligent analysis steps based on the long short-term memory database to trace back all application layer logs before and after the creation time point;

[0051] By using a large language model to correlate and deduce the attack entry point link, the complete attack path from the application layer to the terminal system layer can be reconstructed.

[0052] By adopting the above technical solution, the collaborative engine extracts the creation time, hash fingerprint, and executed command of the abnormal process, triggers a reverse lookup of all application layer logs before and after T_alert on the system log side, and after LLM correlation analysis, it is found that a request from an external IP accessed the ` / weblogic / wls-wsat / CoordinatorPortType` interface 3 seconds before T_alert and carried a large amount of XML data, thus reconstructing the complete attack chain of "WebLogic deserialization vulnerability exploitation → downloading malicious files → writing to scheduled tasks", and generating a complete evidence chain report across system levels.

[0053] Secondly, this invention provides a terminal system collaborative security continuous auditing system based on a large-scale intelligent agent model, the system comprising:

[0054] The endpoint security continuous audit subsystem is used for endpoint security continuous auditing procedures.

[0055] The intelligent polling and analysis subsystem for system logs is used to perform intelligent analysis steps for system logs.

[0056] The large-model safety decision and collaboration engine is used to execute reasoning decisions for large language model agents and to execute bidirectional collaborative steps.

[0057] By adopting the above technical solution, the three subsystems correspond to the three core stages of the methodology: the terminal security continuous audit subsystem is responsible for terminal-side status acquisition, differential filtering, sandbox verification, and instruction execution closed loop; the system log intelligent polling analysis subsystem is responsible for structured parsing, long short-term memory management, and proactive source tracing of logs; and the large-scale model security decision-making and collaboration engine serves as the technical hub, carrying the ReAct inference decisions of LLM agents and scheduling top-down / bottom-up cross-domain collaboration. The modular design of the three subsystems allows for independent deployment and upgrades, reducing the complexity of engineering implementation.

[0058] In summary, this application includes the following beneficial technical effects:

[0059] On the terminal side: The ReAct inference framework empowers the LLM agent with the ability to dynamically generate investigation instructions based on clues discovered on-site, and a security sandbox ensures the security of these instructions, realizing a closed-loop decision-making process from "alarm only" to "alarm + autonomous judgment + secure evidence collection". Meanwhile, state difference denoising reduces the amount of large model input data by more than 95%, effectively reducing token overhead and inference latency, and improving the feasibility of the solution.

[0060] On the system log side: By overcoming the limitations of frequency thresholds through LLM semantic understanding and establishing entity behavior baselines by combining long short-term memory management, it is able to identify covert attacks that do not use signatures.

[0061] Collaborative side: It realizes a two-way automated reasoning chain of "deep investigation of terminal through system anomalies" and "retrieval of system trajectory from terminal anomalies", breaking down security silos and generating a complete evidence chain report from the application layer entry point to the terminal system layer.

[0062] When the system logs detect abnormal API calls, the collaborative engine automatically extracts suspicious IPs and ports, matches them with the backend host clusters carrying the service, and initiates real-time specific data collection, breaking the limitations of conventional audit cycles. The terminal AI, carrying prior knowledge that "this IP exhibits abnormal behavior," targets and investigates abnormal child processes of network sockets established with this IP, web application processes (such as Tomcat / Node.js), and abnormal kernel module loading, achieving rapid capture of silent memory malware and fileless attacks. Attached Figure Description

[0063] Figure 1 This is a general architecture diagram of a collaborative continuous auditing and investigation system provided in an embodiment of the present invention;

[0064] Figure 2 A flowchart illustrating the two-way collaborative linkage between a terminal and a system, provided in an embodiment of the present invention.

[0065] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0066] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0067] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0068] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0069] See Figure 1 This invention provides a terminal and system security collaborative continuous auditing and investigation system based on a large language model intelligent agent, comprising:

[0070] Endpoint Security Continuous Audit Subsystem: Responsible for target host status acquisition, differential filtering, security sandbox control, and endpoint command issuance and execution. This subsystem is deployed on the security operations platform and interacts with the protected target host via encrypted communication channels.

[0071] The encrypted communication channel is established based on the TLS 1.3 protocol and adopts a two-way authentication mTLS mechanism. The terminal security continuous audit subsystem and the target host are authenticated through X.509 certificates to ensure the confidentiality and integrity of data during the instruction issuance and result return process.

[0072] The intelligent polling analysis subsystem for system logs is responsible for real-time parsing of business system logs, maintenance of long short-term memory, baseline modeling of entity behavior, and recognition of behavioral intent. This subsystem interfaces with the log output interface of the business system and obtains incremental log data through a periodic polling mechanism.

[0073] Large Model Security Decision and Collaboration Engine: It carries the reasoning and decision-making of large language model (LLM) agents (based on the ReAct framework and CoT thinking chain), the linkage of external threat intelligence gateways, and the cross-domain collaborative scheduling between the terminal and the system side. It is the technical hub of the three subsystems.

[0074] The relationship between the three subsystems is as follows: Both the endpoint security continuous audit subsystem and the system log intelligent polling analysis subsystem are scheduled by the big model security decision and collaboration engine. The two subsystems communicate bidirectionally through the collaboration engine to form a two-way collaborative closed loop of Top-Down (system log anomalies triggering endpoint in-depth investigation) and Bottom-Up (endpoint anomalies triggering system log source tracing), and finally integrate to generate a complete evidence chain report across system levels.

[0075] Based on the same design concept, and referring to Figure 1 and Figure 2 As shown in the figure, an embodiment of the present invention also provides a method for continuous auditing of collaborative security of terminal systems based on large model intelligent agents, including the following steps:

[0076] S100: Continuous audit steps for endpoint security: Periodically collect the current operating status data of the endpoint host, and compare the current operating status data with the historical health status baseline through state differential filtering; a large language model intelligent agent based on the ReAct inference framework generates tool invocation instructions that conform to the predetermined schema definition based on the abnormal change data; execute the tool invocation instructions after verification by the security sandbox to obtain endpoint investigation evidence; query the external threat intelligence platform based on the endpoint investigation evidence, and use a comprehensive judgment decision matrix to qualitatively classify the threat.

[0077] Specifically, it includes the following sub-steps:

[0078] Step S101: Establishing the initial health status baseline of the terminal

[0079] When the system is first deployed, it logs in with remote credentials protected by asymmetric encryption (such as the SSH protocol for Linux systems and the WinRM protocol for Windows systems) or a lightweight host plugin, executes a set of full data extraction instructions, collects the initial running status of the host, and generates a standardized structure.

[0080] In this embodiment, the core data collection metrics and corresponding execution instructions for the dual platforms are shown in the table below:

[0081] Data categories Data Item Description Linux data collection command examples Windows data acquisition command examples (PowerShell) Process list The PID of a running process, its parent PID, the user that started it, the program path, and the startup command. `ps -eo pid,ppid,user,args,lstart,etimes` `Get-Process \| Select-ObjectId, ParentId, Path, CommandLine,StartTime` Network connection Current TCP / UDP network connection status, peer IP address, and port. `ss -tupna` `Get-NetTCPConnection; Get-NetUDPEndpoint` Listening port Network port being listened to and binding process `ss -tlnp` `Get-NetTCPConnection-StateListen` Key documents System binary directory and configuration file list, size, modification time, and hash value `find / bin / sbin / usr / bin / etc -type f -exec sha256sum{} +` `Get-ChildItem C:\Windows\System32 -Recurse \| Get-FileHash` Startup item Scripts or services that run automatically when the system starts `systemctl list-unit-files;ls -al / etc / init.d / ` `Get-CimInstance Win32_StartupCommand` Planned Tasks User's scheduled task configuration `crontab -l; cat / etc / crontab; ls -al / etc / cron.*` `Get-ScheduledTask` kernel module List of loaded kernel drivers or modules `lsmod` `Get-WmiObject Win32_SystemDriver` Login Session Current online users and login history `who; w; last` `query user; Get-EventLog -LogName Security -InstanceId4624`

[0082] The collected data is converted into standardized JSON data by a text parser to establish an initial health status baseline database B_0. For example, the process baseline entity is represented as:

[0083] B_0 = {E_proc, E_net, E_file, E_startup, E_cron, E_kernel, E_auth}

[0084] Each baseline entity E is composed of structured fields. Taking the process entity E_proc as an example, it includes the following fields: process ID (PID), parent process ID (PPID), user who started the process, path of the program, command line, start time, and runtime (etimes). The combination of these fields constitutes the alignment tuple of the entity, which serves as the basis for subsequent differential alignment.

[0085] Step S102: Attribute-level differential noise reduction and whitelist filtering.

[0086] In subsequent audit cycles (In this embodiment, (Set to 5 minutes), the system periodically collects the current running status. The state difference filtering module compares the results. Baseline of the previous period Extract the variation difference data .

[0087] (1) Attribute-level difference mechanism

[0088] Differential alignment uses combinations of key fields of entities as alignment tuples. For example, for a process entity, the alignment tuple Id_p = (path, cmdline), which uses the program path and startup command line as unique identifiers for the process entity; for a file entity, the alignment tuple Id_f = (path, filename).

[0089] State differential filtering specifically includes:

[0090] Using the combination of key entity fields as comparison tuples, the current running state is compared with the historical baseline by attribute-level differential comparison; if there is a comparison tuple in the current state that does not belong to any comparison tuple in the historical baseline, it is determined to be a newly added entity; if the comparison tuple matches but the corresponding attribute has changed, it is determined to be a tampered entity.

[0091] Specifically, the difference calculation rules are as follows:

[0092] If the current state There exists an entity p whose alignment tuple Id_p does not belong to the historical baseline. If the set of comparison tuples for any entity in B is {Id_b|b∈B_{n-1}}, then the entity p is determined to be a newly added entity;

[0093] If the comparison tuple Id_p matches the corresponding entity b in the baseline, but other attribute fields of entity p (such as the starting user user or the file hash value Hash) have changed relative to the corresponding attributes of the baseline entity b, then entity p is determined to be a tampered entity.

[0094] The above rules only focus on two types of changes: addition and tampering. Entities that are completely consistent with the baseline are automatically removed by the differential filtering module, thereby reducing the amount of data to be processed by the large model by more than 95%, which significantly reduces token overhead and inference latency.

[0095] (2) Two-layer whitelist filtering control

[0096] Specifically, the difference set obtained after attribute-level differencing Further noise reduction filtering is performed through a two-layer whitelist mechanism:

[0097] The first layer is a static administrator whitelist, which filters known legitimate entities by matching paths, wildcards, and fixed SHA256 signatures.

[0098] Specifically, the first layer—the static administrator whitelist—filters known legitimate self-developed system programs or operation and maintenance agents. The whitelist matches based on the following triples: (program path, wildcard pattern, fixed SHA256 signature). For example, the company's internally developed log collection agent ` / opt / company / log_agent` and its SHA256 value are pre-set in the whitelist. Even if the agent subsequently changes some attributes due to version upgrades, it will be automatically filtered out as long as its path, wildcard pattern, and SHA256 signature all match.

[0099] The second layer is an AI dynamic learning whitelist, which adds entities that have been judged to be harmless and have no network external contact behavior as unexpected changes after N consecutive audit cycles (N≥3) to a dynamic whitelist with a set lifespan.

[0100] Specifically, the second layer—the AI-driven dynamic learning whitelist—is as follows: If an entity that has undergone unexpected changes is deemed "benign" by the AI ​​engine in stages S103 and S105 for N consecutive audit periods (N=3 in this embodiment), and the entity has not engaged in any external network activity during this period, the AI ​​engine automatically adds the entity to the dynamic whitelist and sets a time-to-live (TTL, set to 24 hours in this embodiment). After the TTL expires, the whitelist entry automatically becomes invalid and requires verification through N more audit periods before it can be added again. This mechanism transforms whitelist coverage from purely manual maintenance to self-learning expansion, significantly reducing manual maintenance costs.

[0101] (3) Compensation mechanism for preventing missed / erroneous removal

[0102] To avoid security misses caused by whitelist filtering, this step introduces the following compensation mechanism:

[0103] If the hash value of an entity in the whitelist changes, the whitelist filtering of that entity will be forcibly revoked.

[0104] Specifically, if the hash value (SHA256) of any entity in the dual whitelist changes, regardless of whether the entity is still within the validity period of the whitelist, the whitelist filtering of that entity will be forcibly revoked, and it will be re-included in the anomaly analysis process. This mechanism prevents malicious attacks by attackers from replacing legitimate files with the same name.

[0105] Maintain a grayscale event buffer. When the host triggers high-risk behavior, trace back the entity data that was filtered by the two-layer whitelist within a preset time period.

[0106] Specifically, the system maintains a grayscale event buffer to cache candidate data that has been filtered out by the whitelist. When a host triggers high-risk behavior (such as detecting a reverse shell, unauthorized privilege escalation, or abnormal process injection), the system initiates reverse tracing, re-including whitelisted data that was filtered within a preset time window (the previous hour in this embodiment) in the grayscale buffer into the analysis scope, where it is re-examined by the large language model agent. This mechanism ensures that "false positives" are reduced without sacrificing "false negative detection capabilities," providing a fallback protection against missed detections.

[0107] Step S103: Generation of AI agent instructions based on the ReAct framework

[0108] Abnormal data after differential denoising The input, serving as a prompt, is passed to the decision engine of the large language model agent. The large language model employs the ReAct (Reasoning and Acting) framework combined with the Chain of Thought (CoT) for reasoning.

[0109] The ReAct framework works as follows: The large language model first generates a natural language reasoning text (Thought) describing its understanding and analysis logic of the current abnormal data; then it generates an action instruction (Action) indicating the specific investigation operation to be performed next; after the system executes the action, it feeds the result back to the large language model (Observation), which continues to reason based on the result and generates the next action, thus forming a closed-loop decision chain of "reasoning-action-observation-reasoning".

[0110] To ensure the security of the host system, the large language model cannot generate raw shell scripts (such as Bash / PowerShell command strings), but must output tool call JSON data structures that conform to a strictly defined schema. This schema constrains the output of the large language model within a preset secure command space.

[0111] In this embodiment, a typical Tool Call JSON output is shown below.

[0112] {

[0113] "thought": "The differential module detected a new process with PID 5082, located at / tmp / lib.so. I need to obtain the hash value of the binary file corresponding to this process and retrieve its current active network connections to help determine whether the process is a reverse shell or a malicious backdoor."

[0114] "actions": [

[0115] {

[0116] "tool_name": "get_file_hash",

[0117] "parameters": {

[0118] "file_path": " / tmp / lib.so",

[0119] "hash_type": "sha256"

[0120] }

[0121] },

[0122] {

[0123] "tool_name": "get_process_connections",

[0124] "parameters": {

[0125] "pid": 5082

[0126] }

[0127] } ]

[0129] }

[0130] The "thought" field contains the reasoning text of the large language model, describing its analytical logic and action intentions; the "actions" field is an array containing at least one tool invocation action, with each action containing a tool name "tool_name" and parameter key-value pairs "parameters". By limiting the output to the above JSON Schema, it is ensured that the large language model can only act within the preset tool command space and cannot generate arbitrary shell commands beyond its authority.

[0131] The preset tool command space in this embodiment includes, but is not limited to, terminal forensics tools such as get_file_hash (get file hash value), get_process_connections (get process network connections), get_process_info (get process details), list_open_files (list open files of the process), get_network_stats (get network status), and check_loaded_modules (check loaded kernel modules).

[0132] Step S104: Command security sandbox verification line

[0133] After receiving the Tool Call JSON output in step S103, the security sandbox module converts the tool call actions in the JSON into specific host execution commands one by one, and performs three-line cascade verification on the converted commands.

[0134] (1) Strictly parameterized execution

[0135] Specifically, the tool invocation instructions are converted into parameterized arrays for execution to prevent string injection attacks;

[0136] For example, commands are executed as parameterized arrays instead of string concatenation. For instance, the JSON string `{ "tool_name": "get_file_hash", "parameters": { "file_path": " / tmp / lib.so", "hash_type": "sha256"}}` is converted to the parameterized array `["sha256sum", " / tmp / lib.so"]`. By using parameterized arrays, injection attacks caused by direct execution of shell strings are avoided—even if the file path contains special characters (such as spaces, semicolons, and backticks), it will not be mistakenly executed by the shell interpreter.

[0137] (2) Command regular expression template library validation

[0138] Specifically, a command regular expression whitelist is configured to allow only commands that match the preset regular expression pattern to be executed;

[0139] In this embodiment, some regular expressions are:

[0140] File listing command: Matches `^ls\s+-[a-zA-Z]+\s+([a-zA-Z0-9_\-\. / ]+)?$`

[0141] Process file handle command: Matches `^lsof\s+(-p\s+\d+|-i\s+:\d+)$`

[0142] File content reading command: Only allows reading from ` / proc / ` <pid>System status information under / `, matching `^cat\s+ / proc / \d+ / (cmdline|status|environ)$`

[0143] File hashing command: matches `^sha256sum\s+ / [a-zA-Z0-9_\-\. / ]+$`

[0144] Network connection query: matches `^ss\s+-[a-zA-Z]+\s*$`

[0145] (3) Blocking of dangerous characteristics

[0146] Specifically, it blocks commands that include write, delete, or tamper operations, and intercepts redirection characters, pipe characters, and command connectors.

[0147] The following dangerous operation categories will be directly intercepted:

[0148] Commands that include write or delete actions (such as rm, kill, pkill, dd, chmod, chown, mv) prevent large models from creating illusions and accidentally deleting system files or terminating critical processes.

[0149] The redirection symbols (>, >>) prevent output redirection from overwriting system configuration;

[0150] The pipe symbol (|) blocks all combinations except those in a specific whitelist.

[0151] Command concatenation symbols (&&, ;) prevent command chaining.

[0152] After passing three lines of defense, only commands that pass all checks can be executed on the target host. For commands that fail checks, the sandbox will generate a check failure alarm and log it, while also returning a "command blocked by the security sandbox" feedback message to the large language model, which then needs to regenerate an alternative solution.

[0153] In addition, the sandbox creates an ephemeral session in each audit cycle for multi-turn dialogue context management. If the command returns a result exceeding a preset length limit (4000 characters in this embodiment), the sandbox truncates it before transmitting it to the large language model and automatically inserts a truncation warning (such as "[Truncated: only the first 50 lines are shown]") to maintain the context window of the large language model and avoid inference interruption due to excessively large returned results. After the session ends, the system summarizes the investigation conclusions of that audit cycle and stores them in a long-term memory database for later reference.

[0154] Step S105: External intelligence coordination and qualitative decision-making

[0155] The large language model agent, based on the execution results returned by the sandbox (such as file SHA256 hash values, external IP addresses, process behavior characteristics, etc.), calls an external threat intelligence platform (such as VirusTotal) to perform queries. The threat intelligence platform returns the global security assessment results of the queried object, which includes a key indicator: the number of security engines marked as malicious, V_malicious.

[0156] The system uses a comprehensive judgment and decision matrix to perform a comprehensive qualitative analysis of the threat intelligence results and the performance on the terminal host side:

[0157] Rule 1: If V_malicious ≥ 5, meaning at least 5 security engines mark it as malicious, then it is directly classified as a malicious threat (Malicious) without further manual analysis;

[0158] Rule 2: If 1 ≤ V_malicious < 5, and there are abnormal behaviors such as writing to sensitive directories and listening on high ports on the host side, then the logical reasoning of the entity's behavior is combined with the big language model to make a comprehensive judgment, and finally the big language model gives a qualitative conclusion of malicious / suspicious / harmless.

[0159] Rule 3: If V_malicious = 0 (i.e., the external intelligence platform has not marked any malicious engine), but the host side detects reverse shell behavior (such as discovering a suspicious process that actively initiates a reverse connection to the outside world), then the large language model will classify the entity as a high-risk unknown threat (APT attack or Zero-Day attack) and trigger the highest level of security alert.

[0160] The aforementioned comprehensive judgment and decision matrix integrates the global perspective of external intelligence with specific evidence of host-side behavior, avoiding the blind spot of "judging security as if the intelligence platform does not include it" and reducing false alarms and missed alarms caused by a single intelligence source, thus achieving multi-dimensional cross-verification of threat characterization.

[0161] The system in each audit cycle After completion, the newly identified entities in the current period will be updated to the baseline database after manual or automatic evaluation. As the next cycle The historical health status baseline is used to form a continuously iterative baseline evolution mechanism.

[0162] S200: Intelligent analysis steps for system logs: Periodically poll to obtain system logs and parse them into standardized structures; manage and maintain the behavioral trajectory and semantic baseline of accessing entities through long short-term memory; input the current system logs and historical semantic baselines into the big language model for intent recognition and discover abnormal behavior; when suspicious clues are identified, trigger the big language model agent to actively perform multi-dimensional source tracing queries on the log database.

[0163] Step S201: Incremental log reading and structured preprocessing

[0164] The system polls for business system logs at a preset period (every minute in this embodiment). The log sources include, but are not limited to: Nginx / Apache web server access logs, application layer API interface call logs, bastion host operation audit logs, database query logs, etc.

[0165] The preprocessing module parses raw log text in various heterogeneous formats into a standardized JSON structure. The core metadata extracted includes: timestamp, client IP address, account ID, request URI, request body, user agent, and HTTP response status code. Taking an Nginx access log as an example, the standard structure after preprocessing is as follows:

[0166] {

[0167] "timestamp": "2026-06-12T12:00:00Z",

[0168] "client_ip": "198.51.100.42",

[0169] "account_id": "user_admin_01",

[0170] "request_uri": " / api / v1 / user / privileges / update",

[0171] "request_body": "{\"user_id\": 99, \"role\": \"super_admin\"}",

[0172] "user_agent": "Mozilla / 5.0 ...",

[0173] "status_code": 200

[0174] }

[0175] Different log sources require different parsers from the preprocessing module: a regular expression parser is used for Nginx / Apache logs, a JSON parser is used for JSON-formatted API logs, and a dedicated adapter is used for bastion host logs. All parsed logs are stored in the system log database as the data foundation for subsequent analysis.

[0176] Step S202: Long Short-Term Memory Management and Behavioral Modeling Based on Large Language Models

[0177] The system introduces a "Long Short-Term Memory Network" built on Vector Database (Vector DB) and Key-Value Database (KV DB) to model and maintain the behavior of each accessing entity.

[0178] (1) Entity aggregation and intent modeling

[0179] Specifically, the behavioral trajectory of each accessing entity is continuously aggregated using the client IP address or account ID as the key;

[0180] The system uses the client IP address (client_ip) or account ID (account_id) as the entity identification key to continuously aggregate the access behavior trajectory of each entity. For the same entity, the system concatenates its log records at different time points in a time series to form a complete timeline of the entity's access behavior.

[0181] (2) Long-term memory establishment (Semantic Profiling)

[0182] Specifically, the semantic behavior baseline text generated by the large language model from the analysis of entity historical data is stored in a vector database as long-term memory;

[0183] The large language model periodically (every 15 minutes in this embodiment) analyzes the historical behavior data of each entity and outputs a high-dimensional semantic behavior baseline text. This semantic baseline describes the normal behavior pattern of the entity in the natural language of the large language model, rather than the numerical feature vectors used in traditional solutions.

[0184] For example, for an entity with the IP address "IP_A", the semantic behavior baseline text generated by the large language model is:

[0185] "IP_A typically accesses the API statistics during working hours (09:00-18:00), returning fewer than 50 records each time, and the User-Agent is displayed as a regular browser like Chrome."

[0186] The text is vectorized by the embedding model and stored in a vector database as long-term memory for the entity. The vector database supports efficient semantic similarity retrieval. In subsequent intent recognition steps, the system can quickly obtain the historical semantic baseline most relevant to the current behavior through vector retrieval.

[0187] (3) Short-term working context maintenance

[0188] Specifically, the complete request chain of an entity within the most recent preset time period is cached in a key-value database as a short-term working context.

[0189] The key-value database (KV DB) caches the complete request chain for each entity within the most recent preset time window (15 minutes in this embodiment), including the complete URI of the request, request parameters, response status, timestamp, etc. This short-term memory is used by the large language model for sliding window-style real-time behavior comparison—the large language model can simultaneously obtain the entity's current log data and the complete behavior sequence of the most recent 15 minutes in a single inference, thereby identifying abnormal behavior pattern changes that occur within a short period of time.

[0190] The long-term memory (Vector DB) and short-term memory (KV DB) work together as follows: short-term memory provides real-time behavioral context with millisecond-level response, while long-term memory provides entity behavior profiles across weeks / months. The two complement each other in both time and semantic dimensions.

[0191] Step S203: Semantic Anomaly Analysis and Intent Recognition

[0192] The current log slice is input into the large language model along with the historical semantic baseline of the entity. Deviation analysis is performed through semantic understanding to identify logical unauthorized access, slow credential stuffing, or sensitive interface probing behaviors.

[0193] In each analysis cycle, the system merges the latest structured log slice with the historical semantic behavior baseline of the entity in the vector database and inputs it into the large language model, which then performs deviation analysis based on its understanding of the interface semantics.

[0194] The core innovation of this step lies in the fact that deviation analysis no longer relies on the frequency threshold or fixed regular expression pattern of traditional rule engines, but rather on the large language model to understand the logical deviation between the current behavior and the entity's regular behavior from a semantic level.

[0195] The following are three typical detection scenarios in this embodiment:

[0196] Scenario 1 – Logical Privilege Escalation Detection: Large Language Model (MLM) analysis revealed that although an IP address held a valid session token and its access frequency did not trigger traditional anti-fraud thresholds (e.g., 100 times per minute), it attempted to view the personal information of over 900 users by iterating through the `user_id` parameter from ` / api / v1 / user / 99` to ` / api / v1 / user / 1000` within 10 minutes. The MLM compared this behavior with the baseline of the entity typically only viewing its own information, identifying it as a Horizontal Privilege Escalation attempt and triggering an alert.

[0197] Scenario 2 – Slow Credential Striking Detection: An IP address attempts to log in to the same account with different passwords at a low frequency of once per minute. Traditional solutions fail to trigger anti-fraud thresholds due to the low frequency, but a large language model identifies slow credential stuffing attacks by comparing the IP's request sequence with the account's regular login pattern (usually a single successful login).

[0198] Scenario 3 – Sensitive Interface Probing: An IP address rapidly traverses sensitive paths such as `.git / HEAD`, `.env`, ` / wp-config.php.bak`, and ` / api / admin / debug` in lexicographical order, attempting to probe hidden configuration files or debugging interfaces. The Large Language Model semantically determines that these URIs possess a clear "information probing" intent and marks the IP as a suspicious attacker.

[0199] The above three scenarios all belong to non-signature-based attacks, which are difficult to detect using traditional security solutions due to their reliance on fixed rules or frequency thresholds. The semantic deviation analysis of this invention effectively fills this detection blind spot.

[0200] Step S204: AI-driven database tracing mechanism

[0201] Specifically, the proactive multi-dimensional source tracing query of the log database includes: the large language model intelligent agent autonomously constructing query conditions, initiating multi-round correlation aggregation queries to the system log database containing target entities and time ranges, and reconstructing the complete behavioral chain of the attacker.

[0202] When the large language model identifies suspicious clues in the log analysis of the current cycle (for example, a sensitive configuration modification operation is found in the S203 phase), the large language model agent simulates the forensic behavior of a human security expert who searches through historical logs after discovering an anomaly, and initiates an active query request to the system log database.

[0203] (1) Self-construction of query conditions

[0204] The large language model agent autonomously constructs structured database query conditions based on contextual information from suspicious clues. A typical db_query example is as follows:

[0205] json

[0206] {

[0207] "db_query": {

[0208] "target_table": "system_access_logs",

[0209] "conditions": {

[0210] "client_ip": "198.51.100.42",

[0211] "time_range": "current_time - 24 hours"

[0212] },

[0213] "limit": 100

[0214] }

[0215] }

[0216] ```

[0217] Here, "target_table" specifies the target data table for the query (such as the system access log table), "conditions" specifies the constraints based on suspicious entity characteristics (such as client IP, account ID) and the time range, and "limit" limits the number of records returned in a single query to avoid query overload. The query conditions are generated autonomously by the large language model agent, eliminating the need for manual SQL statement writing. However, query execution is constrained by database security access control policies—the AI ​​agent's query permissions are limited to SELECT read operations, and it cannot perform INSERT, UPDATE, DELETE, or other write operations. Furthermore, the target table for the query is limited to a pre-defined whitelist of log data tables.

[0218] (2) Multi-round association aggregation and attack narrative construction

[0219] After executing the query, the database execution module returns the results to the dialogue context of the large language model. The large language model then performs multi-turn association analysis based on the returned data.

[0220] Round 1: Analyze all access records of suspicious IPs in the past 24 hours to identify their access patterns (such as the detection phase, vulnerability exploitation phase, and privilege maintenance phase).

[0221] The second round: If it is found that the IP has accessed multiple different backend services, further query the log data tables corresponding to these services to expand the scope of association;

[0222] The third round: Based on the correlation results of the first two rounds, the large language model construction includes a complete attack narrative from the attack reconnaissance phase to the payload execution phase.

[0223] Finally, the large language model outputs the attack narrative as a text report, which includes: an attack timeline, attacker IP address, description of attack methods (such as SQL injection / deserialization exploitation), a list of affected resources, a chain of attack evidence (each piece of evidence linked to a specific database record), and recommended response measures. This report can serve as a direct reference for security analysts' incident response, significantly shortening the response time from anomaly detection to reconstructing the full attack picture.

[0224] S300: Two-way collaborative linkage steps: When the intelligent system log analysis step detects an anomaly, it sends a trigger command to the continuous terminal security audit step through the collaborative engine to collect cross-domain data; when the continuous terminal security audit step detects an anomaly, it sends a trigger command to the intelligent system log analysis step through the collaborative engine to trace back historical events; and integrates to generate a complete evidence chain report across system levels.

[0225] In this embodiment, when the intelligent system log analysis step detects an anomaly, sending a trigger command to the terminal specifically includes the following steps:

[0226] Extract suspicious IP addresses and port numbers corresponding to abnormal behavior;

[0227] The collaboration engine automatically matches the backend terminal host group that carries the corresponding business.

[0228] The terminal security continuous audit steps are instructed to initiate immediate specific data collection, focusing on investigating network sockets and associated processes established with the suspicious IPs.

[0229] Furthermore, the process of sending a trigger command to the system when an anomaly is detected during the continuous audit of endpoint security includes the following steps:

[0230] Extract the creation time, hash fingerprint, and executed commands of abnormal processes or files in the terminal;

[0231] The collaborative engine instructs the system log intelligent analysis steps based on the long short-term memory database to trace back all application layer logs before and after the creation time point;

[0232] By using a large language model to correlate and deduce the attack entry point link, the complete attack path from the application layer to the terminal system layer can be reconstructed.

[0233] In summary, for example, collaborative flow A: abnormal system logs trigger in-depth terminal investigation (Top-Down mode).

[0234] Triggering condition: The S203 step of the system log audit subsystem detects abnormal behavior, such as a source IP performing an SQL injection attack against a sensitive API and returning a 500 status code.

[0235] Execution process:

[0236] Step A1: The system log audit detected abnormal behavior (such as unauthorized API calls or sensitive interface traversal).

[0237] Step A2: Extract suspicious association features, including suspicious IP addresses (such as 198.51.100.42), port numbers, request URI patterns, etc.

[0238] Step A3: The large model collaboration engine queries the service-host association mapping table based on the business context in the suspicious features (such as the web service to which the target API belongs) and automatically matches the backend host group (such as Host_Group_A) currently carrying the business.

[0239] The service-host association mapping table is stored in the collaboration engine and is used to record the mapping relationship between business services and their deployed backend host clusters. The mapping table can be constructed in ways including but not limited to: automatically generated based on the configuration management database (CMDB), manually configured and bound by the security administrator through the management interface, or obtained in real-time through the container orchestration platform API to obtain the correspondence between service instances and host machines. The data structure of the mapping table includes at least the fields of service identifier, host IP list, service port, and business tag.

[0240] Step A4: The collaboration module breaks the conventional 5-minute cycle limit of terminal auditing and immediately sends an instant specific collection command to the terminal security continuous auditing subsystem corresponding to Host_Group_A.

[0241] Step A5: The terminal-side large language model agent, carrying prior abnormal feature knowledge (including suspicious IP addresses and descriptions of abnormal behavior) transmitted from the system side, issues specific forensic instructions to the target host. Key areas of investigation include: checking for active network sockets (TCP / UDP connections) established with the malicious IP address; checking whether web application processes (such as Tomcat / Node.js) have generated abnormal child processes or loaded abnormal kernel modules; and checking for suspicious code segments with memory mapping.

[0242] By using real-time, specific data collection carrying prior knowledge, it is possible to capture hidden threats that traditional EDR misses due to periodic full data collection, such as memory malware in a silent state and malicious backdoors that have not been written to disk.

[0243] Collaborative flow direction B: Terminal anomaly triggering system trajectory tracing (Bottom-Up mode)

[0244] Triggering condition: Step S102 of the endpoint security audit subsystem detects abnormal changes in the server status, such as the generation of a binary executable file named `lib_update` in the ` / tmp / ` directory of a certain server, and an unknown script being written into the scheduled task.

[0245] Execution process:

[0246] Step B1: The terminal-side state differential engine detects terminal anomalies (such as the addition of abnormal processes or the tampering of scheduled tasks).

[0247] Step B2: The terminal-side large language model agent extracts key forensic features of the abnormal entity (process / file), such as the creation time T_alert, SHA256 hash fingerprint, parent process ID, and execution command line parameters.

[0248] Step B3: The collaborative engine initiates cross-domain linkage, sends a trigger command to the intelligent polling and analysis subsystem of system logs, and requests historical lookup based on long short-term memory databases (Vector DB and KV DB).

[0249] Step B4: After receiving the instruction, the system log agent uses T_alert as the central time point to look back at all application layer log data within the preset time range before and after T_alert (15 minutes before T_alert to 1 minute after T_alert in this embodiment), focusing on request records containing the host IP address or related to the business service.

[0250] Step B5: The retrospective investigation revealed that 3 seconds before the T_alert occurred, an HTTP request from an external IP accessed the ` / weblogic / wls-wsat / CoordinatorPortType` interface, carrying a large amount of XML data. The large language model, through correlation deduction, determined that the attacker exploited a WebLogic deserialization vulnerability (CVE-2017-10271) to carry out a remote code execution attack. This vulnerability allowed the attacker to download the `lib_update` file from the terminal server and persist it via a scheduled task. The system ultimately compiled this process into a complete chain of evidence report covering the entire process from the application layer entry point (WebLogic deserialization vulnerability exploitation) to the terminal system layer behavior (file download – scheduled task tampering).

[0251] The overall effect of two-way collaboration: Collaborative flow A (Top-Down) and collaborative flow B (Bottom-Up) constitute a complete two-way security closed loop. When either subsystem detects an anomaly, it can automatically trigger the other side to conduct supplementary forensics or tracing, completing cross-domain collaborative analysis without manual intervention. The two collaborative flows can be triggered independently or sequentially within the same security event—for example, the Top-Down mode first discovers attack signs on the system log side and triggers endpoint investigation; after endpoint investigation discovers newly added malicious files, it further triggers the Bottom-Up mode for full-link tracing—thus forming a multi-round progressive security analysis capability.

[0252] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," "a preferred embodiment," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0253] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.< / pid>

Claims

1. A method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents, characterized in that, The method includes the following steps: Endpoint security continuous audit steps: Periodically collect the current operating status data of the terminal host, and compare the current operating status data with the historical health status baseline through state differential filtering; a large language model intelligent agent based on the ReAct inference framework generates tool invocation instructions that conform to the predetermined schema definition based on abnormal change data; after verification by a security sandbox, execute the tool invocation instructions to obtain terminal investigation evidence; based on the terminal investigation evidence, query an external threat intelligence platform, and use a comprehensive judgment decision matrix to qualitatively classify the threat; The intelligent analysis steps of system logs are as follows: periodically poll to obtain system logs and parse them into standardized structures; manage and maintain the behavioral trajectory and semantic baseline of accessing entities through long short-term memory; input the current system logs and historical semantic baselines into the big language model for intent recognition and detect abnormal behavior; when suspicious clues are identified, trigger the big language model agent to actively perform multi-dimensional source tracing queries on the log database. Two-way collaborative steps: When the intelligent system log analysis step detects an anomaly, it sends a trigger command to the continuous endpoint security audit step through the collaborative engine to collect cross-domain data; when the continuous endpoint security audit step detects an anomaly, it sends a trigger command to the intelligent system log analysis step through the collaborative engine to trace back historical events; and integrates to generate a complete evidence chain report across system levels.

2. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 1, characterized in that, In the continuous auditing of terminal security steps, the state differential filtering specifically includes: Using the combination of key entity fields as comparison tuples, the current running state is compared with the historical baseline by attribute-level differential comparison; if there is a comparison tuple in the current state that does not belong to any comparison tuple in the historical baseline, it is determined to be a newly added entity; if the comparison tuple matches but the corresponding attribute has changed, it is determined to be a tampered entity.

3. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 2, characterized in that, The state differential filtering also includes a two-layer whitelist filtering: The first layer is a static administrator whitelist, which filters known legitimate entities by matching paths, wildcards, and fixed SHA256 signatures. The second layer is an AI-driven dynamic learning whitelist, which adds entities that have been judged to be harmless and have no network outreach behavior in multiple consecutive audit cycles to a dynamic whitelist with a set lifespan. If the hash value of an entity in the whitelist changes, the whitelist filtering of that entity will be forcibly revoked. Maintain a grayscale event buffer. When the host triggers high-risk behavior, trace back the entity data that was filtered by the two-layer whitelist within a preset time period.

4. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 1, characterized in that, The security sandbox verification specifically includes: The tool invocation instructions are converted into parameterized arrays for execution to prevent string injection attacks; Equipped with a command regular expression whitelist, allowing only commands that match the preset regular expression pattern to be executed; Block commands that include write, delete, or tamper operations, and intercept redirection characters, pipe characters, and command connectors.

5. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 1, characterized in that, In the intelligent analysis steps of the system logs, the long short-term memory management specifically includes: The behavior trajectory of each accessing entity is continuously aggregated using the client IP address or account ID as the key; The semantic behavior baseline text generated by the large language model through analysis of entity historical data is stored in a vector database as long-term memory. The complete request chain of an entity within the most recent preset time period is cached in a key-value database as a short-term working context.

6. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 5, characterized in that, The intent recognition includes: inputting the current log slice and the historical semantic baseline of the entity into a large language model, performing deviation analysis through semantic understanding, and identifying logical unauthorized access, slow credential stuffing, or sensitive interface probing behaviors.

7. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 1, characterized in that, The proactive multi-dimensional source tracing query of the log database includes: the large language model intelligent agent autonomously constructs query conditions, initiates multi-round correlation aggregation queries to the system log database containing target entities and time ranges, and reconstructs the complete behavioral chain of the attacker.

8. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 1, characterized in that, In the bidirectional collaborative linkage step, the step of intelligent system log analysis sending a trigger command to the terminal when an anomaly is detected specifically includes: Extract suspicious IP addresses and port numbers corresponding to abnormal behavior; The collaboration engine automatically matches the backend terminal host group that carries the corresponding business. The terminal security continuous audit steps are instructed to initiate immediate specific data collection, focusing on investigating network sockets and associated processes established with the suspicious IPs.

9. The method for continuous collaborative security auditing of terminal systems based on large-scale intelligent agents according to claim 1, characterized in that, In the bidirectional collaborative linkage step, the step of continuously auditing terminal security sending a trigger command to the system when an anomaly is detected specifically includes: Extract the creation time, hash fingerprint, and executed commands of abnormal processes or files in the terminal; The collaborative engine instructs the system log intelligent analysis steps based on the long short-term memory database to trace back all application layer logs before and after the creation time point; By using a large language model to correlate and deduce the attack entry point link, the complete attack path from the application layer to the terminal system layer can be reconstructed.

10. A terminal system collaborative security continuous auditing system based on large model intelligent agents, used to implement the terminal system collaborative security continuous auditing method based on large model intelligent agents as described in any one of claims 1 to 9, characterized in that, include: The endpoint security continuous audit subsystem is used for endpoint security continuous auditing procedures. The intelligent polling and analysis subsystem for system logs is used to perform intelligent analysis steps for system logs. The large-model safety decision and collaboration engine is used to execute reasoning decisions for large language model agents and to execute bidirectional collaborative steps.

Images