A Hybrid Blockchain-Based Framework for Adaptive Cyber-Risk Prediction and Multi-Layer Threat Mitigation in Enterprise Networks

Abstract

The environment of cybersecurity is changing at a higher rate than most automated defensive systems can keep pace with, and most enterprise-level solutions are based on a fixed set of rules or a black box with machine learning results. This leads to a loophole between identifying and controlling responses, particularly where the mitigation should demand accountability, proportionality, and justifiable reliability. Current AI–blockchain models enhance logging and detection and are seldom used to enforce adaptive, understandable, or risk-weighted response automation. It presents AGML, a hybrid governance-based defense framework that integrates blockchain mitigation execution with reinforcement-tuned prediction of cyber-risks. The system scores the risk continuously, mitigates severity depending on the situation, and recalculates behavior via a closed feedback mechanism. The blockchain layer is an enforcement boundary and not a passive ledger as all activities are auditable and not tamperable. The results of the evaluation show that there is a quantifiable increase in comparison with recent baselines: 96.48% detection accuracy, 95.22% precision, 94.65% recall, and a false-positive rate of 2.81. The average response latency was 312 ms and around 26 ms was due to governance validation. The system was also found to be stable in repeated adversarial cycles and exhibited stable convergence as opposed to drifting. These findings indicate that responsible and responsive automation, not rapid but uninhibited automation, could provide a more feasible solution to the resilient enterprise cybersecurity.

1. Introduction

Enterprise networks are now the nervous system of organizations that are working in the age of technology for organizational success where organizational functions are reliant on the immense networked infrastructure. The type of interconnectivity renders a remarkable efficiency that enables the free flow of communication and real-time and coordinated operations across geographies but equally presents a growing menace of cyber-threats to systems. On the inside or automatically, rogue elements steal and use the opportunity to subdue network structures, systems mal-configurations, human factors, and bugs [1,2].

On the other hand, the blockchain technology is being applied in other fields besides its initial use in cryptocurrency. The features of its decentralized ledger, immutability, and auditability are now viewed as useful to maintain the integrity in security-sensitive logs, provide transparent, tamper-resistant audit trails, and attain provenance of security events [3,4]. The hybrid paradigms of blockchain with AI-based analytics, or integrating blockchain-backed security within conventional enterprise networks, have begun to emerge [5,6]. These advancements are an indication of a bright future: integrating predictive cyber-risk analytics and decentralized trust mechanisms [7,8].

However, there are still some significant gaps in the existing literature. Some papers look at ML-based threat detection and risk prediction separately and do not support them with unchangeable audit or mitigation controls [9,10]. Other papers frequently discuss blockchain as a safe method of logging or consensus-based trust models in a decentralized or peer-to-peer context but rarely mention dynamic and enterprise-wide threat prediction and multi-layered defense approaches [11,12]. In research that tries to integrate security analytics and blockchain, it is common to focus on niche applications (e.g., IoT-device security or supply chain integrity) instead of large enterprise networks with mixed requirements of prediction, mitigation, audit and low latency [13,14]. Secondly, most of the proposals are more of a concept, not a deep experimental analysis of realistic enterprise-scale situations, or they fail to measure the performance overheads, scalability limitations, or false-positive/false-negative trade-offs of hybrid architectures [15,16].

Thus, one issue is evident: limited existing frameworks (i) integrate adaptive cyber-risk forecasting through ML/AI, (ii) incorporate tamper-resistant blockchain-based recording and audit, and (iii) support multi-layer threat mitigation for enterprise networks empirically validated in terms of both effectiveness and performance as well as practicability [17]. In the absence of such integration, the enterprises remain vulnerable: AI-based detection can identify a threat, but without reliable audit or strong response layers, mitigation can be haphazard or faulty. In its turn, blockchain-based logging on its own does not preempt and counter threats. The absence of one well-analyzed hybrid model limits the adoptability of real life [18].

This gap is the influence behind the current work and is likely to serve these dimensions. In particular, we speak about the problem of adaptive prediction of cyber-risks and real-time multi-layered threat-related mitigation in enterprise networks and audit trail maintenance of blockchain tamper-resident. This offers a viable, practical solution to the problem by developing a hybrid model that would integrate ML-based risk analytics, blockchain-based immutable logging, and overlay mitigation controls. It is an excellent effort at the appropriate time: as companies are under mounting pressure, by the presence of more advanced and ruthless opponents, and as the regulatory environment is exerting increasing levels of accountability and traceability of their efforts, such a consistent structure can enhance both their security stance and their readiness to comply.

Current methods based on both traditional IDS- and AI-driven detection as well as blockchain-based logging are insufficient for this purpose. Rule-based IDSs that are statical might not be able to match new attack patterns. ML-based models can be notoriously non-transparent and lack audit trail non-repudiation, and can be easily tampered with or have their forensic value compromised. Solutions based on blockchain alone do not solve predictive threat detection or mitigation in real time. Furthermore, most of the suggested solutions overlook the stratum nature of the enterprise threats at the network level, host level, application level, and user behavior level, thus lacking depth of protection. An enterprise-grade solution should include all these dimensions with a healthy balance in proactive detection, reactive mitigation, and a secure audit.

Therefore, the proposed study involves a Hybrid Blockchain-Adaptive Risk Prediction-Multi-layer Mitigation (H-BARM) Model. Its fundamental goals are the following:

To build an architecture of a permissioned blockchain that can be used in business, and it is needed to allow the in-memory storage of security-relevant events and mitigation measures that cannot be changed.

To develop and deploy an adaptive module of cyber-risk prediction that exploits heterogeneous information sources (network traffic, host logs, user behavior) and a dynamic threat evaluation through the use of ML/AI.

To design and implement a layered mitigation structure that cuts through the network layer, host layer, application layer and user-behavior layer that allows real-time or near-real-time reaction to exceeded risk thresholds.

In order to test the suggested model by simulation or emulation within an enterprise-like setup, it is necessary to test the accuracy of detection, false-positive/false-negative probability, latency of mitigation, system overhead, and scalability at different loads and network sizes.

To compare the performance and effectiveness of the hybrid model with the baseline approaches (e.g., traditional IDSs, pure ML-based detection, blockchain-only logging) and thus prove its benefits and costs.

The work is also narrowly targeted. We focus on both small- and large-scale enterprise networks based on internal network infrastructure with centralized management and need compliance-grade audits. The model presupposes a permissioned blockchain ecosystem (i.e., regulated consortium of reliable nodes inside enterprise scope), since public blockchain generally creates latency and privacy expenses that are unwarranted in the corporate world. We are not commenting on decentralized peer-to-peer networks, public blockchain integration, and blockchain-native distributed applications. Moreover, we will only assess the system in the context of simulation or in a testbed, and the actual implementation of the system in a production setting and extensive field experiments are not part of the current work, but are noted as future research.

Our contribution is novel in multiple ways. First, to the best of our knowledge, there exists no publicly documented framework that coherently merges and empirically validates adaptive ML-based threat prediction, blockchain-based tamper-proof audit, and multi-layer threat mitigation tailored for enterprise networks. Second, as predictive analytics and automated mitigation are integrated within the realm of blockchain governance, the H-BARM model provides both proactive and reactive security, which has more preventive potential and is more accountable than traditional IDSs or logging-only schemes. Third, we offer evidence of practicality by the thorough assessment of realistic network scenarios as indicated by mitigation latency, resource overhead, and scalability, hence providing a blue print to enterprises that intend to deploy solutions. Fourth, we share an architectural design and an evaluation methodology (where available) in an open source, thus providing a testable, expandable base for future studies and practices.

At a high level, our approach is as follows: we take into account multi-dimensional data (network traffic logs, host-level logs, metrics of user behavior) and process them through a feature-extraction and risk-assessment pipeline, where an adapted ML/AI model delivers a changing cyber-risk score. Once the risk score reaches some levels, the on-chain governance based on permissioned blockchain provokes the appropriate mitigation policies: e.g., network-level traffic blocking or isolation, host-level quarantine, application-layer access revocation, or user-level restrictions on their behavior. All detected events, decisions and mitigations are recorded on-chain with immutability, auditability and forensic trace. Simultaneously, the results of mitigation feedback are recorded and may be used to retrain or refine the risk prediction model and allow adaptive learning throughout the process.

Our findings are anticipated to be significant in a variety of ways. In the case of enterprises, this hybrid model can significantly improve security posture through the proactive prediction of threats, responding to them rapidly and in a layered manner and creating audit trails that cannot be tampered with, hence reducing the response time of an incident, minimizing the impact of breaches and ensuring adherence to regulatory requirements. Academically, the suggested H-BARM model adds a new conceptual and practical paradigm to the intersection of blockchain security, AI-based cyber-risk analytics, and multi-layer defense, which would provide the basis of future studies, extensions and real-world applications.

All basic components of the proposed framework, including the structure of the permissioned blockchain network, the feature extraction pipeline, model hyperparameters and evaluation scripts, have been documented and, where feasible, aligned with publicly available data to help in reproducibility and transparency. Its system architecture will be modular, meaning that the researchers will be able to replace datasets, models, or consensus mechanisms without making any changes in the workflow logic. Configuration files hold experimental parameters, simulation environments, and sets of mitigation rules to be able to recreate deterministic reruns of the same condition. In the cases where proprietary limitations do not allow the publication of raw enterprise logs, synthetic and statistically representative datasets are offered so that the methodology and findings can be verified or extended or benchmarked in future research.

The remaining part of this paper has the following structure. Section 2 discusses the literature, summarizing the efforts of previous researchers in the field of blockchain-based security, ML/AI-based threat detection, and mitigation frameworks, as well as pointing out their drawbacks. Section 3 explains our proposed methodology, threat model and detailed design of the hybrid system. The result of implementation is described in Section 4. Section 5 is part of the discussion, and it proceeds to discuss performance, security, limits, and possible extensions. Finally, Section 6 is the conclusion of this paper and the description of the further directions of work.

2. Literature Review

Enterprise cybersecurity as a field has significantly increased in volume over the last 10 years, owing to the increasing complexity of the attack surface, the expansion of the digital presence, and the continued development of the advanced cyber-threats. The primitive systems were more or less on perimeter-based defenses and signature-based intrusion detection systems around which a known attack was compared with a known rule or libraries [19]. They proved ineffective with generic dangers, whereas they proved to be useful with generic threats, when confronting polymorphic malware, zero-day assaults or even socially engineered assaults, which progressed rapidly such that signature databases could not keep pace with them [20]. The increasing mobility and decentralization of enterprise networks were gradually making the fixed models of defense an insufficient factor.

More recent is the tendency of machine learning and artificial intelligence methods being developed as more adaptive solutions. Several studies have been carried out in anomaly-based intrusion detection when abnormalities exist in normal traffic patterns or user behavior, and this is referred to as suspicious [21]. They are random forests, support vector machines and deep neural networks, which are classification techniques that have been widely studied in order to detect malware, classify traffic and provide a warning of threats beforehand [22,23]. Though most of these models exhibit good performance in the controlled testbeds, they exhibit challenges in implementation in the real enterprise environment. Problems with reliability and trust include data sparsity, sample imbalance between benign and malicious, adversarial manipulation, and explainability [24,25]. In addition, other studies record that ML-based systems can degenerate over time provided they are not retrained on live data streams [26].

Simultaneously with the development of AI-controlled security, blockchain technology has become a topic of interest as a tool of reinforcing trust, integrity, and traceability in cybersecurity systems. The immutable ledger features of blockchain render it appropriate in the storage of sensitive data like audit logs, device identities, and access transactions [27]. A number of publications show blockchain-supported authentication systems in which a distributed consensus is not dependent on a single trusted party [28]. Enterprise-specific permissioned blockchain also has been suggested to support internal communication and identity management, as well as providing tamper-proof incident tracking [29,30]. Although they have these benefits, other implementations are faced with scalability issues, operational latency, and storage overhead, particularly when handling large volumes of security telemetry [31].

Several hybrid products that seek to combine AI-based analytics with blockchain-based integrity mechanisms have been developed in recent years. As an illustration, some researchers suggest blockchain as a safe information-sharing scheme of intrusion detection systems spread over various network domains [32]. Other researchers combine blockchain smart contracts to automate security-response policies on the results of machine learning inference [33]. Nevertheless, most of these solutions are proof-of-concept prototypes and have not been tested in the real world of actual business enterprises, where heterogeneous devices, old systems, compliance, and high volumes of traffic add further operational limits to the solution [34]. Also, the literature tends to emphasize either the detection or auditability instead of providing a comprehensive framework of prediction, response, and governance.

The studies devoted to the multi-layer threat mitigation are relatively few. Network traffic monitoring or endpoint protection has been the primary focus of most security models, but there are very few models that include layered defense semantics such that network-level filtering, host-level quarantine, application access revocation and user behavior restriction are coordinated systems [35]. Certain models seek to automate mitigation based on security orchestration applications and policy engines [36]. Nonetheless, such systems do not receive much support from predictive cyber-risk scoring and are usually handled manually by humans, which are not fast to respond to a fast or automated threat [37]. Moreover, there is a concern regarding the accountability and non-repudiation of sensitive or classified information due to the absence of credible audit trails in such systems, especially when such data must be subjected to regulatory standards [38].

A number of literature reviews point to fragmentation, with blockchain security, predictive analytics and automation of mitigation developing in the literature as separate research streams [39,40]. The lack of coherent architectures restricts interoperability and usually causes brittle systems, slow systems or systems with too narrow a focus of operation. Although recent schemes propose adaptive risk scoring schemes depending on a variety of telemetry data, such as user identities, environmental context, and external threat information, most of them do not combine these scoring schemes with decentralized trust or live mitigation procedures [41]. In addition, transparency and explainability are not solved. The use of machine learning predictions without explanations that can be interpreted by a human creates pressure on adoption in enterprise environments where security analysts are unwilling to accept automated responses unless they have justifications [42].

The issues that blockchain-based research streams have not solved yet are also unresolved. Immutable ledgers guaranteed data confidentiality, latency of consensus, resource utilization and governance complexities that impose sufficient reservations on enterprise adopters [43]. Other suggestions include simply hashing identifiers or model decisions and storing the raw data off-chain so as to minimize storage overhead and maintain privacy [44]. However, these methods are promising, introduce complexity in architecture and necessitate the use of synchronization to make sure that there are traceability and consistency between the on-chain metadata and the off-chain storage systems [45]. In addition to this, the majority of blockchain-security research uses small-scale, controlled networks that might not be representative of enterprise conditions such as VPN segmentation, cloud-hybrid systems, or operational technology systems that are integrated with IT infrastructure [46,47,48,49,50,51,52,53,54].

Table 1. Comparative review and gap analysis of recent AI–blockchain cybersecurity research.

S. No.	Reference	Focus Area	Method/Tools	Key Findings	Limitations	Relevance
1	[1] Dhanda et al., 2025	Hybrid AI + blockchain security	ML-based intrusion detection + permissioned blockchain logging	Improved detection accuracy and trusted audit trails	No adaptive risk scoring or multi-layer mitigation	Forms baseline hybrid approach extended in this study
2	[2] Rahman et al., 2024	AI-driven risk management with blockchain	Risk scoring + blockchain-backed evidence tracking	Better visibility of evolving risk posture	Focus on monitoring, lacks real-time threat response	Supports motivation for adaptive mitigation framework
3	[5] Chahid et al., 2025	IoT hybrid IDS with blockchain	ML classifiers + blockchain-secured alerts	Higher resilience and integrity of alerts	Limited to IoT scope; no enterprise-level layers	Demonstrates feasibility but not scalable to enterprise context
4	[6] Kamran et al., 2024	Adversarial-resistant anomaly detection	Hierarchical ensemble learning	Robust multi-anomaly detection	Focus on protecting blockchain layer only	Inspires robustness, but lacks full system integration
5	[14] Sharadqh et al., 2023	Blockchain-enabled bi-level IDS	Graph-based mitigation + smart contracts	Coordinated response and reduced attack impact	Fixed mitigation rules; no adaptive prediction	Relevant to mitigation automation direction explored in this work
6	[8] Goundar et al., 2025	Real-time AI–blockchain security	AI detection + permissioned blockchain	Reduced detection latency and tamper-proof audit	No cyber-risk quantification or layered defense	Closely aligned and informs architectural decisions
7	[31] Ullah et al., 2024	General hybrid AI–blockchain concept	Anomaly detection + distributed record keeping	Enhanced trust in threat intelligence sharing	Mostly conceptual with limited evaluation	Highlights research trend our work operationalizes
8	[33] Ali et al., 2025	AI-based cyber-risk assessment	Multi-source ML-driven risk scoring	Improves prioritization of defensive measures	Lacks blockchain trust layer and mitigation pipeline	Addresses risk scoring gap but missing secure execution layer

indicates the increasing popularity of the integration of artificial intelligence and blockchain to enhance cybersecurity in various settings, including IoT systems and distributed cloud platforms. Although a number of contributions are showing how to improve intrusion detection accuracy, tamper-proof auditability, and distributed decision-making, the vast majority of approaches are limited to one of the isolated components of detection, trusted logging, or risk assessment. All of the reviewed articles lack an integrated and adaptive architecture, which simultaneously offers dynamic cyber-risk prediction, immutable security governance, and coordinated multi-layer mitigation in an enterprise network environment. In addition, scalability, real-time response, guarantees and operational validation (typical of an enterprise) are either not fully examined or discussed at conceptual levels. The identified gaps aid the necessity of a single, rollable, and risk-sensitive hybrid model—one that has the ability to unify predictive analytics, blockchain assurance, and orchestrated mitigation into an integrated security system. The proposed work fills this gap by targeting the mentioned gaps and moving the field closer to practical and sustainable enterprise cybersecurity.

The limitations observed throughout the discussed AI to blockchain models of cybersecurity, including predetermined mitigation policies, no risk estimates’ adaptation, and no integrated multi-working enforcement, demonstrate the necessity of a unified governance-conscious structure of mitigation applicable in an enterprise setting. The identified gaps are addressed in the suggested AGML architecture that involves the integration of continuous prediction of cyber-risks with blockchain-certified mitigation logic and the cross-layer enforcement functionality to enable auditable and proportionate threat response in heterogeneous enterprise architecture.

The gap in these fields of inquiry brings one back to the same line that the fragmented characteristics of the cyber-risk adaptive predictions, the time-based multi-layer, and the audit-resistant enterprise-ready conditions have not been assimilated into a practical, organized, and empirically tested hybrid paradigm. There is a limited number of studies that combine all three pillars of prediction, mitigation and immutable accountability in the ecosystem. Enterprise threats are getting increasingly sophisticated, and regulatory requirements are ever-increasing; thus, solutions that only detect or only record are no longer viable. The literature suggests that the research now enters the transition phase where it is shifting to deployable and resilient security structures but still a large gap in maturity exists.

3. Methodology

The suggested methodology is based on the philosophy of the layered and modular design, which is characteristic of the work of the enterprise networks in the heterogeneous conditions and changing threat behavior. The framework incorporates detection, response and verification as one continuous loop instead of treating them as individual capabilities, and this cycle includes data acquisition, adaptive predictive cyber-risk, permissioned blockchain governance and multi-layered mitigation orchestration. The components exchange their data and collaborate with one another using specific data streams and execution logic mediated by smart contracts. This section outlines the architecture, workflow and computational models and evaluation logic.

These two priorities led to the methodological decisions adopted in this work to be operational feasibility in an enterprise setting and capability to keep up with the changing conditions of cyber-risks. The proposed hybrid architecture had several other design paths before it was finalized. As one example, conventional rule-based IDS models, as well as statistical anomaly detection models, can be interpreted, but novel attack strategies and large-scale behavioral variability are difficult to handle. Transformers and graph neural networks as the deep learning architectures were considered, but their computational load and their inability to explain the results were not as feasible in a real-time decision cycle where accountability was needed. Similarly, having all the telemetry and model outputs stored in a public blockchain would guarantee the highest level of decentralization, but latency, cost and privacy barriers hindered enterprise applications. As a result, the approach takes on a permissioned blockchain design, which balances trust assurance with performance effectiveness, and a lightweight and flexible learning engine that can generate an ever-evolving cyber-risk score as opposed to a binary alert. The originality of the design framework is that these options are intentionally converged, namely, machine learning-based predictive security, immutable blockchain-backed governance and coordinated multi-layer mitigation exploited as a single closed-loop system. Combined with the absence of response from detection, and accountability from automation, up to this point, this is the guarantee that detection should not exist independently of response, and accountability should not exist independently of automation—the latter is essential in the current studies and required in the contemporary enterprise cybersecurity.

3.1. System Architecture Overview

The suggested framework is designed as an enclosed system of security fabric that connects the information gathering process, adaptive risk analytics, blockchain-based governance, and multi-layer mitigation in a unified operations pipeline. Instead of treating intrusion detection, logging, and response as disconnected tools, the architecture couples them through well-defined data and control paths that can run on typical enterprise infrastructure (e.g., containerized services on a private cloud or on-prem cluster). At a high level, the design separates a concern into a data plane for telemetry and inference and a control plane for policy validation and enforcement.

As illustrated in Figure 1, the architecture is organized into four main subsystems:

(i)

Telemetry and Data Interface;

(ii)

Cyber-Risk Prediction Engine;

(iii)

Permissioned Blockchain and Smart-Contract Layer;

(iv)

Multi-Layer Mitigation and Policy Orchestrator.

These building blocks interact by the use of message queues and authenticated APIs in such a way that the system can be scaled horizontally and be resilient should there be overloads or temporary unavailability of individual services.

Figure 1. High-level architecture of the proposed hybrid blockchain model for adaptive cyber-risk prediction and multi-layer threat mitigation.

Figure 1. High-level architecture of the proposed hybrid blockchain model for adaptive cyber-risk prediction and multi-layer threat mitigation.

The Telemetry and Data Interface is placed on top of the enterprise infrastructure. Lightweight collectors are placed on strategic locations: network sensors on core switches or firewalls, agents on critical servers and endpoints, a connection to identity and access management (IAM) systems to obtain authentication logs, and connections to the application gateways to obtain API-level traces. Along with basic statistics (flow durations, request rates), derived features (entropy of destinations, failed-logins ratios), and contextual tags (asset criticality, user role), feature vectors are compact and expressed in the form of a few feature vectors. It is selected as a design instead of raw-log ingestion due to three reasons: it stores less, the normalization process is simplified when there are heterogeneous sources, and it supports inference with low latency, which is feasible within production networks.

The analytic core of the data plane is made up of the Cyber-Risk Prediction Engine. It runs as a stateless inference service (e.g., behind an HTTP/gRPC endpoint) in order to be scalable to more instances in the case of traffic increases. Batched or streamed incoming feature vectors are processed by a preprocessing layer then assessed by the trained model, which remains a risk score R(t) continuously instead of an attack/no-attack label as it is formalized later in (1)–(2). This decision is not without purpose: numerous enterprise attacks become strong in several minutes or hours, and indications are first undetected.

The system of continuous risk score enables the surface of soft anomalies without flooding operators with the hard alarms. The engine also calculates auxiliary indicators, i.e., confidence and type of suspected behavior (e.g., lateral movement, credential abuse) which are part of structured metadata to make downstream decisions.

As soon as the risk score reaches certain limits, the control is transferred to the Permissioned Blockchain and Smart-Contract Layer. This layer is a small consortium ledger established within the enterprise trust boundary, and the validating peers are deployed on hardened servers in other segments (e.g., security operations, compliance, core IT). Instead of recording feature snapshots, risk scores and chosen mitigation decisions on-chain, the system takes hashes of these. This provides every security decision a time-stamped, tamper-resistant footprint that is not too large to fit in the ledger and does not reveal raw telemetry that is sensitive. Smart contracts specify simple yet explicit policies: depending on a combination of risk state, affected asset type and confidence level, which template of mitigation is supposed to be invoked and whether human approval is necessary are determined. The choice of permissioned consensus is due to the fact that it has predictable commit latency, governance that is easy to control, and that it is simpler to integrate with corporate PKI and access-control policies.

Verified decisions are postulated to the Multi-Layer Mitigation and Policy Orchestrator that resides at the interface between the control plane and the current security tooling. This component is not a monolithic super firewall but merely transmits specific instruction to current enforcement points by accessing their own APIs. At the network layer, it can ask an SDN controller or firewall to drop certain flows or restrict ACLs around a subnet or just temporarily relocate a host to a quarantine VLAN. It communicates with endpoint protection or EDR agents at the host layer to kill suspicious processes, block binaries, or become more restrictive on its part. It interacts with API gateways and identity providers at the application layer to revoke tokens, invalidate sessions, or step-up authentication. At the user/identity layer, it can lead into temporary downgrades of privileges or additional controls on accounts that are deemed to be high risk. The administrators cannot easily pass or delete events of mitigation because all the actions are mediated and recorded with the help of the blockchain layer.

After every mitigation episode, there is an outcome data, e.g., whether malicious activity was mitigated, whether there were other alerts or whether the action led to false alarms, summarized and returned to both the blockchain metadata and feedback queue to the Cyber-Risk Prediction Engine. The feedback is used during the periodical retraining process to change thresholds, re-weight features and fine-tune model decision boundaries that have the effect of making the system less noisy and more discriminating over time. In this manner, the architecture will be dynamic: it will continuously adapt to the ever-evolving threat environment, as well as to the behavioral patterns of the organizations themselves, even though it will have high integrity and will be highly traceable by the ledger.

In general, this architecture was chosen because of considering other patterns like centralized SIEM-only analytics, pure AI-based anomaly detection without blockchain, and blockchain-only logging without predictive modeling. The limitations of centralized SIEM designs were their scalability and single-point-of-failure issues, AI-only designs lacked reliable auditability, and blockchain-only designs could only be responsive and did not have any predictive capability. The hybrid approach adopted in Figure 1 integrates the advantages of each of the paradigms, i.e., fast analytics, verifiable governance, and coordinated multi-layer action, into a unified approach that is optimized to enterprise networks.

3.2. Data Acquisition and Feature Engineering

The data engineering workflow is created to make sure that the cyber-risk prediction model has regular, time-synchronized and behaviorally significant inputs and that the system can be deployed in reality with an enterprise setting. The entire pipeline, including the raw telemetry to model-ready input, is shown in Figure 2.

In order to enable reproducibility, all preprocessing parameters, normalization ranges, and feature-window definitions are configurated as opposed to being hard-coded.

3.2.1. Telemetry Sources and Structured Ingestion

This helps to reduce noise and overheads and maintain forensic continuity. In order to formalize ingestion logic, every stream of telemetry Di(t) is modeled (1):

$$D_i(t)=\left\{\begin{array}{c}emit\left(E_i\right(t\left)\right), if {\delta }_i\left(t\right)\ge {\gamma }_i\\ \varnothing , otherwise\end{array}\cdots \right.$$

(1)

In the notation Ei(t) = the raw event snapshot by source i, 8i(t) = the measure of deviation (e.g., the spike in the number of login failures, the bursts of packets), and 8i = the threshold of deviation or signal of an alert. Equation (1) is used to make the system responsive even when there is heavy traffic without jeopardizing the threat coverage. Thresholds γ_i are tuned per environment during deployment.

3.2.2. Preprocessing and Time Alignment

Gathers of telemetry data may come in with random times, or multiply their entries. There is a preprocessing step that gives the structural validation and temporal alignment. In the normalization of time-series inputs, every event timestamps tr is normalized with (2):

$$t^{\prime }=t_r-t_{ref}\cdots$$

(2)

where tref is a synchronized NTP anchor. This model renders the system resistant to the distributed sensor timing drift. In duplicate detection, the following hash-based matching function (3) is used:

$$H\left(E_i\right(t\left)\right)=SHA256\left(E_i\right(t\left)\right)\cdots$$

(3)

Duplicate records with the same hash in a sliding duplicate window are deleted. This prevents the artificial density spikes that might affect the score of anomalies.

3.2.3. Feature Engineering and Behavioral Encoding

The feature extraction is the transformation of structured telemetry into behavior-meaningful measures. Features are pattern deviations, escalation behaviors or contextual inconsistencies instead of crude packets or logs. The representative features are represented in

Table 2. Representative engineered features and associated security relevance.

Layer	Example Feature	Detection Role
Network	Destination entropy	Indicates lateral reconnaissance
Host	Privilege/escalation ratio	Signals possible compromise
Identity	Login failure slope	Tracks credential attack attempts
Application	Token reissue frequency	Flags automation or hijacking

.

To measure the deviation of behavior, a specific attribute xj(t) is then contrasted with a learned baseline μj, against which the value is then given a normalized value of an anomaly intensity (4):

$$A_j(t)={\displaystyle \frac{\mid x_j\left(t\right)-{\mu }_j\mid }{{\sigma }_j+ϵ}} \cdots$$

(4)

where σj = the historical variance for feature j, and ϵ avoids the division by zero. This formulation ensures stability and supports deployment across different environments with distinct operational baselines.

3.2.4. Normalization, Temporal Structuring, and Model Input Packaging

Prior to inference, numerical features are scaled using min–max normalization using (5):

$$x{j}^{\prime }\left(t\right)={\displaystyle \frac{x_j\left(t\right)-x_j,min}{x_j,max-x_j,min}}\cdots$$

(5)

Protocol or user roles are categorical values and are represented using embeddings to maintain the hierarchical meaning and to avoid dimensional explosion. Cyber incidents rarely manifest instantaneously; therefore, model inputs are structured as temporal sequences using (6):

$$F\left(t\right)=\left\{x^{\prime }\left(t-W\right),x^{\prime }\left(t-W+S\right),\dots ,x^{\prime }\left(t\right)\right\}\cdots$$

(6)

where W = the sequence window length, and S = the stride interval. Equation (6) ensures continuity and supports prediction rather than post-fact detection.

3.2.5. Integrity Anchoring for Blockchain Governance

Prior to inference, a cryptographic digest of each sequence of features F(t) is generated by (7):

$$\eta \left(t\right)=SHA256\left(F\right(t\left)\right)\cdots$$

(7)

It is the data which is not sent to the ledger but only η(t) which is logged during blockchain logging. This ensures that there is traceability, and sensitive enterprise telemetry is not compromised, which helps to maintain compliance with the validation of events that occur. It is a relatively simulated method that is the reverse of the earlier study to combine occasion-conditioned information emission, time-based conduct encoding and blockchain-provable preprocessing art into a distinctive repeatable process. The ingestion, normalization, deviation scoring and hashing equations enable deployments to be deterministic, measurable and auditable that are important attributes of reproducibility and adoption by the enterprise.

3.3. Cyber-Risk Prediction Model

The cyber-risk prediction model is the analytical core of the framework, which subsequently reduces the engineered feature sequences to a continuous cyber-risk value R(t) as the measure of the severity of the threat at a given time, and the behavioral pattern of the same. As opposed to other conventional IDS and anomaly detectors, which give binary results (attack vs. benign), the model is capable of encoding threat state by delivering a moving, dynamic probability curve, which can be used to provide early escalation and proportional mitigation decisions.

The model is a lightweight hybrid framework that consists of anomaly scoring and supervised classification. This two-way computation allows the system to identify not only established attack patterns but also the new ones that have never been seen before. The structured input F(t), which is produced by means of Equation (6), is first fed through an anomaly scoring branch, which calculates latent deviation behavior. The score Sa(t) is an anomaly, and it is computed by (8):

$$S_a\left(t\right)=\parallel F\left(t\right)-F^t{\parallel }_2\cdots$$

(8)

F (t) is a reconstruction of F (t) using a small auto encoder that is trained on normal operational baselines. The ℓ2 norm is used, so that the sensitivity to subtle behavioral variations is obtained, but excessive noise amplification is not observed. Simultaneously, the supervised branch estimates the possibility of an attack with a trained classifier, which yields a probability result Pc(t). Graph-based embeddings and transformer encoders are examples of multiple architectures that were first compared. Nevertheless, the last model uses a lightweight recurrent architecture that uses gated recurrent units (GRUs) since it showed the most optimal balance between inference latency, interpretability, and time awareness. The output of the classifier can be represented as follows:

$$Pc\left(t\right)=f\theta \left(F\left(t\right)\right)\cdots$$

(9)

where fθ(.) indicates the trained GRU-based inference function, where θ₀ is learnable. The final score on cyber-risks is calculated by fusing the signal of anomaly and classification through a weighted fusion mechanism (10):

$$R\left(t\right)=\alpha \cdot \sigma \left(Sa\right(t\left)\right)+(1-\alpha )\cdot Pc\left(t\right)\cdots$$

(10)

where σ(.) is a normalizing hugging, especially to normalize anomaly data to the range [0, 1], and is a dynamically changing weight coefficient. The value of coefficient α is not fixed, but it changes according to the confidence feedback due to reinforcement signals that were observed during the past mitigation. This design will help in making sure that, with the normalization of the system, the emphasis of the system changes gradually to detect anomalies and classify them. The rule of updating of α can be written as (11):

$${\alpha }_{t+1}={\alpha }_t+\lambda \cdot \left(e\right(t)-{\alpha }_t)\cdots$$

(11)

At the learning rate λ, e(t) is the stimulus of learning success, learning failure, or partial match of model decision with the actual outcome. In order to be reproducible, all the model components, such as the training data distribution, the hyperparameters, the normalization ranges, and the reinforcement adjustments, are logged into version-managed metadata, and configuration snapshots are anchored with digests that are stored in the blockchain in the context of Section 3.2.5. The output of a soft-threshold mechanism is the translation of the continuous score into the operational states instead of binary alerts. The thresholds T1NT2NT3 are used to define the system to be in normal operation (R(t) < T1), suspicious or early escalation (T1 = R(t) < T2), probable compromise (T2 = R(t) < T3), and confirmed critical threat (R(t)T3). This model is novel in three ways: (1) the continuous risk scoring, as opposed to discrete risk alerts, in favor of early weak-signal detection; (2) the adaptive fusion of anomaly and supervised learning paths, to allow the model to self-correct as the behavior changes; and (3) the blockchain-based reinforcement feedback, to ensure transparent, auditable and tamper-resistant risk scoring improvements. This architecture ensures that the cyber-risk prediction model is a learning risk assessor as opposed to being a fixed intrusion classifier, but it is the foundation of the adaptive, closed-loop cycle of defense, which is being executed by the proposed architecture.

In this formulation, Equation (10) combines the behavioral deviation score that is produced by anomalies and the supervised classification probability to achieve a normalized estimation of cyber-risk that is based on both latent anomalies and probabilistic threat likelihood. By adaptively updating the fusion weight 1 with the reinforcement feedback of the mitigation results, Equation (11) makes the model dynamically balance the sensitivity of the anomaly and the confidence of the classification in terms of varying enterprise threat trends.

3.4. Blockchain Governance and Smart-Contract Execution Layer

The Blockchain Governance Layer offers the trust, auditability and enforcement logic that binds the result of cyber-risk prediction output R(t)R(t)R(t) with the authorized mitigation decisions. It is not designed to store telemetry or act as a cryptocurrency ledger, but as a control fabric that is tamper-resistant, and such that all security decisions are verifiable and immutable and beyond the control of an unauthorized party. There is also no chance of privileged insiders (who have been known to cause some of the most destructive breaches) altering or blocking the mitigation activities in this layer.

This layer is implemented as an authorized blockchain environment, with validating nodes being managed by separate organizational areas (e.g., the security operations, IT compliance, DevSecOps, identity governance). This division is consistent with the principles of zero-trust governance and eliminates the one-way rule of any administrative domain over the system. The consensus mechanism is based on the Practical Byzantine Fault Tolerance (PBFT) protocol instead of Proof of Work or Proof of Stake, deterministic validation delay, and predictable throughput (both are essential in real-time security automation).

3.4.1. Risk Score Commit and State Recording

All calculated risk values are stored on-chain in the form of a miniature transaction record. Rather than storing raw telemetry or prediction vectors, the system commits a structured tuple using (12):

$$\Psi \left(t\right)=\left(R\right(t),\eta (t),C(t),\tau (t\left)\right)\cdots$$

(12)

where R(t) = the continuous cyber-risk estimate from Equation (10), η(t) = the feature-bundle hash from Equation (7), C(t) = the classifier confidence or classification label, and τ(t) = the timestamp normalized using Equation (2). This record makes sure that all decisions can be cryptographically traced to the structured representation of features that was utilized at inferring time—without the disclosure of sensitive information. A blockchain agreement is used to verify and add Ψ(t) to the distributed ledger, and no alteration of it is allowed after the prediction step. The ledger then emerges as a time-based trust source of dynamic enterprise threat posture.

3.4.2. Smart-Contract Policy Model

When a new entry to the blockchain is validated, a routine of smart-contract execution decides to issue a mitigation measure and at what level. Mitigation logic smart contracts store mitigation logic in the form of condition action rules based on the risk score levels established above. Smart-contract logic can be abstractly expressed formally as (13):

$$\mathrm{\Omega }\left(\mathrm{t}\right)=\left\{\begin{array}{c}\mathrm{n}\mathrm{o} \mathrm{a}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\hspace{1em}\mathrm{i}\mathrm{f} \mathrm{R}\left(\mathrm{t}\right)<{\mathrm{T}}^1\\ \mathrm{m}\mathrm{o}\mathrm{m}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r},\hspace{1em}\mathrm{i}\mathrm{f} {\mathrm{T}}^1\le \mathrm{R}\left(\mathrm{t}\right)<{\mathrm{T}}^2\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r},\\ \mathrm{r}\mathrm{e}\mathrm{s}\mathrm{t}\mathrm{r}\mathrm{i}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{v}\mathrm{e} \mathrm{m}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{g}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\hspace{1em}\mathrm{i}\mathrm{f} {\mathrm{T}}^2\le \mathrm{R}\left(\mathrm{t}\right)<{\mathrm{T}}^3\\ \mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l} \mathrm{i}\mathrm{s}\mathrm{o}\mathrm{l}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\hspace{1em}\mathrm{i}\mathrm{f} \mathrm{R}\left(\mathrm{t}\right)\ge {\mathrm{T}}^3\end{array}\right.\cdots$$

(13)

With the mitigation states being associated with increasingly tougher degrees of security enforcement. This deterministic rule-based representation is carefully designed to be deterministic, to ensure that decisions can be described and accept audit. To obtain accountability and avoid unilateral overrides, each execution of a contract produces a digitally signed decision receipt (14):

$$\sigma \left(t\right)=Sig{n}_{kvalidator}\left(\Omega \left(t\right),\Psi \left(t\right)\right)\cdots$$

(14)

where kvalidator is the personal key of the validating node. The receipt ensures the provenance of the mitigation trigger, and it constitutes the trail of evidence in the regulatory or internal governance audit.

3.4.3. Action Authorization and Conflict Prevention

One of the most challenging problems with automated mitigation is to avoid conflicting or duplicate responses—and this is mainly when multiple tools are trying to enforce security at the same time. The blockchain layer deals with this, such that there is no mitigation unless the smart contract provides an authorization token (15):

$$\Theta \left(t\right)=H\left(\sigma \left(t\right)\right)\cdots$$

(15)

The mitigation engine (Section 3.5) is set to disregard any enforcement request that is not accompanied by a valid Θ(t), so that the mitigation can be performed by authenticated blockchain-based government only.

3.4.4. Hyperparameter Configuration and Governance Tuning

Despite the deterministic nature of the implementation of the Blockchain Governance Layer, there are a number of hyperparameters at the configuration level that determine responsiveness, trust assumptions, and operational behavior. Such values are not optimized through stochastic mechanisms such as machine learning, but are empirically adjusted to achieve a balance between latency, auditability, and risk sensitivity. Some hyperparameters of the blockchain governance layer are summarized in

Table 3. Hyperparameter configuration parameters for blockchain governance tuning and operational responsiveness.

Hyperparameter	Symbol	Role	Selected Configuration	Rationale
Validator quorum threshold	Qv	Minimum validator approvals required before decision commit	0.66 majority (PBFT)	Ensures tamper resistance without excessive delay
Smart-contract evaluation cycle	Δc	Time spacing between contract executions	1–3 s	Prevents repeated triggering storms during high-frequency events
Risk-to-action sensitivity factor	β	Determines slope of response escalation	0.35–0.55	Allows controllable transition zone between mitigation tiers
Enforcement retry limit	ρ	Maximum retry attempts if enforcement fails	2 attempts	Avoids infinite loops while improving enforcement reliability
Ledger write compression window	Γ	Batching window for combining similar transactions	5–10 events	Reduces ledger congestion under peak traffic

, with configuration roles, chosen operational ranges, and justification, depending on the requirements of deployment.

The parameters of tunable governance used in the blockchain layer are provided in Table 3, as a replicable reference, which can be deployed, audited, and optimized in future investigations. To formalize the tuning dependencies, the governance response delay Lg may be expressed as (16):

$$Lg=T_{consensus}\left(Qv\right)+T_{exec}\left(\Delta c\right)+T_{audit}\left(\Gamma \right)\cdots$$

(16)

where Tconsensus(Qv) represents PBFT validation latency based on required validator agreement, Texec(Δc) captures smart-contract scheduling overhead, Taudit(Γ) models ledger-write batching overhead. Similarly, the aggressiveness of mitigation execution can be parameterized as (17):

$$A_g=\beta \cdot \left(R\right(t)-T_{mid})\cdots$$

(17)

where T_mid is the midpoint between mitigation thresholds. The higher the β, the sharper the transition into defensive actions. The lower the 2-value, the more benign the escalation curves can be used (e.g., DevOps or dynamic cloud workloads). These hyperparameters can be modified through governance policy files instead of being hard-coded into blockchain logic in order to have long-term ability to change. Any change prompts a signed change in configuration that is stored on-chain, which would ensure audit transparency and reversible traceability in the event of compliance verification.

Table 3 shows that the hyperparameters have a direct effect on the operational behavior in Equations (16) and (17). The validator quorum threshold Qv and batching window Γ are parameters that define the elements of the consensus and audit latency in the governance delay functionality, which affect the speed at which the blockchain validation can complete recorded risk choices. In the meantime, the sensitivity factor β 1 determines the escalation gradient in Equation (17), which is the influence on the transfer of the calculated risk score R(t) to mitigation strength. All these controls will provide a balance between the automation, traceability, and operational safety by keeping the governance process responsive to the changes in the threat but stable enough to prevent an over-reactive response to temporary changes.

3.4.5. Computational Feasibility and Resource Footprint

Even though AGML incorporates reinforcement learning and blockchain-based authorization, the design was made to be computationally inexpensive to apply in real-world applications. Inference on a single event stream during prototype testing took an average of 6–9% CPU and less than 210 MB RAM, and blockchain transactions have a medium workload through the lightweight PBFT configuration. Chain commit time did not increase with load due to the distribution of validator nodes, which were not numerically huge. In the deployment perspective, the framework does not demand the use of any GPU acceleration or scalable cluster scheduling, which is why it can be used with the current SOC infrastructure without significant hardware enhancements. This feature solves a chronic drawback experienced in previous AI-oriented cybersecurity pipelines where processing expenses make the approach impractical to apply.

3.4.6. Novelty and Reproducibility Considerations

There are two major innovations in this layer. First, blockchain consent is not just addressed as a logging tool but a governance gatekeeper, which cannot be used to make unauthorized or opaque mitigation, which is not an aspect of most AI-driven cybersecurity. Second, the robustness of integrating the equations that capture the risk scoring, hashing and the execution and the enforcement of the contract leads to the determination of a de-terministic and reproducible security workflow. All the stages are the print that cannot be erased, and this is the foundation of forensic analysis, recovery following an incident, and compliance with regulatory standards, such as National Institute of Standards and Tech-nology (NIST 800-53) [55] and information security management systems (ISO 27001) [56] and the concepts of the General Data Protection Regulation (GDPR) [57]. All these aspects contribute to the fact that blockchain is not a simple audit layer, but an enforcement mechanism, so that its machine-made security decisions will not lose their validity, trans-parency, and impossibility to change them.

The GRU-based classification module processes temporally structured feature sequences derived from telemetry inputs and produces probabilistic threat estimates used in cyber-risk fusion. Model inference is performed on normalized temporal feature windows as defined in Equation (6).

3.5. Multi-Layer Threat Mitigation System

The Multi-Layer Threat Mitigation System actualizes the last phase of the closed-loop defense cycle by converting blockchain-authenticated results into measured and systematic security measures. It is not merely trying to avoid badness, but rather it gradually implements sensitive response programs as they are proportional to the degree of the risk as indicated by the cyber-risk score R(t). The system provides a structure of enforcement in all levels of the network, endpoint, identity and application in a manner that mitigation is focused, auditable and reversible to avoid unnecessary interference and adversarial increment.

3.5.1. Enforcement Model and Decision Mapping

The mitigation actions are motivated by the decision state Ω(t) of the smart-contract logic of Equation (13). To make the behavior in heterogeneous infrastructure consistent, actions are formalized in a set of templates of standardized enforcement. These templates specify the scope, the point of execution and the roll back logic that provides consistency across deployments. The choice-to-act map is illustrated as (18):

$$M\left(t\right)=g\left(\Omega \left(t\right),\Theta \left(t\right)\right)\cdots$$

(18)

In which, Ω(t) is the decision output of Equation (13), Θ(t) is the blockchain authorization token of Equation (15), and g(SU) is a solver of the abstract decision into enforcement instructions in the layer. In the event that Θ(t) is invalid, out of date or unavailable, the mitigation is rejected—with governance-controlled enforcement.

Equation (18) translates validated mitigation states into executable enforcement instructions across coordinated security layers.

3.5.2. Layer-Specific Mitigation Execution

After authorizing, the mitigation controller converts the validated response state into real enforcement activities then into four synchronized operational domains. In the control layer, temporary ACLs, SDN flow quarantine, rate limiting or lateral-movement blocking are implemented by firewalls or SDN controllers implemented as software. EDR agents can suspend suspicious processes, limit access to the file system, or isolate compromised devices into controlled VLANs at the host and endpoint layer. The identity-level measures are the pausing of authentication tokens, re-authentication, or the temporary denial of higher privileges, to avoid abuse. Lastly, access keys can be revoked at the application and API tier, high-risk function calls can be throttled, or script-based bursts of requests can be slowed until further validation can be performed. The system takes advantage of native vendor APIs and currently existing enforcement mechanisms instead of replacing existing infrastructure, which allows this system to integrate seamlessly with the existing infrastructure and alleviates deployment friction while ensuring operational continuity.

3.5.3. Execution Stability and Safety Logic

The operational risk of automation happening through mitigation can happen when actions move fast. A safety rate-limiter is used to make sure that the frequency of its occurrence is not excessive to stabilize a frequency of high-impact actions. This is formalized as (19):

$$\mathrm{\kappa }(\mathrm{t})=\left\{\begin{array}{c}1,{if n}_{actions}\left(t\right)<\delta \\ 0, otherwise\end{array}\right.\cdots$$

(19)

We assume that the name of the recent events of enforcement is nactions(t), and that δ is an adjustable maximum. In the case of κ(t) = 0, only non-disruptive and monitoring controls are allowed, and no uncontrolled mitigation loops are allowed. Rollback procedures are also recorded within blockchain receipts in order to be able to ensure reversibility, transparency, and the compliance with the requirements of the continuity of operation.

3.5.4. Feedback and Reinforcement Metadata

After every mitigation event, the system measures the effectiveness of the system using the post-action behavioral changes during a brief observation period. Rather than manually confirming this, the framework calculates a reinforcement signal based on a pattern of deviancy, with a significant decrease in abnormal behavior being an indicator of successful intervention, a partial decrease indicating containment and no change indicating failure or false activation. This effectiveness score is then hashed and stored in the blockchain with the initial trace of action, so that all enforcement efforts can be audited and recreated. The metadata of the reinforcement then updates the adaptive tuning in the previous components, especially the weighting factor in the risk fusion model and the system then adjusts the response aggressiveness and decision threshold with time. By this process, the mitigation engine will no longer be a constant automation layer, but rather a learning operational layer, which will become increasingly perfect as it will expose itself to actual deployment.

3.5.5. Novelty and Practical Relevance

The newness of the suggested mitigation layer is in the fact that it does not follow the old method of automated response systems that are based on fixed playbooks or strict rule implementations. The system is built through adding blockchain-backed authorization, risk-responsive enforcement reasoning, reconfigurable safety controls and reinforced-based refinement, becoming an instrument of control and a constantly improving mechanism of security instead of a programmed defensive. This enables the justification of the mitigation measures and audit of their records, which are hard to alter without being sensitive to the unfolding situations. The framework is not just a scaling-up of firewalls or EDR tools as the reactive enforcement tools, but an expandable cyber-resilience mechanism, which works based on the results of its operations, aligns to evolving behaviors and is dynamically responsive to new risks in the enterprise infrastructure.

3.6. Operational Workflow and Proposed Algorithm

Besides the traditional SOAR or the rule-based automated response pipelines, the suggested system suggests a new closed-loop cycle, which is called Adaptive Governance-Driven Mitigation Loop (AGML), and risk calculation, policy verification, mitigation actions, and reinforcement learning interact within the frames of the trust restrictions introduced by blockchain. AGML enables executing no action to be performed on the basis of machine inference; all security decisions are cryptographically authorized, auditable and proportionately applied on the real-time behavioral evolvement basis. Adaptive characteristic is due to weighting changes through reinforcement, whereby the system adapts response granularity to changes across time as opposed to using fixed playbooks. The resulting loop is created not only to identify and prevent threats, but also to control, rationalize, and continuously optimize mitigation measures within dynamic enterprise settings. The outline of the high-level operation is presented in Algorithm 1 and the end-to-end flow is shown in Figure 3.

Algorithm 1. Adaptive Governance-Driven Mitigation Loop (AGML)

Input: Temporal feature sequence F(t) Output: Risk score R(t), validated action M(t), feedback update e(t) 1: Initialize α, thresholds {T1,T2,T3}, and governance parameters from Table 3. 2: while system_active do 3:   F(t) ← preprocess(telemetry(t))          //Section 3.2 4:   S_a(t) ← anomaly_score(F(t)) using (8) 5:   P_c(t) ← classifier_output(F(t)) using (9) 6:   R(t) ← risk_fusion(S_a(t), P_c(t), α) using (10) 7:   Ψ(t) ← construct_chain_record(R(t), η(t), C(t)) using (12) 8:   submit_to_chain(Ψ(t)) → await PBFT consensus 9:   if consensus_valid and Θ(t) issued then 10:     Ω(t) ← policy_resolution(R(t)) using (13) 11:     M(t) ← mitigation_mapping(Ω(t), Θ(t)) using (18) 12:     execute_mitigation(M(t)) under safety constraint (19) 13:     e(t) ← compute_feedback(F(t),Δ) using (20) 14:     α ← update_weighting(α, e(t)) using (11) 15:     store_feedback_hash(e(t)) 16:   else 17:     log_no_action_state(Ψ(t)) 18:   end if 19: end while

In the AGML framework, it brings a change to the previous models of automated response system and governance-conscious adaptive framework. The AGML runs at almost real time during runtime with a computational complexity that is estimated as (20):

$$O\left(AGML\right)\approx O\left(f\right(F\left(t\right)\left)\right)+O\left(PBFT\right)+O\left(m\right)\cdots$$

(20)

where O(f (F (t)) is the risk inference (hybrid anomaly + classifier), O(PBFT) is the consensus overhead, which is based on the validator quorum Qv, and O(m) is the cost of mitigation instruction dispatch and is constrained by safety constraint (19). This complexity is stable and limited, proving that the model can be deployed under the condition of high-volume streams of events without incurring exponential scaling penalties. This is a novelty because it has five characteristics that are integrated. To begin with, blockchain consensus checks all enforcement operations, courting against privileged misuse and governs decision-tamper-proof introduction. Second, the model is also based on the ongoing mindset of cyber-risk scoring as opposed to binary alerting, which enables actionable intervention before an attack is fully achieved. Third, the framework introduces weight adjustment through reinforcement, which allows the risk model to correct its behavior in the long-term depending on how successful previous mitigations were. Fourth, mitigation is relative and situation-specific in the network, identity, host and application layers, and does not always result in overreacting. Lastly, traceability, accountability, and compliance to regulations are enhanced by each mitigation event, and its impact is registered in an irrevocable manner, creating a channel of forensic feedback. By combining these factors, AGML stands out as a dynamic and responsible cybersecurity control mechanism as opposed to a conventional signature-based or rule-based automation engine.

The computational complexity expressed in Equation (20) reflects the combined operational cost of hybrid risk inference, PBFT-based consensus validation, and mitigation execution. This formulation provides an estimate of real-time system responsiveness under varying telemetry loads while maintaining bounded governance latency for enterprise-scale deployments.

The working process formalizes the system functionality and offers the disconnection between conceptual architecture and deployable logic. The joint credentials through blockchain, constant risk scoring and adaptive feedback of reinforcement differentiate the working process from the conventional framework of rule-based security automation. It can then be concluded that it is not merely a plug-and-play component of intrusion response, but a continuous process of security governance, which can shift as the attack trends, the corporate behavior and the outcomes of post-enforcement change with the dynamics of the attack waves.

Figure 3 shows the system-level operational workflow of the AGML system, which represents the exchange between telemetry-based ingestion, hybrid cyber-risk assessment, blockchain-controlled mitigation authorization, and adaptive feedback-based reinforcement of enterprise threat response.

3.7. Experimental Setup and Evaluation Framework

The AGML architecture was tested in a controlled hybrid pilot implementation, which reflects the conditions of enterprise deployment and guarantees reproducibility; the section is a description of the experimental setup in terms of dataset composition, source of telemetry, feature engineering, ground-truth construction, and deployment infrastructure, with which performance evaluation was performed. The architecture was made of a blockchain network with private cloud, smart contract layer, risk-inference-modules and mitigation controller alongside simulated enterprise endpoints, authentication services, IoT nodes and API-driven applications and was divided into on-premises segments as shown in Figure 4. It was all packaged and integrated with Kubernetes to create consistency, and the blockchain layer was a three-validator PBFT cluster to guarantee deterministic validation latency. The telemetry that was collected was the monitored data of Zeek network and OSQuery host events, authentication logs, and API traces, based on the type of features listed in Section 3.2. Regular working loads and the arrangement of adversarial loads (credential assaults, horizontal movement and exfiltration efforts, etc.) were also supported by the environment. It has tested its results on a three-phase model, that is, the baseline behavior, active-attack response, and post-mitigation stabilization, and measured it using the detection accuracy, operational efficiency, such as mitigation and consensus latency, and stability, such as false-positive sensitivity and reinforcement convergence. This setup also ensures realistic deployment behavior rather than idealistic lab inference of the findings in Section 4.

This model is better than the previous models that calibrate the evaluation on a deployable implementation and test as many threat sequences as possible rather than using established benchmarks to ensure that the results in Section 4 reflect a real-world cyber-operational behavior rather than a lab simulation. The methodology, in turn, does substantiate the aspect in which AGML would translate into a deployable resilience mechanism, or not an abstract model of automation of operations of enterprise-wide defense.

3.7.1. Dataset Description and Ground-Truth Construction

The proposed AGML framework was experimentally tested on a composite dataset that was intended to simulate real-world cybersecurity scenarios in the enterprise and to maintain experimental control and reproducibility. The dataset in question consisted of about 1.12 million security-consequential events gathered in the course of an artificial working period of 21 consecutive days. They interred events based on heterogeneous telemetry sources such as logs of network flows, endpoint activity logs, authentication logs and application/API access logs. The data fragmentation and asynchronous characteristics of the current enterprise security operations are mirrored in this multi-source construction.

All experiments, including AGML and control frameworks, were performed with the same dataset so that they could be fairly compared and the effect of confounding variability is removed because the data is not consistent.

Feature Set

A structured set of attributes (38) was modeled out of the raw telemetry to provide system behavior at multiple layers of operation. There were four semantic categories into which features were classified:

• Features at the network level, such as flow duration, inter-arrival time of packets, and protocol distribution entropy, connection frequency, and indicators of an abnormal traffic burst.
• Host/endpoint-level properties, process execution rates, system call anomalies, privilege-escalation attempts, and abnormal file-access patterns.
• Features on identity level, which include authentication failure rates, abnormal session persistence, role abuse indicators, and abnormal correlations with the time of the last login.
• Application/API-level capabilities such as deviation in request frequency, endpoint access anomaly, API abuse patterns and abnormal parameter distributions.

The temporal alignment of all the features was performed using sliding windows to retain sequential dependencies in the decision making based on reinforcement. The minmax scaling was used to normalize continuous features, and the fixed-length representations were used to encode categorical indicators. This preprocessing allowed it to be compatible with the adaptive risk inference and mitigation components without information leakage between the training and evaluation steps.

Ground-Truth Labeling

A hybrid annotation strategy was used to establish ground-truth labels in order to minimize bias and dependence on one detection mechanism. Controlled adversarial injections that were used to create malicious events included credential spraying, lateral movement, privilege abuse, command execution, and simulated data exfiltration. These attack cases were brought through scripted workflows and replayed benchmark traces, and allowed the deterministic identification of malicious intervals.

The consent between various independent sources such as rule-based detectors, anomaly scoring thresholds, and hand analysis of sampled sessions was used to label benign events. No events where the continuity of agreement was not obtained were included in the dataset to maintain the label integrity. This low-pass filtering reduced noises, and ambiguous samples were not allowed to affect model behavior.

After the labeling was performed, the eventual dataset had a class distribution of about 18.6% malicious and 81.4% benign events, which are similar to the natural imbalance of an operational enterprise security log. This disparity was purposely held to make sure the false-positive behavior, mitigation stability and operational reliability are tested in realistic deployment conditions instead of the unrealistically balanced situations.

4. Results

This section gives the empirical analysis of the proposed AGML framework according to the experiment protocol in Section 3.7. There are four important outcome dimensions of the results, which include detection capability, operational latency, stability against repeated adversarial pressure, and false-positive behavior. The recent hybrid AI–blockchain cybersecurity literature such as riskAIchain [2], ML–blockchain IDS strategies [5], AHEAD ensemble learning model [6], collaborative blockchain IDS [13], and the AICyber-Chain framework [33] were sampled based on the selection of recent studies related to the current architectural direction in the research of cyber-risk automation.

4.1. Detection Performance

The first stage of analysis was to identify the quality of the risk prediction engine of AGML using accuracy, precision, recall, F1-score, and AUC. As

Table 4. Comparative detection performance of AGML and baseline approaches.

Model	Accuracy	Precision	Recall	F1-Score	AUC	Ref.
Hybrid ML–Blockchain IDS	92.14%	90.21%	88.34%	89.26%	0.91	[5]
AHEAD Ensemble Model	94.87%	93.12%	90.45%	91.76%	0.94	[6]
Collaborative Blockchain IDS	91.02%	88.76%	87.11%	87.92%	0.89	[13]
AICyber-Chain	95.33%	94.10%	92.87%	93.47%	0.95	[33]
Proposed AGML	96.48%	95.82%	94.65%	95.22%	0.96	—

indicates, the proposed model has a high level of performance in all of the evaluated indicators. Remarkably, AGML had the highest level of recall in comparison with other baselines, which demonstrates better sensitivity towards anomalous and changing adversarial patterns. This advantage appears to be directly linked to the reinforcement-adjusted fusion mechanism described earlier in Section 3.2.

All baseline models were evaluated using identical feature dimensions, training–testing splits, and performance metrics to ensure consistency in comparative assessment. Hyperparameter configurations were adjusted in accordance with dataset characteristics without altering the underlying model architectures.

4.2. Operational Latency and Governance Overhead

Blockchain validation introduces additional processing overhead, and its effect on enforcement speed was studied under varying load conditions. Figure 5 presents the comparative latency profile between AGML and two blockchain-enabled threat mitigation frameworks [2,14]. While AGML exhibits a slightly higher validation processing time than the PBFT-only model in [14], the delay remains within acceptable operational thresholds, particularly for enterprise-class automated mitigation pipelines.

As illustrated in Figure 5, with AGML, it can be determined that the response times at different loads are stable, and the average governance overhead due to blockchain validation does not exceed one-third of a second. This compound figure displays the reaction of the proposed AGML structure to the increasing number of requests and the complexity of governance. In panel (A), a surface of nonlinear three-dimensional latencies of the interaction between the workload intensity and the validation cost of the blockchain exposes a level area of response preceded by the gradual increase in the cost of validation with the increase in the validation depth. The curved nature means that latency increases not in a linear manner but in a nonlinear manner with load, which is indicative of internal prioritization, caching in effect and adaptive scheduling. Providing a comparison between AGML and two blockchain-enabled baselines that are based on the previous literature [2,14], panel (B) is provided. The envelope profile indicates that AGML incorporates mitigation delay in the sub-300 ms band in most traffic conditions, which is not the case with the baseline systems that have a steep slope and earlier performance degradation. In combination with the visual results, it can be seen that AGML is resilient and stable under the operational loads and that it still ensures the rules of governance, such as consensus validation and enforcement that are tamper-proof.

4.3. Stability Under Repeated Adversarial Cycles

Cybersecurity systems built on automation should be stable even when their systems are subjected to repeated cycles of threat exploitation. Other more recent blockchain–AI models drift or become fatigued with repeated exposure to the same adversarial behavior [8,12]. However, AGML exhibited convergence as opposed to degradation in weight adaptation. Figure 6 demonstrates that, with reinforcement learning, the unnecessary mitigation is gradually eliminated, and the decision calibration becomes more precise and refined after each replay. Besides positively affecting the score of rewards, the dynamics of reinforcement actively narrow the band of uncertainty, proving adaptive stabilization in the case of repeated danger.

Panel (A) illustrates the nonlinear reward–stability surface revealing peak policy performance in late convergence stages. The evolution of the learning curve and the gradient is depicted in panel (B) with the explore phase changing to stabilization. In panel (C), there is a mitigation stability envelope, which shows a decrease in variance and decreased residual error when compared to the baseline. In panel (D), the persistence of replay attack is visualized using a deviation heatmap, whereby the brightness is associated with instability and the overlaid curve represents the recovery to stability.

As Figure 6 shows, the behavior patterns regulate the fact that the proposed AGML model is not just responsive to threats but gradually acquires mitigation behavior, gradually coming to a stable equilibrium.

4.4. False-Positive Behavior

False positives are one of the gravest deployment challenges in the actual automation of cybersecurity. Unregulated automation can cause the disruption of business continuity and the absence of confidence in mitigation mechanisms. The false-positive rate of AGML was 2.81, which was significantly lesser than that of AICyber-Chain (3.22) and significantly lesser than older ML–blockchain intrusion detectors, where a false-positive was above 5 percent [5,13]. Apparently, the proportional enforcement model will reduce unnecessary escalations since they will frame decisions on mitigation as compared to reacting to absolute levels. Figure 7 shows the relative performance of the false-positive properties of detection architectures.

Panel (a) uses a comparison of mean false-positives of AGML and three alternative intrusion detectors based on blockchain implementation. The violin-box type of visualization is presented in panel (b), and it can be seen that the results of this visualization are the underlying statistical spread. The suggested AGML architecture shows a lower false-positive rate and reduced volatility, indicating that proportional mitigation and reinforcement-supported adaptation scheme leads to the reduction in the number of unnecessary enforcement instances in the course of automated cybersecurity actions.

4.5. Ablation Study

To gain more insight into the role played by the individual components of the AGML architecture, an ablation study was performed in a systematic way by disabling core modules and comparing the performance of the ablation study to that of the full model configuration. The three design aspects considered in it include (i) reinforcement-guided weighting, (ii) blockchain-governed authorization, and (iii) proportional layer-based mitigation logic. The choice of these modules is due to the fact that they are regarded as the mechanisms that make AGML distinguishable among recently developed hybrid AI–blockchain cybersecurity methods like AHEAD [6], Hybrid ML-Blockchain IDS [5], and AICyber-Chain [33]. The assessment was re-assessed with the same workload of the experiment, as indicated in

Table 5. Ablation study results comparing full AGML model with reduced variants.

Model Variant	Accuracy	FPR	Avg. Mitigation Latency	Change vs. Full Model
Full AGML Model	96.48%	2.81%	312 ms	—
Without Reinforcement Weighting	93.72%	4.09%	297 ms	↓ Accuracy, ↑ FPR
Without Blockchain Authorization	95.11%	4.53%	186 ms	↓ Security assurance
Without Layer-Proportional Mitigation	94.26%	6.41%	274 ms	↑ Over-response + instability
Baseline ML–Blockchain IDS [5]	92.14%	5.32%	261 ms	—
AICyber-Chain [33]	95.33%	3.22%	298 ms	—

Note: ↑ indicates an increase (higher value), ↓ indicates a decrease (lower value).

, with the same datasets and deployment settings in order to eliminate bias. Accuracy, false-positive rate (FPR) and enforcement latency were then taken as the measures of performance because these are the indicators of the real-world operational relevance.

Interpretation of Ablation Results

The results of the ablation suggest that the tuning mechanism by reinforcement is a valuable effort in decision quality. Removal caused its accuracy to decrease by almost 2.8 per cent and the false-positive rate to rise significantly, which confirms that adaptive learning lowers classification rigidity when repeated attack sequences are provided. Removing blockchain authorization resulted in an interesting trade-off: the system became faster (186 ms) because there was no overhead of consensus but controlled decision accountability was lost. This trade-off can cause chains of actions that can be traced in the real world, something that has been suggested in recent studies that propose secure operation of automated response systems [14,33]. In this way, a latency is better, and the integrity of governance is worse. When proportional mitigation logic was removed then the worst degradation was seen as in Figure 8. As revealed by the ablation behavior shown in Figure 8, it is important to maintain the governance and adaptive intelligence as supplementary elements as opposed to viewing them as add-ons. The loss in accuracy in the removal of PBFT consensus or smart-contract authorization was relatively small, but the false-positive rate increased in disproportionate amounts resulting in instability trends in previous blockchain-security ensembles [2,14]. Above, removing a reinforcement-directed adaptation elicited more pronounced collapse, and variance signatures similar to those of previous models based on traditional static detection were exhibited [6,20]. The complete setup had the best accuracy and lowest noise, which confirmed the hypothesis that the AGML layered architecture had a synergetic effect, with governance in place, and decision boundaries stabilized with time through learning.

According to panel (a), the sequential removal of components’ predictive accuracy in ablation testing shows that the removal of reinforcement-based adaptation and multi-layer mitigation engine is the most acute. Panel (b) shows the corresponding evolution in false-positive rate under the same conditions, where the absence of blockchain-validated enforcement and policy-layer intelligence leads to noticeably higher instability. The combined pattern indicates that AGML’s performance does not arise from a single dominant module but from coordinated interaction between consensus, reinforcement learning, and smart-contract-controlled mitigation.

4.6. Statistical Reliability and Repeatability Notes

Despite the excellent results of AGML in all the measured metrics, it was significant to ensure that the identified improvements were not as random or limited to one tuning state. Thus, in all experiments, they were conducted in five independent runs, where seed alignment of models and ordering of event stream were randomized. The inter-run variance was low, with standard deviation values of ±0.42, 0.36, and 0.51 as indicators of accuracy, precision, and recall, respectively, showing consistency in behavior. The latencies of mitigation also exhibited little variation (±1118 ms), which can largely be due to the timing of the chain commit and not due to inference or enforcement logic. These trends imply that the model acquires stable internal models as opposed to opportunistic parameter estimation.

4.7. Resource Cost Evaluation

A comparison of resource costs was carried out to test the hypothesis that AGML had made improvements at the cost of excessive compute overhead. The entire system had a comparable footprint based on the lightweight hybrid systems (like riskAIchain [2]) and much lower than the deep ensemble systems (like AHEAD [6] system). Validation of blockchain was the most expensive process computationally, but also offered the highest value in terms of governance, and this is well aligned to the philosophy of design of the system.

On the whole, the ablation experiment proves that every architectural element has a functional role to play in the robustness of the system. A lack of reinforcement learning means the inability to adapt to change; a lack of blockchain authorization means the inability to mitigate accountability; and a lack of proportional mitigation means the inability to stabilize operations. The balance in the entire AGML model of precision, accountability and controlled automation is as a result of the consolidated behavior of these modules as opposed to single-dimension optimization. In combination, the findings illuminate that AGML can attain a good compromise between the detection, mitigation reactiveness, and operational resilience. The architecture does not seek to remove the processing delays in blockchains but rather predictively controls them, but it uses the governance immutability as a practical security benefit. Relative to current systems, AGML offers advantages in areas in which operational reliability and explainability may be required, especially in the context of high-risk enterprise where automation and explainability are required. Overall, the results indicate that AGML, in addition to acting as a detection accelerator, is a managed cyber-resilience service that enhances detection accuracy, minimizes the false alarm rates, and makes mitigation accountable with predictable real-time behavior.

5. Discussion

The improvement in detection performance and the significant decrease in false positives are not by chance but seem to be a result of the close interconnection between the reinforcement-based inference and blockchain-based authorization reason [54]. With repeated adversarial cycles, the system was found to change its behavior from reactive alerting behavior to calibrated mitigation, implying that the closed feedback loop was driving the maturity of decisions and not fixed classification results. This finding is quite consistent with the initial assumption that accountability and adaptively (when co-located) can lower the risk of automation and enable trustful intervention.

The differences can be seen more clearly when it is contrasted with the current hybrid AI–blockchain cybersecurity systems. In one example, where AHEAD [6] and AICyber-Chain [33] showed competitive accuracy levels, both of them lack a governance-related execution control, i.e., the decision-making process is not cryptographically committed to policy justification. Likewise, IDS models that use blockchain as a log recording layer only [5,13] are not up to the task in terms of refining mitigation, tending to respond in a consistent manner and are connotative of the intensity of the operation environment. The proposed AGML architecture to this end, thus, bridges one such identified gap: it does not just predict a risk, but also controls how, when and how strongly mitigation takes place, without compromising auditability.

There are a number of implications of this behavior. On the theoretical level, the research confirms the notion that blockchain can be used as something more than an immutable database; it can also be viewed as a decision boundary that imposes a democratic agreement prior to cyber activities altering production landscapes. At the operational level, the stability of the system in the case of the long-duration attacks can indicate that it is suitable in the security operations centers (SOCs) where alert fatigue and improperly configured automation is an ongoing problem. A very surprising but fruitful revelation was the tendency of reinforcement adjustment to bring out unwarranted responses in a gradual way—a behavior more in line to the intuition of a human analyst rather than the rigidity of an algorithm.

With that being said, the framework does not have boundaries. The controlled hybrid deployment experiment had been carried out, and even though realistic, the case does not entirely recreate the globally distributed cloud edge networks or highly heterogeneous IoT ecosystems. The dependency on the synthetic replayed adversarial sequences also creates some ecological insecurities, and there is no knowledge of how the system will conduct itself during zero-day, polymorphic, or coordinated multi-vector attacks. Such limitations do not reduce the contribution but instead indicate the opportunities of future tasks, especially the validation of the federated environment, adversarial ML resilience testing, and real-time optimization of blockchain throughput.

In a broader sense, this study will be beneficial to the current debate on autonomy, governance, and trust in cybersecurity automation. The current trends in enterprise network architecture and design are self-defending architecture and frameworks like AGML and are pointing towards a model where security choices are not blindly made by algorithms and are not bottlenecked by human intervention, and where such decisions have a balance of intelligence, traceability, and dynamic reasoning.

6. Conclusions and Future Scope

This study presented a hybrid governance-driven cybersecurity framework integrating machine learning-based cyber-risk prediction with permissioned blockchain-enabled mitigation authorization for enterprise network environments. The proposed Adaptive Governance-Driven Mitigation Loop (AGML) architecture combines continuous risk estimation with tamper-resistant decision validation and coordinated multi-layer mitigation across network, host, identity, and application domains. The framework was evaluated under enterprise-like telemetry conditions using performance metrics such as detection accuracy, precision, recall, false-positive rate, and response latency. The findings indicate that the proposed hybrid architecture can support accountable, risk-aware, and auditable threat mitigation in heterogeneous enterprise infrastructure.

In the future, there are a number of directions that seem to be interesting to pursue. Scalability of the system may be challenged by expanding it to multi-tenant cloud environments or federated governance environments. The other exciting line of inquiry is related to the application of adversarial robustness as the part of the learning loop; thus, the system is not only adaptive but also predicts the manipulation. One of the last directions could be to map the framework onto existing security orchestration platforms deployed in industry to determine whether it supports or interferes with existing SOC processes.

Concisely, AGML shows that security automation does not necessarily need to be a black box. It may be designed and described in a manner that is versatile, without becoming slow and cumbersome. The novelty is more of a step towards a future where machines can respond to a situation without having to be trusted.