Multi-dimensional dynamic zero-trust security protection method and system for agent gateway

Abstract

The application relates to the technical field of network security, and discloses a multi-dimensional dynamic zero-trust security protection method and system for an intelligent agent gateway. The method comprises the following steps: a request access step, a secure transmission channel is established; a fusion evaluation step, multi-source attributes are dynamically fused into risk scores and mapped into hierarchical disposal instructions based on an attribute access control framework; an identity verification step, identity certificates containing hierarchical relationship identifiers are verified to support trust chain tracing and cascading operations; a permission control step, short-term permission credentials are issued and session trust degrees are continuously reduced, and re-authentication is forced when the threshold is broken; a threat response step, automatic responses based on rule matching are performed on security events, and a response rate is controlled through a combination strategy of a cooling mechanism and window flow control; and an audit evidence storage step, evaluation decisions and threat responses are recorded in a double-independent chain hash structure, and tampering is identified through continuity verification. The application realizes sub-second dynamic security protection for high-frequency operation scenarios of intelligent agents.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a multi-dimensional dynamic zero-trust security protection method and system for AI Agent gateways. Background Technology

[0002] The Zero Trust security model, proposed by Forrester Research in 2010, is based on the core principle of "never trust, always verify." Google's Beyond Corp project pioneered enterprise-level implementation of the Zero Trust concept, achieving dynamic access control through multi-dimensional signals such as device trust, user identity, and network location. Microsoft Azure AD conditional access further introduces a risk-adaptive mechanism, automatically adjusting authentication policies based on real-time signals. Existing Zero Trust security solutions are primarily designed for traditional human-computer interaction scenarios, with security response latency typically ranging from minutes to hours, and trust states remaining static after initial authentication.

[0003] With the rapid development of large language models and AI agent technologies, AI agents, as intelligent agents that autonomously execute tasks, are widely used in scenarios such as enterprise-level search enhancement generation (RAG) service gateways, intelligent customer service systems, and automated operation and maintenance platforms. AI agents achieve autonomous task execution based on large language models, with tool invocation frequencies reaching sub-second levels, facing unique threats such as prompt word injection, tool invocation tampering, one-time token replay attacks, and multi-agent collaborative attacks.

[0004] Zero-trust security models have evolved from traditional human-computer interaction scenarios to automated intelligent agent scenarios. Existing zero-trust architectures typically exhibit security response latency ranging from minutes to hours, and the trust state remains static after initial authentication, failing to match the high-frequency operations and dynamic risk changes of intelligent agents. The automated operation characteristics of intelligent agents bring security challenges not yet covered by traditional zero-trust architectures: First, the operation frequency of intelligent agents reaches sub-second levels, which cannot match the security response speed of traditional manual review; second, intelligent agent scenarios face unique threats such as prompt injection attacks, tool call tampering, one-time token replay attacks, and multi-agent collaborative attacks; third, intelligent agent identity authentication often uses static API keys, lacking cryptographic identity binding and anti-replay mechanisms. In summary, in intelligent agent (AI Agent) gateway scenarios, it is urgent to address the problems of single security protection dimensions, delayed response, forged identities, tamperable audits, and static trust. Summary of the Invention

[0005] The purpose of this invention is to provide a multi-dimensional dynamic zero-trust security protection method and system for intelligent agent gateways, which solves the technical problems of single security protection dimension, delayed response, identity can be forged, audit can be tampered with, and trust is static in the prior art, and realizes sub-second dynamic security protection for high-frequency operation scenarios of intelligent agents.

[0006] To achieve the above objectives, the present invention provides the following technical solution: According to one aspect of the present invention, a multi-dimensional dynamic zero-trust security protection method for intelligent agent gateways is provided, comprising the following steps: Access request steps: Receive access request from intelligent agent and establish a secure transmission channel; Integrated assessment steps: Based on the attribute access control framework, at least two attributes from network environment, device status, time constraints, behavioral patterns, and spatial location are dynamically integrated into a risk score and mapped into graded handling instructions; Identity verification step: For requests that pass the risk assessment, verify the identity certificate containing the hierarchical relationship identifier, which is used to support trust chain tracing and cascading operations; Access control steps: Issue short-term access credentials corresponding to the risk score and continuously reduce the session trust level. When the trust level falls below the trust level threshold, trigger a forced re-authentication. Threat response steps: Execute automatic responses based on rule matching for detected security events, and control the response rate through a combination of cooling mechanisms and window rate limiting. Audit evidence preservation steps: Record the assessment decision-making and threat response processes separately, maintain the records independently using a chained hash structure, and identify tampered records through continuous verification.

[0007] According to one embodiment of the present invention, the attribute priorities in the fusion evaluation step, from high to low, are network environment, device status, time constraints, behavior patterns, and spatial location, and the graded handling instructions include low-risk release, medium-risk multi-factor authentication upgrade, and high-risk blocking.

[0008] According to one embodiment of the present invention, the identity verification step further includes an authorized operation list, a replay-protected random number, and hardware binding evidence, and the cascading operation includes recursively revoking sub-identities and detecting trust chain loops through the visited set.

[0009] According to one embodiment of the present invention, the continuous reduction of the limit in the access control step adopts an exponential decay model. The exponential decay model is that the trust level decreases exponentially with the time interval. When the trust level falls below the trust level threshold, a forced re-authentication is performed and the trust level is reset to the initial value.

[0010] According to one embodiment of the present invention, the security events in the threat response step include agent-specific threat events, which include at least one of prompt word injection, tool call tampering, one-time token replay, and multi-agent collaborative intrusion.

[0011] According to one embodiment of the present invention, the threat response step buffers security events through a fixed-capacity double-ended queue and organizes event references by source identifier and event type using a two-level index structure to achieve event association and location.

[0012] According to one embodiment of the present invention, the cooling mechanism in the threat response step includes rule-level cooling and source event type-level cooling, and the window rate limiting includes sliding window count rate limiting, triggering an administrator alarm when the rate limiting threshold is reached.

[0013] According to one embodiment of the present invention, the chained hash structure in the audit evidence storage step includes an independently maintained decision evaluation chain and a threat response chain. Each record contains the hash value of the previous record, and the hash value of the current record is calculated based on the pre-configured audit key serialization entry.

[0014] According to one embodiment of the present invention, the audit and evidence storage step further includes capacity management, wherein when the chain hash structure exceeds the preset capacity, the chain head is updated and the most recent record is truncated and retained, and the verification is performed by traversing from the updated chain head.

[0015] On the other hand, the present invention also provides a multi-dimensional dynamic zero-trust security protection system for intelligent agent gateways, the system comprising: The access module is configured to receive access requests from intelligent agents and establish a secure transmission channel. The fusion assessment module is configured to dynamically fuse at least two attributes from network environment, device status, time constraints, behavioral patterns, and spatial location into a risk score based on an attribute access control framework, and map it into graded handling instructions. The identity verification module is configured to verify the identity certificate containing a hierarchical relationship identifier for requests that have passed the risk assessment. The hierarchical relationship identifier is used to support trust chain tracing and cascading operations. The access control module is configured to issue short-term access credentials corresponding to risk scores and continuously reduce session trust levels. When the trust level falls below the threshold, it triggers forced re-authentication. The threat response module is configured to perform automatic rule-matching-based responses to detected security events and control the response rate through a combination of cooling mechanisms and window rate limiting. The audit and evidence storage module is configured to record the assessment decision-making and threat response processes separately, maintain the records independently using a chained hash structure, and identify tampered records through continuous verification.

[0016] The present invention provides a multi-dimensional dynamic zero-trust security protection method and system for intelligent agent gateways. Compared with the prior art, the beneficial effects of the present invention are as follows: (1) It achieves multi-dimensional dynamic protection, reducing the risk of overall protection failure caused by leakage of a single attribute; Existing technologies employ static access control lists or single-dimensional risk scoring, failing to detect dynamic changes in the request context. Once attackers obtain credentials, they can bypass all protections. The fusion assessment step dynamically integrates at least two attributes from network environment, device status, time constraints, behavioral patterns, and spatial location into a risk score. This multi-attribute dynamic fusion ensures the risk score changes in real-time with the request context; an anomaly in a single attribute can affect the overall score. Tiered handling instructions are dynamically adjusted based on the overall score, requiring attackers to manipulate multiple attributes to within normal ranges simultaneously to bypass the protection, significantly increasing the difficulty of bypassing the protection.

[0017] (2) It realizes strong cryptographic identity binding and hierarchical lifecycle management, eliminating the long-term harm caused by the leakage of static credentials; Existing technologies use static API keys or simple tokens, lacking cryptographic identity binding and anti-replay mechanisms, thus posing risks of identity forgery and token reuse. The identity verification step verifies identity credentials containing hierarchical relationship identifiers, supporting trust chain tracing and cascading operations; the access control step issues short-term access credentials. The hierarchical relationship identifier embeds the agent's identity into the cryptographic certificate; the private key is exclusive to the instance and cannot be copied; the parent Agent identifier establishes hierarchical membership, forming a trust chain topology. If the identity of any node is leaked, the subtree can be recursively revoked through cascading operations, preventing the continuous use of forged identities; short-term access credentials limit the validity period of a single authorization, compressing the token reuse window.

[0018] (3) It realizes the continuous dynamic adjustment of the trust status and overcomes the static defect of "one-time authentication is valid for a long time"; Existing technologies grant permanent trust after initial authentication, failing to detect changes in device security status and abnormal behavior during a session. Access control steps continuously reduce session trust levels, triggering mandatory re-authentication when trust levels fall below a threshold. This continuous reduction allows trust to decay naturally over time, reflecting the accumulation of potential risks during the session; device deterioration or abnormal behavior can directly deduct trust through anomaly detection mechanisms, accelerating the decay process; the threshold triggering mechanism forcibly terminates the session and requires re-authentication when trust levels fall below a critical point, transforming dynamic changes into mandatory security actions.

[0019] (4) It achieves sub-second automatic safety response, matching the high-frequency operation characteristics of the intelligent agent; Existing security orchestration and automated response platforms, relying on manual review, suffer from response latency ranging from minutes to hours, failing to match the sub-second operational frequency of intelligent agents. The threat response step executes rule-matching-based automated responses to detected security events, controlling the response rate through a combination of cooling mechanisms and window rate limiting. Rule matching directly maps security events to pre-defined response actions, eliminating manual decision-making; automated responses execute immediately after event generation, compressing response latency to sub-second levels; and the combination of cooling mechanisms and window rate limiting effectively prevents response storms, ensuring system stability in high-frequency agent scenarios.

[0020] (5) It achieves tamper-proof and non-repudiable security decisions, greatly improving audit reliability; Existing technologies store audit logs in a centralized database, allowing attackers with administrator privileges to tamper with or delete records, thus lacking non-repudiation of security decisions. The audit evidence preservation process uses a chained hash structure to independently maintain records, identifying tampered records through continuity checks. The chained hash structure ensures each record depends on the hash value of the previous record; tampering with historical records disrupts the continuity of all subsequent links. Independent maintenance physically separates decision and response records, requiring attackers to simultaneously tamper with both independent chains to conceal the full attack trail. Continuity checks pinpoint tampering points by recalculating and comparing hash values.

[0021] In summary, the technical solution implemented in this application achieves multi-dimensional comprehensive protection and sub-second automatic security response in the AI ​​Agent gateway scenario. By unifying the modeling of five dimensions—network environment, device baseline, time window, user behavior, and cross-regional operations—into a dynamic risk scoring model, attackers must bypass all dimensions simultaneously to launch an attack, significantly improving protection strength. By assigning each AI Agent instance an Ed25519 / RSA4096 cryptographic key pair and CA signature authentication, trust chain tracing and cascading revocation are supported, effectively preventing identity forgery and token reuse. The SOAR automatic response engine, based on an event-driven architecture, automatically executes multi-level responses such as rate limiting, isolation, and identity revocation within sub-seconds after a security event, matching the high-speed operation frequency of the AI ​​Agent. Through the dual-audit chain design of the HMAC-SHA256 hash chain, any tampering with historical records results in a hash chain break and is detected, ensuring the non-repudiation of security decisions. The exponential decay model continuously and dynamically adjusts session trust, and the system continuously monitors abnormal behavior and changes in device security status, triggering mandatory re-authentication or session termination, overcoming the shortcomings of static trust in traditional solutions. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart of a multi-dimensional dynamic zero-trust security protection method for intelligent agent gateways according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a multi-dimensional dynamic zero-trust security protection system for intelligent agent gateways according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the zero-trust security protection process for AI intelligent operation and maintenance agent access in an embodiment of the present invention; Figure 4 This is a flowchart of the five-dimensional dynamic risk scoring process according to an embodiment of the present invention. Detailed Implementation

[0023] To facilitate a clear description of the technical solutions in the embodiments of the present invention, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. For example, the first threshold and the second threshold are merely used to distinguish different thresholds and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0024] It should be noted that in this invention, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0025] In this invention, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one" or similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, "at least one of a, b, or c" can represent: a, b, c, a combination of a and b, a combination of a and c, a combination of b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0026] Traditional zero-trust security solutions assume that the operator is a human user, with low authentication frequency, long session duration, and acceptable response latency. However, intelligent agents, as autonomous decision-making entities, have high operation frequency, rapid session state changes, and dynamically expanding attack surfaces. Therefore, a comprehensive zero-trust security protection mechanism is needed, which includes multi-dimensional dynamic evaluation, cryptographic identity system, continuous trust decay, automatic response, and anti-tampering auditing.

[0027] like Figure 1 As shown, a flowchart of a multi-dimensional dynamic zero-trust security protection method for intelligent agent gateways is presented. The method includes the following steps: S1. Access Request Steps: Receive access requests from intelligent agents and establish a secure transmission channel; S2. Integration Assessment Steps: Based on the attribute access control framework, at least two attributes from network environment, device status, time constraints, behavioral patterns, and spatial location are dynamically integrated into a risk score and mapped into graded handling instructions. S3. Identity verification step: For requests that pass the risk assessment, verify the identity certificate containing the hierarchical relationship identifier, which is used to support trust chain tracing and cascading operations; S4. Access Control Steps: Issue short-term access credentials corresponding to the risk score and continuously reduce the session trust level. When the trust level falls below the threshold, a forced re-authentication is triggered. The issued short-term access credentials have a fixed validity period. Perform tool call integrity verification, compare the tool's SHA-256 hash value, and refuse to tamper with or discard tool calls.

[0028] S5. Threat Response Steps: Execute automatic responses based on rule matching for detected security events, and control the response rate through a combination of cooling mechanisms and window rate limiting. S6. Audit and Evidence Preservation Steps: Record the assessment decision-making and threat response processes separately, maintain the records independently using a chained hash structure, and identify tampered records through continuous verification.

[0029] Furthermore, the method also includes a one-time token generation and anti-replay step: generating a one-time token carrying a random nonce, verifying the signature, validity period, and channel binding; placing the nonce check and writing in the same critical section through a mutex lock to prevent TOCTOU replay attacks; and generating a security event and sending it to the threat response step when a replay attack is detected.

[0030] like Figure 2 The diagram shows a multi-dimensional dynamic zero-trust security protection system for intelligent agent gateways. This system is used to implement the above method and includes: The access module is configured to receive access requests from intelligent agents and establish a secure transmission channel. The fusion assessment module is configured to dynamically fuse at least two attributes from network environment, device status, time constraints, behavioral patterns, and spatial location into a risk score based on an attribute access control framework, and map it into graded handling instructions. The identity verification module is configured to verify the identity certificate containing a hierarchical relationship identifier for requests that have passed the risk assessment. The hierarchical relationship identifier is used to support trust chain tracing and cascading operations. The access control module is configured to issue short-term access credentials corresponding to risk scores and continuously reduce session trust levels. When the trust level falls below the threshold, it triggers forced re-authentication. The threat response module is configured to perform automatic rule-matching-based responses to detected security events and control the response rate through a combination of cooling mechanisms and window rate limiting. Specifically, it includes: an event buffer queue, a secondary event index, a script rule matching unit, and a cooling rate limiting control unit.

[0031] The audit and evidence storage module is configured to record the assessment decision-making and threat response processes separately, maintain the records independently using a chained hash structure, and identify tampered records through continuity verification; it supports chain capacity truncation and hash chain integrity verification.

[0032] The system also includes a one-time token processing submodule, used to generate OST one-time tokens, verify nonces to prevent replay attacks, and detect replay attacks to output security events. This system is deployed on the AI ​​Agent gateway side, and all Agent access requests are processed by this system. It can be applied to RAG enterprise gateways, intelligent customer service, and automated operation and maintenance platform scenarios.

[0033] In the S1 access request process: the gateway receives the AI ​​Agent access request, establishes a secure transmission channel using TLS 1.3 and mTLS mutual authentication, extracts the original request message and request header information, and encapsulates the request context object.

[0034] In the S2 convergence evaluation steps: attribute priority from high to low is as follows: network environment, device status, time constraints, behavioral patterns, and spatial location. For example... Figure 3 As shown, the specific implementation involves the following sub-steps: S21. Extract network layer attributes: client IP, VPN tag, public WiFi tag, overseas IP tag, and IP threat intelligence; among them, overseas IP risk score is 50, public WiFi risk score is 40, VPN risk score is 10, internal network / loopback address risk score is 0, and ordinary public IP risk score is 20; high-risk CIDR, Tor exit node, and cloud data center IP are further supplemented with threat intelligence bonus points.

[0035] S22. Extract device layer attributes: whether the device has been tampered with, whether it is under MDM control, system patch status, and EDR terminal protection status; among which, set the risk score for device tampering to 100, the risk score for uncontrolled devices to 60, the risk score for unpatched devices to 40, the risk score for EDR offline to 30, and the risk score for secure devices to 0; and add an additional score for device trust decay.

[0036] S23. Time window constraint: Risk score for accessing confidential resources during working hours is 0; risk score for accessing confidential resources outside working hours is 40; risk score for accessing internal resources is 15.

[0037] S24. User Entity Behavior Assessment: Compared with historical behavior baseline, a request frequency exceeding 3 times the baseline results in a risk score of 60, while a frequency between 1.5 and 3 times the baseline results in a risk score of 30.

[0038] S25. Cross-regional assessment: Risk score of 25 for geographical locations spanning more than 500 kilometers; Risk score of 15 for ordinary users accessing sensitive resources across departments.

[0039] The scores for all the above dimensions are summed, with a maximum of 100 points: Low risk, 0-30 points: access granted; Medium risk, 31-60 points: trigger MFA multi-factor authentication upgrade; access granted if MFA verification passes, blocked if it fails; High risk, 61-100 points: access directly blocked, security event generated and sent to the threat response process. The evaluation results of each step in S2 are written into the DecisionPath, fully recording the actual basis for each score.

[0040] In the S3 identity verification step: Each AI Agent instance generates an Ed25519 key pair, with RSA4096 used as a fallback; the CA issues an AgentIdentityProof, which includes the agent identifier (agent_id), instance identifier (instance_id), parent agent identifier (parent_agent_id) hierarchical relationship identifier, authorized_actions list, attestation_nonce (anti-replay random number), hw_evidence (hardware binding evidence), and CA digital signature.

[0041] The specific verification process includes the following sub-steps: S31. Verify the CA's digital signature; S32. Verify the certificate validity period; S33. Verify that agent_id is not in the revocation list; S34. Under the protection of the mutex lock, the nonce is not used and is stored in the anti-replay cache. S35. Verification request operation belongs to the authorized operation list.

[0042] Specifically, for the cascading revocation scenario: when the parent agent's identity is leaked, recursive revocation is performed, traversing all child agents whose parent_agent_id is equal to the target agent_id to complete the identity revocation; the visited set records the agent_ids that have been traversed, detecting trust chain loops and avoiding infinite recursion.

[0043] In S4's access control steps: issue JIT short-term access tokens, with a default validity period of 5 minutes; session trust adopts an exponential decay model. ,in, The trust score of the previous session. For time intervals, The trust half-life is set to 3600 seconds by default. Each time a request arrives, the session trust decay is calculated. When the trust score falls below the threshold of 30, the session is suspended, and re-authentication is forcibly required. If re-authentication is successful, the trust score is reset to the initial 100. Simultaneously, tool call integrity verification is performed, comparing the tool's SHA-256 hash; obsolete or tampered tools are directly rejected from use.

[0044] In S5's threat response steps: Automated rule-matching responses are executed for detected security events, and the response rate is controlled through a combination of cooling mechanisms and window rate limiting. These security events include agent-specific events: prompt word injection, tool call tampering, one-time token replay, and multi-agent collaborative intrusion. Security events are stored in a fixed-capacity double-ended queue, and event correlation and location are completed through a secondary index `source_id-event_type`. Two types of cooling are configured: rule-level cooling and source-event type cooling; sliding window counting rate limiting is used; SOAR playbook rules are matched to automatically execute rate limiting, isolation, session revocation, identity cascading revocation, and IP blocking actions; when the unit window response count reaches the limit, an administrator alarm is triggered.

[0045] The audit evidence preservation process in S6 requires maintaining two independent hash chains: the ABAC decision evaluation chain and the SOAR threat response chain. Each record carries the hash value of the previous record, and the hash of the current record is calculated using an HMAC-SHA256 key. When the audit chain exceeds its maximum capacity, the chain head is updated, and the most recent record is truncated. Integrity verification starts from the chain head and traverses the chain chain by chain, comparing hashes. If the hashes do not match, the record is considered to have been tampered with; if the hashes are inconsistent, the hash chain is considered broken.

[0046] Example 1: Enterprise internal AI intelligent operation and maintenance agent accesses backend server resources.

[0047] Figure 3In the process, the intelligent operation and maintenance agent initiates an access request, and the request entry point performs mTLS two-way authentication and TLS 1.3 transmission. The fusion evaluation module, as the ABAC multi-dimensional dynamic risk scoring engine, outputs a comprehensive risk score from 0 to 100 based on five evaluation dimensions: network trust, device baseline, time window, UEBA behavior, and cross-regional cross-domain. The subsequent branch executes intelligent agent password authentication, MFA two-factor authentication, and JIT dynamic authorization. Then it enters the continuous verification and SOAR automatic response module to complete trust decay, anomaly detection, automatic isolation / revocation / blocking, and other processing. Finally, it outputs to the anti-tampering audit chain to maintain the ABAC decision audit chain and the SOAR response audit chain, respectively.

[0048] Figure 4 The flowchart for multidimensional dynamic risk scoring is as follows: after a request arrives, the context attribute is extracted, and network trust assessment, device security baseline assessment, time window constraint assessment, UEBA behavior anomaly assessment, and cross-regional risk assessment are performed in sequence. IP threat intelligence is added to calculate the comprehensive risk score, with a total score cap of 100. Based on the scoring threshold, there are three handling results: low risk (less than or equal to 30) allow, medium risk (31 to 60) MFA upgrade, and high risk (greater than 60) block.

[0049] For example, when an agent initiates access during working hours on the enterprise intranet, the device baseline is secure and the behavior conforms to the baseline; the comprehensive risk score is 22 points, so low-risk access is granted; the identity verification module verifies the CA signature identity certificate, and the nonce anti-replay verification passes; the access control module issues a 5-minute short-term access token; the session trust level decays exponentially over time; if there is no interaction for a long time, the trust score drops below the threshold, and the gateway forcibly triggers re-authentication.

[0050] For encrypted proof information of Agent identity, a data structure AgentIdentityProof is set up, including: agent_id (unique Agent identifier), agent_type (Agent type), instance_id (instance identifier), public_key_fingerprint (SHA-256 fingerprint of public key), issued_at (issue time), expires_at (expiration time, default 90 days after issuance), authorized_actions (authorized action list), max_privilege (maximum privilege level L1 / L2 / L3), parent_agent_id (parent Agent identifier, used for trust chain tracing), attestation_nonce (anti-replay random number), hw_evidence (hardware binding evidence), and signature (digital signature of the certificate authority for all the above fields).

[0051] For a complete record of the Agent's identity, a data structure AgentIdentityRecord is set up to persistently store the complete record of the Agent's identity, including: proof (AgentIdentityProof type), private_key_pem (private key stored in AES-256-GCM encryption), public_key_pem (public key in PEM format), certificate_pem (X.509 certificate), status (identity status, values ​​include PENDING / ACTIVE / EXPIRED / REVOKED / COMPROMISED), rotated_from (previous identity identifier), created_at (creation timestamp), and updated_at (last update timestamp).

[0052] Set up a data structure DecisionPath, which is used to store the complete decision path for each ABAC evaluation. The information in DecisionPath includes: step name (string), result (allow / reject / MFA upgrade), detail (description), and latency_ms (the number of milliseconds taken for this step).

[0053] Initialize the global identity registry `AGENT_IDENTITY_REGISTRY={}`, which is a dictionary mapping from `agent_id` to `AgentIdentityRecord`. Initialize the revocation list `REVOCATION_LIST=set()`, storing the set of revoked `agent_id`s. Initialize the anti-replay cache `NONCE_REPLAY_CACHE={}`, which is a dictionary mapping from nonce to expiration timestamp. Set the anti-replay mutex `NONCE_REPLAY_LOCK`. Set `NONCE_REPLAY_TTL` to 900 seconds (default 15 minutes). Set the preferred asymmetric cryptography algorithm to Ed25519 and the fallback algorithm to RSA 4096.

[0054] Set up a data structure called SecurityEvent to store complete information about security events. The information in SecurityEvent includes: event_id (unique event identifier), timestamp (event timestamp), severity (severity level, values ​​include INFO / WARNING / ALERT / CRITICAL), event_type (event type, such as ost_replay / prompt_injection / drift_detected / tool_tamper / identity_breach / multi_agent_intrusion), source (event source, values ​​include agent / user / mcp / tool / network), source_id (source identifier), session_id (associated session identifier), task_id (associated task identifier), score (threat score 0-100), description (event description), response_taken (list of executed response actions), and acknowledged (whether acknowledged).

[0055] The SOARPlaybookRule data structure is used to define SOAR automatic response rules. The information in SOARPlaybookRule includes: rule_id (unique identifier of the rule), name (rule name), event_types (list of event types to be triggered), min_severity (minimum severity level to be triggered), applicable_sources (list of applicable source types), auto_execute (whether to execute automatically, false indicates that manual approval is required), cooldown_seconds (cooldown time for the rule), max_actions_per_window (maximum number of responses per window), action (response action type, values ​​include THROTTLE / QUARANTINE / REVOKE_SESSION / REVOKE_IDENTITY / BLOCK_IP / REQUIRE_MFA / SYSTEM_LOCKDOWN), and tier (response level, values ​​include CONTAIN / ERADICATE / RECOVER).

[0056] Initialize the global event buffer `_event_buffer` as a fixed-size double-ended queue (default capacity 5000), automatically evicting the oldest events. Initialize the secondary event index `_event_index`, with the structure `{source_id:{event_type:[events]}}`. Initialize the response counter `_response_counter`, with the structure `{source_id:{ResponseAction:[timestamp_list]}}`. Initialize the cooldown record table `_last_cooldown`, with the structure `{cooldown_key:last_executed_time}`. Initialize the cooldown mutex `_cooldown_lock` and the event buffer mutex `_soar_lock`.

[0057] The SessionRecord data structure is used to store session trust status information. The information in SessionRecord includes: session_id (unique session identifier), user_id (associated user identifier), agent_id (associated agent identifier), trust_score (current trust score, a floating-point number, with an initial value of 100.0), created_at (session creation timestamp), last_verified_at (last verification timestamp), last_activity_at (recent activity timestamp), anomaly_flags (anomaly flag list), and status (session status, with values ​​including ACTIVE / SUSPENDED / TERMINATED).

[0058] The global session registry `_session_registry={}` is a dictionary mapping session_id to sessionRecord. The user behavior baseline registry `_user_behavior_baseline={}` is initialized, with the structure `{user_id:{daily_avg_count, total_requests, days_tracked, last_updated}}`. The session mutex `_session_lock` and the baseline mutex `_baseline_lock` are also initialized.

[0059] The audit chain key AUDIT_SECRET (obtained from the environment variables ABAC_AUDIT_SECRET and SOAR_AUDIT_SECRET respectively) is used for HMAC-SHA256 message authentication code calculation. The ABAC decision audit chain ABAC_AUDIT_LOG=[] is initialized, the hash value of the previous record in the ABAC audit chain ABAC_PREV_HASH="0"×64 (a 64-character hexadecimal zero string, used as the genesis record) is initialized, and the ABAC audit mutex ABAC_AUDIT_LOCK is initialized. The SOAR response audit chain SOAR_AUDIT_LOG=[] is initialized, the hash value of the previous record in the SOAR audit chain SOAR_PREV_HASH="0"×64 is initialized, and the SOAR audit mutex SOAR_AUDIT_LOCK is initialized. The maximum audit chain capacity MAX_AUDIT_LOG_SIZE=10000.

[0060] The MFA verification registry is set to MFA_VERIFIED_REGISTRY={}, with the structure {user_uid:expiry_timestamp}. The MFA verification mutex is initialized to MFA_VERIFIED_LOCK. The MFA verification expiration time is set to MFA_VERIFIED_TTL=900 seconds (15 minutes). Only multi-factor authentication server-side writes to the registry are allowed; the mfa_verified field in the client context is not trusted.

[0061] See Figure 3 As shown, it first receives the access request initiated by the AI ​​Agent and extracts the request context attributes.

[0062] Extracting network layer attributes specifically includes: extracting client_ip from the X-Forwarded-For or X-Real-IP request header; extracting the is_vpn, is_public_wifi, and is_foreign_ip boolean flags from the GeoIP / ASN database query results; and querying threat intelligence scores from the IP reputation database.

[0063] Extracting device layer attributes specifically includes: extracting device_mdm_managed (whether it is managed and controlled by the mobile device), device_os_patched (whether the system patch is up-to-date), device_edr_online (whether the terminal detection response is online), device_tampered (whether jailbreak / rooting / tampering is detected), and device_id (unique device identifier) ​​from the security posture data reported by the client.

[0064] Extracting identity layer attributes specifically includes: extracting user_uid, user_role, user_department, user_level (permission level L1 / L2 / L3), and agent_id from JWT Token or Agent identity proof.

[0065] Extracting request layer attributes specifically includes: extracting action (action type), resource (target resource identifier), resource_department (resource department), resource_level (resource sensitivity level PUBLIC / INTERNAL / CONFIDENTIAL / TOP_SECRET), and request_time (request arrival timestamp) from the request URL and method.

[0066] At this stage, all attributes obtained in the above extraction process are encapsulated into a request context object, which is a dictionary mapping from strings to values ​​of any type.

[0067] like Figure 4 As shown, the next step is to perform a multi-dimensional dynamic risk score on the access requests that reach the gateway.

[0068] Regarding the first dimension of network trust assessment: If `context.is_foreign_ip` is True, it is classified as FOREIGN level, and a risk score of S_NETWORK=50 is returned; if `context.is_public_wifi` is True, it is classified as PUBLIC_WIFI level, and a risk score of S_NETWORK=40 is returned; if `context.is_vpn` is True, it is classified as VPN level, and a risk score of S_NETWORK=10 is returned; if none of the above explicit flags are set, `context.client_ip` is resolved to an IP address object. If `ip.is_private` or `ip.is_loopback` is True, it is classified as INTERNAL level, and a risk score of S_NETWORK=0 is returned; otherwise, it is classified as PUBLIC level, and a risk score of S_NETWORK=20 is returned. The evaluation result of this dimension is appended to the decision path array `DecisionPath`, and the step name is recorded as "network_trust".

[0069] For the second dimension of device security baseline assessment: First, device registration and trust decay calculation are performed. The device_id is retrieved from the context. If the device_id is not empty, a device_registry_lock mutex is acquired. If the device_id is not in the device_registry, a new device entry is created, and the trust score is initialized to 100.0. Otherwise, the elapsed time interval since the last detection is calculated, and the decayed trust score is calculated using the aforementioned decay formula. The health score (health_score) is obtained by looking up the table based on the current device health status (SECURE→100, EDR_OFFLINE→60, UNPATCHED→40, UNMANAGED→20, TAMPERED→0). The trust score is then updated to the smaller of decayed_trust and health_score. If the device registry capacity exceeds the limit, the oldest 10% of entries are evicted in ascending order of last_seen. Release the mutex lock; then assess the device health status: if context.device_tampered is True, it is classified as TAMPERED level, S_DEVICE=100; otherwise, if context.device_mdm_managed is False, it is classified as UNMANAGED level, S_DEVICE=60; ​​otherwise, if context.device_os_patched is False, it is classified as UNPATCHED level, S_DEVICE=40; otherwise, if context.device_edr_online is False, it is classified as EDR_OFFLINE level, S_DEVICE=30; otherwise, it is classified as SECURE level, S_DEVICE=0. Furthermore, an additional risk score for device trust decay is added: if the device trust score `trust_score` < 20, `S_DEVICE_EXTRA` = 50; otherwise, if `trust_score` < 40, `S_DEVICE_EXTRA` = 30; otherwise, if `trust_score` < 60, `S_DEVICE_EXTRA` = 15; otherwise, `S_DEVICE_EXTRA` = 0. `S_DEVICE` = `S_DEVICE` + `S_DEVICE_EXTRA`. Finally, the evaluation results for this dimension are appended to the DecisionPath.

[0070] Evaluation of the third-dimensional time window constraint: First, obtain the hourly portion of request_time and resource_level. If request_time falls within the working time window (e.g., 9:00-18:00), S_TIME=0; otherwise, if resource_level>=CONFIDENTIAL, S_TIME=40; otherwise, if resource_level>=INTERNAL, S_TIME=15; otherwise, S_TIME=0. Then, append the evaluation results for this dimension to the DecisionPath.

[0071] For the fourth dimension of user entity behavior anomaly assessment: First, apply a `baseline_lock` mutex. If `user_id` is not in `_user_behavior_baseline`, create a new baseline record and initialize `daily_avg_count` to 0; otherwise, retrieve the `daily_avg_count` from the baseline. Release the mutex. Calculate the number of requests for this user within the current sliding time window (default 1 hour), `current_count`. If `daily_avg_count` > 0, calculate `deviation = current_count / daily_avg_count`. If `deviation` > 3.0, set `S_UEBA` to 60; otherwise, if `deviation` > 1.5, set `S_UEBA` to 30; otherwise, set `S_UEBA` to 0. If `daily_avg_count` = 0, set `S_UEBA` to 0 (insufficient baseline data, no penalty). Finally, append the evaluation results for this dimension to the `DecisionPath`.

[0072] Regarding the fifth dimension of cross-regional risk assessment: First, perform a cross-location login detection: obtain the historical login IP location list `last_locations` and the current request IP location `current_location`. If the distance between `current_location` and any of `last_locations` exceeds a preset threshold (e.g., 500 km), `S_CROSS_LOCATION` = 25; otherwise, `S_CROSS_LOCATION` = 0. Next, perform a cross-department access detection: obtain `user_department` and `resource_department`. If `user_department` is not equal to `resource_department` and `resource_level>=INTERNAL`, and if `user_level` is L1 or L2 (non-administrator), `S_CROSS_DEPT` = 15; otherwise (administrator level L3), `S_CROSS_DEPT` = 0. Finally, obtain the total risk score for this dimension: `S_CROSS` = `S_CROSS_LOCATION` + `S_CROSS_DEPT`, with a maximum of 40. Append the evaluation results for this dimension to the `DecisionPath`.

[0073] Perform IP threat intelligence bonus assessment: If the IP belongs to the high-risk CIDR set, S_THREAT+=30; if the IP belongs to the Tor egress node list, S_THREAT+=40; if the IP belongs to the cloud service provider / data center IP range, S_THREAT+=15. Append the assessment results to DecisionPath.

[0074] After the above assessments are completed, a comprehensive risk score is calculated and a tiered response is implemented, including: The weighted summation of risk scores across all dimensions is expressed as follows: total_score=S_NETWORK+S_DEVICE+S_TIME+S_UEBA+S_CROSS+S_THREAT, If total_score > 100, then set total_score = 100. The tiered processing specifically includes: If total_score<=30, it is determined to be a LOW risk level. The complete decision path is recorded to DecisionPath, the ABAC decision audit record is appended to the tamper-proof hash chain, and the release decision is returned. If 30 < total_score <= 60, it is determined as a MEDIUM risk level, the server-side MFA verification query is invoked (to query whether the verification status of the user_uid in the MFA_VERIFIED_REGISTRY is within the validity period). If MFA has been verified, an ABAC decision audit record is added, and a pass decision is returned; otherwise, an ABAC decision audit record is added, and a decision requiring MFA upgrade is returned.

[0075] If total_score > 60, it is determined as a HIGH risk level, an ABAC decision audit record is added, a SecurityEvent event (severity=CRITICAL) is generated, the event is pushed to the SOAR event buffer to execute the SOAR response process, and a block decision is returned.

[0076] In the identity authentication step, AI Agent cryptographic identity authentication is performed on the request that has passed the risk assessment.

[0077] During the agent startup phase, a cryptographic identity is created (a double-checked lock prevents concurrent duplicate creation). First check (no lock): If agent_id already exists in AGENT_IDENTITY_REGISTRY and its state is ACTIVE, return the existing identity record directly. Second check (within the lock): If agent_id already exists in AGENT_IDENTITY_REGISTRY and its state is ACTIVE, release the lock and return the existing identity record. Execute the creation process: If KEY_ALGORITHM is "ed25519", generate a key pair using the Ed25519 algorithm; otherwise, generate a key pair using the RSA 4096 algorithm. Encrypt and store the private key: If private key encryption is enabled, obtain a 32-byte key from the key encryption key KEK, encrypt the PEM bytes of the private key using AES-256-GCM mode, and use a randomly generated 12-byte nonce. Encode nonce·ciphertext·tag into Base64 and store it; otherwise, store the private key in plaintext PEM format. Construct AgentIdentityProof: Generate a 32-byte random number as attestation_nonce, calculate the SHA-256 hash of the public key encoded in DER as public_key_fingerprint, obtain the current UTC time as issued_at, calculate issued_at + 90 days as expires_at, and populate fields such as agent_id, agent_type, instance_id, deployer_id, authorized_actions, max_privilege, parent_agent_id, and hw_evidence. CA Signature: If both the CA certificate file and CA private key file exist, load the CA certificate and CA private key, digitally sign the JSON bytes of the identity verification using the CA private key (Ed25519 or RSA-PSS), write the signature result to the `proof.signature` field, construct an X.509 certificate (the CN of the Subject is `agent_id`, and the URI type `urn:agent:{agent_id}` is added in the SAN extension), and sign it with the CA; otherwise, use the persistent development signing key to sign and construct a self-signed X.509 certificate. Persistence: Construct an `AgentIdentityRecord`, serialize it to JSON and write it to a file (file path: `AGENT_IDENTITY_DIR / {agent_id}.json`), add `agent_id` and `AgentIdentityRecord` to `AGENT_IDENTITY_REGISTRY`. Release the lock.

[0078] In the Agent authentication process, the CA signature is first verified: `proof.signature` and the `proof` data (excluding the `signature` field) are extracted and serialized into standard JSON bytes. If the CA certificate file exists, the signature is verified using the CA's public key. If signature verification fails, `False` is returned (no fallback to weak verification occurs if the CA exists); otherwise, the signature is verified using the public key of the development signing key. Next, the expiration time is verified: `proof.expires_at` is parsed into a datetime object. If the current UTC time is greater than `expires_at`, the identity status is updated to `EXPIRED`, and `False` is returned. Finally, the revocation list is verified: if `proof.agent_id` is in `REVOCATION_LIST`, `False` is returned. Verify the nonce replay protection (thread-safe): Obtain `proof.attestation_nonce`, acquire the `NONCE_REPLAY_LOCK` mutex, clear expired entries from the nonce cache, and if `attestation_nonce` is already in `NONCE_REPLAY_CACHE`, release the lock and return `False` (the nonce has been used, a replay attack); otherwise, add `attestation_nonce` to `NONCE_REPLAY_CACHE` with an expiration time of the current time + `NONCE_REPLAY_TTL`, and release the lock. The checking and adding operations must be completed within the same mutex to prevent concurrent requests from exploiting the time window between checking and adding (TOCTOU race condition). Finally, verify the authorization operation: Obtain the requested action; if the action is not in `proof.authorized_actions`, return `False`. Return `True` after all verifications pass.

[0079] In the Agent identity rotation process: generate a new key pair and identity certificate (according to the process initiated by the agent), set the rotated_from field of the new identity record to the agent_id of the old identity, update the status of the old identity to REVOKED and add it to REVOCATION_LIST, persist the new identity record to disk, and remove the old entry and add the new entry in AGENT_IDENTITY_REGISTRY.

[0080] The agent identity revocation and cascading revocation process includes: First, acquiring an IDENTITY_LOCK mutex lock. If the target agent_id is not in AGENT_IDENTITY_REGISTRY, releasing the lock and returning False. Retrieving the target identity record, updating its status to REVOKED, adding the agent_id to REVOCATION_LIST, and persisting it to disk; Recursively cascading revocation of all sub-identities: Traversing all records in AGENT_IDENTITY_REGISTRY, if the record's proof.parent_agent_id equals the target agent_id, recursively calling the revocation function to revoke that sub-identity. Releasing the lock and returning True; Trust chain loop detection: When traversing the identity chain, using the visited set to record visited agent_ids. If a visited agent_id is encountered, an exception is thrown (to prevent infinite loops caused by loops in the trust chain).

[0081] Issue instant authorization tokens and perform integrity checks on authenticated requests, specifically including the following two aspects: Instant authorization token issuance: Generate a token_id, construct a payload (containing token_id, user_uid, action, resource, granted_level, issued_at, expires_at), serialize the payload into JSON, calculate the HMAC-SHA256 signature, and return the Base64 encoded complete token. The token has a default validity period of 300 seconds (5 minutes) and automatically expires. Authorization levels are compared using IntEnum values ​​(L1=1, L2=2, L3=3) to avoid string comparison vulnerabilities. Supply chain tool integrity verification: Upon initial tool registration, a SHA-256 hash is calculated and stored in TOOL_HASH_REGISTRY. Before each tool call, the SHA-256 hash is recalculated and compared with the registration hash. If the tool is marked as remote_source, re-verification is skipped (only the initial verification is performed); if the tool is marked as deprecated, the call is rejected. All registry operations are completed within the TOOL_REGISTRY_LOCK mutex.

[0082] The request content is filtered using a security sandbox and continuous verification is performed.

[0083] First, perform URL security parsing and SSRF protection: Parse the URL to obtain the hostname. If the hostname is a valid IP address, check ip.is_private, ip.is_loopback, ip.is_link_local, ip.is_multicast, ip.is_unspecified, and ip.is_reserved; if any of these are True, block the connection. Simultaneously, check if the embedded IPv4 address in the IPv4-mapped IPv6 address is an internal network address, and check for decimal IP bypass (e.g., converting 2130706433 to 127.0.0.1). If the hostname is not an IP address, check if it ends with .local, .internal, or .localhost. Only HTTP / HTTPS protocols are allowed; Session trust decay: For each request processed, a `_session_lock` mutex is acquired, the decayed session trust score is calculated using the formula `trust(t) = trust0 × 2^(-Δt / half_life)`, `last_activity_at` is updated to the current time, and the lock is released; Trust threshold judgment: If the session trust score is lower than `SESSION_TRUST_MIN_THRESHOLD` (default 30), the session state is marked as `SUSPENDED`, requiring the user to re-complete multi-factor authentication. After successful re-authentication, the trust score is reset to 100.0 and the session is restored to the `ACTIVE` state. User behavior baseline adaptive update: After each request processed, a `_baseline_lock` mutex is acquired, the user behavior baseline is updated (total_requests are accumulated, daily_avg_count is recalculated based on the number of tracking days), and the lock is released. Anomaly detection and forced session termination: If the ratio of the current request frequency to daily_avg_count exceeds ANOMALY_THRESHOLD (default 3.0), record the anomaly flag in anomaly_flags. If the length of anomaly_flags exceeds MAX_ANOMALY_FLAGS (default 3), acquire the _session_lock mutex, update the session state to TERMINATED, set trust_score to 0, generate a SecurityEvent (event_type="session_terminated", severity=ALERT) and push the event to the SOAR buffer, then release the lock.

[0084] Automatic detection and SOAR response for security incidents.

[0085] First, generation and buffering of security events are performed: when any module in the system detects a security threat, a SecurityEvent (including fields such as event_id, timestamp, severity, event_type, source, source_id, session_id, task_id, score, and description) is constructed. Then, the _soar_lock mutex is locked; if _event_buffer is full, the oldest event is evicted from the left end, the reference to this event is removed from _event_index before eviction (if the sublist is empty after removal, the key is deleted, and if all event_types under the source_id are empty, the source_id key is deleted), the new event is appended to _event_buffer, _event_index is updated (the event reference is appended to the corresponding source_id→event_type→list), and the lock is released. Expired events are cleaned up periodically: traverse _event_index, remove event references whose timestamp exceeds EVENT_WINDOW_SECONDS, and delete empty keys to prevent memory leaks.

[0086] Then, event correlation analysis is performed: count the number of high-risk events from the same source: lock the _soar_lock mutex, obtain all event lists under _event_index[source_id], count the number of events critical_count whose timestamp is within the EVENT_WINDOW_SECONDS (default 300 seconds) window and whose severity is CRITICAL, release the lock, and return critical_count. If critical_count >= CRITICAL_THRESHOLD (default 5), an administrator alert escalation is triggered, and the acknowledged flag of all related events is marked as True.

[0087] After that, SOAR Playbook rule matching is executed. Traverse each rule in the default Playbook rule set DEFAULT_PLAYBOOK: skip if event.severity < rule.min_severity; skip if event.source is not in rule.applicable_sources; skip if event.event_type is not in rule.event_types; return the rule if the matching is successful. The default Playbook rule set includes six rules: Rule 1, the event type is ost_replay and the severity level is at least WARNING, the response action is THROTTLE, which is executed automatically with a cooldown of 60 seconds; Rule 2, the event type is prompt_injection and the severity level is at least ALERT, the response action is QUARANTINE, which is executed automatically with a cooldown of 120 seconds; Rule 3, the event type is tool_tamper and the severity level is at least CRITICAL, the response action is REVOKE_IDENTITY, which is executed automatically; Rule 4, the event type is drift_detected and the severity level is at least CRITICAL, the response action is REVOKE_SESSION, which is executed automatically; Rule 5, the event type is identity_breach and the severity level is at least CRITICAL, the response action is REVOKE_IDENTITY, which requires manual approval; Rule 6, the event type is multi_agent_intrusion and the severity level is at least CRITICAL, the response action is SYSTEM_LOCKDOWN, which requires manual approval.

[0088] Thread-safe execution for automated responses. First perform cooldown check and preemption: obtain the cooldown key cooldown_key="{event.source_id}:{event.event_type}" and the current time now. Acquire the _cooldown_lock mutex. If cooldown_key is in _last_cooldown and now - _last_cooldown[cooldown_key] <COOLDOWN_SECONDS (default 30 seconds), release the lock and skip this event.

[0089] If rule.rule_id is in _last_cooldown and now - _last_cooldown[rule.rule_id] <rule.cooldown_seconds, release the lock, and skip this event. Obtain the sliding window counter list counter_list, and clean up expired records that exceed COUNTER_WINDOW_SECONDS (default 3600 seconds). If action_count >= rule.max_actions_per_window (default 10), and if action_count is equal to the upper limit, trigger an administrator alarm, release the lock, and skip this event. Preoccupation: set _last_cooldown[rule.rule_id] = now and _last_cooldown[cooldown_key] = now, and append the current time to counter_list. Release _cooldown_lock. Execute response actions (executed outside the lock to avoid deadlock caused by calling user code while holding the lock): execute the corresponding response according to the type of rule.action — if it is THROTTLE, call the gateway rate limiting interface to lower the request rate upper limit; if it is QUARANTINE, temporarily downgrade the source_id permission to L1 read-only; if it is REVOKE_SESSION, call the continuous verification module to terminate the session; if it is REVOKE_IDENTITY, call the Agent identity module to revoke the identity (execute the aforementioned cascading revocation process); if it is BLOCK_IP, add the source IP to the temporary firewall blocklist; if it is SYSTEM_LOCKDOWN, switch the system to the secure lock mode where only administrators are allowed to operate. If a callback function for this action is registered in SOAR_ACTION_CALLBACKS, call the callback function. Append the SOAR audit record to the tamper-proof hash chain (perform step 7.2). Append the event to the responses_taken list. Finally, when the number of同源 responses reaches the upper limit, trigger an administrator alarm to notify manual intervention for handling.

[0090] Regarding the steps for constructing and verifying the anti-tampering audit chain, the first step is to append the ABAC decision audit chain. After the ABAC policy engine completes a decision evaluation, it acquires the ABAC_AUDIT_LOCK mutex lock, constructs the audit entry entry={timestamp, user_uid, user_role, action, score, decision_path, prev_hash:ABAC_PREV_HASH}, serializes the entry (excluding the record_hash field) into alphabetically ordered JSON bytes, calculates the hexadecimal string of record_hash=HMAC-SHA256(ABAC_AUDIT_SECRET, entry_bytes), sets entry["record_hash"]=record_hash, ABAC_PREV_HASH=record_hash, and then appends ABAC_AUDIT_LOG.append(entry).

[0091] If len(ABAC_AUDIT_LOG) > MAX_AUDIT_LOG_SIZE, update ABAC_CHAIN_HEAD to ABAC_AUDIT_LOG[0]["prev_hash"], and retain the most recent 9999 records. Release the lock. Then, the SOAR response audit chain is appended: After the SOAR engine executes an automatic response, a SOAR_AUDIT_LOCK mutex is acquired, an audit entry is constructed: entry={timestamp, event_id, event_type, severity, source_id, action_taken, rule_id, description, prev_hash: SOAR_PREV_HASH}, the entry (excluding the record_hash field) is serialized into alphabetically ordered JSON bytes, and the hexadecimal string of record_hash=HMAC-SHA256(SOAR_AUDIT_SECRET, entry_bytes) is calculated. entry["record_hash"]=record_hash, SOAR_PREV_HASH=record_hash, and SOAR_AUDIT_LOG.append(entry). The truncation check is performed as before, and the lock is released. Finally, the integrity of the audit chain is verified. Apply the ABAC_AUDIT_LOCK mutex lock, with prev_hash = ABAC_CHAIN_HEAD. For each entry in ABAC_AUDIT_LOG: if the entry's prev_hash is not equal to prev_hash, record an error "chain broken" and exit the loop; otherwise, extract the record_hash where stored_hash equals the entry, recalculate expected_hash = HMAC - SHA256(ABAC_AUDIT_SECRET, entry_bytes), and if they are not equal, record an error "record tampered with" and exit the loop; otherwise, prev_hash equals stored_hash. Release the lock and return (errors is empty, errors). The verification logic for the SOAR audit chain is the same, using SOAR_AUDIT_LOCK, SOAR_AUDIT_LOG, and SOAR_CHAIN_HEAD.

[0092] In addition, the method can also perform one-time token generation, verification, and replay protection.

[0093] OST token generation includes: generating a 32-byte random nonce, constructing the token payload (containing token_id, action, channel, issued_at, expires_at, and nonce), serializing the token payload into standard JSON bytes, calculating signature=HMAC-SHA256(OST_SECRET, payload_bytes), and constructing the complete token as Base64 encoded JSON.

[0094] OST token verification and replay protection include: decoding the Base64 token to extract the payload and signature, recalculating the HMAC-SHA256 signature for comparison (using hmac.compare_digest to prevent timing attacks), checking whether the action and channel match (channel binding verification), and checking whether it has expired.

[0095] Nonce replay protection verification (thread-safe, TOCTOU protection) includes: acquiring a NONCE_CACHE_LOCK mutex; if the cache capacity exceeds a threshold, lazy cleanup of expired entries; if the nonce is in NONCE_CACHE, releasing the lock and returning False (nonce has been consumed, replay attack); otherwise, NONCE_CACHE[nonce] = current time + TTL, releasing the lock and returning True. The checking and adding operations must be completed within the same mutex to prevent concurrent requests from exploiting the time window between checking and adding. If a replay attack is detected, a SecurityEvent (event_type="ost_replay", severity=WARNING) is generated and pushed to the SOAR buffer to trigger an automatic rate limiting response.

[0096] This invention presents a multi-dimensional dynamic zero-trust security protection method and system for AI Agent gateways. First, it unifies five dimensions—network trust, device security baseline, time window constraints, abnormal user behavior, and cross-regional risks—into a dynamic risk scoring model, implementing a three-tiered handling system based on the score. Then, it assigns an Ed25519 / RSA4096 cryptographic key pair and a CA-signed identity certificate to each AI Agent instance, achieving identity anti-counterfeiting and trust chain traceability. Next, based on an event-driven architecture, it automatically executes multi-level security responses such as rate limiting, isolation, and identity revocation within a sub-second time window. Simultaneously, it uses an exponential decay model to continuously and dynamically adjust session trust, triggering mandatory re-authentication when it falls below a threshold. Finally, it uses an HMAC-SHA256 hash chain to perform tamper-proof auditing of all security decisions, ensuring the non-repudiation of security decisions.

[0097] By applying the technical solution of this application, multi-dimensional comprehensive protection and sub-second automatic security response are achieved in the AI ​​Agent gateway scenario. This method unifies the modeling of five dimensions—network environment, device baseline, time window, user behavior, and cross-regional operations—into a dynamic risk scoring model. Attackers must bypass all dimensions simultaneously to launch an attack, significantly improving protection strength. By assigning each AI Agent instance an Ed25519 / RSA4096 cryptographic key pair and CA signature identity verification, it supports trust chain tracing and cascading revocation, effectively preventing identity forgery and token reuse. Through the SOAR automatic response engine based on an event-driven architecture, it automatically executes multi-level responses such as rate limiting, isolation, and identity revocation within sub-seconds after a security event occurs, matching the high-speed operation frequency of the AI ​​Agent. Through the dual-audit chain design of the HMAC-SHA256 hash chain, any tampering with historical records will cause the hash chain to break and be detected, ensuring the non-repudiation of security decisions. By continuously and dynamically adjusting session trust through an exponential decay model, the system continuously monitors abnormal behavior and changes in device security status, triggering forced re-authentication or session termination, overcoming the shortcomings of static trust in traditional solutions.

[0098] Although the invention has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, disclosure, and other materials. In this specification, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple components. A single processor or other unit can implement several functions listed in the specification. While certain measures are described in different embodiments, this does not mean that these measures cannot be combined to produce good results.

[0099] Although the invention has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made therein without departing from the spirit and scope of the invention. Accordingly, this specification and drawings are merely illustrative of the invention and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of the invention. Clearly, those skilled in the art can make various alterations and modifications to the invention without departing from its spirit and scope. Thus, if such modifications and modifications fall within the scope of the invention and its equivalents, the invention is also intended to include such modifications and modifications.

Claims

1. A multi-dimensional dynamic zero-trust security protection method for intelligent agent gateways, characterized in that, Includes the following steps: Access request steps: Receive access request from intelligent agent and establish a secure transmission channel; Integrated assessment steps: Based on the attribute access control framework, at least two attributes from network environment, device status, time constraints, behavioral patterns, and spatial location are dynamically integrated into a risk score and mapped into graded handling instructions; Identity verification step: For requests that pass the risk assessment, verify the identity certificate containing the hierarchical relationship identifier, which is used to support trust chain tracing and cascading operations; Access control steps: Issue short-term access credentials corresponding to the risk score and continuously reduce the session trust level. When the trust level falls below the trust level threshold, trigger a forced re-authentication. Threat response steps: Execute automatic responses based on rule matching for detected security events, and control the response rate through a combination of cooling mechanisms and window rate limiting. Audit evidence preservation steps: Record the assessment decision-making and threat response processes separately, maintain the records independently using a chained hash structure, and identify tampered records through continuous verification.

2. The method according to claim 1, characterized in that, The attributes in the fusion assessment step, from highest to lowest priority, are network environment, device status, time constraints, behavioral patterns, and spatial location. The graded handling instructions include low-risk release, medium-risk multi-factor authentication upgrade, and high-risk blocking.

3. The method according to claim 1, characterized in that, The identity verification step also includes an authorized operation list, a replay-protected random number, and hardware binding evidence. The cascading operation includes recursively revoking sub-identities and detecting trust chain loops through the visited set.

4. The method according to claim 1, characterized in that, The continuous reduction of the limit in the access control step adopts an exponential decay model. The exponential decay model is that the trust level decreases exponentially with the time interval. When the trust level falls below the trust level threshold, a forced re-authentication is performed, and the trust level is reset to the initial value.

5. The method according to claim 1, characterized in that, The security events in the threat response steps include agent-specific threat events, which include at least one of the following: prompt word injection, tool call tampering, one-time token replay, and multi-agent collaborative intrusion.

6. The method according to claim 1, characterized in that, The threat response steps buffer security events using a fixed-capacity double-ended queue and organize event references by source identifier and event type using a two-level index structure to achieve event association and location.

7. The method according to claim 1, characterized in that, The cooling mechanism in the threat response steps includes rule-level cooling and source event type-level cooling. The window rate limiting includes sliding window count rate limiting, which triggers an administrator alarm when the rate limiting threshold is reached.

8. The method according to claim 1, characterized in that, The chained hash structure in the audit evidence storage step includes an independently maintained decision evaluation chain and a threat response chain. Each record contains the hash value of the previous record, and the hash value of the current record is calculated based on the pre-configured audit key serialization entry.

9. The method according to claim 1, characterized in that, The audit and evidence preservation steps also include capacity management. When the chained hash structure exceeds the preset capacity, the chain head is updated and the most recent record is truncated. During verification, the chain is traversed starting from the updated chain head.

10. A multi-dimensional dynamic zero-trust security protection system for intelligent agent gateways, used to implement the method described in any one of claims 1 to 9, characterized in that, The system includes: The access module is configured to receive access requests from intelligent agents and establish a secure transmission channel. The fusion assessment module is configured to dynamically fuse at least two attributes from network environment, device status, time constraints, behavioral patterns, and spatial location into a risk score based on an attribute access control framework, and map it into graded handling instructions. The identity verification module is configured to verify the identity certificate containing a hierarchical relationship identifier for requests that have passed the risk assessment. The hierarchical relationship identifier is used to support trust chain tracing and cascading operations. The access control module is configured to issue short-term access credentials corresponding to risk scores and continuously reduce session trust levels. When the trust level falls below the threshold, it triggers forced re-authentication. The threat response module is configured to perform automatic rule-matching-based responses to detected security events and control the response rate through a combination of cooling mechanisms and window rate limiting. The audit and evidence storage module is configured to record the assessment decision-making and threat response processes separately, maintain the records independently using a chained hash structure, and identify tampered records through continuous verification.

Images