An audit monitoring method and system based on multi-agent dynamic permission grading

Abstract

The application discloses an audit monitoring method and system based on multi-agent dynamic permission grading, comprising: constructing a trusted security foundation; generating a dynamic token based on a permission control strategy, the load of the dynamic token containing the permission identification of an atomic operation unit defined by the permission control strategy; implementing micro-permission life cycle control, triggering the corresponding permission recovery operation when any permission recovery trigger condition is met; performing full-process audit and anomaly detection, collecting system full-link logs, and performing four-layer collaborative detection; implementing hierarchical response through a multi-level alarm and intervention mechanism, and optimizing based on audit data. The application introduces a dynamic token, micro-permission atomization and a dynamic recovery mechanism, controls the permission granularity to the smallest operation unit, and realizes automatic real-time recovery of the permission. Through a four-layer collaborative detection model combined with a weighted voting decision mechanism, known threats, behavior anomalies, complex attack chains and unknown threats can be efficiently responded to.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to an auditing and monitoring method and system based on multi-agent dynamic permission hierarchy. Background Technology

[0002] With the rapid development of fields such as the Industrial Internet of Things (IIoT) and autonomous driving, multi-agent collaborative operation systems are becoming increasingly popular. Agents need to adjust their collaborative permissions in real time based on task requirements and environmental conditions (such as geographical location and time windows), resulting in permission hierarchy characterized by "fine-grained, dynamic, and complex relationships." Traditional static access control models (such as Role-Based Access Control, RBAC) cannot adapt to the instantaneous nature and contextual relevance of dynamic permissions. Once dynamic permissions are acquired by malicious agents or hijacked within their validity period, the lack of effective real-time monitoring and immediate intervention mechanisms leads to the inability to promptly stop permission abuse. Existing auditing systems are mostly post-event analyses, with logs scattered across different components, recording only single-node operations and lacking unified, end-to-end permission-related identifiers. This results in low efficiency in tracing and analyzing the source of security incidents, making it difficult to quickly and accurately locate the root cause and determine responsibility. Existing security detection relies heavily on predefined fixed rules or single machine learning models, lacking a collaborative mechanism that integrates the advantages of multiple detection technologies, and failing to achieve full-spectrum coverage of "known violations, abnormal behavior, complex related attacks, and unknown new threats." Summary of the Invention

[0003] The purpose of this invention is to provide an audit monitoring method and system based on multi-agent dynamic permission hierarchy, so as to solve the problems mentioned in the background art, such as insufficient dynamic adaptability of permissions, insufficient audit traceability, and single detection mechanism.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] According to one aspect of the present invention, an audit monitoring method based on multi-agent dynamic permission hierarchy is provided, the method comprising:

[0006] To build a trusted and secure foundation, multi-factor authentication and dynamic identity verification are performed on users, intelligent agent devices and intelligent agent services, and data communication and storage within the system are encrypted;

[0007] A dynamic token is generated based on the access control policy, and the payload of the dynamic token includes the access control policy's definition of the access control policy's permission identifier for atomic operation units.

[0008] Implement micro-permission lifecycle management, continuously monitor the context state of the intelligent agent, and trigger the corresponding permission revoke operation of the dynamic token when any permission revoke trigger condition is detected;

[0009] The system conducts full-process auditing and anomaly detection, collects logs from the entire system chain, and performs four-layer collaborative detection through rule engine, behavior baseline, correlation analysis and machine learning model in sequence.

[0010] Based on the results of the four-layer collaborative detection, a weighted voting decision is made to generate a risk score. A graded response based on the risk score is implemented through a multi-level alarm and intervention mechanism, and optimization is carried out based on audit data.

[0011] Based on the aforementioned scheme, the atomic operation unit is defined based on four dimensions: operation object, operation type, time range, and data / space range.

[0012] Based on the aforementioned scheme, the dynamic token adopts a lightweight custom format, which includes, in sequence, a token identifier, an agent identifier, a list of permission identifiers, an expiration date, an environment hash, and a digital signature.

[0013] The environment hash is generated by hashing agent identifier, timestamp, geographical location, device status and request identifier.

[0014] Based on the aforementioned scheme, the verification of the dynamic token includes verifying the validity of the digital signature using the public key corresponding to the signing private key; if the signature is invalid, the token is immediately rejected; the current environment hash is recalculated and compared with the environment hash carried in the token; if they do not match, the token is rejected.

[0015] Based on the aforementioned scheme, the verification of the dynamic token also includes anti-replay verification, which checks whether the random number contained in the token exists in the short-term usage records maintained by the server; if it exists, it is determined to be a duplicate use and the token is rejected.

[0016] Based on the aforementioned scheme, the permission revocation trigger conditions include: geographical deviation, time window, and abnormal behavior; the geographical deviation is when the distance between the current location of the intelligent agent and the authorized location exceeds a preset threshold; the time window is when the system time exceeds the absolute or relative validity period of the permission; the abnormal behavior is when the idle time of a highly sensitive permission exceeds a preset duration.

[0017] Based on the aforementioned scheme, the four-layer collaborative detection includes: rule engine filtering, behavior baseline screening, correlation analysis and mining, and machine learning-assisted detection;

[0018] The rule engine filtering generates a rule engine matching degree by executing predefined rules on token validity, permission scope, application frequency, and geographical location. The behavior baseline screening constructs the behavior baseline of the intelligent agent role based on the sliding window algorithm and calculates the deviation of the behavior baseline using the exponentially weighted moving average algorithm. The association analysis mining integrates multi-source log data and performs association risk analysis based on preset attack chain association rules. The machine learning-assisted detection adopts a hybrid model structure combining isolated forest and long short-term memory network to detect static anomalies and sequence anomalies respectively, and outputs machine learning anomaly probabilities.

[0019] Based on the aforementioned scheme, the weight allocation for the weighted voting decision is as follows: the rule engine matching degree is 0.3, the behavior baseline deviation degree is 0.25, the association risk is 0.25, and the machine learning anomaly probability is 0.2. The tiered response includes: high-risk, immediately executing token revocation, complete permission freeze, and triggering manual intervention investigation process; medium-risk, executing partial permission freeze and automatically notifying the security administrator; low-risk, enhancing monitoring intensity and recording detailed audit logs; normal risk, only recording basic operation logs, without taking additional measures.

[0020] Based on the aforementioned scheme, key logs in the system's end-to-end log are stored on the blockchain; the storage includes: calculating the hash value of the log and constructing a Merkle tree, writing the Merkle root and log metadata into the blockchain; when verifying log integrity, recalculating the log hash and comparing it with the Merkle root stored on the blockchain.

[0021] According to another aspect of the present invention, an audit and monitoring system based on multi-agent dynamic permission hierarchy is provided. The system includes: a trusted authentication module, a dynamic token service module, a micro-permission management module, an audit analysis engine module, and a security closed-loop management module.

[0022] The trusted authentication module is used to perform multi-factor authentication and dynamic identity verification for users, smart agent devices, and smart agent services.

[0023] The dynamic token service module is used to generate, verify, and revoke dynamic tokens, and maintain a random number blacklist to prevent replay attacks.

[0024] The micro-permission management module is used to define the trigger conditions for shrinking atomic permissions and monitoring permissions, and to generate permission revoke instructions;

[0025] The audit analysis engine module is used to collect end-to-end logs and integrates a rule engine, behavior baseline analysis unit, correlation analysis unit, and machine learning model to perform four-layer collaborative detection and weighted voting decision-making.

[0026] The security closed-loop management module is used to execute alarms and interventions based on risk levels, and to drive the optimization of strategies, rules and models based on audit data.

[0027] As can be seen from the above technical solution, the present invention has at least the following advantages and positive effects compared with the prior art: by introducing a context-bound dynamic token, the validity of the permission is strongly correlated with environmental parameters such as the real-time geographical location and device status of the intelligent agent, so that the permission can automatically and immediately expire when it leaves the authorized environment, fundamentally eliminating the risk of abuse after the token is stolen; through the micro-permission atomicity and dynamic recycling mechanism, the granularity of the permission is controlled at the smallest operation unit, and the automatic and real-time recycling of the permission is realized based on multi-dimensional trigger conditions (such as geographical deviation and time window).

[0028] By employing a four-layer collaborative detection model consisting of a rule engine, behavioral baseline, correlation analysis, and machine learning, supplemented by a weighted voting decision-making mechanism, the system effectively integrates the determinism of rules, the adaptability of baselines, the globality of correlations, and the generalization ability of machine learning. This enables the system to efficiently respond to known threats, behavioral anomalies, complex attack chains, and unknown threats simultaneously, achieving a dual improvement in detection range and accuracy.

[0029] By binding a globally unique associated ID to the entire chain of operations, rapid and accurate tracing from abnormal operations to the source of permissions is achieved within minutes, improving the efficiency of event chain location; by storing the hash value of key audit logs in the blockchain for evidence preservation, the integrity and immutability of log data are ensured, providing credible evidence for security incident investigations and compliance audits.

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

[0031] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0032] Figure 1 This is a schematic diagram of an audit and monitoring method based on dynamic hierarchical permission of multiple agents according to the present invention;

[0033] Figure 2 This is a schematic diagram of the dynamic token generation and verification process of the present invention;

[0034] Figure 3 This is a schematic diagram of the four-layer collaborative detection and decision-making process of the present invention. Detailed Implementation

[0035] To more clearly illustrate the purpose, technical solutions, and advantages of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein. On the contrary, these embodiments are provided so that the present invention will be more comprehensive and complete, and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0036] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full understanding of embodiments of the invention. However, those skilled in the art will recognize that the technical solutions of the invention can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of the invention.

[0037] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0038] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0039] The present invention will now be described in detail with reference to specific embodiments:

[0040] Example 1, such as Figure 1 As shown in the figure, this embodiment provides an auditing and monitoring method based on multi-agent dynamic permission hierarchy. The specific steps of the method are as follows:

[0041] S1: Build a trusted and secure foundation, perform multi-factor authentication and dynamic identity verification for users, intelligent agent devices and intelligent agent services, and encrypt the data communicated and stored within the system.

[0042] In this embodiment, to achieve initial trust in entity identity, a differentiated multi-factor authentication (MFA) scheme is adopted for different entity types.

[0043] For user and administrator authentication, a multi-factor authentication mechanism based on knowledge factors, ownership factors, and biometric factors is adopted.

[0044] Specifically, the knowledge factor uses a user-defined string password, which is salted and hashed before storage. The salt value is a randomly generated 16-byte string, and the hash algorithm is SHA-256. The hash result and the salt value are stored separately, and the hash result is stored in the hardware security module. The holding factor uses a hardware token conforming to the FIDO2 protocol. During authentication, the authentication server sends a one-time challenge code to the client. The hardware token digitally signs the challenge code using an internal asymmetric key and returns it. The server verifies the signature to achieve authentication. The biometric factor uses fingerprint or facial recognition technology conforming to the ISO / IEC 19794 series standards. Facial recognition needs to integrate liveness detection. The collected biometric templates are encrypted and stored in the hardware security module.

[0045] For the authentication of intelligent agent devices, a binding authentication method based on hardware root trust and public key infrastructure is adopted. Specifically, each intelligent agent device is pre-installed with a trusted platform module conforming to the TPM 2.0 standard at the factory, and a unique asymmetric endorsement key pair is generated within this module, whose private key cannot be exported. The device needs to apply for an X.509 digital certificate from the certificate authority within the system. This certificate binds the public key of the device's endorsement key to the device identifier, forming a verifiable certificate chain consisting of a root certificate, intermediate certificates, and a device certificate. When the device accesses the network, it needs to submit the complete certificate chain to the authentication gateway. The authentication gateway verifies the signature validity of the certificate chain level by level, and finally verifies whether the public key in the device certificate matches the public key of the endorsement key in the TPM.

[0046] For the authentication of the agent service, an integrity verification mechanism based on code signing is adopted. Specifically, before the agent service is deployed, the executable file is digitally signed using the enterprise GPG private key stored in the hardware security module to generate a corresponding signature file. When the agent service starts, the system loader uses the corresponding GPG public key to verify the validity of the signature file. If the signature verification fails or the file is tampered with, the service startup process is terminated.

[0047] After initial authentication, the entity's identity is continuously and dynamically verified to prevent identity theft and session hijacking. Specifically, the system collects and integrates the device's hardware identifiers (CPU serial number, motherboard MAC address, TPM chip model), network address information (IP address range, gateway MAC address, DNS server address), and historical behavioral characteristics (average number of collaborative agents per day, average number of permission requests per day) to generate a device fingerprint baseline, which is stored on the authentication server. In subsequent critical interactive sessions, the system collects current device characteristics in real time and generates new fingerprints, which are then compared with the baseline fingerprint for similarity. When the fingerprint change rate exceeds a preset threshold, the system determines that the identity is abnormal and triggers a forced re-authentication process. For agents with high-frequency interactions, the authentication server periodically sends them cryptographically secure random challenge codes. The agent must encrypt or sign the challenge code using a pre-shared key or internal private key pre-placed in its secure environment and return a response. The authentication server verifies the correctness of the response, and if the verification fails multiple times consecutively, it immediately freezes all operational permissions of the agent. The random challenge code is generated by the random number generator CryptoAPI to ensure unpredictability. The pre-shared key (PSK) uses the AES-256 algorithm, is negotiated during system and agent initialization, and is stored in the TPM (Trusted Platform Module).

[0048] To ensure the confidentiality and integrity of identity and business data during transmission and storage, further measures are taken, including end-to-end communication encryption, layered encrypted storage of sensitive data, and security protection for API interfaces.

[0049] End-to-end communication is encrypted. All network communication between system components is mandated to use the TLS 1.3 protocol and configured to support only cipher suites with forward secrecy features. Both communicating parties must verify the validity of each other's digital certificates. For example, only quantum-safe certified cipher suites are enabled, including TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. Weak cipher suites with known vulnerabilities are explicitly disabled through protocol stack layer configuration, including but not limited to the AES-CBC mode algorithm and the SHA-1 hash algorithm. The Diffie-Hellman key exchange algorithm (ECDHE) based on elliptic curves is used for session key negotiation to ensure forward security; even if the private key is subsequently leaked, historical communication sessions remain confidential. A hierarchical trust system based on enterprise-level certificate authorities is established. Both communicating parties must perform bidirectional certificate chain verification. The verification process includes certificate validity verification, certificate revocation list verification, and extended key usage verification. Self-signed certificates and CA-issued certificates not registered in the trusted certificate repository are strictly rejected.

[0050] Sensitive data is stored in a layered encrypted manner, constructing a layered key management system. The root key (KEK) is stored in the hardware security module (HSM), and the data encryption key (DEK) is dynamically generated from the root key through a key derivation function (HKDF algorithm). Sensitive data is encrypted and stored using the AES-256-GCM algorithm, which also generates authentication tags for data integrity verification. Non-sensitive but privacy-protected data in the logs, such as user identifiers, device identifiers, and precise geographical location information, undergo hash desensitization and precision fuzzing to achieve privacy protection.

[0051] API interface security protection involves deploying a Web Application Firewall at the intelligent agent access gateway. This firewall uses a semantic analysis rule base to defend against SQL injection and cross-site scripting attacks, and dynamically blocks access requests based on source IP address and behavioral patterns. Multi-layered attack interception is implemented, employing a semantic analysis engine based on abstract syntax tree parsing to dynamically identify and block SQL statements containing malicious logical structures such as "UNION SELECT" and "OR 1=1". Injection attack detection is achieved through syntax feature matching and behavioral anomaly assessment. Input-side filtering and cleaning based on HTML entity encoding are performed, while context-aware encoding conversion is executed on the output side to block script injection attack vectors. The validity of the Referer field in the HTTP request header and the anti-counterfeiting token are verified simultaneously. The anti-counterfeiting token is bound to the user session and generated using cryptographic random numbers. Implement dynamic traffic control by setting request frequency thresholds for source IP addresses. For example, set a hard rate limiting policy of ≤100 times / minute for key token verification interfaces. Monitor request density within a time window in real time. For example, trigger an abnormal behavior flag when a specific IP initiates ≥50 requests within 1 second. Establish a mapping relationship between the number of violations and the duration of the ban. For example, implement a 10-minute temporary ban for the first violation, upgrade to 1 hour for the second violation, and initiate a 24-hour long-term ban for the third or more violations, and record it in the security event audit log.

[0052] S2: Generate a dynamic token based on the access control policy, wherein the payload of the dynamic token contains the access control identifier of the atomic operation unit defined by the access control policy.

[0053] The access control strategy defines the smallest permission unit and establishes multi-dimensional dynamic permission revoke trigger conditions to ensure that permissions are only valid in the necessary context and for the shortest possible time. The access control strategy mainly consists of atomic permission splitting strategy and dynamic revoke trigger strategy.

[0054] Permissions are broken down into atomic operation units, each uniquely identified by four dimensions: operation object, operation type, time frame, and data / spatial scope. The operation object is the specific entity to which the permission applies, explicitly defined as a single device, sensor, or data field. For example, the policy stipulates that "all sensors" cannot be used as the object; it must be explicitly defined as "sensor A." The operation type is the specific action performed by the permission, breaking down complex operations into basic operations. For example, the policy stipulates that "read / write" permissions must be broken down into two independent atomic permissions: "read" and "write." The time frame is the precise time window in which the permission is valid. For example, the policy stipulates that temporary permissions must have a clearly defined absolute time (e.g., 2025-07-28 10:00-10:05) or be bound to the task lifecycle. The data / spatial scope is the data boundary or physical space boundary to which the permission applies. For example, the policy stipulates that data operation permissions must be precise to the field level (e.g., "inventory quantity field in the inventory table"), and device control permissions must be bound to a geofence (e.g., "workshop A").

[0055] When an agent needs to perform a specific task, it proactively initiates a permission request. The request explicitly includes the agent's own identity, the type of permission requested (e.g., "read temperature data from sensor A"), and current context information (e.g., timestamp, precise geographical location, device operating status, etc.). Based on a predefined permission control policy, the agent makes a logical judgment and only approves the minimum operational unit necessary to complete the task. Table 1 shows examples of atomic permissions for different agent roles.

[0056]

[0057] like Figure 2The diagram illustrates the dynamic token generation and verification process. The dynamic token serves as the carrier for permission issuance, employing a custom lightweight binary format to reduce network transmission and storage overhead. Its structure, in sequence, includes: token identifier, agent identifier, permission identifier list, validity period, environment hash, and digital signature, carrying the most critical security information in the smallest possible data size. The token identifier is 16 bytes long and is used to globally and uniquely identify the token. It consists of an 8-byte millisecond-level Unix timestamp and an 8-byte cryptographically secure random number to ensure its uniqueness and unpredictability. The agent identifier is 8 bytes long and is used to identify the agent that applied for the token. It is encoded in ASCII. The permission identifier list is a variable-length field that lists the numbers of all atomic permissions granted by the token. Each permission ID is fixed at 4 bytes and corresponds to the smallest unit of operation defined by the permission control policy. Multiple IDs are connected by a specific separator. The validity period is 4 bytes long and is in seconds. It represents the valid lifespan of the token from the time of its generation. The digital signature is 64 bytes long and is used to ensure the integrity and authenticity of the token. It uses the Ed25519 digital signature algorithm to sign the concatenated data of all the above fields (token ID to environment hash). The signature private key is securely stored by the hardware security module.

[0058] The environment hash is 32 bytes long, which strongly correlates the token's validity with the security context in which it was generated, ensuring that the token is only valid in the intended environment; it is a key field for achieving context-aware security. Its input parameters uniquely and comprehensively characterize the security context in which the token was generated. The input parameters are concatenated and fed into the SHA-256 hash function for calculation; the input parameters include: agent identifier, timestamp, geographic location, device status, and request identifier. The intelligent agent identifier is consistent with the intelligent agent identifier field in the token structure; the high-precision timestamp is a millisecond-level Unix timestamp to ensure the instantaneous uniqueness of the hash value; the geographic location is the intelligent agent's current latitude and longitude information, with precision retained to at least four decimal places (e.g., 30.1234°N, 120.5678°E) to provide accurate geofence binding; the device status is a 1-byte status code used to indicate the real-time status of the intelligent agent device, for example: 0x00 indicates offline, 0x01 indicates online, and other values ​​can be reserved to indicate low battery, network abnormality, etc.; the request identifier is a unique ID for this permission request, using UUID version 4 format, and taking its first 16 bytes to balance uniqueness and length. An exemplary calculation process is as follows:

[0059] Environment hash = SHA-256(Agent ID "exec_001" + Timestamp "1722154530123" + Latitude and Longitude "30.1234,120.5678" + Device Status "0x01" + First 16 bytes of Request ID "a1b2c3d4e5f6a7b8")

[0060] When an agent attempts to access a protected resource or perform an operation requiring authorization, token verification is performed first. The gateway intercepts the agent's request, extracts the dynamic token, and executes a complete verification process: checking the revocation list to confirm the token has not been actively revoked; verifying the signature to confirm the token's integrity and authenticity; performing anti-replay verification to check if the token's random number has been used; verifying the environment context by recalculating the environment hash to confirm that the current context is consistent with when the token was generated; and verifying the validity period to confirm that the token is still valid. Only after all verifications pass will the gateway forward the request to the backend business system for execution; if any step fails, the request will be immediately rejected and an alarm will be triggered.

[0061] The signature verification process involves using the public key corresponding to the signature private key to verify the validity of the digital signature. In this embodiment, the verification service first uses the Ed25519 public key stored in the HSM to verify the signature portion of the token. If the signature is invalid, the token is immediately rejected. The environment context verification process involves the verification service (usually an agent gateway) collecting current environment parameters (agent ID, current time, current location, current device status) in real time after the signature verification passes. It then recalculates the current environment hash using the same algorithm as when the token was generated. The newly calculated environment hash is compared byte-by-byte with the environment hash carried in the token. If the two are inconsistent, it is determined that the context environment has undergone a significant change, and the token immediately becomes invalid.

[0062] The anti-replay verification checks whether the random number contained in the token exists in the short-term usage records maintained by the server; if it exists, it is determined to be a duplicate use, and the token is rejected. Specifically, this embodiment adopts an active anti-replay attack mechanism based on dynamic serial numbers and a distributed blacklist. When generating a dynamic token, an 8-byte monotonically increasing random number is generated as the anti-replay serial number; this serial number is embedded in a specific field of the token and signed together with the token itself to ensure that it cannot be tampered with. The system deploys a 3-master 3-slave Redis cluster as a distributed high-speed cache to maintain a "recently used serial number blacklist". The keys in the blacklist adopt a uniform format, for example: nonce:{agent_id}:{nonce_value}, where {agent_id} is the agent identifier and {nonce_value} is the serial number of the token. The blacklist key's lifespan is set to the token's maximum validity period plus a security buffer (e.g., 10 minutes); for example, if the token's validity period is 5 minutes, then the blacklist lifespan is 15 minutes; this ensures that the serial number of any token cannot be reused throughout its entire lifecycle and the subsequent buffer period.

[0063] For replay protection verification, the agent identifier and serial number are extracted from the parsed token. The gateway sends a query request to the Redis cluster to check the blacklist and whether the key nonce:{agent_id}:{nonce_value} exists. If it exists, it means that the serial number has been used before, and this request is a replay attack. The gateway immediately rejects the request and logs a security alert. If it does not exist, it means that the serial number is being used for the first time. The gateway then writes the serial number key to the Redis blacklist and sets the above-mentioned timeout. Subsequent business logic processing continues.

[0064] S3: Implement micro-permission lifecycle management, continuously monitor the context state of the agent, and trigger the corresponding permission revoke operation of the dynamic token when any permission revoke trigger condition is detected.

[0065] The access control service continuously monitors the system context and proactively triggers access control revoke when the conditions are met. These conditions include: geographical deviation, time window exceeding, device anomaly, behavioral anomaly, and access control policy updates. Geographical deviation is determined by the distance between the agent's current location and its authorized location, calculated in real-time using the Haversine formula. If this distance exceeds a preset threshold (e.g., 1 km), it is considered a geographical deviation, triggering access control revoke. Time window exceeding is triggered when the system time exceeds the absolute or relative validity period of the access control, such as a fixed validity period or a task-related validity period (30 seconds after task completion). Device anomaly is triggered if any of the following anomalies are detected: TPM chip verification failure, device fingerprint change rate exceeding a threshold (e.g., 15%), network interruption duration exceeding a certain time (5 minutes), or detection of malicious code or abnormal processes. Abnormal behavior: When highly sensitive permissions are left idle, they are considered unnecessary and will be revoked. Thresholds are set according to the sensitivity of the permissions. For example: highly sensitive permissions (such as control - core devices): revoked after more than 5 minutes of inactivity; medium sensitive permissions (such as write - database): revoked after more than 10 minutes of inactivity; low sensitive permissions (such as read - sensors): revoked after more than 30 minutes of inactivity. When permission control policies are updated, the permission management service will compare the old and new policies. Permissions generated based on the old policy that conflict with the new policy will be immediately revoked in batches.

[0066] Furthermore, the access control service analyzes the above triggering conditions and generates a structured access revocation instruction once the conditions are met. For example, this instruction is in JSON format:

[0067] {

[0068] "revoke_id": "rev-2025072810:05:30-001", / / Recycle command ID

[0069] "agent_id": "exec_agent_001", / / Agent ID

[0070] "permission_ids": ["0001", "0003"], / / List of permission IDs to be revoked

[0071] "token_ids": ["tk-2025072810:00-001"], / / Associated token ID

[0072] "trigger_condition": "Geographical deviation (Workshop A → Workshop C, distance 1.5km)", / / Trigger condition

[0073] "timestamp": "2025-07-28T10:05:30Z" / / Instruction generation time

[0074] }

[0075] The permission management service publishes eviction instructions to a high-throughput message queue (such as Kafka). All token services and agent gateways subscribe to this message topic to ensure that instructions are received in real time. After receiving the eviction instruction, the token service adds all token identifiers in the token_ids list in the instruction to a distributed revocation list (such as a Redis cluster) and marks its status as "evidented". After receiving the eviction instruction, the agent gateway synchronously updates its local, efficient permission / token cache blacklist. Thereafter, any request carrying an evictioned token or attempting to exercise an evictioned permission will be directly intercepted and rejected at the gateway layer. The permission management service writes the eviction instruction and its execution result (such as "successfully evictioned 2 permissions") as a key audit event into the audit log and synchronizes it to the blockchain evidence storage system to ensure that the entire eviction operation process is traceable and tamper-proof.

[0076] S4: Perform full-process auditing and anomaly detection, collect system logs across the entire chain, and sequentially conduct four-layer collaborative detection through rule engine, behavior baseline, correlation analysis, and machine learning model.

[0077] Lightweight data collection probes are deployed at key nodes to collect end-to-end logs, building a foundation for audit data. Specifically, the collected data includes: authentication logs, permission request logs, token operation logs, permission usage logs, and system status logs.

[0078] The identity authentication log records all authentication attempts for all entities, including authentication ID, entity ID, authentication method, IP address, device fingerprint, timestamp, result (success / failure), and reason for failure; the permission request log records each permission request, including request ID, agent ID, list of permissions requested, context of the request (time, location), policy matching result, and associated token ID; the token operation log records token generation, verification, and revocation behaviors, including operation type, token ID, operation result, timestamp, and executing entity; the permission usage log records the specific operations of the agent, including operation ID, agent ID, permissions used, operation object, operation result, associated token ID, and real-time context; the system status log records the operational health status and abnormal events of core components such as the policy engine and token service.

[0079] Key logs in the system's end-to-end logs are stored on the blockchain. This storage involves: calculating the log's hash value and constructing a Merkle tree, writing the Merkle root and log metadata to the blockchain; and recalculating the log hash and comparing it with the Merkle root stored on the blockchain when verifying log integrity. Specifically, all logs are uniformly stored in JSON format for structured storage, ensuring machine readability and analyzability. A globally unique association ID is generated for each operation chain, in the format: {first 8 digits of entity ID} - {timestamp} - {last 16 digits of UUID}. This association ID will be used throughout the entire process from permission application, policy decision-making, token generation to permission use, enabling logs scattered across various system modules to be accurately linked into a complete story chain, laying the foundation for accurate traceability. Logs employ a hierarchical storage strategy. Recent high-frequency logs (such as permission usage logs and token verification logs) are stored in time-series databases such as InfluxDB for real-time querying, retained for 3 months, and supporting fast querying and real-time monitoring by time range. Long-term logs (especially critical operation logs) are stored in an Elasticsearch cluster for historical tracing. The hash values ​​of critical logs (such as permission requests and policy changes) are written to a blockchain (such as Hyperledger Fabric) for notarization, leveraging the blockchain's immutability to ensure the credibility of audit data. Critical logs requiring notarization are organized in batches, and the SHA-256 hash value of each log entry is calculated. The hash values ​​of a batch of logs are then used to construct a Merkle tree. The root hash of the Merkle tree, along with relevant batch metadata (such as time window and log type), is written to the Hyperledger Fabric consortium blockchain. When it is necessary to verify whether a log entry has been tampered with, the original log is retrieved from the business database (Elasticsearch), its hash is recalculated, and verification is performed based on the Merkle root and path information stored in the blockchain. If verification fails, it can be concluded that the log has been tampered with.

[0080] The four-layer collaborative detection adopts a pipeline architecture, where the processing results of the previous layer can serve as input for the next layer. The first layer is a rule engine for filtering, which quickly handles known threats. It uses rule engines such as Drools to load predefined business security rules and detect explicit and known threat patterns. For rule management, it supports online hot updates of rules, including adding, modifying, and enabling / disabling operations. It uses ECDSA digital signatures to verify rule change permissions and ensure rule integrity. It establishes a version control system to retain a complete history and support one-click rollback.

[0081] The core rule set includes rules for token validity, permission scope, request frequency, and geographic location. For example, the token expiration detection rule (validity): when a token for a permission usage event expires earlier than the current system time, and the operation has been successfully executed, a high-risk rule is matched. Permission out-of-bounds detection rule (permission scope): by associating IDs with permission request events and usage events, a high-risk rule is matched when the actual usage permission exceeds the original request scope. High-sensitivity permission high-frequency request detection rule (request frequency): based on a time window statistics mechanism, when the same agent requests high-sensitivity permissions 10 times within one minute, a medium-risk rule is matched. Abnormal geographic location operation detection rule: combining the agent's registered location information, when control-related permissions are detected to be used in areas more than 1 kilometer from the registered location, the geographic distance is calculated based on the Haversine formula, and a high-risk rule is matched.

[0082] Matching high-risk rules carries a very high degree of malicious intent, and if successful, will directly lead to serious consequences such as control of the core system, tampering with or leakage of critical data. It usually involves unauthorized use of permissions or explicit attack instructions. Matching medium-risk rules shows a strong malicious tendency or a significant deviation from normal behavior, but has not yet caused substantial damage, or its uncertainty is slightly higher. Matching low-risk rules is a minor policy violation or a deviation from best practices. It does not pose a direct threat, but may indicate misconfiguration or potential risks that need attention.

[0083] The second layer is behavioral baseline screening, which identifies behaviors that deviate from the norm. Based on historical data, a sliding window algorithm is used to construct dynamic behavioral baselines for agents with different roles. These baselines include: permission request frequency baseline, permission usage type baseline, scope of collaborating objects baseline, and time distribution baseline. The sliding window is configured with a 24-hour window size, updated hourly, and a statistical model using the mean ± 3σ for the normal range, ensuring that 99.7% of normal behaviors fall within this range.

[0084] The baseline for permission request frequency is established by statistically analyzing the number of permission requests made by agents per hour to form time-series data. The normal range is calculated based on the sample mean and standard deviation. For example, the mean for monitoring agents is 10.25 times / hour, the standard deviation is 1.5, and the 3σ range is [5.75, 14.75], which is rounded to [5, 15] times / hour. For different role agents, the configuration is as follows: monitoring agents [5, 15] times / hour, execution agents [20, 40] times / hour, and management agents [10, 25] times / hour.

[0085] The permission usage baseline uses a JSON structured data format to define the role-permission mapping relationship, including a list of allowed permissions and a list of prohibited permissions, supporting wildcard pattern matching. A monthly update mechanism is established to dynamically adjust the permission mapping library based on task changes. Statistics are compiled on the collaborating objects and average daily interaction frequency of the agent over the past 7 days. The top 10 objects with the most interactions are considered the normal collaboration range, with a threshold set as follows: interactions with unfamiliar objects should not exceed 10%. Statistics are also differentiated between weekdays / holidays and peak / off-peak hours. For example, in a production workshop, the agent's operation frequency during peak hours should be ≥80%, and the operation frequency on holidays should be ≤30% of that on weekdays.

[0086] Furthermore, a multi-level deviation detection and exponentially weighted moving average (EWMA) algorithm are used to calculate the overall behavioral baseline deviation, and cumulative alarms are triggered for persistent minor anomalies. Real-time deviation detection includes: frequency deviation detection, comparing the current behavior with the baseline interval; for example, if 25 requests exceed the [5,15] interval, a level 1 alarm is triggered; type deviation detection, detecting prohibited access, triggering a level 2 alarm; collaboration deviation detection, the proportion of interactions with unfamiliar objects exceeding a threshold triggers a level 1 alarm; and time deviation detection, the frequency of operations exceeding a multiple of the baseline during abnormal periods triggers a level 2 alarm. For cumulative deviation detection (EWMA algorithm), the deviation is calculated as: single-dimensional deviation value / upper limit of the baseline interval; EWMA formula: EWMA t =α × current deviation + (1-α) × EWMA t-1 The smoothing coefficient α = 0.3. A Level 3 alarm is triggered when the EWMA score is ≥ 60. Optionally, for the tiered alarm and handling, a Level 1 alarm indicates a minor deviation, which is only logged without any action; a Level 2 alarm indicates a moderate deviation, which automatically notifies the security administrator; and a Level 3 alarm indicates a severe deviation, which temporarily freezes permissions and initiates an in-depth investigation.

[0087] The third layer involves correlation analysis and mining to uncover complex attack chains. Based on the Security Information and Event Management (SIEM) system, a unified data lake is constructed, integrating multi-source log data. This embodiment integrates five types of security data sources: identity authentication data, including authentication identifier, agent identifier, authentication method, network address, device fingerprint, timestamp, and authentication result; permission request data, including request identifier, agent identifier, permission list, context environment, policy matching result, and token identifier; token operation data, including operation identifier, token identifier, operation type, execution result, failure reason, and timestamp; agent behavior data, including operation identifier, agent identifier, operation type, accessed resources, interaction objects, and execution result; and environmental status data, including status identifier, area information, device status, network topology, and location data. All data is uniformly encoded in JSON format, establishing an event association key mechanism that supports data association based on agent identifier, time window, network address, and other dimensions.

[0088] The core attack chain association rules include: Authentication-Token Association Rules: Detecting multiple authentication failures of the same network address within a short period (e.g., 10 minutes), followed by the application for a token from a location exceeding a threshold (e.g., 50 kilometers) from the agent's registration location, is identified as a brute-force attack chain combined with geolocation spoofing and marked as a "high-risk attack chain"; Permission-Behavior Association Rules: Detecting an agent's repeated requests for multiple highly sensitive permissions unrelated to its role within a short period, all of which are rejected, followed by immediate high-frequency data interaction with an unfamiliar agent, is identified as a permission probe combined with data leakage and marked as a "medium-high-risk attack chain"; Time-Location Association Rules: Detecting an agent's sudden change in geographical location within a short period (distance exceeding physical movement limits) and subsequent request for device control permissions at the new location, is identified as a location spoofing attack chain combined with unauthorized control and marked as a "high-risk attack chain"; Multi-Agent Collaboration Association Rules: Detecting multiple agents requesting complementary permission combinations from different gateways within a similar time window, is identified as a collaborative unauthorized attack chain and marked as a "high-risk attack chain". Optionally, a quantitative assessment of associated risks can be conducted. For the scoring dimensions and weights, the attack chain integrity (assessed based on the number of associated events and logical coherence) has a weight of 0.4, the permission sensitivity level (based on the security risk level of the permissions involved) has a weight of 0.3, and the historical attack matching degree (based on similarity to known attack patterns) has a weight of 0.3. For risk classification and handling, for high-risk attack chains (score ≥ 80), the relevant tokens should be immediately revoked and a manual investigation initiated; for medium-high risk attack chains (score 60-79), the relevant permissions should be frozen and the administrator notified; for medium-risk attack chains (score 40-59), monitoring intensity should be increased and detailed logs recorded.

[0089] The fourth layer is machine learning-assisted detection to discover unknown new threats. It adopts a hybrid model structure combining Isolation Forest and Long Short-Term Memory (LSTM) networks to detect static anomalies and sequential anomalies respectively. Isolation Forest is used to detect static anomaly patterns in single permission request behavior. The input is a 32-dimensional feature vector, including: permission type features (using one-hot encoding to represent 10 permission types), request frequency features (the number of requests in the last 5 minutes standardized to the [0,1] interval), geographic location features (distance from the registration location standardized to the [0,1] interval), role matching features (permission and role matching degree (0-1 continuous value)), time features (whether it is during working hours, binary label), collaboration object features (whether the collaboration object is within the baseline, binary label), historical behavior features (standardized value of the proportion of similar behaviors in the last 7 days), and extended features (17-dimensional auxiliary features such as permission sensitivity level and request result). The model is trained using 100,000 normal samples (historical compliant behavior) and 50,000 abnormal samples, with 100 trees, a maximum number of samples of 256, and an abnormal sample ratio parameter of 0.1. Evaluation metrics include: accuracy ≥ 95%, recall ≥ 90% (ensuring fewer missed cases), and precision ≥ 85% (ensuring fewer false positives).

[0090] The LSTM model is used to detect dynamic anomalous patterns in a continuous sequence of operations by an agent. The input is a 128-dimensional sequence feature, constructed based on the last 10 operations. Single-step features include: permission type encoding (10-dimensional one-hot vector), operation interval (standardized value of the time difference from the previous operation), operation result (success / failure binary label), and collaborator matching degree (0-1 continuous value). The network structure is as follows: input layer (128-dimensional), first LSTM layer (64 neurons, tanh activation, returning the sequence), second LSTM layer (64 neurons, tanh activation), fully connected layer (32 neurons, ReLU activation), and output layer (1-dimensional, sigmoid activation). The model is trained using 100,000 normal sequences and 50,000 anomalous sequences, with an Adam optimizer (learning rate = 0.001), binary cross-entropy loss, 50 training epochs, and a batch size of 32. Evaluation metrics include: accuracy ≥ 94%, recall ≥ 89%, and precision ≥ 84%.

[0091] The detection process proceeds sequentially as follows: Feature extraction: Real-time logs are cleaned and then 32-dimensional static features and 128-dimensional temporal features are extracted in parallel; Parallel inference: Dual models are processed synchronously, with Isolation Forest outputting anomaly probability P1 and LSTM outputting anomaly probability P2; Weighted fusion: The final anomaly probability P = 0.6 × P1 + 0.4 × P2, reflecting the dominant weight of static detection; Secondary verification: When P ≥ 0.85, the rule engine is triggered for review to reduce the false positive rate; Alarm generation: After the review is passed, an unknown anomaly alarm is generated, and the anomaly pattern is recorded for rule base updates.

[0092] S5: Based on the results of the four-layer collaborative detection, a weighted voting decision is made to generate a risk score, and a graded response based on the risk score is implemented through a multi-level alarm and intervention mechanism, while optimization is performed based on audit data.

[0093] like Figure 3 As shown, the system receives the output results of the four-layer collaborative detection, establishes a four-dimensional risk assessment system to generate the final risk level, and implements alarm and intervention measures. Specifically, the weight allocation for each dimension is as follows: rule matching degree has a weight of 0.3, behavioral baseline deviation has a weight of 0.25, association risk has a weight of 0.25, and machine learning anomaly has a weight of 0.2; the output of each layer can adopt the following quantitative standards:

[0094] 1) Rule matching score: 100 points for matching a high-risk rule (such as using a token after it has expired); 80 points for matching a medium-risk rule (such as frequently applied for); 60 points for matching a low-risk rule; 0 points for not matching any rule.

[0095] 2) Deviation from behavioral baseline: 100 points for triggering a Level 3 alarm (severe cumulative deviation); 80 points for triggering a Level 2 alarm (moderate real-time deviation); 60 points for triggering a Level 1 alarm (minor deviation); 0 points for no deviation;

[0096] 3) Associated Risk Score: 100 points for identifying a high-risk attack chain (such as multi-agent collaborative privilege escalation); 80 points for identifying a medium-to-high-risk attack chain; 60 points for identifying a medium-risk attack chain; 0 points for no associated risk.

[0097] 4) Machine learning anomaly probability: The model output anomaly probability P≥0.9 is scored as 100 points, 0.85≤P<0.9 is scored as 80 points, 0.8≤P<0.85 is scored as 60 points, and P<0.8 is scored as 0 points.

[0098] Final risk score = (rule matching score × 0.3) + (behavioral baseline deviation score × 0.25) + (association risk analysis score × 0.25) + (machine learning anomaly score × 0.2).

[0099] Through a multi-level alarm and intervention mechanism, a graded response based on the final risk score is implemented, including: high risk (score ≥ 80), immediately execute token revocation, completely freeze permissions, and trigger manual intervention investigation process; medium risk (60 ≤ score < 80), execute partial permission freeze and automatically notify the security administrator; low risk (40 ≤ score < 60), enhance monitoring intensity and record detailed audit logs; normal risk (score < 40), only record basic operation logs, and do not take additional action.

[0100] Specifically, the multi-level alarm and intervention mechanism, for low-risk alarms and interventions, includes the following alarm methods: recording in audit logs without sending proactive notifications; displaying a low-risk alarm counter in the administrator console; and the log format including alarm identifier, risk level, agent identifier, event description, and timestamp. Intervention measures include: not taking automatic blocking measures; marking the event as "requiring attention" for later review by the administrator; and establishing a low-risk event aggregation and analysis mechanism to identify potential risk trends.

[0101] For medium-risk alerts and interventions, alerting methods include: recording audit logs and synchronizing them to the blockchain for evidence storage; sending email / SMS notifications to administrators, including alert identifiers, agent identifiers, and event descriptions; and standardizing notification templates to ensure information integrity and traceability. Intervention measures include: temporarily freezing highly sensitive permissions of agents for 30 minutes; blocking permission request requests for 10 minutes (for high-frequency request scenarios); requiring administrators to confirm the authenticity of alerts within 2 hours, and immediately lifting restrictions if false alarms are detected; establishing a false alarm feedback mechanism and optimizing detection rules.

[0102] For high-risk alerts and interventions, alerting methods include: recording audit logs and synchronizing them to the blockchain; sending email / SMS / WeChat notifications to all security administrators; setting up repeat notifications every 5 minutes until someone responds; and forcing a pop-up notification in the console accompanied by an audible alarm. Intervention measures include: immediately revoking all valid tokens of the agent and synchronizing the revocation list to Redis within 1 second; interrupting all collaboration links of the agent and rejecting new connection requests; freezing the bound device interface and disabling the security chip and network port; triggering a 15-minute emergency response mechanism and recording the administrator's response time.

[0103] Once an alarm is triggered, a standardized emergency response work order is automatically generated, including instructions on the handling steps. After accepting the work order, the administrator verifies the authenticity of the event and views the operation logs and device status. For false alarms, the administrator performs actions such as unfreezing, restoring collaboration, marking false alarms, and updating the detection baseline / rules. For real attacks, the administrator performs a four-stage emergency response: evidence collection, isolation, source tracing, and remediation.

[0104] Furthermore, the audit data within each phase is statistically analyzed periodically, and optimizations are made based on the analysis results. In this embodiment, to ensure the immutability and legal compliance of the audit data, a consortium blockchain-based evidence storage scheme is adopted. Specifically, a four-node consortium blockchain network is constructed using Hyperledger Fabric, with each node independently managed by the security audit center, the access control department, the operations and maintenance department, and a third-party regulatory agency. The nodes are configured with 16-core CPU / 32GB RAM / 1TB SSD hardware specifications, Fabric 2.5 software version, and Go language chaincode development. Network requirements: dedicated fiber optic communication, bandwidth ≥100Mbps, latency <50ms, ensuring PBFT consensus efficiency.

[0105] For the block header structure, the block header includes the previous block hash, Merkle root, timestamp, and block sequence number to ensure the blockchain is tamper-proof. The block body stores a list of log hashes and related metadata, with a single block capacity limit of ≤1000 log records. The block metadata records the consensus node signatures and consensus time, providing proof of legitimacy. Further, the log on-chain process includes: grouping key operation logs (such as permission applications, policy changes, and token revocations) by associated IDs to form log batches; calculating the SHA-256 hash value of each log within a batch and constructing a Merkle tree; writing the Merkle tree root hash and batch metadata (such as batch ID, time range, and log quantity) to the blockchain via a smart contract call; when it is necessary to verify whether a log has been tampered with, retrieving the original log from the business database and recalculating its hash; verifying based on the Merkle root and path information stored on the blockchain; if path verification fails or the Merkle root does not match, the log is determined to have been tampered with.

[0106] Furthermore, it enables rapid time-chain location for multi-dimensional tracing; supports combined retrieval based on multiple conditions such as agent ID, operation time range, permission type, associated ID, and operation result; and provides a standardized query API. For example, the tracing process is illustrated using an abnormal device startup as an example: Starting with an abnormal event (e.g., device B is started at 10:05), the execution agent (exec_agent_001) and its token (tk-001) are located through the permission usage log; the token operation log is traced through the token ID to obtain the token's generation time and associated permission request ID; the request context (e.g., time, geographical location) is reconstructed through the permission request log, and the matching policy ID is confirmed; the policy content and agent role are verified, and the authenticity of the request context is verified by combining the environment hash stored on the blockchain, ultimately completing the reconstruction of the entire event chain from the abnormal phenomenon to the source of permission granting.

[0107] Furthermore, perform audit data analysis regularly (e.g., weekly) and drive the following optimizations based on quantitative indicators: Abnormal permission approval rate = (number of approvals that do not conform to the principle of least privilege / total number of approvals) × 100%. If this rate > 5%, trigger strategy condition optimization; Rule false alarm rate = (number of false alarms in rules / total number of rule alarms) × 100%. If this rate > 10%, trigger rule threshold adjustment; Baseline deviation rate = (number of operations that trigger baseline alarms / total number of operations) × 100%. If this rate > 8%, trigger baseline model reconstruction; Machine learning false alarm rate = (number of anomalies discovered manually but not detected by the model / total number of anomalies) × 100%. If this rate > 5%, trigger incremental model training. Preferably, all optimized strategies, rules, and models must be backtested in a test environment using historical data, and the release process can only begin after key indicators have been confirmed to have improved. A gradual release strategy is adopted, with the new version first enabled in 10% of the agent population, and full release only after 24 hours of stable operation. The system has a preset version rollback interface, so that if serious defects are found during the canary release (such as a surge in false positive rate), the operations and maintenance personnel can quickly switch to the previous stable version to ensure system availability.

[0108] Example 2 presents an exemplary audit and monitoring system based on multi-agent dynamic permission hierarchy, including a trusted authentication module, a dynamic token service module, a micro-permission management module, an audit analysis engine module, and a security closed-loop management module.

[0109] The trusted authentication module performs multi-factor authentication and dynamic identity verification for users, smart agent devices, and smart agent services. Specifically, it implements authentication for users using a password, biometrics, and hardware token; authentication for smart agent devices based on a TPM hardware root of trust and certificate chain; and code signature verification for smart agent services. After initial authentication, it continuously verifies the entity's identity. Dynamic identity verification ensures continued trustworthiness of the identity throughout the session by building a device fingerprint baseline and detecting anomalies.

[0110] The dynamic token service module is used to generate, verify, and revoke dynamic tokens, and maintain a random number blacklist to prevent replay attacks. It generates lightweight dynamic tokens based on authorization decisions from a policy engine. The token's payload includes an atomic permission identifier, validity period, and a critical environment hash, and is signed using a security algorithm such as Ed25519. The private key is protected by an HSM. When an agent accesses resources, it performs comprehensive security verification on the token, including signature validity, environment hash consistency, and replay attack checks. It maintains a distributed token revocation list and random number blacklist, supporting real-time and efficient revocation operations for single or batch tokens based on instructions.

[0111] The micro-permission management module is used to define atomic permissions, monitor permission contraction trigger conditions, and generate permission revoke instructions; it stores and manages the permission control policies, which define the splitting criteria of atomic operation units (operation object, operation type, time range, data / space range); it continuously monitors the context state of the agent, and compares multiple indicators such as geofence, time window, device health, and permission usage interval in real time, i.e., predefined revoke trigger conditions; once any revoke condition is met, it immediately generates a structured permission revoke instruction and broadcasts it to the token service module and all agent gateways through a message queue (such as Kafka), ensuring that the revoke operation takes effect within seconds.

[0112] The audit analysis engine module collects end-to-end logs, integrating a rule engine, a behavior baseline analysis unit, a correlation analysis unit, and a machine learning model to perform four-layer collaborative detection and weighted voting decision-making. Probes are deployed at key nodes throughout the system to collect structured audit logs and bind globally unique association IDs to each operation chain for data interconnection. The rule engine executes predefined hard rules to quickly intercept known threats; the behavior baseline analysis unit, based on sliding window and EWMA algorithms, builds and maintains a normal behavior model of the agent, detecting subtle behavioral deviations; the correlation analysis unit integrates multi-source logs and mines complex, multi-step security events through an attack chain rule base; the machine learning model uses algorithms such as Isolation Forest and LSTM to detect unknown and novel attack patterns. The module receives the outputs from the above four layers and performs weighted voting fusion according to preset weights to generate the final risk score and level.

[0113] The security closed-loop management module is used to execute alerts and interventions based on risk levels, and to drive the optimization of policies, rules, and models based on audit data. Based on the risk level output by the audit analysis engine, it automatically executes tiered response strategies, including immediate token revocation and manual intervention for high-risk situations, permission freezing and administrator notification for medium-risk situations, and logging and enhanced monitoring for low-risk situations. It periodically analyzes audit data to generate quantitative indicators; based on these indicators, it automatically or assisted administrators in iteratively optimizing access control policies, detection rule thresholds, behavioral baseline models, and machine learning algorithms, and feeds back the verified optimization results to the corresponding modules, driving continuous improvement in system security capabilities.

[0114] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims. It should be understood that the invention is not limited to the precise structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. An auditing and monitoring method based on multi-agent dynamic permission hierarchy, characterized in that, The method includes: To build a trusted and secure foundation, multi-factor authentication and dynamic identity verification are performed on users, intelligent agent devices and intelligent agent services, and data communication and storage within the system are encrypted; A dynamic token is generated based on the access control policy. The payload of the dynamic token includes the access identifier of the atomic operation unit defined by the access control policy. The dynamic token adopts a lightweight custom format and includes, in sequence, a token identifier, an agent identifier, a list of access identifiers, an expiration date, an environment hash, and a digital signature. The environment hash is generated by hashing the agent identifier, timestamp, geographic location, device status, and request identifier. Implement micro-permission lifecycle management, continuously monitor the context state of the intelligent agent, and trigger the corresponding permission revoke operation of the dynamic token when any permission revoke trigger condition is detected; The system performs full-process auditing and anomaly detection, collecting logs from the entire system chain. It then employs a four-layer collaborative detection process: rule engine filtering, behavior baseline screening, correlation analysis and mining, and machine learning-assisted detection. Specifically, rule engine filtering detects known threat patterns based on predefined rules and outputs rule matching scores; behavior baseline screening constructs behavioral baselines for agent roles, detects deviations from these baselines based on historical behavior data, and outputs the deviation score; correlation analysis and mining identifies complex attack chains based on multi-source log relationships and outputs correlation risk scores; and machine learning-assisted detection identifies unknown anomaly patterns using machine learning models and outputs anomaly probabilities. Based on the results of the four-layer collaborative detection, a weighted voting decision is made to generate a risk score. A multi-level alarm and intervention mechanism is then implemented to implement a graded response based on the risk score, while optimization is performed based on audit data. The weighted voting decision is achieved by weighting and fusing the rule matching degree, the baseline deviation, the associated risk score, and the anomaly probability. The behavioral baseline of the agent role is constructed based on the sliding window algorithm, and the behavioral baseline deviation is calculated using an exponentially weighted moving average algorithm. The machine learning model adopts a hybrid model structure combining isolated forest and long short-term memory network to detect static anomalies and sequential anomalies, respectively.

2. The audit and monitoring method based on multi-agent dynamic permission hierarchy according to claim 1, characterized in that, The atomic operation unit is defined based on four dimensions: operation object, operation type, time range, and data / spatial range.

3. The auditing and monitoring method based on multi-agent dynamic permission hierarchy according to claim 1, characterized in that, Verification of the dynamic token includes verifying the validity of the digital signature using the public key corresponding to the signing private key; if the signature is invalid, the token is immediately rejected; the current environment hash is recalculated and compared with the environment hash carried in the token; if they do not match, the token is rejected.

4. The auditing and monitoring method based on multi-agent dynamic permission hierarchy according to claim 3, characterized in that, The verification of the dynamic token also includes a replay protection verification, which checks whether the random number contained in the token exists in the short-term usage records maintained by the server; if it exists, it is determined to be a duplicate use and the token is rejected.

5. The audit and monitoring method based on multi-agent dynamic permission hierarchy according to claim 1, characterized in that, The conditions for triggering the revocation of permissions include: geographical deviation, time window exceeding, and abnormal behavior; the geographical deviation is when the distance between the current location of the agent and the authorized location exceeds a preset threshold; the time window exceeding is when the system time exceeds the absolute or relative validity period of the permission; the abnormal behavior is when the idle time of a highly sensitive permission exceeds a preset duration.

6. The auditing and monitoring method based on multi-agent dynamic permission hierarchy according to claim 1, characterized in that, Key logs in the system's end-to-end log are stored on the blockchain; the storage includes: calculating the hash value of the log and constructing a Merkle tree, writing the Merkle root and log metadata into the blockchain; when verifying log integrity, recalculating the log hash and comparing it with the Merkle root stored on the blockchain.

7. An auditing and monitoring system based on multi-agent dynamic permission hierarchy, used to implement the method described in any one of claims 1 to 6, characterized in that, It includes a trusted authentication module, a dynamic token service module, a micro-permission management module, an audit analysis engine module, and a security closed-loop management module; The trusted authentication module is used to perform multi-factor authentication and dynamic identity verification for users, smart agent devices, and smart agent services. The dynamic token service module is used to generate, verify, and revoke dynamic tokens, and maintain a random number blacklist to prevent replay attacks. The micro-permission management module is used to define the trigger conditions for shrinking atomic permissions and monitoring permissions, and to generate permission revoke instructions; The audit analysis engine module is used to collect end-to-end logs and integrates a rule engine, behavior baseline analysis unit, correlation analysis unit, and machine learning model to perform four-layer collaborative detection and weighted voting decision-making. The security closed-loop management module is used to execute alarms and interventions based on risk levels, and to drive the optimization of strategies, rules and models based on audit data.

Images