Secure Cloud-Native Platforms for Critical Service Continuity: An AI-Driven Framework for National Cyber and Economic Resilience

Secure Cloud-Native Platforms for Critical Service Continuity: An AI-Driven Framework for National Cyber and Economic Resilience. AI stands for artificial intelligence. The article by Jawad Yaqoob Mir and Fawad Mir appeared in the American Journal of Innovation in Science and Engineering in 2026. Mir and Mir call their design AICER, which stands for AI-driven Integrated Cyber-Economic Resilience. They address fragmented approaches to cloud resilience, AI-assisted IT operations, cybersecurity and governance. The focus is how AICER connects those concerns in a conceptual framework.

Cloud-native applications are assembled from interconnected services spread across hybrid and multi-cloud environments. Those environments can include interfaces and authentication systems. They can also include databases and messaging queues. Third-party services and external cloud providers may also be involved. This structure supports independent scaling and fault isolation. It can also create paths for one failure to affect dependent services. The software supply chain adds another dimension. It can include open-source packages and container images. It can also include third-party libraries and infrastructure templates. Mir and Mir therefore frame resilience as more than keeping infrastructure available. Their broader view includes software integrity and service criticality. It also covers regulatory obligations and business continuity. The economic consequences of disruption are considered as well.

The research question is architectural: can one decision-support system connect operational telemetry with cybersecurity and software-assurance evidence? Operational telemetry means metrics, logs, traces and runtime events. The system would also bring governance policies and economic impact into the same decision process. The intended result is coordinated recovery advice rather than separate operational and security views of the same incident. AICER also asks whether AI recommendations can be checked against policy and regulatory requirements while people retain authority over consequential actions. Recovery priorities would account for service importance and potential economic impact rather than availability alone.

The method is DSRM, which stands for Design Science Research Methodology. In plain terms, the researchers designed an artefact—a conceptual architecture—to address a problem identified through an integrative literature review, international security standards and cloud-computing practices. They derived requirements, developed AICER, applied it to representative resilience scenarios and assessed it before implementation. That assessment considered whether the requirements were covered, whether the components fit together logically, whether the design aligned with standards, and whether its governance and implementation appeared feasible. This was not a test of a deployed system or a measurement of implementation performance.

The resulting architecture organizes its layers into a staged decision path. The architecture includes critical-service objectives and recovery priorities. It also includes cloud workload and service-health data. An intelligence stage combines operational telemetry with vulnerability information. It also uses threat and dependency information. This stage produces predictions and root-cause analysis. It also produces recovery recommendations. A software-assurance stage checks code and provenance. It also checks an SBOM, which stands for software bill of materials. An economic stage estimates disruption impact and service priority. Governance then evaluates recommendations against policies and security controls. It records the decision and routes consequential actions to a human operator. Together, these layers form the proposed integrated AICER design.

The researchers exercised the design with a representative national digital-payment scenario. The service experiences latency while a newly disclosed vulnerability is found in a deployed container dependency. The proposed engine combines operational telemetry with cybersecurity alerts and software-assurance evidence. It assesses whether the latency reflects an infrastructure, deployment or network problem. The policy layer checks the recommendation against required controls. In the scenario, governance approves a rollback to a known-good software version. It also isolates services and alerts cybersecurity operators. This walkthrough explains the intended information flow and approval path.

AICER remains a conceptual framework. Its evaluation examined requirements coverage and internal logic. It also considered standards alignment, governance and apparent feasibility rather than implementation performance. The researchers identify prototype implementation, experiments and deployment as future work. AI also brings unresolved concerns around explainability and transparency. Governance and changing model behaviour remain concerns as well. Because the assessment did not examine implementation performance, performance remains to be tested through prototype implementation and experimental validation.

For security architects, AICER may be useful as a design checklist. Map each critical service to its mission objectives, recovery priorities and regulatory constraints. Then identify whether the response process can combine runtime health, service dependencies, threat evidence and software-provenance status. Detection engineers and incident responders can examine where operational and security evidence remains separated. The architecture also offers a cautious automation rule: use AI to analyse context and recommend actions, but keep deterministic controls, policy checks and human authorization for consequential decisions. Economic priority and software integrity should become explicit recovery inputs. Because effectiveness is untested, teams should validate any implementation locally before trusting it with service isolation, rollback or disaster recovery.

Mir and Mir contribute a unified conceptual architecture connecting cloud operations and cybersecurity evidence with AI-assisted analysis. It also brings software assurance, economic impact and governance into the decision path. Security architects and platform teams may use it to examine whether recovery decisions account for service dependencies and software trust. Detection engineers and incident responders may also check business priority and accountable approval. The practical takeaway is to design those connections explicitly while keeping AI subordinate to policy and human authority. Teams should not infer proven improvements in detection, recovery or continuity. The study evaluated a design through requirements and representative scenarios rather than a deployed implementation.