Artificial intelligence identity and access control method and system

Abstract

This disclosure provides an AI identity identification and access control method and system. The method includes: responding to a system call received by the operating system kernel, obtaining the AI ​​identity of the current process initiating the system call as a first AI identity; determining a target entity and its AI identity based on the type of the system call, wherein the AI ​​identity of the target entity is used as a second AI identity; performing an access control check in a kernel event handling path based on the first AI identity and the second AI identity to determine the current process's permission to execute the system call on the target entity, and generating an access control check result; allowing the system call to continue execution when the access control check result is passed, and preventing the system call from executing when the access control check result is failed.

Description

Technical Field

[0001] This invention relates to the field of operating systems, and in particular to AI identity identification and access control methods and systems. Background Technology

[0002] With the rapid development of generative artificial intelligence (AI) technology, especially the widespread application of large-scale language models and multi-agent systems, AI is gradually moving from cloud services to terminal devices and becoming deeply coupled with operating systems. AI processes within the system undertake core functions such as inference, training, and complex task planning, involving numerous system calls related to process creation, file access, network communication, and shared memory. Simultaneously, security risks arising from AI applications due to issues like prompt injection, model illusions, and jailbreak attacks are becoming increasingly prominent. Malicious AI processes may use high-risk system calls (such as ptrace, mount, and unshare) to perform attacks such as container escape, sensitive file theft, or system damage. Therefore, ensuring the operational security of AI-related entities within the operating system has become a critical issue that urgently needs to be addressed. However, existing operating system kernel security mechanisms are significantly inadequate in addressing these issues. Summary of the Invention

[0003] This disclosure aims to at least partially address one of the technical problems in the related art.

[0004] The first aspect of this disclosure provides an AI identity identification and access control method, applied to an operating system kernel, including the following steps:

[0005] In response to a system call received by the operating system kernel, the AI ​​identity identifier of the current process that initiated the system call is obtained as the first AI identity identifier;

[0006] The target entity and its AI identity identifier are determined based on the type of the system call, and the AI ​​identity identifier of the target entity is used as the second AI identity identifier.

[0007] Based on the first AI identity and the second AI identity, an access control check is performed in the kernel event handling path to determine the current process's permission to execute the system call on the target entity, and an access control check result is generated.

[0008] The system call is allowed to continue execution when the access control check result is passed, and the system call is blocked when the access control check result is failed.

[0009] Optionally, the AI ​​identity identifier includes an AI flag, an AI type field, and a derived source field. The AI ​​flag indicates whether the target object is AI-related. The AI ​​type field indicates the AI ​​type of the target object, which includes native AI processes and derived AI processes. The derived source field indicates the derived scenario of the derived AI process. The target object is the current process or the target entity. The step of performing access control checks to determine the current process's permission to execute the system call on the target entity and generating access control check results includes:

[0010] The first AI identity identifier and the second AI identity identifier are respectively converted into corresponding SELinux type tags. The SELinux type tag corresponding to the first AI identity identifier is used as the subject tag, and the SELinux type tag corresponding to the second AI identity identifier is used as the object tag. The conversion is based on the AI ​​type field and the derived source field in the AI ​​identity identifier.

[0011] Based on the subject label and object label, the SELinux access vector cache is invoked to query the matching historical permission judgment result. If a matching historical permission judgment result is found, the historical permission judgment result is used as the access control check result.

[0012] If no matching historical permission determination result is found, the access control check result is obtained by performing permission determination according to the preset AI type enforcement rule. The preset AI type enforcement rule predefines the allow or deny operation when different subject tags perform system calls on different object tags.

[0013] Optionally, the step of performing access control checks to determine the current process's permission to execute the system call on the target entity and generating access control check results further includes:

[0014] When the access control check result is passed, the system call sequence bound to the first AI identity in the current time window is obtained, and a real-time behavior Merkle tree is constructed based on the system call sequence. A leaf node of the real-time behavior Merkle tree reflects a system call in the system call sequence, a branch node is formed by aggregating several consecutive leaf nodes, and the root node is formed by aggregating branch nodes level by level.

[0015] The real-time behavior Merkle tree is compared with the pre-built behavior baseline Merkle tree using a hierarchical hash comparison, and the final access control check result is determined based on the comparison result.

[0016] Optionally, the pre-built behavioral baseline Merkle tree is constructed in the following way:

[0017] The system call sequence of the current process under normal operating conditions is collected as a baseline sequence, and the baseline sequence is sliced ​​into multiple sub-sequences according to a fixed time window;

[0018] For any subsequence, each system call within the subsequence is mapped to a leaf node of a Merkle tree, and the hash values ​​of the leaf nodes are aggregated sequentially upwards to generate a Merkle tree corresponding to the subsequence as a candidate Merkle tree.

[0019] The candidate Merkle tree with the smallest fluctuation is selected from the candidate Merkle trees corresponding to multiple subsequences as the behavior baseline Merkle tree corresponding to the current process, and the root hash value of the behavior baseline Merkle tree is stored in the read-only memory page of the operating system kernel.

[0020] Optionally, the AI ​​identity identifier further includes a unique derived identifier, which is a unique identifier of the target object in the operating system kernel. The step of mapping each system call within the subsequence to a leaf node of a Merkle tree includes:

[0021] For any system call, obtain the system call number, the hash value of the system call key parameters, the relative timestamp of the system call, and the unique derived identifier in the first AI identity identifier. The relative timestamp reflects the position of the system call within the fixed time window.

[0022] The hash value of the leaf node corresponding to the system call is generated based on the call number, the hash value of the key parameter, the relative timestamp, and the unique derived identifier.

[0023] Optionally, the hierarchical hash comparison of the real-time behavioral Merkle tree with the pre-built behavioral baseline Merkle tree includes the following steps:

[0024] Compare the root hash values ​​of the real-time behavioral Merkle tree with the behavioral baseline Merkle tree;

[0025] If the root hash values ​​match, the system call is deemed safe, and the final access control check result is passed.

[0026] If the root hash values ​​are inconsistent, the hash values ​​of the child nodes are recursively compared layer by layer from the root node until all leaf nodes with mismatched hash values ​​are located. The global difference is calculated based on the number of mismatched leaf nodes and the mismatch ratio of nodes at each layer. When the global difference exceeds a preset threshold, the system call is determined to be insecure, and the final access control check result is failed.

[0027] Optionally, the step of preventing the system call from executing when the access control check result is a failure includes:

[0028] The access control check result is shared to the LSM system call verification hook via eBPF. The LSM system call verification hook is located before the system call core execution path.

[0029] When the current process initiates a system call, the operating system kernel invokes the LSM system call verification hook to perform interception based on the access control check result.

[0030] Optionally, after the step of obtaining the AI ​​identity identifier of the current process that initiated the system call as the first AI identity identifier, the method further includes:

[0031] The operating system kernel pre-configures cgroups control groups corresponding to the native AI process and cgroups control groups corresponding to the derived AI process based on the AI ​​type field in the first AI identity identifier.

[0032] Optionally, the types of system calls include process creation system calls, file or resource creation system calls, inter-process communication system calls, dynamic library loading system calls, and file execution system calls. The step of determining the target entity and the AI ​​identity identifier of the target entity based on the type of system call includes:

[0033] If the system call is a process creation system call and the current process is AI-related, then the target entity is the created child process, the AI ​​type field in the second AI identity identifier is the AI ​​type in the first AI identity identifier, and the derived source field is derived from the parent process.

[0034] If the system call is a file or resource creation system call and the current process is AI-related, then the target entity is the created file or system resource. A second AI identity is generated for the target entity and stored through file system extended attributes. In the second AI identity, the AI ​​type field is a derived AI process and the derived source field is a resource creation derived.

[0035] If the system call is an inter-process communication system call, the current process as the sender is AI-related, and the target process as the receiver is not AI-related, then the target entity and the target process update the second AI identity identifier of the target entity. After the update, the AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is derived from process communication.

[0036] If the system call is a dynamic library loading system call, the target entity is a loading process, and if the loaded shared library has an AI association identifier and the target entity is not AI-related, then the second AI identity identifier of the target entity is updated. After the update, the AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is a dynamically loaded derivative.

[0037] If the system call is a file execution system call, the target entity is the process that executes the target file. If the target file has an AI-generated resource identifier, a second AI identity identifier is generated for the target entity. The AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is either an AI-generated binary execution derivative or an AI script execution derivative.

[0038] A second aspect of this disclosure provides an AI identity and access control system, including:

[0039] The identity acquisition module is used to respond to a system call received by the operating system kernel, acquire the AI ​​identity of the current process that initiated the system call as the first AI identity, determine the target entity and the AI ​​identity of the target entity according to the type of the system call, and use the AI ​​identity of the target entity as the second AI identity.

[0040] The access control module is used to perform access control checks in the kernel event processing path based on the first AI identity and the second AI identity to determine the current process's permission to execute the system call on the target entity, and generate access control check results.

[0041] The execution module allows the system call to continue execution when the access control check result is passed, and prevents the system call from executing when the access control check result is failed.

[0042] Compared with related technologies, the AI ​​identity identification and access control method of this disclosure responds to a system call received by the operating system kernel, obtains the first AI identity of the current process, determines the second AI identity of the target entity according to the system call type, performs access control checks in the kernel event handling path based on the first and second AI identity, and allows or blocks the execution of the system call according to the check results. By identifying AI-related entities and embedding the access control check in the system call execution path of the kernel state layer, permission determination and blocking can be completed before high-risk system calls are actually executed, effectively avoiding illegal access and damage to system resources by malicious AI processes, and significantly improving the security of the operating system. Attached Figure Description

[0043] Figure 1 An organizational structure diagram of an embodiment of the operating system provided in this disclosure;

[0044] Figure 2 A flowchart of an embodiment of the AI ​​identity identification and access control method provided in this disclosure;

[0045] Figure 3 A flowchart of an embodiment of access control checks;

[0046] Figure 4 A flowchart of an embodiment for constructing a behavior baseline Merkle tree;

[0047] Figure 5 A schematic diagram of a Merkle tree embodiment provided in this disclosure. Detailed Implementation

[0048] To better understand this disclosure, various aspects of this disclosure will be described in more detail with reference to the accompanying drawings. It should be understood that these detailed descriptions are merely illustrative of exemplary embodiments of this disclosure and are not intended to limit the scope of this disclosure in any way. Throughout the specification, the same reference numerals refer to the same elements. The expression "and / or" includes any and all combinations of one or more of the associated listed items.

[0049] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0050] The inventors discovered through research that the existing operating system kernel's security mechanisms are significantly inadequate in dealing with the various problems brought about by AI processes, primarily in the following aspects:

[0051] Firstly, the access control policies of existing kernel security components (such as SELinux and AppArmor) are mainly based on traditional attributes such as process ID and user ID. They cannot effectively distinguish whether a process is a native process carrying the core logic of AI or a derivative process derived from or affected by AI. This makes it difficult for the system to implement differentiated permission control for different types of AI entities, and makes it difficult to trace the source of security incidents.

[0052] Secondly, most current security measures for AI applications (such as sandbox isolation, API access control, and behavior monitoring) are implemented in a customized manner at the application layer or container layer. Security components from different vendors and in different scenarios need to be customized and developed. The lack of a unified management framework at the operating system level makes it difficult to reuse underlying basic policies and track cross-component security issues.

[0053] Thirdly, AI application abnormal behavior detection solutions generally adopt a separate architecture of kernel-mode collection and user-mode analysis, which requires multiple context switches and memory copies, resulting in end-to-end latency of milliseconds. Meanwhile, the execution time of high-risk system calls is only in the microsecond range, causing the detection action to always lag behind the attack execution and making it impossible to achieve preemptive blocking.

[0054] Furthermore, since the detection and adjudication logic mainly operates in user space, malicious processes can bypass the detection mechanism by terminating the detection process or tampering with the rule configuration, and attacks involving forgery or identity impersonation are difficult to identify effectively.

[0055] To address at least one of the above technical problems, this disclosure provides an AI identity identification and access control method and system. The AI ​​identity identification and access control method is applied to the operating system kernel. The core improvement of this disclosure is that by adding AI identity identifiers to AI-related entities (including processes, files, shared memory, pipes, message queues, etc.) at the kernel state layer, and performing access control checks in the kernel event handling path based on the AI ​​identity identifiers, the behavior of AI entities can be monitored, thereby improving the security performance of the operating system.

[0056] To better understand the technical solutions disclosed herein, the organizational architecture of the operating system will first be described. For an example, please refer to [reference needed]. Figure 1 , Figure 1 This is a diagram illustrating the hierarchical structure of the Linux operating system, such as... Figure 1 As shown, in the Linux operating system, the kernel mode and the user mode are strictly separated.

[0057] The user-space layer includes a syms configuration tool, an eBPF data parsing tool, an upper-layer security management platform, and existing business applications. The syms configuration tool is used by developers or operations personnel to debug kernel modules, drivers, or system behavior. The eBPF data parsing tool uses eBPF technology to collect system runtime data and analyzes, visualizes, or interactively displays it through AI models to achieve intelligent monitoring, anomaly detection, and performance optimization. The upper-layer security management platform provides a unified security policy management interface for issuing firewall rules and access control policies, and centrally managing network and host security. The existing business applications are the system's original business workload.

[0058] The kernel layer is the core foundation of the system, providing underlying resource management, scheduling, and security frameworks, such as... Figure 1 As shown, the existing operating system kernel space already contains the following basic security components:

[0059] 1. The process management subsystem, whose key structure is task_struct, is used to manage the creation, scheduling, and state transitions of processes;

[0060] 2. The LSM security module, whose key structure is security_manager_open, allows the registration of hook functions on critical kernel paths, providing a unified access point for security modules such as SELinux and AppArmor. Existing hooks are mainly used in traditional security scenarios.

[0061] 3. SELinux module, which includes TE rules, SecurityContext, etc., implements fine-grained permission control based on the type tags of subjects (processes) and objects (files, ports, etc.). Its policies are mainly based on traditional attributes such as process ID and user ID.

[0062] 4. The Cgroupsv2 module is used to limit the CPU, memory and other resources of process groups through control groups.

[0063] 5. eBPF (Extended Berkeley Packet Filter) virtual machine: Allows sandboxed programs to run in the kernel for scenarios such as network filtering, performance monitoring, and security observation.

[0064] 6. Audit system (auditd): Records system call events for security auditing.

[0065] Existing operating systems lack the ability to identify and differentiate AI entities, resulting in the mixed management of AI processes and ordinary processes. This makes it impossible to implement effective real-time defenses against AI-specific security risks (such as prompt injection, model illusion, and jailbreak attacks). AI-related processes, files, shared memory, and other resources lack unified identification in the kernel, making it difficult to match security policies and trace cross-component security issues.

[0066] To address the aforementioned issues, this disclosure proposes an AI identity and access control architecture based on native kernel-level support. For example... Figure 1 As shown, this architecture makes minimal intrusive extensions to the existing Linux kernel state layer, specifically including the following modules:

[0067] 1. AI Identity Verification Module

[0068] This module is responsible for establishing unified AI identities for AI-related entities at the operating system kernel level. Specifically, it extends the process control block (task_struct) to add AI flags, AI type fields, derived source fields, parent AI process identifiers, and tamper-proof checksums. For resources such as files, AI identities are stored through extended attributes (xattr). This module is also responsible for the initialization, reading, updating, and verification of AI identities, distinguishing AI entities from traditional entities.

[0069] 2. AI-powered Identity Verification and Leakage Propagation Engine

[0070] This engine is responsible for the automatic propagation of AI identity identifiers within the operating system. Taint propagation logic is embedded in the LSM hooks of critical system calls, covering more than ten derivative scenarios, including process creation (fork, clone), resource creation (open, shmget, pipe), inter-process communication (msgrcv, shmat), dynamic library loading (mmap corresponding to dlopen), file execution (execve), and container mounting. For example, when an AI process creates a child process, the taint propagation engine automatically marks the child process as a derived AI process (ai_origin=0x01); when a non-AI process modifies AI-generated resources, the engine marks that non-AI process as a derived AI process (ai_origin=0x03). Through comprehensive propagation rules, it ensures that any process or resource affected by AI can be marked.

[0071] 3. AI Access Control Engine

[0072] This engine is publicly responsible for performing access control checks based on AI identity identifiers. For example... Figure 1 As shown, the engine employs a layered inspection mechanism, sequentially performing static permission checks and dynamic behavior checks within the system call path to control AI entities. It primarily comprises a two-layer structure:

[0073] (1) Static Permission Check Layer: This layer is deeply integrated with the SELinux framework, mapping AI identity identifiers to SELinux type labels. Specifically, when a system call occurs, the access control engine converts the first AI identity identifier of the current process into a subject label (such as native_ai_t or derived_ai_t), and converts the second AI identity identifier of the target entity into an object label (such as ai_resource_t). Then, it calls the SELinux Access Vector Cache (AVC) to determine permissions: if the cache is hit, the historical determination result is returned directly; if it is not hit, the determination is made according to the preset AI type enforcement rule (TE rule).

[0074] As can be seen, this static permission check improves upon existing hook functions by embedding taint propagation logic in the LSM hook, using the eBPF virtual machine, and leveraging the SELinux and Cgroupsv2 modules to monitor AI-related derivative processes. Finally, it uses an auditing system to mark AI entities, thereby enabling the identification of some AI derivative processes.

[0075] (2) Dynamic behavior inspection layer

[0076] If the static permission check passes, and the system has enabled the behavior baseline detection function, then a dynamic behavior check will be performed. Specifically, this layer maintains a behavior baseline Merkle tree for each AI process. For system calls initiated by the current process, a real-time behavior Merkle tree is constructed, and the safety of the system call is determined by comparing the real-time behavior Merkle tree with the behavior baseline Merkle tree.

[0077] Regardless of whether it's a static or dynamic check, the final access control check results are shared to the LSM system call verification hook via eBPF.

[0078] 4. AI Process Resource Management Engine

[0079] This engine uses cgroupsv2 to implement resource isolation and dynamic quota adjustment for AI processes. It pre-creates a dedicated cgroups control group subtree for each AI process and automatically associates processes with the corresponding control groups based on the AI ​​type field. When the AI ​​behavior monitoring engine detects high-risk anomalies (such as frequent calls to sensitive system calls, model file checksum mismatches, or container escape characteristics), the AI ​​process resource management engine automatically moves the process to a restricted control group and dynamically adjusts resource quotas (e.g., limiting CPU usage to below 10% and reducing memory limits to 1 / 4 of the original quota).

[0080] 5. eBPF Data Acquisition and Sharing Module

[0081] This module is responsible for lightweight data acquisition and cross-module information sharing. In kernel mode, it is mounted at system call entry points (tracepoints) and LSM hooks via eBPF programs to collect system call and access control check results. Simultaneously, this module maintains an eBPF global hash map for sharing anomaly detection results between the AI ​​behavior monitoring engine and the AI ​​access control engine: the behavior monitoring engine writes its results to the map, and the access control engine reads its results from the map. This module is also responsible for pushing abnormal events to the user-space security platform via the eBPF circular buffer to trigger alarms; this will not be elaborated upon in this disclosure.

[0082] 6. Kernel-mode sysfs configuration interface, which supports user-mode manual marking of AI entities by specifying PID / file path / network port, and supports batch marking (such as specifying all files in a directory as AI-generated resources), for special scenarios of automated failure determination.

[0083] Those skilled in the art will understand that, based on the above overall improvement approach, the embodiments of this disclosure provide an AI identity identification and access control method, for example, such as... Figure 2 As shown, it includes the following steps:

[0084] Step S101: In response to the system call received by the operating system kernel, obtain the AI ​​identity identifier of the current process that initiated the system call as the first AI identity identifier.

[0085] In this embodiment of the disclosure, a system call is an interface through which a user-mode program requests services from the operating system kernel, such as file operations, process control, and network communication. The current process is the process that initiates the system call.

[0086] AI identity identifiers are a set of structured attribute data maintained at the operating system kernel level. They are used to identify whether an entity (process, file, memory region, etc.) is related to artificial intelligence, and the specific type and source of that relationship. The first AI identity identifier is the AI ​​identity identifier of the current process. After obtaining the first AI identity identifier, if the current process is AI-related, step S102 is executed; otherwise, if the current process is not AI-related, the traditional operating system permission check mechanism is used.

[0087] Step S102: Determine the target entity and its AI identity identifier based on the type of the system call, and use the target entity's AI identity identifier as the second AI identity identifier.

[0088] In this embodiment of the disclosure, the type of system call is the category of operation performed by the system call, such as process creation, file operation, inter-process communication, etc.

[0089] The target entity is the object of the system call operation, such as a created child process, an opened file, or accessed shared memory. The second AI identity is the AI ​​identity of the target entity. Determining the AI ​​identity of the target entity involves: generating an AI identity for the target entity if it is being created for the first time; or updating an existing AI identity.

[0090] Step S103: Based on the first AI identity identifier and the second AI identity identifier, perform an access control check in the kernel event handling path to determine the current process's permission to execute the system call on the target entity, and generate an access control check result.

[0091] The kernel event handling path is the code execution path for the operating system kernel to handle system calls. This disclosure embeds access control checking logic within this path.

[0092] Access control checks determine whether a subject (the current process) is permitted to perform a current operation (i.e., a system call) on an object based on the identity attributes of the subject (the current process) and the object (the target entity). Access control checks result in two states: passed and failed.

[0093] Step S104: If the access control check result is passed, the system call is allowed to continue execution; if the access control check result is failed, the system call is blocked from execution.

[0094] When the access control check passes, the system call executes normally; when the access control check fails, the kernel returns an error code directly, preventing the system call from executing.

[0095] Compared with related technologies, the AI ​​identity identification and access control method of this disclosure responds to a system call received by the operating system kernel, obtains the first AI identity of the current process, determines the second AI identity of the target entity according to the system call type, performs access control checks in the kernel event handling path based on the first and second AI identity, and allows or blocks the execution of the system call according to the check results. By identifying AI-related entities and embedding the access control check in the system call execution path of the kernel state layer, permission determination and blocking can be completed before high-risk system calls are actually executed, effectively avoiding illegal access and damage to system resources by malicious AI processes, and significantly improving the security of the operating system.

[0096] Optionally, the AI ​​identity identifier includes an AI flag, an AI type field, and a derived source field. The AI ​​flag indicates whether the target object is AI-related. The AI ​​type field indicates the AI ​​type of the target object, which includes native AI processes and derived AI processes. The derived source field indicates the derived scenario of the derived AI process. The target object is the current process or the target entity. Wherein:

[0097] The AI ​​flag is a Boolean value (0 or 1) that indicates whether the target object is AI-related. A value of 1 indicates that the object is an AI-related entity, and a value of 0 indicates that it is not an AI-related entity.

[0098] The AI ​​type field indicates the AI ​​type of the target object. In this disclosure, the AI ​​type includes at least two types: "native AI process" and "derived AI process". Among them, the "native AI process" is the process that directly carries the core AI logic, such as the process that runs large language model inference, the main process of AI training tasks, etc.; the "derived AI process" is the process that is derived from or influenced by the native AI process through fork, exec, dynamic library loading, inter-process communication, etc.

[0099] The Derivation Source field is used to indicate the derivation scenario of the derived AI process, such as parent process derivation, AI execution generating file derivation, dynamic loading of AI shared library derivation, inter-process communication derivation, etc.

[0100] In some embodiments, the AI ​​identity may further include a checksum field, which stores a tamper-proof checksum of the AI ​​identity. Each time the AI ​​identity is read, the kernel recalculates the hash value of the current field and compares it with the stored `ai_checksum`. If they do not match, the identity is determined to have been tampered with, the current system call is rejected, and an audit log is recorded to prevent malicious processes from forging or tampering with the AI ​​identity to bypass the security mechanism. In the operating system kernel, the AI ​​identity can be stored in an extended field of the process control block (`task_struct`). Taking the Linux kernel as an example, the following fields can be added to `task_struct`:

[0101] structtask_struct{

[0102] / / ...existing fields...

[0103] unsigned intai_flag; / / AI flag, 0: non-AI process, 1: AI process

[0104] unsignedchar ai_type; / / AI type, 0x01: native AI process, 0x02: derived AI process

[0105] unsigned int parent_ai_id; / / Unique identifier for the parent AI process (for native processes, it's its own PID)

[0106] unsignedcharai_origin; / / Derived source, such as 0x01 derived from the parent process, 0x06 derived from the AI-generated file, etc.

[0107] unsigned intai_checksum; / / Anti-tampering checksum

[0108] };

[0109] Among them, ai_flag is the AI ​​flag, which the kernel uses to quickly determine whether a process is AI-related; ai_type is the AI ​​type, used to distinguish between native AI processes and derived AI processes, so as to implement differentiated management strategies; parent_ai_id is the unique identifier of the parent AI process, used to trace the derivative chain of AI processes, which is convenient for tracing security incidents; ai_origin is the origin, which records in detail how the process became an AI-related process, such as through fork inheritance, execution of AI-generated files, or being marked through inter-process communication; ai_checksum is the checksum field, which is also a tamper-proof checksum, obtained by hashing (such as SHA-256) the key fields of AI identification (ai_flag, ai_type, parent_ai_id, ai_origin), and is used to prevent malicious processes from forging AI identity identifiers.

[0110] In specific implementation, a read-only AI framework feature library is maintained in kernel mode. This feature library stores the MD5 values ​​of known AI framework dynamic libraries, core API function addresses, and features of common model file formats (such as .pth and .ckpt). When a process is created, the kernel scans its loaded dynamic libraries. If any AI framework matches in the feature library, its AI flag is automatically set to 1 and its AI type field is set to native AI process (e.g., 0x01) through the module described above. Furthermore, this embodiment also provides a manual labeling mechanism. The operating system kernel exposes a sysfs interface (e.g., / sys / kernel / ai_identity / manual_mark), allowing administrators with CAP_SYS_ADMIN privileges to manually mark AI entities by specifying the PID, file path, or network port. This interface supports batch labeling (e.g., specifying all files in a directory as AI-generated resources) for automated failure detection in special scenarios.

[0111] For resources such as files and shared memory, AI identities can be stored through file system extended attributes (xattr), for example:

[0112] user.ai_attr="ai_type=0x03;creator_ai_id=1234;resource_type=file;checksum=0xabcdef".

[0113] Correspondingly, such as Figure 3 As shown, the step of performing access control checks to determine the current process's permission to execute the system call on the target entity and generating access control check results includes:

[0114] Step S201: Convert the first AI identity identifier and the second AI identity identifier into corresponding SELinux type tags respectively. The SELinux type tag corresponding to the first AI identity identifier is used as the subject tag, and the SELinux type tag corresponding to the second AI identity identifier is used as the object tag. The conversion is based on the AI ​​type field and the derived source field in the AI ​​identity identifier.

[0115] SELinux is the mandatory access control (MAC) module in the Linux kernel. It controls access permissions by assigning type labels to subjects (processes) and objects (files, ports, etc.) in the system and defining type enforcement (TE) rules.

[0116] In this embodiment, the SELinux type system is expanded to include AI-specific types, such as native_ai_t (native AI process type), derived_ai_t (derived AI process type), and ai_resource_t (AI generated resource type). The conversion function dynamically generates the corresponding SELinux type label based on the values ​​of ai_type and ai_origin.

[0117] Step S202: Based on the subject tag and object tag, call the SELinux access vector cache to query the matching historical permission judgment result. If a matching historical permission judgment result is found, proceed to step S203. If no matching historical permission judgment result is found, proceed to step S204.

[0118] Step S203: Use the historical permission determination result as the access control check result.

[0119] Specifically, SELinux's Access Vector Cache (AVC) is used to cache recent permission determination results, i.e., historical permission determination results, to avoid duplicate calculations. Once the subject and object labels are determined, the system calls the AVC query interface. If the corresponding determination result exists in the access vector cache, it is returned directly.

[0120] Step S204: Obtain access control check results by performing permission determination according to preset AI type enforcement rules. The preset AI type enforcement rules predefine the allow or deny operations when different subject tags perform system calls on different object tags.

[0121] If the AVC rule is not matched, permission determination will be made according to the pre-configured TE rule (pre-defined AI type mandatory rule). For example:

[0122] #Allow native AI processes to read and write AI-generated resources

[0123] allownative_ai_tai_resource_t:file{readwrite};

[0124] #Prohibit derivative AI processes from accessing sensitive kernel files

[0125] denyderived_ai_tkernel_sensitive_t:file{readwrite};

[0126] If the access control check fails after steps S203 and S204, then step S208 is executed.

[0127] The dynamic behavior inspection layer disclosed herein will be described in detail below.

[0128] To further match non-preset behaviors driven by LLM Agent semantics, and to avoid bypassing static identity markers through modified frameworks, container isolation, etc., in some embodiments, the step of performing access control checks to determine the current process's permission to execute the system call on the target entity and generating access control check results further includes:

[0129] Step S205: When the access control check result is passed, obtain the system call sequence bound to the first AI identity within the current time window, and construct a real-time behavior Merkle tree based on the system call sequence. A leaf node of the real-time behavior Merkle tree reflects a system call within the system call sequence, a branch node is formed by aggregating several consecutive leaf nodes, and the root node is formed by aggregating branch nodes level by level.

[0130] The current time window is a fixed-length time period, such as 5 minutes, which stores the latest system calls. The system call sequence is a chronological order of all system calls initiated by the current process within this current time window.

[0131] In this disclosure, the real-time behavioral Merkle tree is a Merkle tree dynamically constructed based on the system call sequence of the current process within the current time window. A leaf node reflects a single system call within the system call sequence, branch nodes are aggregated from several consecutive leaf nodes, and the root node is formed by aggregating branch nodes upwards level by level.

[0132] In some embodiments, the real-time behavior Merkle tree is constructed incrementally to avoid the overhead of recalculating the entire tree for each new system call, which will not be elaborated upon in this disclosure.

[0133] Specifically, the operating system kernel maintains a real-time behavior Merkle tree for each AI process, with a structure completely identical to the behavior baseline Merkle tree (same leaf node aggregation granularity, same tree height). When an AI process generates a new system call, the kernel performs the following incremental update operations:

[0134] Operation 1: Add a new leaf node. Based on the system call number, key parameter hash value, relative timestamp, and the unique derived identifier of the current process, calculate the new leaf node hash value leaf_hash_new, and insert it as the rightmost leaf node of the tree.

[0135] Operation 2: Update branch nodes level by level. Starting from the newly inserted leaf node, update the hash value of its parent branch node level by level upwards. The hash value of each branch node is recalculated as the SHA-256 hash of the concatenation of the hash values ​​of all its child nodes. Since each update only affects the nodes on the path from the leaf node to the root node (a total of log₂n nodes), the time complexity of a single insertion operation is O(logₙ), where n is the total number of leaf nodes in the current time window.

[0136] Operation 3: Incremental Update During Window Sliding. When the current time window ends and a new window begins, the kernel performs a window switching operation: the entire real-time behavior Merkle tree of the original time window is discarded, and a new real-time behavior Merkle tree is reconstructed based on the system call sequence of the new time window. Since the new time window overlaps with the old time window (sliding window mechanism), the kernel can reuse part of the hash chain of the previous window, further reducing the amount of computation.

[0137] Through the above incremental construction method, the maintenance overhead of the real-time behavior Merkle tree is logarithmically related to the number of system calls within the window, rather than linearly.

[0138] Step S206: Perform a hierarchical hash comparison between the real-time behavior Merkle tree and the pre-built behavior baseline Merkle tree, and determine the final access control check result based on the comparison result.

[0139] After step S206, if the access control check fails, step S208 is executed; if it passes, step S207 is executed.

[0140] Step S207: Allow the system call to continue.

[0141] Step S208: Refuse to execute the system call.

[0142] The behavioral baseline Merkle tree is a Merkle tree pre-constructed during the normal operation of the AI ​​process, representing its normal behavioral pattern. In this embodiment, the AI ​​identity identifier further includes a unique derived identifier (unique_id), which is a unique identifier for the target object within the operating system kernel.

[0143] It's important to note that each AI process corresponds to a behavioral baseline Merkle tree. For any AI process, such as the current process, its behavioral baseline Merkle tree corresponds to the current process's AI identity identifier (first AI identity identifier). In other words, each AI process has its own independent behavioral baseline Merkle tree bound to its identity. The construction process of the behavioral baseline Merkle tree collects the system call sequence of a specific AI process, and its root hash value is stored in a kernel read-only memory page, associated with the AI ​​identifier field in the process's `task_struct`. Therefore, the behavioral baselines of different AI processes are independent of each other and do not interfere with each other.

[0144] The hierarchical hash comparison starts from the root node and compares the hash values ​​of the corresponding nodes of the real-time behavior Merkle tree with the behavior baseline Merkle tree layer by layer to determine whether the behavior deviates from the normal pattern.

[0145] Compared with related technologies, this embodiment introduces an anomaly detection mechanism based on behavior patterns on the basis of traditional identity-based access control. In this way, even if an AI process has a legitimate AI identity, if its behavior pattern deviates from the pre-established baseline (for example, it does not call ptrace under normal circumstances, but suddenly tries to call it), it will be judged as unsafe and refused to execute. This method provides an effective means to prevent new attacks such as prompt word injection and model jailbreaking.

[0146] In some embodiments, such as Figure 4 As shown, the pre-built behavioral baseline Merkle tree is constructed in the following way:

[0147] Step S301: Collect the system call sequence of the current process in normal operation as a reference sequence, and slice the reference sequence into multiple sub-sequences according to a fixed time window.

[0148] The normal operating state refers to the stable running state of the AI ​​process under conditions of no attacks and no anomalies. The operating system determines this state through machine learning or administrator labeling. The collected system call sequence is called the baseline sequence. This sequence is then sliced ​​into multiple subsequences according to fixed time windows (e.g., 5 minutes).

[0149] Step S302: For any subsequence, map each system call within the subsequence to a leaf node of a Merkle tree, and aggregate sequentially upwards based on the hash value of the leaf node to generate a Merkle tree corresponding to the subsequence as a candidate Merkle tree.

[0150] For each subsequence within a fixed time window, a Merkle tree is constructed as a candidate Merkle tree. Leaf nodes correspond to a single system call. The aggregation rule is as follows: aggregate k consecutive leaf nodes (e.g., 10) into a branch node. The hash value of the branch node is the SHA-256 hash of the concatenation of the hash values ​​of its child nodes. This process is repeated upwards until the root node is generated.

[0151] Step S303: Select the candidate Merkle tree with the smallest fluctuation from the candidate Merkle trees corresponding to multiple subsequences as the behavior baseline Merkle tree corresponding to the current process, and store the root hash value of the behavior baseline Merkle tree in the read-only memory page of the operating system kernel.

[0152] Among them, the Merkle tree with the smallest fluctuation is the one that differs the least from all other candidate Merkle trees. The Merkle tree with the smallest fluctuation represents the stable behavior pattern of the AI ​​process. In practice, this can be determined by comparing the differences in the root hash values ​​of each candidate Merkle tree or by calculating the edit distance between adjacent time window trees, which will not be elaborated in this disclosure.

[0153] Once selected, the root hash value R_base of the behavior baseline Merkle tree is stored in a read-only memory page of the operating system kernel (e.g., set via the set_memory_ro() function). Any subsequent attempt to write to this memory page (whether by a user-space process or a kernel thread) will trigger a page fault and be intercepted by the kernel. Simultaneously, the physical page frame containing the root hash value is marked as a reserved page, prohibiting swapping out or remapping, thus forming an immutable behavior trust anchor.

[0154] The embodiments disclosed herein ensure the stability of the behavioral baseline Merkle tree through multi-window sampling and fluctuation filtering; and prevent malicious processes from tampering with the baseline by storing the root hash value in a read-only memory page.

[0155] It should be noted that for any AI process, when the normal business iteration of the AI ​​process requires updating the behavior baseline Merkle tree, the administrator is only allowed to trigger the update through the corresponding sysfs kernel interface (such as / sys / kernel / ai_identity / update_baseline). The update uses the RCU mechanism to atomically replace the baseline pointer without affecting the normal detection logic. At the same time, the baseline version number is updated and version rollback is prohibited to ensure the traceability and security of the baseline.

[0156] In one possible implementation, the AI ​​identity further includes a unique derived identifier, which is a unique identifier of the target object in the operating system kernel. The step of mapping each system call within the subsequence to a leaf node of a Merkle tree includes:

[0157] Step B1: For any system call, obtain the call number of the system call, the hash value of the key parameters of the system call, the relative timestamp of the system call, and the unique derived identifier in the first AI identity identifier. The relative timestamp reflects the position of the system call within the fixed time window.

[0158] The system call number is a unique identifier assigned by the operating system kernel to each system call (e.g., 0 for `read` and 1 for `write` in Linux), used to uniquely identify the type of system call. The hash value of key parameters is obtained by hashing key parameters affecting access control in the system call (such as the file path for `open` and the parameter array for `execve`). This disclosure uses hash values ​​instead of the original parameters to ensure uniqueness while avoiding storing excessively large parameter data. The relative timestamp reflects the position of the system call within the fixed time window, such as the number of milliseconds from the start of the fixed time window, used to distinguish between identical calls but different sequences of actions. The unique derived identifier is a unique identifier for the AI ​​process within the operating system kernel. It can be generated by combining the process PID with its parent process information, creation time, etc., ensuring uniqueness throughout the entire system lifecycle. It is used to bind the action sequence to a specific AI entity, preventing forgery.

[0159] Step B2: Generate the hash value of the leaf node corresponding to the system call based on the call number, the hash value of the key parameter, the relative timestamp, and the unique derived identifier.

[0160] In practice, the generated leaf node hash value can be represented as:

[0161] leaf_hash=SHA256(syscall_num||args_hash||relative_ts||unique_id)

[0162] Where || represents byte concatenation operation, syscall_num represents the call number, args_hash represents the hash value of the key parameters, relative_ts represents the relative timestamp, and unique_id represents the unique derived identifier.

[0163] By setting up the mapping between system calls and leaf nodes as shown above, it is possible to capture the behavior changes of any AI process through hashing.

[0164] Specifically, let the collision-resistant hash function be H(·). This disclosure uses the SHA-256 algorithm, whose output length is 256 bits, and the collision probability is negligible. For a binary Merkle tree, its leaf node set L={l1,l2,…,l…} n}, where l i =H(d i ), l i Let d represent the i-th leaf node. i This refers to the original data corresponding to the i-th leaf node (i.e., the system call number, the hash value of the key parameters, the relative timestamp, and the unique derived identifier). For an example, please refer to [reference needed]. Figure 5 , Figure 5 This is a schematic diagram of a Merkle tree embodiment, where each leaf node l i For a single system call, branch node h i (For example, h1, h2) are composed of several leaf nodes. The root hash value R is the unique fingerprint of the entire tree, representing the complete characteristics of the AI ​​process's system call behavior within the corresponding time window. Here, || represents byte-level concatenation, and the root node R is the final hash value of the entire tree. From the collision resistance of hash functions, the core theorem can be derived: the original data d of any leaf node... i A change will inevitably lead to a change in the hash value of its parent node, grandparent node, and even the root node R; conversely, if the root hash R of two Merkle trees is completely identical, then the original data of all leaf nodes of the two trees will be completely identical.

[0165] Based on the above principles, this disclosure establishes a one-to-one mapping relationship between system call behavior and Merkle tree nodes. Through this mapping relationship, it can be guaranteed that any behavior change can be captured by hash, and any two different system calls will inevitably generate different d. i The same system call will inevitably generate the same d i .

[0166] This embodiment of the disclosure uses the call number, parameter hash, timestamp, and unique identifier as hash inputs to ensure that any two different system call behaviors (including different call types, different operation objects, different execution orders, and different callers) will generate different leaf node hash values. Simultaneously, because it includes a unique derived identifier, the same behavior of different AI processes will also generate different leaf node hash values, achieving a strong binding between behavior and identity, and preventing attackers from bypassing detection by forging behavior sequences.

[0167] In some embodiments, the hierarchical hash comparison of the real-time behavioral Merkle tree with the pre-built behavioral baseline Merkle tree includes the following steps:

[0168] Step C1: Compare the root hash values ​​of the real-time behavioral Merkle tree with those of the behavioral baseline Merkle tree.

[0169] Step C2: If the root hash value matches, the system call is deemed safe, and the final access control check result is passed.

[0170] The root hash of the real-time behavior Merkle tree is exactly the same as the root hash of the behavior baseline Merkle tree, indicating that all system call behaviors (including call order, key parameters, and time intervals) within the current time window are completely consistent with normal behavior, and therefore it is determined to be safe.

[0171] Step C3: If the root hash values ​​are inconsistent, recursively compare the hash values ​​of child nodes layer by layer from the root node until all leaf nodes with mismatched hash values ​​are located. Calculate the global difference degree based on the number of mismatched leaf nodes and the mismatch ratio of nodes at each layer. When the global difference degree exceeds a preset threshold, the system call is determined to be insecure, and the final access control check result is "failed".

[0172] At this point, step S104 specifically means that the system call is rejected if the access check control result is not passed, or if the access check result is passed but the final access check result is not passed, and the system call is continued to be executed if both the access check result and the final access check result are passed.

[0173] When the root hash values ​​are inconsistent, the algorithm starts from the root node and compares the hash values ​​of the child nodes layer by layer, only recursively entering branches with mismatched hash values, thus quickly locating all leaf nodes with mismatched hash values ​​(i.e., abnormal system calls). For example, for a binary Merkle tree with n leaf nodes, the specific comparison process for steps C1 to C3 is as follows: compare the root node hash values ​​of the real-time behavioral Merkle tree and the behavioral baseline Merkle tree; if the root node hash values ​​are inconsistent, proceed to the next level and compare the hash values ​​of the left and right child nodes of the two root nodes; for child nodes with inconsistent hash values, continue recursively comparing downwards until all leaf nodes with mismatched hash values ​​are located; for child nodes with consistent hash values, their entire subtree is considered normal and no further comparison is needed, thus significantly improving comparison efficiency.

[0174] For example, if a Merkle tree has n leaf nodes, then the height of the tree is log₂n. When it is necessary to determine whether the current system call deviates from the baseline, the comparison engine performs the following operations: First, it compares the hash values ​​of the root node, with each comparison taking constant time; if the root node is inconsistent, it compares the hash values ​​of the child nodes layer by layer, only entering the branches where the hashes do not match at each step.

[0175] Furthermore, to quantify the degree of deviation in system call behavior when the root hash values ​​do not match, this embodiment defines the hierarchical difference degree D_h as the proportion of the number of branch nodes with mismatched hash values ​​at the h-th level to the total number of nodes at that level, which can be expressed as:

[0176] D_h = (N_mismatch_h / N_total_h) × 100%

[0177] Where N_mismatch_h is the number of branch nodes with mismatched hash values ​​at layer h, and N_total_h is the total number of branch nodes at layer h.

[0178] Since the levels closer to the leaf nodes reflect the changes in a single system call more effectively, different weighting coefficients are set for different levels. The weighting coefficient for the h-th level is denoted as w_h. For example, w_0 = 0.6 is used for the leaf level (h=0), w_1 = 0.3 is used for the first-level branch (h=1), and w_h = 0.1 is used for the second-level branch and above (h≥2).

[0179] The formula for calculating the global dissimilarity D is:

[0180] D=Σ(w_h × D_h)

[0181] When the global difference D is greater than or equal to the preset difference threshold D th If the behavior is deemed abnormal, the system call is considered unsafe; otherwise, it is considered safe. The global difference degree D can accurately quantify the degree of behavioral deviation, distinguishing between isolated, occasional anomalies and overall behavioral pattern drift, thus avoiding misjudging isolated anomalies as serious attacks.

[0182] In some embodiments, to avoid a preset difference threshold D th To address the misjudgment caused by using a fixed threshold, a dual-threshold model combining a static base threshold and a dynamic adaptive threshold can be employed. The specific solution is as follows:

[0183] The static base threshold D_th_base is preset based on the type of AI process. For example, it is preset to 20% for AI Agent scenarios, 35% for AI inference scenarios, and 50% for AI training scenarios.

[0184] The dynamic adaptive threshold D_th_dynamic is adjusted based on the baseline fluctuation range of the AI ​​process's historical behavior, and its calculation formula is as follows:

[0185] Dth_dynamic=Dth_base+α×σ

[0186] Where σ is the standard deviation of the difference over 10 historical time windows, and α is the adaptive coefficient (default α=2), used to adapt to the normal behavioral fluctuations of the AI ​​process.

[0187] The final threshold is the larger of the two values, namely D. th =max(Dth_base,Dth_dynamic).

[0188] In some embodiments, the step of preventing the execution of the system call when the access control check result is a failure includes:

[0189] The access control check result is shared to the LSM system call verification hook via eBPF. The LSM system call verification hook is located before the system call core execution path.

[0190] When the current process initiates a system call, the operating system kernel invokes the LSM system call verification hook to perform interception based on the access control check result.

[0191] In this embodiment, the access control check result is written into an eBPF global hash map, and an LSM system call verification hook is registered in kernel mode. This hook is located before the core execution path of the system call. Since the actual execution time of high-risk system calls is usually greater than or equal to 1 microsecond, this solution can block the system call before it is actually executed. Furthermore, because both the eBPF map and the LSM system call verification hook run in kernel mode, malicious processes in user mode cannot terminate or tamper with the detection logic, fundamentally solving the problem of easy bypassing of detection and greatly enhancing security. It is understood that when the access control check adopts a detection mechanism combining static detection based on AI identity and anomaly detection based on dynamic behavior, both the access control check result and the final access control check result will be written into the eBPF global hash map.

[0192] In some embodiments, after obtaining the AI ​​identity identifier of the current process that initiated the system call as the first AI identity identifier, the method further includes: assigning a corresponding cgroups control group to the current process according to the AI ​​type field in the first AI identity identifier, wherein the operating system kernel pre-configures a cgroups control group corresponding to the native AI process and a cgroups control group corresponding to the derived AI process.

[0193] The cgroups control group is used to limit, record, and isolate the physical resources used by the process group. In this embodiment, the operating system kernel pre-creates the cgroups control group corresponding to the AI ​​process during the initialization phase, and the two control groups are configured with different resource quotas and access restriction policies respectively.

[0194] Native AI process control group ( / sys / fs / cgroup / ai / native / ): Because native AI processes carry core AI logic (such as large language model inference and training tasks), they require high computing resources. Example configuration: 80% CPU quota, 32GB memory limit, access to GPU devices allowed, and unlimited network bandwidth.

[0195] Derived AI process control group ( / sys / fs / cgroup / ai / derived / ): Derived AI processes are derived from or influenced by native AI processes, typically undertaking auxiliary tasks and having low resource requirements. Example configuration: CPU quota 20%, memory limit 8GB, GPU device access prohibited, network bandwidth limited to 100Mbps. Of course, the above specific data values ​​are merely examples, and this disclosure is not limited to these.

[0196] When the operating system kernel receives a system call and obtains the first AI identity identifier of the current process, it first assigns the corresponding cgroups control group to the current process based on the AI ​​type field in the first AI identity identifier before continuing to perform subsequent access control checks.

[0197] In practice, the kernel completes the association through the following process: It reads the `ai_type` field from the `task_struct` of the current process, determines whether it is a native AI process or a derived AI process. If `ai_type` is a native AI process, the target control group path is ` / sys / fs / cgroup / ai / native / `; if `ai_type` is a derived AI process, the target control group path is ` / sys / fs / cgroup / ai / derived / `; if it is a non-AI process, cgroups association is not performed, and the original control group remains unchanged. The kernel writes the PID of the current process to the `cgroup.procs` file of the target control group, automatically includes the process in the corresponding control group, and immediately applies the group's preset resource quota and access restriction policies.

[0198] Through the above cgroups control group allocation mechanism, different resource quotas can be obtained for native AI processes and derived AI processes respectively, ensuring that core AI tasks have sufficient computing resources; and cgroups control groups are automatically allocated based on the type field of AI identity identifier, realizing automated management of identity recognition and resource allocation, reducing the complexity of operation and maintenance.

[0199] When the AI ​​behavior monitoring engine detects high-risk anomalies (such as frequent process calls to sensitive system calls, model file checksum mismatch, container escape characteristics), the kernel can perform cgroups-linked degradation operations, and this disclosure does not impose any restrictions on this.

[0200] In some embodiments, the types of system calls include process creation system calls, file or resource creation system calls, inter-process communication system calls, dynamic library loading system calls, and file execution system calls.

[0201] The steps for determining the target entity and its AI identity identifier based on the type of the system call include:

[0202] If the system call is a process creation system call (such as fork, clone) and the current process is AI-related, then the target entity is the created child process, the AI ​​type field in the second AI identity identifier is the AI ​​type in the first AI identity identifier, and the derived source field is derived from the parent process (ai_origin=0x01), that is, the child process inherits the AI ​​identity identifier of the parent process.

[0203] If the system call is a file or resource creation system call (such as open, openat2 to create a file, shmget to create shared memory) and the current process is AI-related, then the target entity is the created file or system resource. A second AI identity is generated for the target entity and stored through the file system extended attribute (xattr). In the second AI identity, the AI ​​type field is the derived AI process, and the derived source field is the resource creation derivative (ai_origin=0x03).

[0204] If the system call is an inter-process communication system call (such as msgrcv, shmat), the current process as the sender is AI-related, and the target process as the receiver is not AI-related, then the target entity updates the second AI identity identifier of the target entity. After the update, the AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is process communication derived (ai_origin=0x0B).

[0205] If the system call is a dynamic library loading system call (such as mmap corresponding to dlopen), the target entity is the loading process. If the loaded shared library has an AI association identifier and the target entity is not AI-related, then the second AI identity identifier of the target entity is updated. After the update, the AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is a dynamically loaded derivative (ai_origin=0x0A).

[0206] If the system call is a file execution system call (such as execve), the target entity is the process that executes the target file. If the target file has an AI-generated resource identifier (i.e., the file is created or modified by an AI process), then a second AI identity identifier is generated for the target entity. The AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is either an AI-generated binary execution derivative (ai_origin=0x06) or an AI script execution derivative (ai_origin=0x08).

[0207] It is understandable that other taint propagation rules can also be predefined and encoded through derived source fields, which will not be listed here.

[0208] Based on the same inventive concept, a second aspect of this disclosure provides an AI identity and access control system, comprising:

[0209] The identity acquisition module is used to respond to a system call received by the operating system kernel, acquire the AI ​​identity of the current process that initiated the system call as the first AI identity, determine the target entity and the AI ​​identity of the target entity according to the type of the system call, and use the AI ​​identity of the target entity as the second AI identity.

[0210] The access control module is used to perform access control checks in the kernel event processing path based on the first AI identity and the second AI identity to determine the current process's permission to execute the system call on the target entity, and generate access control check results.

[0211] The execution module allows the system call to continue execution when the access control check result is passed, and prevents the system call from executing when the access control check result is failed.

[0212] The identity verification module can be used to obtain the identity information. Figure 1The AI ​​identity module and AI identity taint propagation engine are combined to implement this. Specifically, the AI ​​identity module maintains the storage and retrieval of AI identities through extended process control blocks (task_struct) and file system extended attributes (xattr). When a system call occurs, the module reads the first AI identity from the current process's task_struct; simultaneously, the AI ​​identity taint propagation engine, based on the system call type (such as process creation, file creation, inter-process communication, dynamic library loading, file execution, etc.), invokes the corresponding taint propagation rules to generate or update a second AI identity for the target entity. The logic for obtaining and generating both identities is integrated into the interface functions of the AI ​​identity module, such as get_ai_identity() and update_ai_identity().

[0213] Access control module can be accessed through Figure 1 The AI ​​access control engine is implemented in the code. Specifically, the AI ​​access control engine employs a layered inspection mechanism. First, the engine converts the first and second AI identity identifiers into SELinux type tags and calls the SELinux Access Vector Cache (AVC) for static permission checks. If the static check passes and the behavior baseline detection function is enabled, the engine further calls the dynamic behavior inspection layer. Anomalies are determined by comparing the real-time behavior Merkle tree with the behavior baseline Merkle tree. The access control check result (pass or fail) is uniformly output by the engine and shared with subsequent modules through eBPF global hash mapping.

[0214] The execution module can be accessed through Figure 1 The kernel's eBPF acquisition and sharing module coordinates with the kernel's native system call execution path. Specifically, the execution module uses the eBPF acquisition and sharing module to write access control check results into the eBPF global hash map and registers a system call verification hook in the LSM framework (located before the core system call execution path). When the current process initiates a system call, the kernel first calls this LSM hook. The hook function reads the access control check result corresponding to the current process from the eBPF map. If the result is a failure, the hook function directly returns an error code, preventing the system call from entering the core execution logic; if the result is a success, the hook function returns 0, allowing the system call to continue execution.

[0215] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An AI identity and access control method, characterized in that, Applied to the operating system kernel, it includes the following steps: In response to a system call received by the operating system kernel, the AI ​​identity identifier of the current process that initiated the system call is obtained as the first AI identity identifier; The target entity and its AI identity identifier are determined based on the type of the system call, and the AI ​​identity identifier of the target entity is used as the second AI identity identifier. Based on the first AI identity and the second AI identity, an access control check is performed in the kernel event handling path to determine the current process's permission to execute the system call on the target entity, and an access control check result is generated. The system call is allowed to continue execution when the access control check result is passed, and the system call is blocked when the access control check result is failed. The AI ​​identity identifier includes an AI flag, an AI type field, and a derived source field. The AI ​​flag indicates whether the target object is AI-related. The AI ​​type field indicates the AI ​​type of the target object, which includes native AI processes and derived AI processes. The derived source field indicates the derived scenario of the derived AI process. The target object is the current process or the target entity. The step of performing access control checks to determine the current process's permission to execute the system call on the target entity and generating access control check results includes: The first AI identity identifier and the second AI identity identifier are respectively converted into corresponding SELinux type tags. The SELinux type tag corresponding to the first AI identity identifier is used as the subject tag, and the SELinux type tag corresponding to the second AI identity identifier is used as the object tag. The conversion is based on the AI ​​type field and the derived source field in the AI ​​identity identifier. Based on the subject label and object label, the SELinux access vector cache is invoked to query the matching historical permission judgment result. If a matching historical permission judgment result is found, the historical permission judgment result is used as the access control check result. If no matching historical permission determination result is found, the access control check result is obtained by performing permission determination according to the preset AI type enforcement rule. The preset AI type enforcement rule predefines the allow or deny operation when different subject tags perform system calls on different object tags. 2.The AI identity and access control method of claim 1, wherein, The step of performing access control checks to determine the current process's permission to execute the system call on the target entity and generating access control check results further includes: When the access control check result is passed, the system call sequence bound to the first AI identity in the current time window is obtained, and a real-time behavior Merkle tree is constructed based on the system call sequence. A leaf node of the real-time behavior Merkle tree reflects a system call in the system call sequence, a branch node is formed by aggregating several consecutive leaf nodes, and the root node is formed by aggregating branch nodes level by level. The real-time behavior Merkle tree is compared with the pre-built behavior baseline Merkle tree using a hierarchical hash comparison, and the final access control check result is determined based on the comparison result. 3.The AI identity and access control method of claim 2, wherein, The pre-built behavioral baseline Merkle tree is constructed in the following way: The system call sequence of the current process under normal operating conditions is collected as a baseline sequence, and the baseline sequence is sliced ​​into multiple sub-sequences according to a fixed time window; For any subsequence, each system call within the subsequence is mapped to a leaf node of a Merkle tree, and the hash values ​​of the leaf nodes are aggregated sequentially upwards to generate a Merkle tree corresponding to the subsequence as a candidate Merkle tree. The candidate Merkle tree with the smallest fluctuation is selected from the candidate Merkle trees corresponding to multiple subsequences as the behavior baseline Merkle tree corresponding to the current process, and the root hash value of the behavior baseline Merkle tree is stored in the read-only memory page of the operating system kernel. 4.The AI identity and access control method of claim 3, wherein, The AI ​​identity identifier also includes a unique derived identifier, which is a unique identifier of the target object in the operating system kernel. The step of mapping each system call in the subsequence to a leaf node of a Merkle tree includes: For any system call, obtain the system call number, the hash value of the system call key parameters, the relative timestamp of the system call, and the unique derived identifier in the first AI identity identifier. The relative timestamp reflects the position of the system call within the fixed time window. The hash value of the leaf node corresponding to the system call is generated based on the call number, the hash value of the key parameter, the relative timestamp, and the unique derived identifier. 5.The AI identity and access control method of claim 4, wherein, The hierarchical hash comparison of the real-time behavioral Merkle tree with the pre-built behavioral baseline Merkle tree includes the following steps: Compare the root hash values ​​of the real-time behavioral Merkle tree with the behavioral baseline Merkle tree; If the root hash values ​​match, the system call is deemed safe, and the final access control check result is passed. If the root hash values ​​are inconsistent, the hash values ​​of the child nodes are recursively compared layer by layer from the root node until all leaf nodes with mismatched hash values ​​are located. The global difference is calculated based on the number of mismatched leaf nodes and the mismatch ratio of nodes at each layer. When the global difference exceeds a preset threshold, the system call is determined to be insecure, and the final access control check result is failed. 6.The AI identity and access control method of claim 1, wherein, The step of preventing the system call from executing when the access control check result is unsuccessful includes: The access control check result is shared to the LSM system call verification hook via eBPF. The LSM system call verification hook is located before the system call core execution path. When the current process initiates a system call, the operating system kernel invokes the LSM system call verification hook to perform interception based on the access control check result.

7. The AI identity and access control method of claim 1, wherein, Following the step of obtaining the AI ​​identity identifier of the current process that initiated the system call as the first AI identity identifier, the method further includes: The operating system kernel pre-configures cgroups control groups corresponding to the native AI process and cgroups control groups corresponding to the derived AI process based on the AI ​​type field in the first AI identity identifier.

8. The AI ​​identity identification and access control method according to claim 6, characterized in that, The types of system calls include process creation system calls, file or resource creation system calls, inter-process communication system calls, dynamic library loading system calls, and file execution system calls. The steps for determining the target entity and the AI ​​identity identifier of the target entity based on the type of system call include: If the system call is a process creation system call and the current process is AI-related, then the target entity is the created child process, the AI ​​type field in the second AI identity identifier is the AI ​​type in the first AI identity identifier, and the derived source field is derived from the parent process. If the system call is a file or resource creation system call and the current process is AI-related, then the target entity is the created file or system resource. A second AI identity is generated for the target entity and stored through file system extended attributes. In the second AI identity, the AI ​​type field is a derived AI process and the derived source field is a resource creation derived. If the system call is an inter-process communication system call, the current process as the sender is AI-related, and the target process as the receiver is not AI-related, then the target entity and the target process update the second AI identity identifier of the target entity. After the update, the AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is derived from process communication. If the system call is a dynamic library loading system call, the target entity is a loading process, and if the loaded shared library has an AI association identifier and the target entity is not AI-related, then the second AI identity identifier of the target entity is updated. After the update, the AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is a dynamically loaded derivative. If the system call is a file execution system call, the target entity is the process that executes the target file. If the target file has an AI-generated resource identifier, a second AI identity identifier is generated for the target entity. The AI ​​type field in the second AI identity identifier is a derived AI process, and the derived source field is either an AI-generated binary execution derivative or an AI script execution derivative.

9. An AI-based identity verification and access control system, characterized in that, include: The identity acquisition module is used to respond to a system call received by the operating system kernel, acquire the AI ​​identity of the current process that initiated the system call as the first AI identity, determine the target entity and the AI ​​identity of the target entity according to the type of the system call, and use the AI ​​identity of the target entity as the second AI identity. The access control module is used to perform access control checks in the kernel event processing path based on the first AI identity and the second AI identity to determine the current process's permission to execute the system call on the target entity, and generate access control check results. The execution module allows the system call to continue execution when the access control check result is passed, and prevents the system call from executing when the access control check result is failed. The AI ​​identity identifier includes an AI flag, an AI type field, and a derived source field. The AI ​​flag indicates whether the target object is AI-related. The AI ​​type field indicates the AI ​​type of the target object, which includes native AI processes and derived AI processes. The derived source field indicates the derived scenario of the derived AI process. The target object is the current process or the target entity. The access check control module is also used for: The first AI identity identifier and the second AI identity identifier are respectively converted into corresponding SELinux type tags. The SELinux type tag corresponding to the first AI identity identifier is used as the subject tag, and the SELinux type tag corresponding to the second AI identity identifier is used as the object tag. The conversion is based on the AI ​​type field and the derived source field in the AI ​​identity identifier. Based on the subject label and object label, the SELinux access vector cache is invoked to query the matching historical permission judgment result. If a matching historical permission judgment result is found, the historical permission judgment result is used as the access control check result. If no matching historical permission determination result is found, the access control check result is obtained by performing permission determination according to the preset AI type enforcement rule. The preset AI type enforcement rule predefines the allow or deny operation when different subject tags perform system calls on different object tags.

Images