Inference methods for dynamically triggering zero-trust engine operation and adjusting verification strength based on business risks during computer program execution, computer program products and systems

Abstract

This invention provides an inference method, computer program product, and system for dynamically triggering a zero-trust engine and adjusting verification strength based on business risks during computer program execution. The inference method includes: establishing at least one business risk attribute for the execution of at least one computer program installed on a computer device, wherein the business risk attribute further includes a plurality of risk event standards with different risk levels, and each risk event standard corresponds to a verification level; and when an operation command is dynamically received during the execution of the computer program, triggering any of the risk event standards in the business risk attribute, selecting the verification level corresponding to the risk event standard, and activating a zero-trust engine electrically connected to the computer device to perform a trust inference operation based on the verification level; wherein, when the zero-trust engine reports that the trust inference operation result is non-compliant, the computer program performs a cybersecurity protection operation.

Description

[Technical Field]

[0001] This invention relates to the fields of computer program design architecture and cybersecurity enhancement technology, and in particular to a method for inferring the activation of a zero-trust engine and adjusting the verification strength based on business risks during computer program execution, a computer program product and system thereof, thereby strengthening the triggering path of the zero-trust verification mechanism and effectively improving cybersecurity control. [Previous Technology]

[0002] Existing information systems often use the concept of "Zero Trust Architecture (ZTA)" as the primary basis for improving information operation security. This architecture emphasizes that no user, device, or application is pre-trusted; instead, continuous verification mechanisms are used to ensure the legitimacy and legitimacy of each transaction. In practice, zero-trust systems typically rely on environmental background data such as user identity, multi-factor authentication, behavioral analysis, and device status for risk assessment and access control.

[0003] However, most existing zero-trust systems focus on environmental level data, such as user devices, login locations, and connection history. They lack an effective mechanism for interpreting the semantic structure and business risk information implicit in the user's actual operational instructions. In other words, while zero-trust mechanisms can assess environmental risks, they struggle to differentiate between situations where the risk level varies significantly due to different parameters within the same operational type. For example, in a corporate environment, operational instructions such as money transfers, data export, or permission changes, even with the same format, can have their overall risk level significantly affected by the parameters (such as amount, target, and time) and the operator's characteristics. Traditional risk control methods often rely on static rules or role classifications, failing to dynamically infer operational risks based on the semantic meaning of the actions input by the operator. This leads to overly strict or overly lenient verification processes, affecting user experience and reducing the accuracy of risk response. In addition, traditional risk models are mostly based on historical events or statistical results. They often cannot reflect the potential risks brought about by new business operations or combinations of variable parameters in a timely manner, thus creating gaps in protection or misjudging risks.

[0004] In view of the above problems, based on years of experience in related industries, the inventor has proposed an inference method, system and computer program product that dynamically triggers the zero-trust engine and adjusts the verification strength based on business risk attributes during computer program execution. The aim is to strengthen the shortcomings of existing zero-trust verification mechanisms in terms of semantic interpretation and risk mapping, thereby effectively improving the risk management of various computer programs in the business execution aspect of information systems. [Summary of the Invention]

[0005] One objective of this invention is to provide a technology that dynamically triggers the zero-trust engine and adjusts the verification strength based on business risk attributes when a computer program is executing business operations, thereby improving the problem that existing risk judgment criteria are too static or difficult to cover diverse operational semantics, thereby enhancing the operational risk management of computer program business execution.

[0006] To achieve the above objectives, the present invention proposes an inference method for dynamically triggering a zero-trust engine and adjusting verification strength based on business risks during the execution of a computer program. The method includes: establishing at least one business risk attribute for the execution of at least one computer program installed on a computer device, wherein the business risk attribute is further configured with a plurality of risk event standards of varying risk levels, and each of these risk event standards corresponds to a verification level; and when an operation command is dynamically received during the execution of the computer program and triggers any of the risk event standards in the business risk attribute, selecting the verification level corresponding to the risk event standard, and activating a zero-trust engine electrically connected to the computer device to perform a trust inference operation based on the verification level; wherein, when the zero-trust engine reports that the trust inference operation result is non-compliant, the computer program performs a cybersecurity protection operation.

[0007] To achieve the above objectives, based on the aforementioned similar technical concepts, this invention further proposes a computer program product that dynamically triggers the zero-trust engine based on business risk and adjusts the verification strength, to be loaded and executed via a computer device, comprising: a first program instruction that causes a microprocessor to dynamically receive an operation instruction; a second program instruction that follows the first program instruction and causes the microprocessor to respond, determining whether the operation instruction has triggered at least one pre-built business risk attribute; wherein, the business risk attribute is further configured with a plurality of risk event standards of different risk levels, and each of these risk event standards corresponds to a verification level content; a third program instruction; and a fourth program instruction. The microprocessor executes a security protection operation when the second instruction determines that the operation instruction is a business risk attribute. A third instruction, following the third instruction, causes the microprocessor to activate a zero-trust engine connected to the computer device via telecommunications, and selects the verification level corresponding to the risk event standard to perform a trust inference operation. A fourth instruction, following the fourth instruction, causes the microprocessor to execute a security protection operation when the zero-trust engine reports that the trust inference operation result is non-compliant after executing the fourth instruction.

[0008] To achieve the above objectives, based on the aforementioned similar technical concepts, this invention further proposes an inference system that dynamically triggers a zero-trust engine and adjusts verification strength based on business risk during the execution of a computer program. This system runs on at least one computer program installed on a computer device and includes: a construction module that constructs at least one business risk attribute for the execution of the computer program, and further sets multiple risk event standards with different risk levels according to the business risk attribute, and each of these risk event standards corresponds to a verification level; and a judgment module that is electrically connected to the construction module and dynamically... Upon receiving an operation command, the system determines whether the operation command has triggered any of the risk event criteria in the business risk attribute; a verification module, electrically connected to the verification module, selects the verification level content corresponding to the risk event criterion when the verification module determines that the operation command has triggered any of the risk event criteria in the business risk attribute, and starts a zero-trust engine electrically connected to the computer device to perform a trust inference operation based on the verification level content; and a contingency module, electrically connected to the verification module, drives the computer program to perform a cybersecurity protection operation when the zero-trust engine reports that the trust inference operation result is non-compliant.

[0009] Furthermore, based on the aforementioned inference method, system and computer program product technology, in one embodiment, the cybersecurity protection operation is driven by the computer program to disconnect the computer device from the network or issue an alert.

[0010] Further, in another embodiment, when the trust inference operation is performed several times in the execution of the computer program, the plurality of verification conditions in the verification level content of the subsequent trust inference operation that have been verified in the previous trust inference operation will not be verified again.

[0011] In another embodiment, the business risk attribute corresponds to a risk event model. The risk event model performs a comprehensive risk score based on at least one semantic feature after semantic decomposition of the operation instruction, and maps it to the corresponding risk event standard.

[0012] Preferably, the semantic feature includes one or a combination of the following: operator attribute, range of operation parameter values, operation counterpart attribute, or operation time information.

[0013] In summary, this invention addresses the problem that most verification triggering mechanisms in existing zero-trust architectures still rely heavily on static settings and struggle to reflect changes in operational semantics in real time. Therefore, it proposes a dynamic trust inference technology architecture that integrates business semantic analysis and risk perception logic. The approach involves pre-establishing at least one business risk attribute when a computer program executes business operations, and further setting corresponding multiple risk event standards and verification levels. This allows the system to perform real-time risk assessment and mapping based on the semantic features contained in the operation instructions (such as operator attributes, operation counterparts, parameter ranges, and time information) to determine whether to trigger a trust verification operation. When the triggering condition is met, the system automatically calls the zero-trust engine connected to external telecommunications to execute a trust inference operation of corresponding verification strength, and automatically performs cybersecurity protection actions such as network disconnection and alerts based on the result. This not only achieves differentiation and dynamic adaptation of verification strength but also effectively covers potential risks arising from diverse operational semantics, avoiding the blind spots in existing technologies that cannot flexibly handle complex business processes. Furthermore, by accumulating the results of verifying conditions, redundant verification can be avoided, thereby improving execution efficiency. Overall, this invention significantly improves the accuracy of operational risk response, the flexibility of trust decisions, and the real-time nature of information security control in computer programs during business operations, effectively achieving the technical objectives and effects of enhancing information system security and practical feasibility.

Implementation Method

[0015] To enable those skilled in the art to clearly understand the technical content of this invention, the following description is provided in conjunction with the accompanying drawings. The structures, block diagrams, logic module configurations, and process sequences shown in the drawings are illustrative of the technical features of this invention and are not intended to limit the actual system deployment or application design details. The modules, processing flows, or parameter settings shown in each figure are merely reference embodiments for understanding this invention, and may be flexibly adjusted according to system architecture or service requirements in actual applications.

[0016] Please refer to Figure 1, which is a flowchart of the inference method according to an embodiment of the present invention. This embodiment discloses an inference method for dynamically triggering the zero-trust engine and adjusting the verification strength based on business risk during computer program execution. The computer program refers to an application program installed on a computer device with an operating system (such as iOS, WINDOWS, etc.) to achieve specific functions. Such applications include computer programs with financial management functions, computer programs with accommodation management functions, computer programs with medical management functions, computer programs with machine equipment management functions, and so on. Once these computer programs are installed on the computer device, they can be started and run at any time to perform their relevant business functions as needed. Furthermore, the biggest difference between the technical features of this invention and existing applications on the market lies in the fact that, during the operation of these applications, various conditional factors input by external operations are preset according to their functional attributes. These factors include: operator attributes, such as identity, job grade, or job requirements; range of operation parameter values, such as the amount of money input for various behaviors such as transfers, currency exchange, and transactions; operation counterpart attributes, such as transfer, transaction object, and currency exchange; or operation time information, such as daytime, afternoon, or evening, or more finely segmented time points. By analyzing these various conditional factors, the system determines whether the business risk has reached the point where a zero-trust engine connected to the computer device should be activated for verification. The verification strength is determined by the level of business risk after analyzing the various conditional factors input by external operations. The zero-trust engine may include a verification module, a behavior analysis module, and a trust assessment module, and can be connected to an identity verification server, MFA service, or SIEM system via API to perform verification and event response actions. In other words, the operation process of these applications described in this invention is basically no different from the conventional understanding of their operation functions. The only difference is that when certain types and degrees of business risks are triggered during the execution process and verification is required, the zero-trust engine is dynamically activated to perform verification based on the verification strength of the current operation behavior.

[0017] To further explain, the inference method described in this embodiment generally includes two procedures. In the first procedure (step S10), at least one business risk attribute is established for the execution operation of at least one computer program installed on the computer device. For example, for the computer program with accounting management function, the execution operation of its transfer operation is set as a business risk attribute that should be verified. Furthermore, the business risk attribute is further set with multiple risk event standards of different risk levels, and each of these risk event standards is set with a corresponding verification level. Continuing the previous example, different levels of risk event standards are set for the risk level that the transfer operation may involve. When it is judged to be high risk, there are more verification levels; conversely, low risk naturally has fewer verification requirements. Of course, the actual number of risk event standards is determined by the business orientation of the computer program, rather than by a fixed classification standard.

[0018] Subsequently, in the subsequent procedure (step S20), when an operation instruction is dynamically received during the execution of the computer program and triggers any of the risk event standards in the business risk attribute, the verification level content corresponding to the risk event standard is selected, and the zero-trust engine connected to the computer device is started to perform a trust inference operation using the verification level content; wherein, when the zero-trust engine reports that the trust inference operation result is non-compliant, the computer program executes a cybersecurity protection operation; wherein the cybersecurity protection operation can be driven by the computer program to disconnect the computer device from the network or issue an alert. For example, when an operator uses the computer program with the accounting management function to perform a transfer operation involving a certain amount, a higher-level risk event standard is triggered, and then the higher-level verification level content drives the zero-trust engine connected to the computer device to perform the trust inference operation using the verification level content. In short, in low-level zero-trust comparison scenarios, the system may only need to perform single-factor authentication, such as username and password login, valid credentials in the browser, or quick verification of registered devices. It can even automatically complete verification through existing Single Sign-On (SSO) mechanisms, supplemented by behavioral analysis comparing users' usual operating habits for post-verification, ensuring operational efficiency and user experience while maintaining basic trust. In contrast, in high-level comparisons, the system strengthens the verification process, such as enabling multi-factor authentication (MFA) mechanisms, requiring users to provide dynamic passwords (such as OTPs), hardware keys, or biometrics for identity verification. It may also additionally require behavioral verification and contextual information (such as whether the current device matches past records). If a trusted connection still cannot be established, the zero-trust engine responds with a non-compliant result, and the system will subsequently trigger contingency modules to implement security protection measures such as blocking the connection, disconnecting from the network, or issuing alerts.

[0019] Furthermore, when the trust inference process is performed multiple times during the execution of the computer program, if any of the verification conditions in the verification level of a subsequent trust inference process have already been verified in a previous trust inference process, then those conditions will be automatically considered verified and will not require repeated verification. This effectively reduces the system burden and user operation friction caused by repeated verification, and improves the overall system responsiveness and user experience while ensuring security. At the same time, the hierarchical management of verification conditions and the verification status memory mechanism further enhance the decision-making consistency of trust inference, avoiding process interruptions or contradictory verification results due to repeated verification.

[0020] Furthermore, preferably, the business risk attribute corresponds to a risk event model. Upon receiving the operation instruction, the risk event model performs semantic decomposition to extract at least one semantic feature, and inputs the extracted semantic feature into a risk calculation logic for comprehensive risk scoring. For example, this may include sentence decomposition and contextual lexical analysis of the operation instruction, combined with rule-based comparison or machine learning models to extract recognizable semantic features. The risk calculation logic may include mapping each semantic feature to an overall risk score using weighted summation or a non-linear function. This allows for an overall assessment of the potential risk level of the operation instruction in a specific business environment, and automatically maps the scoring result to preset risk event standards to determine the corresponding verification level. Preferably, the risk event model can further self-adjust based on previous verification results or abnormal operation events, updating the semantic feature weights and risk score correspondence logic, thereby gradually enhancing the model's accuracy and cybersecurity sensitivity. Accordingly, this comprehensive risk assessment design avoids misjudgment based on a single indicator. Instead, it utilizes multi-context cross-validation to effectively enhance the model's ability to identify abnormal behavior and the accuracy of reliable inferences, thereby strengthening the dynamic adjustment efficiency of the verification process in the zero-trust mechanism. The semantic features can include one or a combination of the following: operator attributes (e.g., whether the transfer was executed by an accountant with administrative authority or a temporary account), operation parameter value range (e.g., whether the transfer amount is more than three times the average of the past thirty days), operation matching attributes (e.g., whether the receiving account is appearing for the first time, whether it comes from an abnormal region, or overlaps with a high-risk list), or operation time information (e.g., whether the operation was performed outside of working hours or in the early morning of a national holiday). This enables high-dimensional semantic recognition and context comparison, accurately classifying low-risk and high-risk instructions and behaviors, and triggering verification processes of varying intensities accordingly, such as transitioning from simple authentication to multi-factor or human-computer interaction verification, to ensure both security and user experience. In summary, the inference method of this invention can be used to verify those involved in business risks during the operation of the computer program, thereby enhancing the verification model's ability to perceive abnormal operation patterns and supporting subsequent dynamic adjustment of verification levels, effectively improving the overall cybersecurity agility and responsiveness of the system.

[0021] Please refer to Figure 2, which is a schematic diagram of the operation of a computer program product according to an embodiment of the present invention. This embodiment discloses a computer program product that dynamically triggers the operation of a zero-trust engine and adjusts the verification strength based on business risks, and is loaded and executed via a computer device. The definitions and relationships between the computer program, computer device, zero-trust engine, and so-called execution operation and business risks are the same as in the previous embodiments, and will not be repeated here.

[0022] Further explanation: The computer program product described in this embodiment can be stored in a non-temporary computer-readable storage medium and carries a set of instructions executable by a microprocessor. These instructions comprise the following modules or functional units. The computer program product includes: a first program instruction that causes the microprocessor to dynamically receive an operation instruction triggered actively or passively. This operation instruction can be for various operations such as viewing specific types of data, or modifying, deleting, or exporting data.

[0023] Subsequently, a second program instruction is executed, following the aforementioned first program instruction, to control the microprocessor to execute a risk judgment process, specifically to compare and determine whether the operation instruction triggers at least one pre-built business risk attribute within the system. The so-called business risk attribute can be categorized according to different business processes, such as abnormal financial transactions, changes in key supply chain data, potential leakage of personnel information, or abuse of system management authority. Each business risk attribute has multiple risk event standards divided according to the degree of risk. Each risk event standard corresponds to a verification level; for example, level one requires one-time password verification, level two requires MFA, and level three further requires dual verification of device authentication and manual approval.

[0024] Subsequently, a third program instruction is executed, which follows the aforementioned second program instruction. After determining that the operation instruction corresponds to a specific business risk attribute, the microprocessor needs to further analyze which risk event standard within that risk attribute the operation instruction specifically matches. This may involve multi-dimensional condition calculations, such as time point, user role, historical operation trajectory, and sensitivity tags of operation data, to further refine the risk level classification. For example, if the operation is to check personal data, an employee from the finance department performing the operation during normal working hours can be classified as risk level one; if it is an external IP address exporting data outside of business hours, it is classified as risk level three.

[0025] Subsequently, a fourth program instruction is executed, which follows the aforementioned third program instruction. Once the risk event standard is clear, the microprocessor controls a zero-trust engine that is electrically connected to its computer device, and initiates a trust inference operation for the verification level corresponding to the risk event standard. The zero-trust engine can be a module deployed in an enterprise private cloud or hybrid cloud architecture. Its internal implementation includes an identity authentication module, a behavior analysis module, a biometric verification module, and a device security status awareness module, etc., which comprehensively performs trust scoring and decision inference on whether to allow the operation instruction to continue to be executed.

[0026] Subsequently, a fifth program instruction is executed, which follows the trust inference operation initiated by the fourth program instruction. If the zero-trust engine reports a non-compliant result (e.g., verification failure, device not logged in, ambiguous identity, or abnormal behavior), the microprocessor is controlled to immediately initiate one or more cybersecurity protection operations. These operations may include: pausing the operation, locking the current user session, issuing warnings such as notifying cybersecurity personnel or sending security incident alerts, disconnecting the computer device from the network such as blocking subsequent connections from suspicious IP addresses, or automatically inputting the event into the Security Incident Management System (SIEM) for post-event analysis. This design enhances the enterprise's ability to respond to potential risks during operations and also provides the technical conditions for implementing a trustless default defense architecture.

[0027] Further, similar to the aforementioned embodiments, in this embodiment, during the execution of the computer program product, for example, if the trust inference operation is triggered several times in a relatively short period of time (e.g., the user performs several high-risk operations in succession during a certain operation phase), the zero-trust engine will process the verification level content corresponding to each trust inference operation; wherein, if some of the multiple verification conditions required for subsequent trust inference (e.g., password verification, multi-factor verification, biometric verification, device authentication, etc.) have been successfully verified in the previous trust inference operation, the system can mark such verification conditions as "verified status" in subsequent operations and skip them instead of forcibly repeating them, thereby improving the user experience and reducing the system load caused by repeated verification.

[0028] For example, when a user performs a high-risk operation involving modification of financial data for the first time, the zero-trust engine may require biometric identification (such as fingerprint or facial recognition) and device integrity verification (such as whether the device has an enterprise protection agent installed). If the user then performs another personnel data export operation, which also requires the same level of verification, the engine can automatically refer to the previous verification result and validity period (such as verification valid within 10 minutes) to determine that the aforementioned biometric identification and device verification conditions have been met. In this case, the user will not be required to perform these actions again, but will only be checked for conditions that have not yet been verified or have additional requirements (such as one-time passwords). This design can effectively avoid user operation interruptions and fatigue caused by over-verification, and also helps to optimize the allocation of system resources and enhance the flexibility and status awareness of the verification process, achieving a risk-responsive access control strategy that is more in line with the zero-trust architecture concept.

[0029] Further, the business risk attribute of the computer program product described in this embodiment corresponds to a risk event model. This risk event model, based on predefined business knowledge and semantic recognition logic, performs semantic decomposition on the received operation instruction, thereby extracting and identifying at least one semantic feature, and then performing a comprehensive risk scoring operation. Through semantic decomposition, the risk event model can identify potential risks to cybersecurity and business that may be caused by the operation intent, such as abnormal resource access patterns, changes in critical data, or cross-departmental calls, and derives a risk score result based on the model's built-in risk assessment rules (such as risk weight tables, risk threshold settings, etc.). This risk score is then mapped to one or more corresponding risk event standards as the basis for subsequent zero-trust verification level determination.

[0030] The above semantic features may include, but are not limited to, any one or any combination of the following: Operator attributes: such as the operator's job level, role permissions, department, or whether it is an abnormal account (such as logging in from an unexpected region); Operation parameter value range: such as abnormal input parameters, requested amount exceeding the set limit, or attempts to remit more than the set number of transactions; Operation counterpart attributes: whether this operation involves key system modules, sensitive data forms, cross-departmental / cross-level resource access, or external remittance recipients; or operation time information: such as whether the request was made during non-working hours, holidays, or at a time when the operation had not been performed before. Accordingly, through the multi-dimensional combination analysis of the above semantic features, the computer program product of this embodiment can accurately determine the potential risk level contained in the operation instructions, so that the risk event model not only has static rule matching capabilities, but also can dynamically adjust the risk assessment standards according to the operation context, thereby improving the real-time responsiveness and accuracy of the zero-trust mechanism to changes in business risks.

[0031] Please refer to Figure 3, which is a schematic diagram of the inference system according to an embodiment of the present invention. This embodiment discloses an inference system 1 that dynamically triggers the zero-trust engine and adjusts the verification strength based on business risks during computer program execution. It runs on at least one computer program installed on a computer device 2. The definitions and relationships between the computer program, computer device, zero-trust engine, execution operation, and business risk are the same as in the previous embodiments and will not be repeated here.

[0032] Furthermore, the inference system further emphasizes that, for the business risks of the computer program, the system personnel can set the triggering conditions and corresponding execution content of the zero-trust engine according to their actual needs. First, the inference system 1 of this embodiment, which dynamically triggers the zero-trust engine and adjusts the verification strength based on business risks during the execution of a computer program, includes: a construction module 10, a judgment module 11, a verification module 12, and a response module 13. The construction module 10 is used to construct at least one business risk attribute for the execution of the computer program. The business risk attribute can be a single operation scenario or a set of parameters used to characterize the operation risk. Based on the business risk attribute, a plurality of risk event standards corresponding to different risk levels are further constructed. The risk event standards may include, but are not limited to, instruction type, operation scope, access object, user role, time period, and geographical location. Each risk event standard is respectively set with at least one verification level. The verification level is used to define the identity verification or trust assessment method and intensity to be performed under the risk level. For example, a low-risk event standard corresponds to a lower intensity verification (such as single-factor authentication), while a high-risk event standard corresponds to a multi-factor authentication method. Furthermore, the judgment module 11 is electrically connected to the construction module 10 and dynamically monitors and receives one or more operation commands during the execution of the computer program. The operation commands are triggered by the user terminal or the application layer. The judgment module 11 parses the operation commands and compares whether they meet any risk event standard constructed by the construction module 10, thereby determining whether the operation triggers a specific business risk situation and outputting the risk trigger judgment result and the corresponding verification level content. Next, the verification module 12 is electrically connected to the judgment module 11. When the judgment module 11 determines that any risk event standard has been triggered, it selects the verification level content corresponding to the risk event standard and further activates a zero-trust engine 3 electrically connected to the computer device 2. The verification module 12 provides the verification level content to the zero-trust engine 3 as the basis for trust inference. The zero-trust engine 3 performs risk assessment, identity verification, device status assessment, historical behavior comparison, and other analyses to determine whether to allow the operation to continue. Subsequently, the response module 13 is electrically connected to the verification module 12, and receives feedback notifications after the zero-trust engine 3 completes the trust inference operation. If the notification shows that the result of the trust inference operation is non-compliant, the response module 13 will drive the computer program to execute at least one cybersecurity protection operation. The cybersecurity protection operation may include, but is not limited to, disconnecting the computer device from the network, interrupting the operation process, issuing an abnormal warning, activating an isolation mechanism, restricting access permissions, or executing additional verification procedures, so as to respond to potential risks in a timely manner and enhance system security.

[0033] Furthermore, when the trust inference operation is performed several times during the execution of the computer program, the system has a verification condition tracking and comparison mechanism. This mechanism cross-compares the verification level content involved in the subsequent trust inference operation with the verification conditions already completed in the previous trust inference operation. If multiple verification conditions (e.g., identity authentication, biometrics, device trust verification, environmental risk detection, etc.) have been completed in the previous trust inference operation within a preset valid timeframe, and their execution context still meets the trust assumptions of the verification conditions, the system will determine that their verification status is still valid, and automatically omit the repeated verification steps for these conditions in the subsequent trust inference operation. This design reduces unnecessary verification operations, lowers the user's interaction burden, and improves the execution efficiency in multi-stage operation processes, while maintaining consistency between the verification results and the zero-trust trust inference judgment criteria. The system can also set individual validity periods and re-verification policies for different verification conditions to ensure a balance between security and convenience.

[0034] For example, the inference system 1 can be applied to a medical management computer program, which is used to handle operations such as patient data inquiry, electronic medical record editing, prescription approval, and downloading sensitive medical information. During the execution of the medical management computer program, when a user performs operations such as "viewing basic patient information", "editing electronic medical record content", "issuing prescriptions", and "downloading complete medical records" after logging in, the system may trigger corresponding trust inference operations one by one based on the risk event standards corresponding to certain operations. However, through the aforementioned technical means, that is, when the trust inference operation is performed several times during the execution of the computer program, if the verification level required by the subsequent trust inference operation includes multiple verification conditions (such as biometrics, device trust status, multi-factor authentication, etc.) that are the same as those in the previous trust inference operation and have been verified, the system can automatically determine that these conditions have been successfully verified and are within the validity period, and therefore will not require the user to repeat the same verification. In this way, when medical personnel approve prescriptions or download complete medical records immediately after editing them, the system does not require users to perform the same verification steps again (such as facial recognition or re-entering OTPs). This effectively reduces unnecessary verification burdens in the workflow, improves efficiency and user experience, while maintaining the integrity of risk perception and security controls. This design is also particularly suitable for practical environments in medical settings that require rapid response while ensuring high levels of cybersecurity.

[0035] Further, the business risk attribute corresponds to a risk event model. The risk event model is predefined to generate at least one semantic feature after semantic decomposition of the operation instruction. A comprehensive risk score is generated based on these semantic features, and the score result is mapped to the corresponding risk event standard to determine the trust strength requirement of the operation. For example, in a foreign exchange management operation, if the operation instruction involves foreign currency conversion, the system decomposes the relevant semantic features for the operation instruction. The semantic features may be one or a combination of the following: operator attributes (such as whether they are high-authority financial personnel, whether their role has an authorized position in the organization); operation parameter value range (such as whether the amount of a single foreign exchange transaction exceeds the preset warning limit, or whether the difference between the exchange rate set by the user and the spot market price is abnormal); operation counterpart attributes (such as whether the foreign exchange involves accounts in high-risk countries, or financial institutions not on the whitelist); operation time information (such as whether it is executed at night, on holidays, or during non-peak trading hours, or close to the time of recent suspicious behavior). In short, this risk event model can conduct comprehensive risk assessment based on these semantic features. For example, the behavior of "non-high-privilege users performing large-amount currency exchange to accounts in high-risk countries in the early morning" can be rated as a high-risk event and mapped to a higher-level verification level, triggering in-depth audits of multi-identity authentication and zero-trust engines. Conversely, if it is a frequent and highly compliant operation, it can only be mapped to the low-risk event standard and can be handled with low verification burden.

[0036] In summary, this invention addresses the problem that current zero-trust architectures rely heavily on static settings for verification triggering, making it difficult to reflect changes in operational semantics in real time. It proposes a dynamic trust inference architecture that combines business semantic analysis and risk perception logic. By pre-setting business risk attributes with multi-level risk event standards and verification layers when a computer program executes business operations, the system can assess risks in real time based on the semantic features contained in the operation instructions (such as operator attributes, operation counterparts, parameter ranges, and time information) to determine whether to trigger trust verification. When conditions are met, the system can automatically activate the zero-trust engine connected via telecommunications, perform trust inference with corresponding verification strength, and trigger cybersecurity protection actions such as network disconnection or alerts based on the result. This design not only enables dynamic adjustment and differentiated control of verification strength but also covers potential risks caused by diverse operational semantics, effectively filling the gap in existing technologies' inability to respond to complex business contexts. Furthermore, by reusing the verification condition comparison process, redundant verification can be reduced, improving processing efficiency. Therefore, this invention not only strengthens the risk control and real-time defense capabilities of information systems in business operations, but also takes into account the flexibility and feasibility of technical implementation, thus effectively achieving the technical problem that this invention aims to solve.

[0037] However, the above description is only a preferred embodiment of the present invention and should not be used to limit the scope of the present invention. Therefore, all equivalent changes and modifications made without departing from the scope of the present invention should be covered within the patent scope of the present invention. [Simplified Explanation of the Diagram]

[0014] Figure 1 is a flowchart of the inference method according to an embodiment of the present invention. Figure 2 is a schematic diagram of the operation of a computer program product according to an embodiment of the present invention. Figure 3 is a schematic diagram of the inference system according to an embodiment of the present invention.

Claims

1. A method for dynamically triggering a zero-trust engine and adjusting verification strength based on business risk during computer program execution, comprising: establishing at least one business risk attribute for the execution of at least one computer program installed on a computer device, wherein the business risk attribute is further configured with a plurality of risk event standards of different risk levels, and each of the risk event standards corresponds to a verification level; and when an operation command is dynamically received during the execution of the computer program and triggers any of the risk event standards in the business risk attribute, selecting the verification level corresponding to the risk event standard, and activating a zero-trust engine electrically connected to the computer device to perform a trust inference operation based on the verification level; wherein, When the zero-trust engine reports that the trust inference result is non-compliant, the computer program executes a cybersecurity protection operation.

2. The inference method as described in claim 1, wherein, The cybersecurity protection operation is driven by the computer program to disconnect the computer device from the network or issue an alert.

3. The inference method as described in claim 1, wherein, When the trust inference operation is performed several times during the execution of the computer program, multiple verification conditions in the verification level of the subsequent trust inference operation that have been verified in the previous trust inference operation will not be verified again.

4. The inference method as described in claim 1, wherein, The business risk attribute corresponds to a risk event model. The risk event model is based on at least one semantic feature obtained after semantic decomposition of the operation instruction, performs a comprehensive risk score, and maps it to the corresponding risk event standard.

5. The inference method as described in claim 4, wherein, The semantic feature includes one or a combination of the following: operator attribute, range of operation parameter values, operation counterpart attribute, or operation time information.

6. A computer program product that dynamically triggers a zero-trust engine based on business risk and adjusts verification strength, loaded and executed via a computer device, comprising: a first program instruction that causes a microprocessor to dynamically receive an operation instruction; and a second program instruction that follows the first program instruction, causing the microprocessor to respond and determine whether the operation instruction has triggered at least one pre-built business risk attribute; wherein, The business risk attribute is further defined with multiple risk event standards of varying risk levels, and each of these risk event standards corresponds to a verification level. A third program instruction, following the second program instruction, when the second program instruction determines that the operation instruction belongs to the business risk attribute, the microprocessor further determines which of the risk event standards in the business risk attribute the operation instruction conforms to. A fourth program instruction, following the third program instruction, causes the microprocessor to activate a zero-trust engine connected to the computer device via telecommunications, and selects the verification level content corresponding to the risk event standard to perform a trust inference operation. A fifth program instruction, following the fourth program instruction, causes the microprocessor to perform a cybersecurity protection operation when the zero-trust engine reports that the trust inference operation result is non-compliant after executing the fourth program instruction.

7. The computer program product as described in claim 6, wherein, The cybersecurity protection operation is driven by the computer program to disconnect the computer device from the network or issue an alert.

8. The computer program product as described in claim 6, wherein, When the trust inference operation is performed several times during the execution of the computer program, multiple verification conditions in the verification level of the subsequent trust inference operation that have been verified in the previous trust inference operation will not be verified again.

9. The computer program product as described in claim 6, wherein, The business risk attribute corresponds to a risk event model. The risk event model is based on at least one semantic feature obtained after semantic decomposition of the operation instruction, performs a comprehensive risk score, and maps it to the corresponding risk event standard.

10. The computer program product as described in claim 9, wherein, The semantic feature includes one or a combination of the following: operator attribute, range of operation parameter values, operation counterpart attribute, or operation time information.

11. An inference system for dynamically triggering a zero-trust engine and adjusting verification strength based on business risk during the execution of a computer program, running on at least one computer program installed on a computer device, comprising: a construction module for constructing at least one business risk attribute for the execution of the computer program, and further setting a plurality of risk event standards with different risk levels according to the business risk attribute, and each of the risk event standards corresponding to a verification level; and a judgment module, electrically connected to the construction module, and determining whether the operation instruction has triggered any of the risk event standards in the business risk attribute when dynamically receiving an operation instruction during the execution of the computer program. A verification module, telecommunication-connected to the judgment module, selects the verification level corresponding to the risk event standard when the judgment module determines that the operation command has triggered any of the risk event standards in the business risk attribute, and starts a zero-trust engine telecommunication-connected to the computer device to perform a trust inference operation based on the verification level content; and a contingency module, telecommunication-connected to the verification module, drives the computer program to perform a cybersecurity protection operation when the zero-trust engine reports that the trust inference operation result is non-compliant.

12. The inference system as described in claim 11, wherein, This cybersecurity protection operation involves disconnecting the computer from the network or issuing a warning.

13. The inference system as described in claim 11, wherein, When the trust inference operation is performed several times during the execution of the computer program, multiple verification conditions in the verification level of the subsequent trust inference operation that have been verified in the previous trust inference operation will not be verified again.

14. The inference system as described in claim 11, wherein, The business risk attribute corresponds to a risk event model. The risk event model is based on at least one semantic feature obtained after semantic decomposition of the operation instruction, performs a comprehensive risk score, and maps it to the corresponding risk event standard.

15. The inference system as described in claim 14, wherein, The semantic feature includes one or a combination of the following: operator attribute, range of operation parameter values, operation counterpart attribute, or operation time information.

Images