Agent runtime security detection system, method, device and medium

Abstract

The application discloses an agent runtime security detection system, method, device and medium, and is applied to the field of artificial intelligence technology. The application comprises the following steps: a trusted input layer performs identity verification on behavior events of an agent runtime; an anomaly detection layer performs trusted verification on the behavior events that pass the identity verification, converts the behavior events that pass the trusted verification into a security detection context, loads a multi-dimensional security detection baseline based on the security detection context, inputs the security detection context and the multi-dimensional security detection baseline into a multi-type anomaly detector to obtain an anomaly detection result, generates an anomaly event and an anomaly evidence package based on the anomaly detection result; and a shunt response layer determines a red line risk level based on the anomaly event and the anomaly evidence package, and generates a risk management suggestion based on the red line risk level. The application improves the input source data credibility, cross-layer over-authorization identification capability, anomaly evidence reuse capability and high-risk management timeliness, and enhances the security of the agent runtime.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a system, method, device and medium for detecting the operational safety of an intelligent agent. Background Technology

[0002] With the rapid development of artificial intelligence technology, agent systems have evolved from simple dialogue interactions into complex systems capable of invoking external tools, accessing business resources, executing payments, controlling data, and sending data, thus exhibiting external side effects. The security detection targets during the agent's runtime are no longer limited to model input and output text, but have expanded to include a runtime behavior chain comprised of identity, credentials, tool invocation, resource access, state changes, and cross-system collaboration.

[0003] Currently, security detection solutions for intelligent agents during operation mainly include the following categories: (a) Input Prompt Security Detection Scheme. This type of scheme mainly detects whether the input prompts contain jailbreak, injection, character tampering, sensitive words, or malicious commands, usually located before model invocation or after model output. The limitation of this type of scheme is that it only focuses on text content and cannot detect abnormalities at the behavioral level such as tool invocation and resource access.

[0004] (ii) Operation Log Auditing Solution. This type of solution collects agent request, response, tool call logs, or business transaction logs, and performs keyword matching, frequency statistics, failure rate analysis, or sensitive field detection afterward. The limitation of this type of solution is that ordinary logs are easily tampered with—when the agent is running, or when the tool gateway or business system is controlled by an attacker, tool call records may be forged, abnormal records deleted, or normal records rewritten, resulting in a lack of credible evidence for security detection and accountability.

[0005] (III) Access Control or Permission Verification Schemes. These schemes typically verify identity, tokens, or permissions at the resource entry point, determining whether to grant access based on a permission table. The limitation of these schemes is that detection based solely on single-point rules struggles to identify cross-layer unauthorized access—for example, a text request may appear normal, but its delegated token audience may differ from the target resource, or a low-level credential may be used to access a highly sensitive resource, or the call effect may suddenly change from reading to payment, control, or bulk sending. Observing any single field in isolation makes it difficult to promptly detect the true risk.

[0006] (iv) Credit scoring or risk profiling schemes. These schemes calculate an agent's credit score, risk level, or trustworthiness status based on historical events, health check results, violation records, and behavioral statistics. The limitation of these schemes is that high-risk events such as serious unauthorized access, sensitive data leakage, and irreversible major external side effects, if included in the weighted scoring along with ordinary minor anomalies, may be diluted and unable to trigger timely actions such as suspension, traffic limiting, mandatory re-examination, or manual review.

[0007] In summary, while existing security detection solutions for the runtime of intelligent agents have solved the problems of text detection, log auditing, access control, and comprehensive risk assessment, they still have problems such as unreliable source data leading to failure of tracing, fragmented single-point rules leading to missed detection of collaborative attacks, and weighted scoring passivation leading to delayed response to high-risk events, which seriously affect the security of the intelligent agent runtime. Summary of the Invention

[0008] This application provides a system, method, device, and medium for security detection during the runtime of intelligent agents, to solve the problem that existing security detection methods for the runtime of intelligent agents are ineffective. The technical solution provided by this application is as follows: On the one hand, this application provides a security detection system for the runtime of an intelligent agent, comprising: This application provides a security detection system for the runtime of an intelligent agent, including: The trusted input layer is used to verify the identity of behavioral events during the runtime of the target intelligent agent. The anomaly detection layer is used to perform trusted verification on behavioral events that have passed identity verification and convert these events into a security detection context. A multi-dimensional security detection baseline is obtained based on the security detection context. The security detection context and the multi-dimensional security detection baseline are then input into a multi-type anomaly detector to obtain anomaly detection results. Anomaly events and anomaly evidence packages are generated based on the anomaly detection results. The triage governance layer is used to determine the red line risk level based on abnormal events and abnormal evidence packages, and to generate corresponding risk governance recommendations based on the red line risk level.

[0009] The above solution addresses the problem that single-dimensional detection is insufficient to identify complex cross-layer risks by upgrading the detection target from ordinary logs to trusted behavioral flows with verified identities, and by combining multi-dimensional baselines with multi-type detectors for comprehensive judgment. At the same time, it supports subsequent precise governance by generating structured abnormal evidence packages.

[0010] Optionally, the trusted input layer includes: The hardware anchor identity and state maintenance module is used to maintain the hardware anchor identity and hardware anchor state of the target intelligent agent. The hardware anchor identity includes the intelligent agent identity number generated during registration, the registered anchor type, the hardware anchor fingerprint and the issuance key, as well as the parent-child identity relationship generated during operation. The hardware anchor state includes the state bits of the target intelligent agent and the anchor state. The Trusted Behavior Flow Access Module is used to monitor behavioral events during the runtime of the target intelligent agent in real time. It calls the hardware anchor identity and hardware anchor state of the target intelligent agent maintained by the Hardware Anchor Identity and State Maintenance Module to perform identity verification on the behavioral events during the runtime of the target intelligent agent.

[0011] The above solution ensures the physical credibility of the source of behavioral events by binding and maintaining the identity and state of the hardware anchor, thus preventing identity impersonation or forged event injection.

[0012] Optionally, the anomaly detection layer includes: The event verification and normalization module is used to perform multi-dimensional trusted anchor joint verification on behavioral events that have passed identity verification, and to extract multi-dimensional context from behavioral events that have passed multi-dimensional trusted anchor joint verification to form a security detection context. Among them, multi-dimensional trusted anchor joint verification includes identity authenticity verification, content integrity verification, temporal continuity verification, and source legality verification; multi-dimensional context includes identity context, resource context, tool effect context, sensitive data context, time window context, and group context. The multi-baseline management module is used to extract multi-dimensional composite localization features of the target agent from the security detection context. Using the multi-dimensional composite localization features as the query key, it reads the identity anchor baseline, access permission baseline, and behavior statistics baseline from the pre-stored multi-baseline database as multi-dimensional security detection baselines. Among them, the identity anchor baseline includes the pre-maintained hardware anchor identity and hardware anchor state of the target agent; the access permission baseline includes a pre-configured set of access control rules for the target resources; and the behavior statistics baseline includes benchmark values ​​of various behavior statistics indicators obtained by periodically calculating offline values ​​of historical behavior event streams that have passed trusted verification. The anomaly detection matrix module is used to input the security detection context and multi-dimensional security detection baseline into multiple types of anomaly detectors to obtain anomaly detection results. Among them, the multiple types of anomaly detectors include anchor consistency detectors, admission boundary detectors, high-impact tool sequence detectors, injection and bypass detectors, data leakage detectors, and swarm propagation detectors. The abnormal evidence package generation module is used to generate abnormal events and abnormal evidence packages based on the abnormality detection results.

[0013] The above scheme achieves comprehensive coverage of identity, permissions, tool sequences, injection attacks, data leakage, and group anomalies through a matrix combination of three baselines and six types of detectors, thereby improving the accuracy of identifying cross-layer unauthorized access risks.

[0014] Optionally, the abnormal evidence package generation module is used to extract abnormal detection fact information based on the abnormal detection results; generate a context hash value based on the abnormal detection fact information and the associated event context of the behavioral event; perform data anonymization processing on the original business payload of the behavioral event; generate abnormal events and abnormal evidence packages based on the abnormal detection fact information, the context hash value, and the original business payload after data anonymization processing; perform cryptographic hash operation on the abnormal evidence package to obtain an evidence integrity digest, and write the evidence integrity digest into the abnormal evidence package.

[0015] The above solution, through a dual verification mechanism of context hashing and evidence integrity summary, combined with sensitive data anonymization, ensures the legal validity and traceability of evidence while also protecting business privacy.

[0016] Optionally, the traffic diversion governance layer includes: The Red Line Triage and Governance Recommendation module is used to determine the red line risk level of abnormal events and abnormal evidence packages by using pre-configured red line triage rules. If the red line risk level is ordinary abnormality, governance recommendations such as monitoring, downsampling observation, or reminders are generated. If the red line risk level is soft red line, governance recommendations such as suspending high-risk operations and entering the manual review or multi-party authorized review queue are generated. If the red line risk level is hard red line, governance recommendations such as suspension, flow restriction, mandatory re-examination, or regulatory reporting are generated.

[0017] The above solution separates serious risks from ordinary scores and establishes a three-level triage mechanism, which avoids the dilution of major security incidents by the average of normal behavior and ensures timely response and handling in high-risk scenarios.

[0018] Optionally, the traffic diversion governance layer may also include: The credit profile feedback module is used to trigger a recalculation of the credit profile of the target intelligent agent based on abnormal events and red line risk levels. Among them, when recalculating the credit profile, the lower the red line risk level, the lower the penalty weight of the abnormal event.

[0019] The above scheme realizes the dynamic linkage between anomaly detection and the credit system, enabling credit evaluation to reflect the security status of the intelligent agent during its operation in real time.

[0020] Optionally, the traffic diversion governance layer may also include: The review and rule calibration module receives review conclusions from manual review or multi-party authorized review queues regarding the risk levels of abnormal events and red lines; records the reasons for false alarms and scenarios of missed alarms in the review conclusions; adjusts the rule parameters or configuration thresholds in the current version's detection rules based on the reasons for false alarms and scenarios of missed alarms to obtain the new version's detection rules; writes the new version's detection rules into the gray-scale release record and gradually expands the scope of effectiveness of the new version's detection rules according to the preset gray-scale ratio; and retains the detection rules of historical versions so as to perform retrospective interpretation based on the historical version's detection rules when historical abnormal events occurred.

[0021] The above scheme supports the continuous evolution of detection strategies and the interpretability of historical results through closed-loop feedback and version management mechanisms, thus adapting to the dynamic changes in the security confrontation of intelligent agents.

[0022] On the other hand, this application provides a method for security detection during the runtime of an intelligent agent, including: Identity verification is performed on behavioral events of the target intelligent agent during its runtime. Perform trusted verification on behavior events that pass identity verification, and convert the trusted verification-passed behavior events into a security detection context; Obtain a multi-dimensional security detection baseline based on the security detection context; The security detection context and multi-dimensional security detection baseline are input into the multi-type anomaly detector to obtain anomaly detection results; Generate abnormal events and abnormal evidence packages based on the abnormality detection results; The red line risk level is determined based on abnormal events and abnormal evidence packages, and corresponding risk governance recommendations are generated based on the red line risk level.

[0023] On the other hand, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-mentioned intelligent agent runtime security detection method.

[0024] On the other hand, this application also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, implement the above-described intelligent agent runtime security detection method.

[0025] The beneficial effects of this application are as follows: This application constructs an immutable, trusted behavioral flow input foundation by introducing hardware-based identity verification and multi-dimensional trusted anchor joint verification before anomaly detection, fundamentally solving the problem of detection failure caused by the easy forgery of ordinary logs. Based on this, a multi-dimensional security detection baseline composed of identity anchor baseline, access control baseline, and behavioral statistics baseline is used, along with an anomaly detection matrix covering anchor consistency, access boundaries, tool sequences, injection bypass, data leakage, and group propagation, to achieve accurate identification of cross-layer privilege escalation, complex attack chains, and group risks.

[0026] Furthermore, by generating structured anomaly evidence packages containing context hashes, desensitized payloads, and integrity summaries, and combining this with a three-tiered triage and governance mechanism for ordinary anomalies, soft red lines, and hard red lines, the dilution of serious security incidents by the average of normal behavior is avoided, while ensuring the accuracy and traceability of handling decisions. Simultaneously, through credit profile feedback and rule version calibration mechanisms, the continuous evolution of security detection capabilities and the interpretability of historical results are achieved, effectively improving the operational security and governance efficiency of the intelligent agent system in open environments.

[0027] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the composition structure of the intelligent agent runtime security detection system in this application embodiment; Figure 2 This is a schematic diagram of the three security detection baselines and the six anomaly detector matrix in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the linkage between the red line diversion and governance of abnormal events in the embodiments of this application; Figure 4 This is a schematic diagram outlining the process of the intelligent agent runtime security detection method in the embodiments of this application; Figure 5 This is a schematic diagram of the hardware structure of the electronic device in the embodiments of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and beneficial effects of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] Example 1 like Figure 1 As shown, this embodiment provides a security detection system for the runtime of intelligent agents. The system is logically divided into three layers: a trusted input layer, an anomaly detection layer, and a traffic management layer. These three layers interact through standardized data objects, forming a closed-loop defense system from event access to risk handling.

[0031] The trusted input layer is used to verify the identity of behavioral events during the runtime of the target intelligent agent.

[0032] Specifically, the trusted input layer, acting as a pre-filter barrier in the entire security detection system, plays a crucial role in ensuring that the data sources entering subsequent analysis links are genuine and tamper-proof. In the agent's runtime environment, behavioral events may originate from various channels, including the agent's runtime environment, tool gateways, resource verification parties, or security detection centers. If these raw events are used directly for analysis without verification, they are highly susceptible to attackers forging logs or replay attacks. Therefore, the trusted input layer does not directly focus on the correctness of business logic but rather on verifying the physical credibility and integrity of the event's source. For example, this layer can verify whether an event carries a valid hardware anchor signature, server-side receipt, and hash chain continuity to confirm that the behavioral event was indeed generated by a registered target agent in a legitimate state. Only behavioral events that pass this layer's identity verification are allowed to proceed to the next level; conversely, events that fail verification are marked as untrusted input and isolated, thus preventing invalid or malicious data from consuming subsequent detection resources and contaminating the detection model.

[0033] The anomaly detection layer is used to perform trusted verification on behavioral events that have passed identity verification and convert them into a security detection context; obtain a multi-dimensional security detection baseline based on the security detection context; input the security detection context and the multi-dimensional security detection baseline into a multi-type anomaly detector to obtain anomaly detection results; and generate anomaly events and anomaly evidence packages based on the anomaly detection results.

[0034] Specifically, the anomaly detection layer is the core analysis engine of this system, and its processing flow includes four key data transformation stages. First, although the event has passed identity verification, deeper trust verification (such as content integrity and temporal continuity) is still required to exclude anomalies where the identity is legitimate but the content has been tampered with by a man-in-the-middle or the timing is disordered. Second, the system converts the verified raw behavioral events into a structured security detection context. This process essentially maps heterogeneous log fields to unified semantic features, such as converting specific API call parameters into "tool effect context" or "sensitive data context," enabling subsequent detectors to analyze based on a unified dimension. Third, based on the location features (such as identity ID, resource identifier, etc.) in the security detection context, the system dynamically loads corresponding multi-dimensional security detection baselines. These baselines cover identity anchor states, access control rules, and historical behavioral statistics, providing a dynamic reference system for anomaly determination. Finally, the system simultaneously inputs the context and baselines into multiple types of anomaly detectors, using matrix cross-analysis to identify complex risks such as cross-layer privilege escalation, injection attacks, or data leaks, and encapsulates the detection results into anomaly events and anomaly evidence packages. The abnormal evidence package not only includes risk labels, but also integrates complete evidence information such as trigger signals, context hashes, related event references, and baseline versions, enabling it to independently support audit review and judicial tracing, and solving the problems of fragmented and unusable traditional alarm information.

[0035] The triage governance layer is used to determine the red line risk level based on abnormal events and abnormal evidence packages, and to generate corresponding risk governance recommendations based on the red line risk level.

[0036] Specifically, the traffic diversion governance layer is responsible for making decisions that translate technical detection results into business governance actions. This layer does not treat all anomalies equally; instead, it categorizes abnormal events into different risk levels based on pre-configured diversion rules, such as ordinary anomalies, soft red lines, and hard red lines. This tiered mechanism is designed to prevent serious security risks from being diluted by the average of numerous minor anomalies. For different risk levels, the system generates differentiated risk governance recommendations: for ordinary anomalies, non-intrusive measures such as monitoring or downsampling observation are recommended; for soft red lines, high-risk operations are suspended and placed in a manual or multi-party authorized review queue to balance security and business continuity; for hard red lines, strong control measures such as immediate suspension, traffic limiting, or mandatory re-inspection are recommended. It should be noted that the traffic management layer in this embodiment only outputs management suggestions and does not directly execute irreversible operations such as identity revocation or data deletion. The final decision-making authority is reserved in an authorized external management module or manual approval process. This design ensures a clear boundary of authority and responsibility between the security detection system and the business execution system, and prevents serious business interruption incidents caused by false alarms.

[0037] This embodiment constructs an intelligent agent security detection system through the collaborative work of the three-layer architecture described above. This system possesses both a foundation of underlying hardware trust and flexible governance capabilities at the upper layers. The trusted input layer ensures the authenticity of the detection data, the anomaly detection layer enables accurate identification and evidence consolidation of cross-dimensional risks, and the diversion and governance layer ensures the timeliness and appropriateness of risk handling. Together, these three elements support the technical foundation for the secure operation of intelligent agents in an open environment.

[0038] Example 2 As an alternative implementation method, such as Figure 1 As shown, the trusted input layer includes a hardware anchor identity and state maintenance module 10 and a trusted behavior flow access module 20, wherein: The hardware anchor identity and state maintenance module 10 is used to maintain the hardware anchor identity and hardware anchor state of the target intelligent agent. The hardware anchor identity includes the intelligent agent identity number generated during the registration of the target intelligent agent, the registered anchor type, the hardware anchor fingerprint and the issuance key, as well as the parent-child identity relationship generated during operation. The hardware anchor state includes the state bits of the target intelligent agent and the anchor state.

[0039] Specifically, this embodiment delves into the functional constraint of "trustworthiness" through concrete hardware binding and state machine mechanisms to prevent it from being interpreted as a mere software-level verification. The hardware anchor identity is not merely a logical string identifier, but a root of trust tightly bound to the physical hardware environment in which the target agent operates. For example, the hardware anchor fingerprint can be a unique feature value generated based on a physically unclonable function of a security chip, trusted execution environment, or hardware security module. This ensures that even if an attacker obtains the agent's identity number and signing key, they cannot forge a legitimate hardware anchor identity if they cannot replicate the underlying hardware characteristics. The registration anchor type identifies the type of hardware carrier upon which the identity relies, such as an onboard secure element, an external USB key, or a cloud-hosted HSM, so that the system can select a matching verification algorithm during subsequent verification. The signing key is a private key written into the hardware security zone by a trusted certification authority during the registration phase. It is used to digitally sign behavioral events generated during runtime, thereby ensuring the authenticity and non-repudiation of the event source. In addition, the parent-child relationship records the trust transfer link between the main intelligent agent and its derived child intelligent agents, enabling the system to trace the authorization source of the child intelligent agent's behavior and prevent unauthorized derived intelligent agents from impersonating the parent's permissions.

[0040] Regarding the hardware anchor state, it contains dynamic information in two dimensions: status bits and anchor state, reflecting the real-time security status of the target agent during runtime. Status bits typically indicate the agent's current lifecycle stage, such as activated, frozen, deactivated, or under maintenance; while the anchor state specifically characterizes the validity of the hardware root of trust, such as valid, expired, revoked, or suspected of being damaged. Unlike static registration information, the hardware anchor state is dynamically updated as the operating environment changes. For example, when the system detects abnormal tampering with the hardware environment of a target agent, or receives an emergency freeze command from the administrator, the hardware anchor identity and state maintenance module 10 immediately changes the agent's anchor state to "invalid" or sets its status to "frozen." This dynamic maintenance mechanism ensures that even if a previously legally registered agent's operating environment is no longer trustworthy or its permissions are revoked, the system can detect and respond within milliseconds, avoiding the security window caused by excessively long certificate validity periods or delayed blacklist updates in traditional solutions.

[0041] The trusted behavior flow access module 20 is used to monitor the behavior events of the target intelligent agent in real time, call the hardware anchor identity and hardware anchor state of the target intelligent agent maintained by the hardware anchor identity and state maintenance module 10, and perform identity verification on the behavior events of the target intelligent agent in the runtime.

[0042] In the specific execution process, whenever the trusted behavior flow access module 20 receives a behavior event, it first extracts the declared agent identity number and the attached digital signature from the metadata in the event header. Subsequently, the trusted behavior flow access module 20 sends a query request to the hardware anchor identity and state maintenance module 10 to obtain the latest hardware anchor state and public key information corresponding to the identity number. The verification logic includes dual verification: the first is cryptographic verification, which uses the obtained public key to verify the signature and confirm that the event was indeed generated by the hardware entity holding the corresponding issuing key and that the content has not been tampered with; the second is state compliance verification, which checks whether the current state bit and anchor state are within the permission set that allows the execution of this type of operation. Only when both verifications pass will the behavior event be determined as having passed identity verification and then forwarded to the subsequent anomaly detection layer for processing.

[0043] If any verification step fails, the trusted behavior flow access module 20 will immediately terminate the subsequent flow of the event and mark it as untrusted input for isolation. For example, if signature verification fails, it may mean that the event was forged by an attacker or tampered with during transmission; if the anchor status shows "revoked" or "expired," it indicates that the agent's trust credentials have expired; if the status bit is "frozen," it means that the agent is under security investigation or control. By intercepting these failed verification events before they enter the core detection engine, this embodiment not only effectively prevents malicious forged data or invalid dirty data from polluting the subsequent anomaly detection matrix and avoids an increase in the false alarm rate, but also significantly reduces the computational overhead of the system's deep analysis of massive logs, ensuring that the entire security detection system can concentrate resources on processing behavior flows with a truly trustworthy foundation, thereby improving the overall efficiency and accuracy of runtime security detection. It should be understood that although this embodiment describes a specific verification order and field composition, in other embodiments, the hardware anchor identity may also include other features that can characterize the uniqueness of the hardware, and the verification logic can also be adaptively adjusted according to the business security level, as long as the real-time identity verification function based on the hardware trust root can be achieved.

[0044] Example 3 As an alternative implementation method, such as Figure 1 As shown, the anomaly detection layer includes an event verification and normalization module 30, a multi-baseline management module 40, and an anomaly detection matrix module 50, which constitute the core analysis engine of the intelligent agent runtime security detection system. Through a standardized data processing pipeline, it transforms raw behavioral events into structured risk intelligence that can be understood by machines; where: The event verification and normalization module 30 is used to perform multi-dimensional trusted anchor joint verification on the behavior events that have passed identity verification, and to extract multi-dimensional context from the behavior events that have passed the multi-dimensional trusted anchor joint verification to form a security detection context.

[0045] Although the behavioral event has passed the initial identity verification, deeper issues such as content tampering, time sequence errors, or illegitimate sources may still exist, necessitating more granular verification. This requires multi-dimensional trusted anchor joint verification, which includes identity authenticity verification, content integrity verification, time sequence continuity verification, and source legitimacy verification. Identity authenticity verification focuses on verifying whether the digital signature carried by the event matches the declared identity; content integrity verification confirms that the event content has not been tampered with during transmission by comparing the payload digest and hash value; time sequence continuity verification checks whether the event's timestamp is within a reasonable window and the preceding hash chain is continuous, preventing replay attacks or log insertion; and source legitimacy verification verifies whether the event sender has the authority to write such events. Only when all four verifications pass will the event be considered a trusted sample and enter the subsequent analysis process; otherwise, it will be marked as abnormal input and isolated, thus ensuring the purity of the detection data.

[0046] For events that pass verification, the event verification and normalization module 30 further performs multi-dimensional context extraction, converting them into a unified security detection context. This multi-dimensional context includes identity context, resource context, tool effect context, sensitive data context, time window context, and group context. Essentially, this process maps heterogeneous raw log fields into standardized semantic feature vectors. For example, the identity context includes information such as identity number, parent identity, child identity, hardware anchor identifier, and status bits, used to construct a trust profile of the agent; the resource context includes resource level, type, permitted credentials, and write-back obligations, used to define the sensitivity of the operation object; the tool effect context abstracts specific API call parameters into semantic tags such as read, write, send, pay, and control, facilitating the identification of high-risk operations; the sensitive data context records field categories, destination addresses, and digest hashes, supporting data leakage detection; the time window context provides short-term, medium-term, and long-term statistical keys, supporting frequency and trend analysis; and the group context associates features with the same registrant or hardware chain, serving the identification of collaborative attacks. Through this normalization process, the system can shield the differences in underlying log formats, providing a unified and rich analytical dimension for upper-layer detectors.

[0047] The multi-baseline management module 40 is used to extract multi-dimensional composite localization features of the target intelligent agent from the security detection context; using the multi-dimensional composite localization features as the query key, it reads the identity anchor baseline, permission access baseline and behavior statistics baseline from the pre-stored multi-baseline database as multi-dimensional security detection baselines.

[0048] The "multi-dimensional composite positioning feature" here refers to a unique index key composed of the target intelligent agent's identity ID, the currently accessed resource identifier, the hardware anchor chain, the registrant, and the scene tag. Its function is similar to a primary key in a database query, accurately locating the normal behavioral baseline corresponding to the current behavioral event. The three baselines represent different dimensions of "normal" standards: the identity anchor baseline includes the pre-maintained hardware anchor identity and hardware anchor state of the target intelligent agent, with data sourced from the hardware anchor identity and state maintenance module 10, used to determine whether the current behavior is still backed by trusted hardware at the time of registration; the access control baseline includes a pre-configured set of access control rules for the target resource, such as resource level, allowed credential type, authorization scope, and validity period, used to verify the compliance of operations; and the behavioral statistics baseline includes benchmark values ​​of various behavioral statistical indicators obtained through periodic offline calculation of historical behavioral event streams that have passed trusted verification, such as tool call frequency, effect type distribution, average cost consumption, and abnormal rejection rate, used to identify abnormal fluctuations deviating from historical norms. By dynamically loading these three types of baselines, the system can construct a dynamic reference system that adapts to the current scenario for each detection, rather than relying on a static global threshold, thereby significantly improving the accuracy of identifying abnormal behavior in complex business environments.

[0049] It should be noted that when a dedicated multidimensional security detection baseline cannot be read from the pre-stored multi-baseline database using multidimensional composite positioning features as the query key, the multi-baseline management module 40 can automatically downgrade and load the group multidimensional security detection baseline (such as "average frequency of all agents under the same registration party" or "overall performance of all instances under the same model version") until the target agent has accumulated enough of its own context data, and then switch back to the dedicated multidimensional security detection baseline.

[0050] The anomaly detection matrix module 50 is used to input the security detection context and multi-dimensional security detection baseline into multi-type anomaly detectors to obtain anomaly detection results. For example... Figure 2 As shown, the anomaly detection matrix module 50 adopts a matrix architecture, using a multi-dimensional security detection baseline as the horizontal input dimension and multiple types of anomaly detectors as vertical analysis units to form a three-dimensional defense network. These multiple types of anomaly detectors include anchor consistency detectors, access boundary detectors, high-impact tool sequence detectors, injection and bypass detectors, data leakage detectors, and swarm propagation detectors. Each detector independently determines its risk based on the cross-information of context and baseline, and outputs a risk signal.

[0051] Specifically, the anchor consistency detector reads the identity number, signing key, hardware anchor reference, and status bits from the current behavioral event and compares them with the identity anchor baseline. When it detects an inconsistency between the behavioral signature anchor and the registration anchor, an anchor status of paused or revoked, mutually exclusive anchors for the same identity appearing within a short period, or a sub-identity's behavior being untraceable to its parent identity's creation event, it outputs a risk of identity impersonation or anchor anomaly. For example, if an agent uses security chip A as its hardware anchor during registration, but the behavioral event generated during runtime is signed by a software simulator, the detector will immediately trigger an alarm.

[0052] The access boundary detector reads the resource level, credential type, token audience, authorization scope, and validity period, and matches them against the access control baseline. When it detects that a high-sensitivity resource has received a low-level credential, the resource audience and token audience are inconsistent, a delegated token has exceeded its scope, an expired identity continues to access the resource, or the resource entry point has failed to fulfill its write-back obligation, it outputs a risk of unauthorized access or resource access violation. For example, a token granted only "read-only" permissions attempting to call a "write" interface, even if its identity is legitimate, will be blocked by this detector.

[0053] The high-impact tool sequence detector performs sequence analysis on tool calls that have side effects, such as payment, control, sending, and writing. When the same identity exhibits a combination of patterns within a short window, such as high-frequency payments, batch sending, continuous control, reading sensitive data before sending to an external address, or bypassing rejection before switching tools, it outputs the risk of tool abuse or irreversible side effects. For example, if an agent calls a transfer tool five times in one minute with increasing amounts, this clearly deviates from the normal business interaction rhythm and is a typical tool abuse pattern.

[0054] The injection and bypass detector uses input digests, policy hit digests, rejection results, tool call changes, and session context to assess risk. When a session triggers a highly sensitive tool call immediately after injection characteristics appear, a request that the model should have rejected is executed indirectly through a toolchain, or multiple sub-identities collaborate to bypass a single identity restriction, the detector outputs a warning of injection, model bypass, or policy evasion risk. For example, if user input contains obvious SQL injection statements, and the model does not directly execute the SQL but subsequently calls a database query tool with concatenated parameters, this "borrowed weapon" behavior will be identified by the detector.

[0055] The data leakage detector uses sensitive field categories, field quantity, digest hash, destination address, traffic changes, and result status for judgment. It outputs a data leakage risk when sensitive field categories do not match resource authorization, a large amount of data with similar digests is sent out in a short period, the destination address is not within the historically trusted range, or multiple identities under the same hardware chain exhibit similar outbound behavior. For example, if an agent suddenly sends a batch of data packets containing the category of "ID card number" to an external IP address it has never accessed before, even if the single transmission volume does not exceed the limit, it will be flagged due to the abnormal destination and sensitive content.

[0056] The group propagation detector aggregates anomalous events from contract registrants, those on the same hardware chain, those with the same model version, those using the same tool entry point, and those using the same resource entry point. When multiple identities under a single hardware chain or registrant simultaneously exhibit anchor anomalies, access violations, data leaks, or tool abuse, it outputs a batch of anomalous risks and attaches a risk propagation flag to the anomalous evidence package. For example, if ten agents belonging to the same cloud tenant simultaneously attempt to access unauthorized highly sensitive resources, this is highly likely an organized automated attack rather than an isolated misoperation.

[0057] Through the parallel operation and cross-validation of the above six types of detectors, the anomaly detection matrix module 50 can not only identify single-point violations, but also capture complex attack chains that cross levels, time sequences, and entities, effectively solving the problem that traditional single-dimensional detection is unable to cope with advanced persistent threats. It should be understood that although this embodiment lists six specific detector types, in other embodiments, other types of detectors, such as model illusion detectors and compliance detectors, can be added or replaced according to business needs. As long as they follow the matrix-style judgment logic of "context + baseline," they should all be covered within the scope of protection of this application.

[0058] Example 4 As an optional implementation, the abnormal evidence package generation module 60 is used to extract abnormal detection fact information based on the abnormal detection results; generate a context hash value based on the abnormal detection fact information and the associated event context of the behavioral event; perform data anonymization processing on the original business payload of the behavioral event; generate abnormal events and abnormal evidence packages based on the abnormal detection fact information, the context hash value, and the original business payload after data anonymization processing; perform cryptographic hash operation on the abnormal evidence package to obtain an evidence integrity digest, and write the evidence integrity digest into the abnormal evidence package.

[0059] This embodiment decouples the evidence generation logic from the anomaly detection matrix, forming an independent and standardized data processing pipeline. This aims to address the problems of fragmented traditional security alert information, lack of legal validity, and high risk of privacy breaches. Through a combination of cryptographic techniques and structured encapsulation, the generated evidence package meets the stringent requirements of judicial evidence collection and compliance auditing, while also ensuring secure transfer within the production environment.

[0060] Specifically, the internal processing flow of the abnormal evidence package generation module 60 can be divided into the following five key steps: Step S61 involves extracting anomaly detection factual information based on the anomaly detection results. This step essentially standardizes, cleans, and enhances the raw signal output from the detection layer. The extracted factual information includes not only direct judgments such as risk type, trigger signal list, severity level, and confidence level, but also must be associated with the current detection rule number and version number, related event references, and baseline references. For example, when an "unauthorized payment" risk is detected, the factual information not only records the risk label but also precisely records the rule version number that triggered the judgment (v2.3.1) and the access control baseline ID upon which it was based. This design ensures that subsequent reviewers can accurately trace back to the specific rule environment at the time of the detection, avoiding unexplainable issues caused by rule iterations.

[0061] Step S62: Generate a context hash value based on the anomaly detection factual information and the context of related events of the behavioral event. To prevent attackers from tampering with or deleting individual anomaly events afterward to cover up the attack chain, this embodiment introduces a hash binding mechanism based on event chains. Specifically, the event identifier, timestamp, and key digest of the target behavioral event that triggered the current anomaly are concatenated with the corresponding information of N related events preceding the target behavioral event in the trusted event chain to form a context string. A cryptographic hash operation (such as SHA-256 or the national cryptographic SM3 algorithm) is then performed on this context string to generate a context hash value. For example, if N is set to 5, the hash value of the current event actually covers the combined characteristics of itself and the previous 5 events. This means that any tampering with historical events will cause the context hash value verification of all subsequent events to fail, thereby ensuring the continuity and non-repudiation of the anomaly evidence in the time dimension.

[0062] Step S63: Sensitive data desensitization is performed based on the anomaly detection factual information and the original business payload of the target behavioral event. In security detection during the intelligent agent's runtime, behavioral events often contain user privacy or trade secrets; directly writing plaintext into the evidence package would pose serious compliance risks. Therefore, this embodiment strictly distinguishes between the event's control header and business payload, processing only the sensitive fields within the business payload. Specific desensitization strategies include several lower-level implementation methods: first, category labeling, which retains only the semantic type of the field (such as "ID number" or "bank card number") while erasing the specific numerical value; second, desensitization digest, which performs a one-way hash operation on sensitive content, retaining comparison capability but losing reconstruction capability; and third, storage reference, which only saves the security token or index ID pointing to the encrypted storage service in the evidence package, while the original data is stored in an independent encrypted area with strict access control. For example, for a behavioral event containing a user's mobile phone number, the evidence package may only record "phone_hash:a1b2c3..." or "ref_id: enc-store-9981", without saving the plaintext "138xxxx0000". This tiered anonymization mechanism ensures the traceability of evidence while minimizing the risk of privacy leaks.

[0063] Step S64: Based on the data generated in the preceding steps, a dual output structure of abnormal events and abnormal evidence packages is generated. To balance real-time processing efficiency with the needs of in-depth auditing, this embodiment adopts a dual-track output system that separates light and heavy data. Abnormal events, as lightweight fact records, only contain core index fields such as abnormality number, identification, detection time, risk type, severity level, and context hash value, and are written into the trusted event chain for rapid consumption by the downstream triage and governance layer. Abnormal evidence packages, on the other hand, serve as heavyweight dossier records, fully encapsulating all information such as abnormality type, detection rule details, trigger signal list, context hash, related event references, baseline references, suggested actions, de-identified business payload, and detection time, and are stored in a dedicated evidence repository. This design avoids performance bottlenecks caused by transmitting large data packets in the real-time message queue, while also ensuring that complete evidence materials can be obtained losslessly through the indexes in the abnormal events when in-depth investigation is required.

[0064] Step S65: Generate an evidence integrity digest based on the complete content of the anomalous evidence package. After the evidence package is assembled, the system performs a cryptographic hash operation on its complete payload content again to generate an evidence integrity digest, and writes this digest into the last field of the anomalous evidence package. This digest is equivalent to a "digital seal" for the evidence package. Any modification to any field within the evidence package (including desensitized data, rule version, context hash, etc.) will result in a discrepancy between the recalculated digest and the stored digest. In subsequent judicial evidence collection or internal auditing, the verifying party only needs to recalculate the hash once to confirm whether the evidence has remained intact and tamper-free since its generation. It should be understood that although this embodiment describes a specific five-step processing flow and specific desensitization and hashing strategies, in other embodiments, the desensitization granularity can be dynamically adjusted according to the level of business sensitivity, or more advanced privacy computing technologies such as zero-knowledge proofs can be used to replace traditional desensitization. As long as the dual goals of credible evidence consolidation and privacy protection can be achieved, they should be covered within the scope of protection of this application.

[0065] Example 5 As an alternative implementation method, such as Figure 1 As shown, the diversion and management layer includes the red-line diversion and management suggestion module 70; The Red Line Triage and Governance Recommendation Module 70 is used to determine the red line risk level of abnormal events and abnormal evidence packages by adopting pre-configured red line triage rules. If the red line risk level is ordinary abnormality, governance recommendations such as monitoring, downsampling observation, or reminders are generated. If the red line risk level is soft red line, governance recommendations such as suspending high-risk operations and entering the manual review or multi-party authorized review queue are generated. If the red line risk level is hard red line, governance recommendations such as suspension, flow restriction, mandatory re-examination, or regulatory reporting are generated.

[0066] Specifically, such as Figure 3 As shown, the red-line triage and governance suggestion module 70 serves as a decision-making hub connecting technical detection and business governance. Its core mechanism lies in mapping abstract risk signals into specific handling strategies through pre-configured red-line triage rules. These pre-configured red-line triage rules are not hard-coded logic embedded in the code, but rather dynamically loadable rule sets stored in the form of policy description languages ​​or structured configuration tables. This allows security operations personnel to flexibly adjust the trigger thresholds and judgment conditions of red lines at each level according to changes in business scenarios, without recompiling and deploying the system. This design enables security detection capabilities to quickly adapt to the iteration of intelligent agent application scenarios and the emergence of new attack methods.

[0067] For common anomalies, typical scenarios include slight deviations in tool call frequency, single access denials to low-sensitivity resources, or explainable temporary network timeout failures. While these anomalies deviate from the baseline, they do not constitute a substantial security threat or may be due to normal business fluctuations. Therefore, the governance recommendations generated by the redline traffic diversion and governance suggestion module 70 are primarily non-intrusive monitoring, downsampling observation, or alerts. For example, when it is detected that an agent's API call count exceeds the baseline by 10% within a unit of time but does not reach the rate limiting threshold, the system only records the event and increases the log sampling rate for subsequent similar events without interrupting business requests. This approach avoids false alarms caused by oversensitivity that could disrupt business continuity, while also maintaining an observation window to promptly escalate the response level if the trend worsens.

[0068] For soft red lines, the judgment criteria typically cover situations where evidence is questionable, judgment requires consideration of specific business context, or multiple failed cross-verification attempts have not yet resulted in irreversible consequences. For example, an agent might call multiple query tools in batches within a short period. Although each individual query is compliant, the combined pattern suggests data scraping. However, this period coincides with a major business promotion, potentially creating a legitimate need for batch data synchronization. In this case, the red line diversion and governance suggestion module 70 will not directly block the business but will generate a governance suggestion to suspend the high-risk operation and enter a manual review or multi-party authorization review queue. This suspension is a temporary intermediate state designed to buy time for manual intervention and prevent the risk from escalating during the cooling-off period. The multi-party authorization review queue is designed to address misjudgments caused by excessive privileges or cognitive blind spots of a single administrator. It requires confirmation from at least two authorized persons with different roles (such as a security auditor and a business manager) before the suspension can be lifted or the action taken. It is important to note that when an anomaly is marked with a soft red line, it means the system has detected significant suspicion but lacks conclusive evidence. In this case, the authorization is not essentially granting detection authority, but rather decision-making authority, including the right to informed review of the anomaly's authenticity, the right to execute temporary intervention measures, and the right to overturn or downgrade the alarm. This mechanism, while ensuring a safety baseline, respects the complexity of business operations to the greatest extent possible, avoiding arbitrary handling of ambiguous areas by automated systems.

[0069] The "hard red lines" refer to clearly defined high-risk situations such as serious unauthorized actions, unauthorized payments, leakage of sensitive data, irreversible and significant external side effects, or batch anomalies within the same registration party and hardware chain. Once a hard red line is triggered, the red line diversion and governance suggestion module 70 will immediately generate governance suggestions such as suspension, rate limiting, mandatory re-examination, or regulatory reporting. For example, when an agent is detected attempting to transfer funds to an unauthorized external account, the system will immediately suggest suspending all financial tool access permissions for that agent and automatically generate a draft report that meets regulatory format requirements. This automated, robust control ensures that when facing high-certainty risks, the system can stop losses within milliseconds, preventing further damage due to delays caused by manual responses.

[0070] It should be understood that although the red-line diversion and governance suggestion module 70 can generate the aforementioned governance suggestions, in this embodiment, the red-line diversion and governance suggestion module 70 strictly adheres to the security boundary principle of separating detection and execution. For irreversible state change operations such as identity revocation, data deletion, and tombstone marking, the red-line diversion and governance suggestion module 70 only outputs an abnormal evidence package containing a complete evidence chain and suggested actions. The final execution instruction must be issued by an independently authorized external governance module or lifecycle management module after verifying the legality of the suggestion. This design prevents the security detection module itself from becoming a source of disruption to business due to logical defects or being compromised, ensuring that even in extreme abnormal situations, the system's handling behavior remains within a controllable and traceable framework of rights and responsibilities. Through the synergy of the above three-level diversion mechanism and security boundary, this embodiment achieves precise governance across the entire spectrum from minor disturbances to severe attacks, avoiding the dilution of serious risks by massive noise and preventing excessive intervention in normal business operations, significantly improving the efficiency and robustness of security governance during the intelligent agent's runtime.

[0071] Example 6 As an alternative implementation method, such as Figure 1 As shown, the triage governance layer also includes a credit profile feedback module 80; The credit profile feedback module 80 is used to trigger a recalculation of the credit profile of the target intelligent agent based on abnormal events and red line risk levels; wherein, during the credit profile recalculation, the lower the red line risk level, the lower the penalty weight of the abnormal event.

[0072] Specifically, the credit profile feedback module 80 constitutes a dynamic linkage interface between the security detection system and the full lifecycle management of the intelligent agent. This module receives abnormal events and their corresponding red-line risk levels from the traffic management layer as factual input, and triggers a recalculation of the target intelligent agent's credit score or trustworthiness status accordingly. The design logic of "the lower the red-line risk level, the lower the penalty weight" in this embodiment is not a simple linear mapping, but rather aims to solve the "noise accumulation and false positive" problem commonly found in traditional risk control models. During the actual operation of the intelligent agent, many common anomalies (such as occasional network timeouts, minor frequency deviations, or non-malicious parameter format errors) are captured and marked as anomalies by the detector, but they are often essentially normal fluctuations in the business environment or within a tolerable fault-tolerant range, rather than subjective malicious attacks. If these low-level anomalies are given the same or similar penalty weights as high-level risks, over time, an intelligent agent that has been running stably for a long time but occasionally experiences technical failures may be wrongly judged as a high-risk entity due to the accumulation of a large number of minor deductions, thus suffering unnecessary traffic limiting or blocking. Therefore, this embodiment introduces a dynamic penalty factor negatively correlated with the red line level into the recalculation formula. This ensures that the credit profile only significantly decreases when the agent frequently triggers substantial security risks such as soft or hard red lines. For sporadic, ordinary anomalies, the system records them with very low weight or ignores them altogether. This mechanism effectively distinguishes between "technical disturbances" and "security threats," ensuring that the credit profile truly reflects the agent's security posture rather than simply its activity level or failure rate. This improves the accuracy and business-friendliness of subsequent governance decisions.

[0073] Example 7 As an alternative implementation method, such as Figure 1 As shown, the traffic diversion governance layer also includes a review and rule calibration module 90; The review and rule calibration module 90 is used to receive review conclusions on abnormal events and red line risk levels from manual review or multi-party authorized review queues; record the reasons for false alarms and scenarios of missed alarms in the review conclusions; and adjust the rule parameters or configuration thresholds in the current version detection rules based on the reasons for false alarms and scenarios of missed alarms to obtain new version detection rules; write the new version detection rules into the gray release record, and gradually expand the scope of effectiveness of the new version detection rules according to the preset gray release ratio; at the same time, it retains the detection rules of historical versions so as to perform retrospective interpretation based on the historical version detection rules when historical abnormal events occurred.

[0074] Specifically, the review and rule calibration module 90 endows the security detection system with the ability to continuously self-evolve in adversarial environments. In the field of agent security, attack methods and business models are rapidly iterating, and static detection rules are prone to failure or generating a large number of false alarms. This embodiment solves this problem by establishing a closed-loop feedback link from "manual / multi-party review" to "automatic rule tuning". When the reviewer or the authorized committee makes a final decision on an anomaly (e.g., confirming it as a false alarm or a missed alarm), the review and rule calibration module 90 not only records the decision result, but also structurally extracts the root cause of the misjudgment (e.g., "batch queries during promotional periods are normal business" or "new injection features are not covered by existing regular expressions"). Based on this structured attribution data, the system can automatically or manually adjust the parameters of the detection rules (e.g., increase the frequency threshold) or add new feature matching items to generate a new version of the detection rules.

[0075] To ensure the security of rule changes, new version detection rules are not immediately implemented across all systems. Instead, they are written into a gray-scale release record and gradually expanded in scope according to preset gray-scale ratios (e.g., 1%, 5%, 20% up to 100%). During the gray-scale period, the system monitors the false positive and false negative rates under the new rules in real time. Further expansion is only allowed after the indicators meet the standards, and automatic rollback occurs if any anomalies are detected. This gradual release strategy effectively avoids the risk of network-wide service paralysis due to rule configuration errors. More importantly, the review and rule calibration module strictly retains all historical versions of detection rules and their effective time windows. This design is crucial for compliance audits and dispute resolution: when it is necessary to review an abnormal alarm from three months ago or conduct judicial evidence collection, the system can accurately load the rule version that was in effect at that time for retrospective interpretation, restoring the judgment logic at that time, rather than using the latest rules to evaluate historical events in a misguided manner. Through the above mechanism, this embodiment achieves the unity of dynamic evolution of security detection strategy and historical interpretability, enabling the system to continuously adapt to new business forms and attack variants while maintaining a high detection rate, thus forming a long-term security operation closed loop.

[0076] Example 8 like Figure 4 As shown, this embodiment provides a method for security detection during the runtime of an intelligent agent. The general flow of this method is as follows: Step S101: Access the behavioral events during the runtime of the target intelligent agent.

[0077] The trusted behavior flow access module 20 receives behavior events in real time from sources such as the intelligent agent runtime environment, tool gateway, resource verification party, or security detection center. These events constitute the raw input data objects for subsequent detection processes, and their types cover tool invocation events, resource access results, status query results, and health check results. For example, a typical tool invocation event at least includes fields such as tool identifier, invocation effect, request digest, response digest, invocation result, session reference, and scene tag, providing basic materials for subsequent identity verification and context extraction.

[0078] Step S102: Verify the identity of the behavioral events during the runtime of the target intelligent agent.

[0079] In this step, the system first performs hardware anchor-based identity verification on the behavioral events accessed in step S101. Specifically, the trusted behavioral flow access module 20 calls the target agent's hardware anchor identity and hardware anchor state stored in the hardware anchor identity and state maintenance module 10 to verify whether the digital signature carried by the event is valid and whether the current anchor state is within the permitted range. This step constitutes the first security valve in the entire detection process. If the identity verification passes, the behavioral event is marked as a trusted source event and flows to the next stage; if the identity verification fails, such as due to signature mismatch or invalid anchor state, the behavioral event is immediately isolated as untrusted input and will not enter the subsequent anomaly detection link. This pre-filtering mechanism effectively prevents forged events or invalid data from consuming core detection resources and ensures that subsequent analysis is only carried out on behavioral flows with a physical trust foundation.

[0080] Step S103: Perform trusted verification on the behavior events that have passed the identity verification, and convert the trusted verification-passed behavior events into a security detection context.

[0081] Although the event has passed identity verification, further verification of its content integrity and temporal continuity is still needed to rule out transmission tampering or replay attacks. The event verification and normalization module 30 performs multi-dimensional joint verification of trusted anchors on the behavioral event, including identity authenticity, content integrity, temporal continuity, and source legitimacy. Only when all verification items pass is the system converted into a structured security detection context. This conversion process essentially maps heterogeneous raw log fields into standardized semantic feature vectors, such as extracting identity context, resource context, tool effect context, sensitive data context, time window context, and group context. Through this normalization process, the original discrete event is transformed into a machine-understandable and computable structured data object, laying a unified data foundation for subsequent multi-dimensional analysis.

[0082] Step S104: Obtain a multi-dimensional security detection baseline based on the security detection context.

[0083] In this step, the multi-baseline management module 40 extracts multi-dimensional composite localization features of the target agent from the security detection context and uses these features as a query key to dynamically read the corresponding baseline data from the pre-stored multi-baseline database. Specifically, the acquired multi-dimensional security detection baselines include the identity anchor baseline, the access permission baseline, and the behavior statistics baseline. The identity anchor baseline provides hardware trust endorsement during registration, the access permission baseline defines the compliance boundaries that the current operation should follow, and the behavior statistics baseline reflects the behavior patterns under historical normal conditions. This step enables the dynamic construction of the detection reference system, allowing subsequent anomaly detection to be accurately compared based on the current specific identity, resources, and scenario, rather than relying on static global thresholds.

[0084] Step S105: Input the security detection context and multi-dimensional security detection baseline into the multi-type anomaly detector for parallel determination.

[0085] In this step, the anomaly detection matrix module 50 receives the two types of input data mentioned above and performs parallel or serial cross-analysis using six types of detectors: anchor consistency detector, admission boundary detector, high-impact tool sequence detector, injection and bypass detector, data leakage detector, and group propagation detector. Each detector independently compares and judges against baseline data using contextual features, outputting anomaly detection results that include risk type, severity level, trigger signal, and confidence level. This matrix-style detection mechanism ensures that the system can comprehensively identify potential cross-layer privilege escalation and complex attack behaviors from multiple dimensions such as identity, permissions, tool sequences, model interactions, data security, and group collaboration.

[0086] Step S106: Obtain the anomaly detection results output by the multi-type anomaly detector; wherein, the anomaly detection results include comprehensive risk score, risk type, risk severity level, trigger signal, suggested action and confidence level, etc.

[0087] Specifically, by using multiple types of anomaly detectors, such as anchor consistency detector, admission boundary detector, high-impact tool sequence detector, injection and bypass detector, data leakage detector, and group propagation detector, to make parallel judgments, it is possible to identify anomalies in the target intelligent agent's runtime from multiple dimensions, including identity, permissions, tools, models, data, and groups.

[0088] Step S107: Generate anomaly events and anomaly evidence packages based on the anomaly detection results.

[0089] In this step, the anomaly evidence package generation module 60 standardizes and encapsulates the anomaly detection results output in step S105. Specifically, the system extracts anomaly detection factual information, generates a context hash value by combining it with the associated event context, and performs de-identification processing on the original business payload, ultimately generating a lightweight anomaly event and a heavyweight anomaly evidence package. The anomaly event is written into a trusted event chain for rapid indexing, while the anomaly evidence package contains a complete rule version, signal list, baseline reference, and evidence integrity summary, stored in a dedicated evidence repository. This step not only solidifies the detection conclusion but also ensures the immutability and privacy security of the evidence through cryptographic means, providing sufficient factual basis for subsequent auditing and review.

[0090] Step S108: Determine the red line risk level based on the abnormal events and abnormal evidence packages, and generate corresponding risk governance recommendations based on the red line risk level.

[0091] In this step, the red-line triage and governance suggestion module 70 determines the red-line risk level of abnormal events and evidence packages based on pre-configured triage rules. This step forms three differentiated handling branches: if determined to be a common anomaly, the system generates monitoring, downsampling observation, or alert-type governance suggestions to address minor deviations or business fluctuations; if determined to be a soft red line, the system generates governance suggestions to suspend high-risk operations and enter a manual review or multi-party authorized review queue, so as to introduce human decision-making when evidence is questionable or requires business context judgment; if determined to be a hard red line, the system generates governance suggestions such as suspension, rate limiting, forced re-examination, or regulatory reporting to achieve immediate blocking of high-risk situations such as serious unauthorized access, data leakage, or irreversible side effects. Through this hierarchical triage mechanism, the system avoids serious security risks being diluted by massive amounts of common anomalies, while preventing excessive intervention in normal business, ensuring the accuracy and timeliness of governance measures.

[0092] Step S109: Joint governance and credit profile recalculation.

[0093] After completing the red line diversion, the system will send the generated governance suggestions to the external governance authorization or lifecycle execution module for actual handling. At the same time, it will feed back the abnormal events and red line markers to the credit profile feedback module 80 to trigger credit recalculation. Among them, during credit profile recalculation, the lower the red line risk level, the lower the penalty weight of the abnormal event.

[0094] Step S110, verification and rule calibration.

[0095] Specifically, the system receives review conclusions from manual or multi-party authorized review queues regarding anomalies and red-line risk levels; records the causes of false positives and scenarios of missed positives in the review conclusions; and adjusts the rule parameters or configuration thresholds in the current version's detection rules based on these causes to obtain new version detection rules; writes the new version detection rules into the gray-scale release record and gradually expands the scope of effectiveness of the new version detection rules according to a preset gray-scale ratio; simultaneously, it retains historical version detection rules for retrospective interpretation based on historical version detection rules at the time of historical anomalies. This step completes a full closed loop from detection to governance and feedback optimization, enabling security detection capabilities to continuously evolve with changes in the business environment and adversarial situation.

[0096] It should be understood that although the steps described above are presented in a specific order in this embodiment, in actual implementation, some steps may be processed in parallel or optimized in a pipeline according to computing resources or business needs, as long as the logical correctness of the data dependencies is maintained. For example, the baseline loading in step S104 may overlap with the context normalization in step S103 to improve the overall detection throughput.

[0097] Example 9 This embodiment provides an electronic device, which may be, but is not limited to, a mobile phone, tablet computer, laptop computer, computer, server, etc. Figure 5 As shown, the electronic device 500 provided in this embodiment includes at least a processor 501, a memory 502, and a computer program stored in the memory 502 and capable of running on the processor 501. When the processor 501 executes the computer program, it implements the above-mentioned intelligent agent runtime security detection method.

[0098] In one possible implementation, processor 501 can be a single processing element or a collective term for multiple processing elements. For example, processor 501 can be a central processing unit (CPU) or one or more integrated circuits configured to implement the aforementioned intelligent agent runtime security detection method. Specifically, processor 501 can be a general-purpose processor, including but not limited to CPUs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0099] In one possible implementation, memory 502 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 5021 and / or cache memory 5022, and may further include read-only memory (ROM) 5023; memory 502 may also include a program tool 5025 having a set (at least one) of program modules 5024, including but not limited to: operating subsystem, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0100] In one possible implementation, the electronic device 500 provided in this embodiment may further include a bus 503 connecting different components (including processor 501 and memory 502). The bus 503 represents one or more types of bus structures, including memory bus, peripheral bus, local area bus, etc.

[0101] In one possible implementation, the electronic device 500 can also communicate with one or more external devices 504, such as, but not limited to, devices that enable a user to interact with the electronic device 500 (e.g., mobile phones, computers, etc.), and / or devices that enable the electronic device 500 to communicate with one or more other electronic devices (e.g., routers, modems, etc.). This communication can be performed via an input / output (I / O) interface 505. Furthermore, the electronic device 500 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 506. Figure 5 As shown, network adapter 506 communicates with other modules of electronic device 500 via bus 503.

[0102] It should be understood that, despite Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with the electronic device 500, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) subsystems, tape drives, and data backup storage subsystems.

[0103] It should be noted that, Figure 5 The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of this embodiment.

[0104] Furthermore, this embodiment also provides a computer-readable storage medium storing computer instructions. When executed by a processor, these computer instructions implement the aforementioned intelligent agent runtime security detection method provided in this embodiment. Specifically, the computer instructions can be built into or installed in the processor, enabling the processor to implement the aforementioned intelligent agent runtime security detection method by executing the built-in or installed computer instructions.

[0105] In addition, this embodiment also provides a program product, which includes program code. When the program code is executed by a processor, it implements the above-described intelligent agent runtime security detection method.

[0106] In one possible implementation, the program product provided in this embodiment can take the form of any combination of one or more readable media, wherein the readable media can be a readable signal medium or a readable storage medium, and the readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. Specifically, more specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, RAM, ROM, an erasable programmable read-only memory (EPROM), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0107] Example 10 To more clearly illustrate the application and technical effects of the present application's technical solution in a real-world business environment, a detailed explanation is provided below using an intelligent agent payment security detection scenario as an example. It should be understood that this embodiment is merely an illustrative application scenario demonstration and is not intended to limit the scope of protection of this application. Other intelligent agent operation scenarios involving sensitive data access, device control, or cross-system collaboration can be implemented with reference to the logic of this embodiment.

[0108] In this application scenario, suppose a financial intelligent agent receives a user instruction during operation and attempts to execute a transfer tool call, but this instruction is actually generated by an attacker through a prompt injection attack. The entire security detection and handling process unfolds chronologically as follows: First, the trusted behavior flow access module 20 receives the transfer tool call event in real time. Although the event content contains malicious inducement instructions, the digital signature and hardware anchor fingerprint carried by the event are valid because the attacker hijacked a legitimate session channel or used an authorized sub-agent identity to initiate the request. The hardware anchor identity and state maintenance module 10 confirms that the anchor state of the agent is active and the signature verification is successful. Based on this, the trusted behavior flow access module 20 determines that the event identity verification is successful and allows it to proceed. This process reflects the design principle of the trusted input layer, which focuses on verifying the physical credibility of the event source. It avoids prematurely intercepting potentially legitimate but abnormal business requests due to malicious features at the content level, and also prevents attackers from interfering with the detection system by forging logs.

[0109] Subsequently, the event enters the anomaly detection layer. The event verification and normalization module 30 performs multi-dimensional trusted anchor joint verification on the event. After confirming that the content integrity and temporal continuity are correct, it converts it into a security detection context containing identity context, resource context, tool effect context, and sensitive data context. The multi-baseline management module 40 then dynamically loads the corresponding identity anchor baseline, access permission baseline, and statistical baseline of the agent's historical transfer behavior based on the identity ID and resource identifier in this context. After receiving the above input, the anomaly detection matrix module 50 triggers multiple detectors to analyze in parallel. Among them, the injection and bypass detector identifies the inducement semantic features in the user input that attempt to cover system security instructions by analyzing the input summary and session context, and outputs injection risk signals; at the same time, the high-impact tool sequence detector, combined with the behavioral statistical baseline, finds that the agent suddenly switched from a regular balance query operation to a large transfer operation within a very short time window, and lacked the necessary intermediate confirmation steps, which significantly deviated from the historical normal distribution, and outputs tool abuse and irreversible side effect risk signals. This matrix-style cross-judgment mechanism effectively overcomes the defect of single-dimensional detection in being unable to identify complex combined attacks.

[0110] Next, the anomaly evidence package generation module 60 initiates the evidence solidification process based on the aforementioned detection results. This module extracts factual information such as the anomaly type, trigger signal list, and detection rule version, and concatenates the summaries of the current event and its preceding related events to generate a context hash value, ensuring the immutability of the attack chain over time. For sensitive business payloads such as the receiving account and transaction amount involved in the transfer event, the module performs de-identification processing, retaining only field category markers and storage references in the anomaly evidence package, without saving plaintext data. The resulting lightweight anomaly event is written into the trusted event chain for rapid downstream consumption, while the heavyweight anomaly evidence package containing complete forensic information is stored in a dedicated evidence repository, along with an evidence integrity summary for subsequent audit verification.

[0111] Then, the Red Line Triage and Governance Recommendation Module 70 consumes the abnormal event and evidence package. Given that the event simultaneously exhibits two serious risk characteristics—injection attack and high-risk fund operation—and involves irreversible external side effects, the Red Line Triage and Governance Recommendation Module 70 classifies it as a hard red line based on pre-configured red line triage rules. The system immediately generates a governance recommendation to suspend all financial tool access permissions for the agent and automatically triggers the regulatory report generation process. It is important to emphasize that at this point, the system only outputs the governance recommendation and a high-risk flag; it does not directly execute irreversible operations such as account cancellation or transaction record deletion. The final decision-making authority remains with the authorized external governance module, thus ensuring a clear boundary of responsibility between security detection and business execution.

[0112] Finally, after manual review or multi-party authorized review confirms that the event is indeed a malicious attack, the credit profile feedback module 80 receives the review conclusion and a hard red line marker, triggering a recalculation of the target agent's credit profile. Because it hits the hard red line, the system assigns a high penalty weight to this abnormal event, significantly lowering its credit score, resulting in stricter access restrictions for the agent in subsequent cycles. Simultaneously, the review and rule calibration module 90 records the characteristic patterns of this attack and the reasons for false positives, automatically adjusting the parameter thresholds of the injection detection rules or adding new feature matching items, generating a new version of the detection rules and incorporating it into the gray-scale release process. This closed-loop feedback mechanism enables the security detection system to continuously learn and evolve from actual attack cases, constantly improving the accuracy and response speed in identifying new types of hint injection and tool abuse attacks.

[0113] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0114] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0115] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0116] Obviously, those skilled in the art can make various modifications and variations to this embodiment without departing from the spirit and scope of this embodiment. Therefore, if these modifications and variations of this embodiment fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A security detection system for the operation of an intelligent agent, characterized in that, include: The trusted input layer is used to verify the identity of behavioral events during the runtime of the target intelligent agent. The anomaly detection layer is used to perform trusted verification on behavioral events that have passed identity verification, and to convert the trusted verification-passed behavioral events into a security detection context. A multidimensional security detection baseline is obtained based on the security detection context; The security detection context and the multi-dimensional security detection baseline are input into a multi-type anomaly detector to obtain anomaly detection results; Based on the anomaly detection results, generate anomaly events and anomaly evidence packages; The triage and governance layer is used to determine the red line risk level based on the abnormal event and the abnormal evidence package, and to generate corresponding risk governance suggestions based on the red line risk level.

2. The intelligent agent runtime safety detection system as described in claim 1, characterized in that, The trusted input layer includes: The hardware anchor identity and state maintenance module is used to maintain the hardware anchor identity and hardware anchor state of the target intelligent agent; wherein, the hardware anchor identity includes the intelligent agent identity number generated when the target intelligent agent registers, the registration anchor type, the hardware anchor fingerprint and the issuance key, as well as the parent-child identity relationship generated during operation; the hardware anchor state includes the state bit and anchor state of the target intelligent agent; The trusted behavior flow access module is used to monitor the behavior events of the target intelligent agent in real time, and call the hardware anchor identity and hardware anchor state of the target intelligent agent maintained by the hardware anchor identity and state maintenance module to perform identity verification on the behavior events of the target intelligent agent during its runtime.

3. The intelligent agent runtime safety detection system as described in claim 1, characterized in that, The anomaly detection layer includes: The event verification and normalization module is used to perform multi-dimensional trusted anchor joint verification on behavioral events that have passed identity verification, and to extract multi-dimensional context from the behavioral events that have passed the multi-dimensional trusted anchor joint verification to form a security detection context; wherein, the multi-dimensional trusted anchor joint verification includes identity authenticity verification, content integrity verification, temporal continuity verification, and source legality verification; the multi-dimensional context includes identity context, resource context, tool effect context, sensitive data context, time window context, and group context; The multi-baseline management module is used to extract multi-dimensional composite localization features of the target agent from the security detection context; using the multi-dimensional composite localization features as query keys, it reads identity anchor baseline, access permission baseline, and behavior statistics baseline from a pre-stored multi-baseline database as multi-dimensional security detection baselines; wherein, the identity anchor baseline includes the pre-maintained hardware anchor identity and hardware anchor status of the target agent; the access permission baseline includes a pre-configured set of access control rules for the target resources; and the behavior statistics baseline includes benchmark values ​​of multiple types of behavior statistics indicators obtained by periodically calculating offline data from historical behavior event streams that have passed trusted verification. An anomaly detection matrix module is used to input the security detection context and the multi-dimensional security detection baseline into a multi-type anomaly detector to obtain anomaly detection results; wherein, the multi-type anomaly detector includes an anchor consistency detector, an admission boundary detector, a high-impact tool sequence detector, an injection and bypass detector, a data leakage detector, and a swarm propagation detector; An anomaly evidence package generation module is used to generate anomaly events and anomaly evidence packages based on the anomaly detection results.

4. The intelligent agent runtime safety detection system as described in claim 3, characterized in that, The abnormal evidence package generation module is used to extract abnormal detection fact information based on the abnormal detection results; A context hash value is generated based on the anomaly detection factual information and the associated event context of the behavioral event; The original business payload of the aforementioned behavioral event is subjected to data anonymization processing; Based on the anomaly detection factual information, the context hash value, and the original business payload after data anonymization, anomaly events and anomaly evidence packages are generated. A cryptographic hash operation is performed on the abnormal evidence package to obtain an evidence integrity digest, and the evidence integrity digest is written into the abnormal evidence package.

5. The intelligent agent runtime safety detection system as described in claim 1, characterized in that, The traffic diversion and management layer includes: The red-line triage and governance suggestion module is used to determine the red-line risk level of the abnormal event and the abnormal evidence package by using pre-configured red-line triage rules. If the red-line risk level is a normal anomaly, governance suggestions such as monitoring, downsampling observation, or reminders are generated. If the red-line risk level is a soft red line, governance suggestions such as suspending high-risk operations and entering the manual review or multi-party authorized review queue are generated. If the red-line risk level is a hard red line, governance suggestions such as suspension, flow restriction, forced re-examination, or regulatory reporting are generated.

6. The intelligent agent runtime safety detection system as described in any one of claims 1-5, characterized in that, The diversion and management layer also includes: The credit profile feedback module is used to trigger a recalculation of the credit profile of the target intelligent agent based on the abnormal event and the red line risk level; wherein, during the credit profile recalculation, the lower the red line risk level, the lower the penalty weight of the abnormal event.

7. The intelligent agent runtime safety detection system as described in any one of claims 1-5, characterized in that, The diversion and management layer also includes: The review and rule calibration module is used to receive review conclusions from manual review or multi-party authorized review queues regarding the abnormal events and the red line risk levels; record the false alarm reasons and missed alarm scenarios in the review conclusions; and adjust the rule parameters or configuration thresholds in the current version detection rules based on the false alarm reasons and missed alarm scenarios to obtain new version detection rules; write the new version detection rules into the gray release record, and gradually expand the effective scope of the new version detection rules according to the preset gray release ratio; at the same time, it retains the historical version detection rules so as to perform retrospective interpretation based on the historical version detection rules when the historical abnormal events occurred.

8. A method for security detection during the operation of an intelligent agent, characterized in that, include: Identity verification is performed on behavioral events of the target intelligent agent during its runtime. Perform trusted verification on behavior events that pass identity verification, and convert the trusted verification-passed behavior events into a security detection context; A multidimensional security detection baseline is obtained based on the security detection context; The security detection context and the multi-dimensional security detection baseline are input into a multi-type anomaly detector to obtain anomaly detection results; Based on the anomaly detection results, generate anomaly events and anomaly evidence packages; The red line risk level is determined based on the abnormal event and the abnormal evidence package, and corresponding risk governance recommendations are generated based on the red line risk level.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the intelligent agent runtime security detection method as described in claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the intelligent agent runtime security detection method as described in claim 8.

Images