AI-Driven Adaptive Encryption Framework for a Modular Hardware-Based Data Security Device: Conceptual Architecture, Formal Foundations, and Security Analysis

Abstract

This paper presents a conceptual architecture for an AI-Driven Adaptive Encryption Device (AI-AED), a tri-modular hardware platform embodied in a registered industrial design. The device integrates a Secure Input Module, an AI-Enhanced Central Processing Unit with biometric authentication, and a Secure Output Module connected by unidirectional buses. We formalise the adaptive encryption policy as a constrained Markov decision process (CMDP) over a discrete action space of 216 cryptographic configurations, with safety constraints that provably prevent convergence to insecure states. A formal threat model based on extended Dolev–Yao assumptions with four physical access tiers defines attacker capabilities, and anti-downgrade safeguards enforce a monotonically non-decreasing security floor during threat escalation. An information-theoretic analysis shows that adaptive algorithm selection contributes an additional entropy term H(α) to ciphertext uncertainty, upper-bounded by log₂(|L_enc|) ≈ 1.58 bits, while noting this represents increased attacker uncertainty rather than a strengthening of any individual cipher. A component-level latency model estimates 0.91–1.00 ms pipeline latency under normal operation and 3.14–3.42 ms under active threat, including integration overhead. Simulation validation over 1000 episodes compares a tabular Q-learning baseline against the proposed Deep Q-Network operating on the continuous state space: the DQN achieves 82% fewer constraint violations, 6× faster threat response, and more stable policy switching, demonstrating the advantage of continuous-state reinforcement learning for safety-critical adaptive encryption. All claims are positioned as theoretical contributions requiring empirical validation through prototype implementation.

1. Introduction

The contemporary cybersecurity landscape is characterised by an escalating arms race between increasingly sophisticated attack methodologies and defensive encryption technologies. Traditional encryption systems, while mathematically robust, operate on static parameters that remain fixed regardless of the evolving threat environment [1,2]. This rigidity creates a fundamental vulnerability: the inability to dynamically respond to novel attack vectors, changing network conditions, or emerging threats such as quantum computing advances.

From a systems engineering perspective, the challenge of adaptive encryption can be formulated as an optimal control problem given a stream of real-time sensor observations characterising the threat environment, to determine the cryptographic configuration that maximises security while satisfying latency and resource constraints. This formulation naturally maps to the Markov decision process framework, where the encryption device is the controlled plant, the threat landscape is the disturbance, and the cryptographic configuration is the control input. The contribution of this paper lies in formalising this mapping for a physically modular hardware architecture, establishing safety guarantees through constrained MDP theory, and providing information-theoretic bounds on the security advantage of adaptive versus static encryption.

Recent advances in artificial intelligence have demonstrated capabilities in pattern recognition and adaptive decision-making [3,4]. However, integrating these capabilities directly into dedicated hardware encryption devices remains underexplored. While software-level AI-enhanced security systems have gained traction in intrusion detection, the application of embedded AI for real-time cryptographic parameter optimisation within physically modular hardware presents unique challenges not adequately addressed in the literature [5,6].

This paper presents a conceptual framework for an AI-Driven Adaptive Encryption Device (AI-AED) integrating machine learning within a tri-modular hardware architecture registered under UK Design No. 6,488,506 (Locarno Classes 10-05 and 14-02). Our contributions are as follows:

• A tri-modular hardware architecture—Secure Input Module (SIM), AI-Enhanced Central Processing Unit (AI-CPU), and Secure Output Module (SOM)—mapped to the registered industrial design.
• A formal MDP formulation for the reinforcement learning-based adaptive encryption policy, with a complete state space, action space, transition dynamics, and reward structure.
• Three algorithmic specifications: ATAM decision pipeline, adaptive key rotation, and authentication escalation protocols.
• An information-theoretic security proof demonstrating strictly higher ciphertext entropy for adaptive encryption versus static systems.
• A theoretical performance model with latency and throughput estimates based on published TinyML benchmarks.
• A worked numerical scenario illustrating system behaviour under a multi-stage attack.

2. Related Work

2.1. Static Encryption and Hardware Security Modules

Symmetric algorithms such as AES-256 [7] and ChaCha20-Poly1305 provide strong confidentiality guarantees under the assumption that keys are securely managed and algorithmic parameters are appropriately selected for the threat context. Hardware Security Modules (HSMs) conforming to FIPS 140-3 [8] encapsulate these algorithms within tamper-resistant boundaries, providing physical protection for cryptographic keys and operations. However, HSMs operate with fixed, pre-configured parameters: the encryption algorithm, key length, and rotation schedule are set during provisioning and remain static throughout operation. Anderson [9] notes that this rigidity, while simplifying formal security analysis, creates operational vulnerabilities when the threat landscape evolves faster than the HSM’s configuration cycle.

The NIST Post-Quantum Cryptography standardisation has produced CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium for digital signatures [10], addressing the long-term threat posed by Shor’s algorithm to public-key cryptography [11]. However, transitioning existing HSM deployments to post-quantum algorithms requires firmware updates, recertification, and often hardware replacement—a process that Bernstein and Lange [12] estimate will take a decade or more across deployed infrastructure. This slow transition period represents a critical vulnerability window that an adaptive system could address through autonomous algorithm migration.

2.2. AI in Cybersecurity

Machine learning has achieved significant success in peripheral cybersecurity functions: intrusion detection systems using deep learning [13,14], malware classification through convolutional neural networks [15], and adaptive response orchestration via reinforcement learning [16]. Taherdoost and Slimani [5], in a recent bibliometric review, document rapid growth in AI-cryptography research since 2020 and identify a critical gap: “there is a scarcity of practical implementation research” for frameworks that “seamlessly integrate adaptive encryption techniques with anomaly detection.” Our work directly addresses this identified gap by proposing such a framework grounded in a registered hardware architecture.

Within the narrower domain of AI applied directly to cryptographic operations (as opposed to peripheral security), existing work includes genetic algorithm-based techniques for cryptanalysis of TEA [17], neural network random number generators for key generation [18], and LSTM-based classifiers for network intrusion patterns [19]. However, these approaches apply AI to isolated components of the cryptographic pipeline. No existing work integrates AI-driven threat classification, adaptive algorithm selection, dynamic key rotation, and authentication escalation within a unified, hardware-enforced architecture—the combination that defines the AI-AED contribution.

2.3. Adaptive Encryption and Modular Hardware

Context-aware encryption that adjusts parameters based on environmental conditions has been explored primarily in IoT contexts. Yang et al. [20] proposed security and privacy mechanisms for IoT that adapt to device constraints, while Al-Turjman et al. [21] explored similar adaptations for smart city infrastructure. However, these approaches use rule-based parameter adjustment (e.g., “if battery < 20%, use AES-128 instead of AES-256”) rather than learned policies optimised through reinforcement learning. The AI-AED’s CMDP formulation represents a fundamentally different approach: the policy is learned from interaction with the threat environment and provably constrained against insecure configurations, rather than manually specified by a security engineer.

Elkhodr [22] proposed an AI-driven framework integrating blockchain with quantum-resistant cryptography for IoT security. Their framework shares our motivation of combining AI with adaptive cryptography, but operates entirely at the software level without dedicated hardware isolation. The AI-AED addresses this limitation through physical module separation—a property that provides tamper resistance and side-channel isolation that software-only architectures cannot achieve.

Modular hardware architectures have demonstrated viability in security-critical domains: POS terminals separate PIN entry from transaction processing, hardware tokens isolate key storage from host systems, and smart cards provide tamper-resistant execution environments [23]. The AI-AED extends this modularity principle to the full encryption pipeline, with each module (SIM, AI-CPU, SOM) serving a distinct security function connected by unidirectional buses.

3. Hardware Design and Functional Mapping

3.1. Design Overview

The AI-AED is registered under UK IPO Design No. 6,488,506 (27 November 2025), classified under Locarno Classes 10-05 and 14-02. It comprises three physically distinct modules (Figure 1).

3.2. Module Descriptions

Secure Input Module (SIM): Recessed display and 3 × 4 keypad for PIN entry, command input, and manual key fragment entry. Hardware-isolated from the AI-CPU via a unidirectional secure bus.

AI-Enhanced Central Processing Unit (AI-CPU): Large touchscreen, biometric fingerprint sensor (oval element), dual speaker grilles, and rear-mounted camera (Figure 2). Houses the NPU, crypto accelerator, TRNG, and secure element. Mounted on an adjustable tilting stand. The rear panel (Figure 3) provides Ethernet, USB, and memory card interfaces.

Secure Output Module (SOM): Display, thermal printer, and card reader for encrypted exports, cryptographic receipts, audit logs, and smart card-based key distribution.

3.3. Interconnection Architecture

Modules connect laterally (Figure 4) with a unidirectional bus: SIM → AI-CPU (write-only), AI-CPU → SOM (read-only). This prevents lateral attack movement.

Side-Channel Monitoring Sensors. The AI-CPU module incorporates dedicated sensors for the Anomaly Detection Engine’s side-channel monitoring capability. Specifically, (i) an internal current sense resistor on the power supply rail provides real-time power consumption waveforms to the ADE at 10 MHz sampling rate, enabling detection of differential power analysis (DPA) [24] probing patterns; (ii) a near-field electromagnetic (EM) probe mounted within the module enclosure captures local EM emanations, with the ADE trained to distinguish normal operational signatures from anomalous patterns indicative of external EM probing at Tier 1 proximity; and (iii) high-resolution timing counters on all cryptographic operations detect statistical timing deviations that may indicate timing-based side-channel attacks. These sensors feed directly into the ADE via a dedicated internal bus, separate from the data path, ensuring that monitoring does not introduce additional side-channel leakage. The sensor specifications are defined in

Table 1. Side-channel monitoring sensor specifications.

Sensor	Measurement	Sample Rate	ADE Output
Current sense resistor	Power rail current	10 MHz	DPA detection
Near-field EM probe	Local EM emanations	5 MHz	EM probing detection
Timing counters	Operation cycle counts	Per-operation	Timing attack detection
Temperature sensor	Die temperature	1 kHz	Fault injection detection

.

4. AI-Encryption Framework Architecture

4.1. Component Mapping

Table 2. Logical-to-physical component mapping.

Logical Component	Module	Hardware Elements
Secure Input Layer	SIM	Keypad, display, and secure bus
AI Threat Analysis (ATAM)	AI-CPU	NPU, touchscreen, biometrics, and camera
Crypto Execution (CEU)	AI-CPU	Crypto accelerator, TRNG, and secure element
Key Management (AKMS)	AI-CPU + SIM/SOM	Key store, distribution bus, and smart card I/F
Secure Output Layer	SOM	Display, printer, card reader, and audit storage

maps logical components to physical modules.

4.2. Cryptographic Execution Unit

The CEU implements a reconfigurable pipeline operating across three functionally distinct cryptographic sub-libraries: L_enc = {AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305} (symmetric authenticated encryption), L_kem = {ECDH-P256, CRYSTALS-Kyber-512, CRYSTALS-Kyber-768} (key encapsulation mechanisms), and L_sig = {ECDSA-P256, CRYSTALS-Dilithium-2} (digital signatures). The ATAM selects independently within each sub-library based on threat context. The primary encryption function operates over L_enc:

E: P × K × L_enc × M → C, where E(p, k, α, m) = Enc_α(p, k, m)

where P is the plaintext space, K the key space, L_enc the symmetric cipher library, M the mode set, and C the ciphertext space. The selector α ∈ L_enc is dynamically determined by the ATAM for data encryption operations. Separately, the key exchange function operates over L_kem for session key establishment, and the authentication function operates over L_sig for message authentication and non-repudiation. This separation ensures that the adaptive selection compares functionally equivalent primitives—the system never “switches” between a symmetric cipher and a KEM, as these serve fundamentally different cryptographic purposes.

4.3. Formal MDP Formulation for Adaptive Encryption Policy

We formalise the RLPE as a Markov decision process M = (S, A, T, R, γ) defined as follows.

Definition 1 (State Space).

The state space S = S_threat × S_resource × S_sensitivity × S_auth × S_latency is the Cartesian product of five continuous dimensions: s = (s_threat, s_resource, s_sensitivity, s_auth, s_latency) where s_threat ∈ [0, 1] is the normalised threat level from the NNTC, s_resource ∈ [0, 1] is the CPU/memory utilisation, s_sensitivity ∈ {1, 2, 3, 4, 5} is the data classification level, s_auth ∈ [0, 1] is the current authentication confidence score, and s_latency ∈ R+ is the current communication latency in milliseconds.

Definition 2 (Action Space).

The action space A is the discrete set of configuration tuples:

A = L × K_len × F_rot × M × Auth_level

where L_enc = {α₁, α₂, α₃} is the symmetric cipher library, K_len ∈ {128, 256} bits (matching supported cipher key lengths), F_rot ∈ {f₁, f₂, …, f₆} is the set of discrete rotation frequencies (ranging from 1 h to continuous), M = {GCM, CCM} is the authenticated encryption mode set (ECB and CBC are excluded as they lack built-in authentication), and Auth_level ∈ {1, 2, 3} represents single-factor, two-factor, and three-factor authentication requirements respectively. The KEM selection from L_kem and signature selection from L_sig are treated as secondary action dimensions, yielding a total primary action space |A| = 3 × 2 × 6 × 2 × 3 = 216 discrete configurations for the symmetric encryption pipeline. The reduced action space compared to an unconstrained formulation is deliberate: it excludes functionally invalid combinations (e.g., AES-128 with 256-bit keys) and unauthenticated modes, ensuring every configuration in A is cryptographically sound by construction.

Definition 3 (Transition Function).

The transition function T: S × A → Δ(S) maps state-action pairs to probability distributions over next states. We decompose transitions as

T(s′|s, a) = P(s′_threat|s_threat, a) · P(s′_resource|a) · P(s′_latency|a)

where P(s′_threat|s_threat, a) models threat evolution (stronger encryption may deter or not deter attackers), P(s′_resource|a) captures the computational cost of action a (e.g., switching to CRYSTALS-Kyber increases resource utilisation), and P(s′_latency|a) models the latency impact. The sensitivity and authentication dimensions are treated as deterministic, given the action.

Definition 4 (Reward Function).

The reward R: S × A × S′ → R is

R(s, a, s′) = w₁ · Sec(a, s) − w₂ · Lat(a) − w₃ · Res(a) + w₄ · Adapt(s, a)

where Sec(a, s) = (key_bits(a)/512) · cipher_strength(α) · (1 + s_threat) is the security score normalised to [0, 2], Lat(a) = latency(a)/latency_max is the normalised latency penalty, Res(a) = resource_cost(a)/resource_budget is the resource utilisation fraction, and Adapt(s, a) = 1 − |threat_level_coverage(a) − s_threat| is an adaptation bonus that rewards proportional response: perfect threat-response matching yields Adapt = 1, while maximum mismatch yields Adapt ≈ 0, penalising both under- and over-reaction. The discount factor γ = 0.95 balances immediate security with long-term efficiency.

Definition 5 (Policy).

The optimal policy π*: S → A is obtained by solving

π* = arg max_π E[Σ_{t = 0}^{∞} γ^t R(s_t, π(s_t), s_{t + 1})]

In practice, we approximate π* using a Deep Q-Network (DQN) with experience replay and target network stabilisation [25], suitable for the discrete action space of |A| = 216 configurations. The DQN operates directly on the continuous state representation without manual discretisation, using two hidden layers of 64 units with ReLU activations. This architecture is validated against a tabular Q-learning baseline in Section 5.8.2, demonstrating superior constraint compliance and threat response over the continuous state space.

Definition 6 (Safety Constraints).

We extend the MDP to a constrained MDP (CMDP) [26] by introducing safety constraint functions C_i: S × A → {0, 1}: Rather than incorporating these as soft cost constraints solved via Lagrangian relaxation (the standard CMDP approach), we enforce them as hard action space constraints through action masking—a stricter mechanism that provides deterministic safety guarantees at the cost of potentially excluding reward-optimal actions: C₁(s, a): σ(a) ≥ σ_min—minimum security strength is always maintained; C₂(s, a): key_bits(a) ≥ min_key_len(cipher(a))—key length matches or exceeds cipher minimum; C₃(s, a): if s_threat > 0.5, then auth_level(a) ≥ 2—elevated threats require multi-factor authentication; and C₄(s, a): cipher(a) ∈ L_approved—only pre-validated algorithms are selectable. The complete observe–decide–constrain–act–evaluate cycle is illustrated in Figure 5.

The constrained optimal policy is

π* = arg max_π E[Σ γ^t R(s_t, a_t)] subject to C_i(s_t, π(s_t)) = 1 for all i, t

Theorem 1 (Safety Guarantee via Action Masking).

Under the CMDP formulation, the AI-AED policy π* cannot converge to any configuration a where σ(a) < σ_min, regardless of the reward signal or state trajectory. This follows directly from the hard constraint C₁, which is enforced at the action selection level: the RLPE action mask zeros the Q-values of all actions violating any constraint C_i before the argmax selection. Since the safe action set A_safe = {a ∈ A:C_i(s, a) = 1 ∀ i} is non-empty for all reachable states (guaranteed by construction of L_approved), the policy always selects from A_safe.

Hardware Enforcement. As a defence-in-depth measure independent of the CMDP formulation, the CEU implements a hardware action validator that checks every configuration received from the RLPE against the constraint set before execution. If any constraint is violated, the CEU ignores the RLPE output and applies a hardcoded FALLBACK_CONFIG (AES-256-GCM, 256-bit key, maximum rotation, and three-factor authentication). This hardware check operates independently of the software RL stack and cannot be overridden through adversarial manipulation of the ATAM.

4.4. ATAM Sub-Components

Neural Network Threat Classifier (NNTC): A quantised MobileNetV3-Small architecture producing threat vector T ∈ [0, 1]ⁿ across n = 8 categories (DDoS, brute-force, side-channel, injection, malware, phishing, zero-day, and benign). The NNTC operates on a fixed-length feature vector constructed from three input streams: (i) statistical features extracted from network packet headers and flow metadata (packet rate, entropy of destination addresses, and protocol distribution) over a sliding window; (ii) side-channel sensor readings from the ADE (power, EM, and timing features); and (iii) visual scene classification from the rear camera (detecting physical proximity or tampering indicators). These heterogeneous inputs are concatenated into a unified feature vector and processed through the MobileNetV3-Small backbone, which was selected for its efficiency on resource-constrained hardware rather than for image-specific processing.

Anomaly Detection Engine (ADE): A variational autoencoder (VAE) with reconstruction error threshold θ. An observation x is flagged anomalous when ||x − Dec(Enc(x))||_2 > θ, where θ is set at the 99th percentile of calibration reconstruction errors.

Multi-Modal Authentication: Confidence C_auth = α₁·PIN(SIM) + α₂·Biometric(AI-CPU) + α₃·Token(SOM) + α₄·Visual(Camera), with coefficients adjusted by the RLPE.

4.5. Algorithmic Specifications

The ATAM decision pipeline, adaptive key rotation protocol, and authentication escalation protocol are specified in Algorithms 1, 2, and 3, respectively. Algorithm 3 specifies the minimum authentication level as a hard safety floor, analogous to the CMDP constraints C₁–C₄. The RLPE independently selects Auth_level as part of the action vector a, but is constrained to select Auth_level ≥ L_req as computed by Algorithm 3. The RL policy may select a higher authentication level than the minimum if the learned reward structure indicates this is optimal—for example, requesting three-factor authentication at s_threat = 0.5 even though the floor only requires two-factor. Algorithm 3 thus functions as a safety constraint rather than the authentication policy itself.

Algorithm 1: ATAM Decision Pipeline

Input: data_stream D, sensor_inputs X, current_state s Output: action vector a, updated state s′ 1:    T ← NNTC.classify(D, X.camera)       //threat vector 2:    s_threat ← max(T [0..n−2])                    //max non-benign 3:    anomaly_score ← ADE.evaluate(D, X) 4:    if anomaly_score > θ then 5:            s_threat ← max(s_threat, 0.8)      //elevate threat 6:    end if 7:    s_auth ← compute_auth_confidence(X) 8:    s ← (s_threat, s_resource, s_sensitivity, s_auth, s_latency) 9:    a ← RLPE.select_action(s)                      //ε-greedy DQN 10: if a ∉ SAFE_CONFIGS then 11:          a ← FALLBACK_CONFIG                            //HW-enforced 12: end if 13: CEU.apply(a.α, a.key_len, a.mode) 14: AKMS.set_rotation(a.f_rot) 15: return a, s

Algorithm 2: Adaptive Key Rotation Protocol

Input: threat_level s_threat, base_frequency f_base, λ Output: rotation event or no-op 1:    f_rot ← f_base × (1 + λ × s_threat) 2:    t_next ← 1/f_rot                                        //seconds 3:    if time_since_last_rotation ≥ t_next then 4:            K_new ← TRNG.generate(key_len) 5:            K_new ← K_new ⊕ NPU.pseudo_random(key_len)//hybrid 6:            H(K_new) ← estimate_entropy(K_new) 7:            if H(K_new) < entropy_threshold then 8:                    K_new ← TRNG.generate(key_len) //fallback 9:            end if 10:          AKMS.install_key(K_new) 11:          AKMS.schedule_zeroise(K_old, delay = 2 s) 12:  end if

Algorithm 3: Authentication Escalation Protocol

Input: threat_level s_threat, current_auth_level L_curr Output: required_auth_level L_req 1:    if s_threat < 0.3 then 2:            L_req ← 1                                                   //PIN only 3:    else if s_threat < 0.7 then 4:            L_req ← 2                                                   //PIN + biometric 5:    else 6:            L_req ← 3                                                   //PIN + biometric + token 7:    end if 8:    if L_req > L_curr then 9:            SIM.request_pin_reentry() 10:          if L_req ≥ 2 then AI-CPU.request_biometric() 11:          if L_req ≥ 3 then SOM.request_token() 12:          C_auth ← fuse_auth_signals() 13:          if C_auth < min_confidence[L_req] then 14:                  CEU.lock(); raise ALERT 15:      end if 16:   end if 17:   return L_req

4.6. Key Lifecycle Management and Communication

Neural Entropy Augmentation: Rationale and Safeguards

The use of neural network-assisted entropy in cryptographic key generation is a deliberate design choice that requires careful justification, as it introduces a non-certified stochastic component into a security-critical pipeline.

Design Rationale. The NPU-generated pseudo-random sequence is not a replacement for the certified hardware TRNG. Rather, it functions as a conditioning layer applied via XOR to the TRNG output: K = TRNG(n) ⊕ NPU_random(n). By the properties of XOR, if either source produces output with full entropy, the combined output retains at least that entropy level. The NPU contribution can only increase (never decrease) the min-entropy of the combined output, provided the two sources are statistically independent.

Independence Assurance. The NPU random generator operates on a separate seed derived from internal timing jitter of the neural processing unit, which is physically independent of the TRNG’s noise source (typically thermal or shot noise in a dedicated analogue circuit). No feedback path exists between the two generators.

Continuous Bias Detection. The AKMS applies the NIST SP 800-90B entropy estimation tests to every generated key before installation [27,28]. Specifically, (i) the Most Common Value estimate provides a lower bound on min-entropy; (ii) the Markov estimate tests for sequential dependencies; and (iii) the Compression estimate detects non-random structure. If the estimated min-entropy falls below 7.9 bits/byte for a 256-bit key (equivalent to 253.6 bits of min-entropy), the key is rejected, the NPU contribution is discarded, and a pure TRNG key is generated as a fallback (Algorithm 2, lines 7–8).

Certification Path. We acknowledge that the hybrid entropy source would require independent evaluation under standards such as AIS 31 (German BSI) or NIST SP 800-90B [27] before deployment in certified environments. The framework supports a configuration mode that disables NPU entropy augmentation entirely, operating on certified TRNG output alone.

The AKMS implements Algorithm 2 with the following key lifecycle specifications.

Maximum Key Lifetime Bounds. The key lifecycle state machine, including adaptive rotation and emergency zeroisation paths, is shown in Figure 6. Each cryptographic key K is assigned a maximum lifetime T_max based on the algorithm and key length: T_max(AES-256) = 24 h, T_max(AES-128) = 8 h, T_max(ChaCha20-256) = 24 h, and T_max(Kyber-512) = 48 h. These bounds apply regardless of threat level; the adaptive rotation (Algorithm 2) may rotate keys more frequently, but never less frequently than T_max. A hardware monotonic counter in the secure element tracks key age independently of system time, preventing clock manipulation attacks.

Secure Zeroisation. Upon key retirement, the AKMS executes a three-stage zeroisation procedure: (1) the active key register is overwritten with random data from the TRNG; (2) the register is overwritten with the bitwise complement; (3) the register is overwritten with zeros. This sequence follows NIST SP 800-88 Rev. 1 guidelines for cryptographic key destruction [29]. A tamper-triggered emergency zeroisation circuit can execute all three stages within 50 μs upon detection of physical intrusion at any module, destroying all key material in the secure element before an attacker can extract it.

Key Recovery Mechanism. The AI-AED does not support key escrow to avoid introducing a single point of compromise. Instead, operational continuity is maintained through a key pre-generation buffer: the AKMS maintains a buffer of N_buffer = 8 pre-generated, entropy-validated keys ready for immediate deployment. If the TRNG fails or produces below-threshold entropy, the system draws from this buffer while alerting the operator through the SOM display and audit log. If the buffer is exhausted without TRNG recovery, the device enters a safe-halt state, refusing further encryption operations until the entropy source is restored or physically serviced. This fail-secure design ensures that degraded key material is never used.

The SCI on the AI-CPU rear panel provides Ethernet, USB, and memory card interfaces with protocol-agnostic encryption wrapping. The camera supports QR-based out-of-band key bootstrapping.

4.7. Anti-Downgrade Safeguards

A critical concern with dynamic algorithm selection is the potential for downgrade attacks, whereby an adversary manipulates threat inputs to induce the system to select a weaker cipher configuration. We address this through a monotonic security floor mechanism.

Definition 7 (Security Ordering).

We define a partial order ≤_sec over the action space A such that a₁ ≤_sec a₂ if and only if the security strength of configuration a₁ is less than or equal to that of a₂. The security strength function σ: A → ℝ is defined as

σ(a) = key_bits(a) × cipher_strength(α) × mode_security(m)

where cipher_strength(α) is a normalised rating for each algorithm (e.g., AES-256 = 1.0, ChaCha20 = 1.0, and CRYSTALS-Kyber-512 = 1.1) and mode_security(m) reflects authenticated encryption properties (GCM = 1.0 and CCM = 0.95). Only authenticated modes are included in A; unauthenticated modes (ECB and CBC) are excluded by construction.

Definition 8 (Monotonic Security Floor).

During an active threat escalation period (defined as any interval where s_threat has exceeded threshold τ_escalation = 0.5 within the preceding window T_window), the RLPE is constrained such that

σ(a_{t + 1}) ≥ σ_floor = max(σ(a_t) × δ, σ_min)

where δ ∈ (0.85, 1.0] is the maximum permitted de-escalation rate, and σ_min is the absolute minimum security strength. This prevents rapid oscillation between high and low security states. Full de-escalation to baseline is only permitted after s_threat < τ_baseline = 0.2 for a sustained period T_cooldown (configurable, default 30 min).

Negotiation Attack Prevention. The AI-AED does not implement cipher negotiation with external entities. The CEU unilaterally selects the encryption configuration based on ATAM output. External recipients must support the full cipher library or operate in a pre-agreed fixed-cipher mode, eliminating negotiation-based downgrade vectors entirely.

5. Theoretical Security Analysis

5.1. Formal Threat Model

We define the adversary model by extending the classical Dolev–Yao (DY) network attacker model [30] with physical access capabilities relevant to hardware security devices.

Definition 9 (Network Adversary).

Following Dolev–Yao assumptions, the network adversary A_net can: (i) intercept, record, and replay any message transmitted over the communication channel; (ii) inject arbitrary messages into the channel; (iii) prevent the delivery of any message (denial of service); and (iv) perform computationally bounded cryptanalysis on intercepted ciphertexts. The adversary cannot break the underlying cryptographic primitives within polynomial time bounds.

Definition 10 (Physical Access Tiers).

We define four tiers of physical adversary capability.

Tier 0 (Remote Only): The adversary has no physical access to the device and operates solely as A_net over the communication channel.

Tier 1 (Proximity): The adversary is within physical proximity (<2 m) of the device and can attempt passive side-channel observations, including electromagnetic emanation capture, power consumption monitoring via inductive coupling, and acoustic analysis. The adversary cannot physically contact the device.

Tier 2 (Contact): The adversary has intermittent physical contact with a single module (e.g., a user-facing SIM) but not the AI-CPU or SOM. The adversary can attempt port probing, peripheral injection via USB, and observation of the SIM display and keypad.

Tier 3 (Full Physical): The adversary has sustained physical access to all modules, including the ability to attempt decapsulation, micro-probing, and fault injection. This represents the strongest adversary class.

Definition 11 (Insider Threat).

The insider adversary A_ins possesses valid authentication credentials for at least one factor (e.g., knowledge of a PIN) but does not possess all factors required for the maximum authentication level. A_ins may attempt privilege escalation, session hijacking, or credential theft to access higher-sensitivity operations. The complete threat model with four physical access tiers and module security boundaries is depicted in Figure 7.

The AI-AED’s defences are evaluated against the composite adversary A = A_net ∪ A_phys(Tier k) ∪ A_ins, where k ∈ {0, 1, 2, 3}. The tri-modular architecture specifically addresses Tier 2 adversaries by ensuring that the compromise of any single module does not yield sufficient information to reconstruct cryptographic keys or override AI-driven security policies.

5.2. Information-Theoretic Security Analysis

Theorem 2 (Entropy of Adaptive Encryption).

Let C_s denote the ciphertext produced by a static encryption system using a fixed algorithm α₀ ∈ L, and let C_a denote the ciphertext produced by the AI-AED with adaptive algorithm selection over cipher library L = {α₁, …, α_n}. Then, the conditional entropy of the adaptive ciphertext satisfies the following:

H(C_a|P) = H(C_s|P) + H(α)

where H(α) is the Shannon entropy [31] of the algorithm selection distribution induced by the RLPE policy. This yields

H(C_s|P) < H(C_a|P) ≤ H(C_s|P) + log₂(|L|)

The upper bound is achieved when the policy selects algorithms uniformly; the lower strict inequality holds for any non-degenerate policy (each algorithm selected with non-zero probability).

Important Qualification. Theorem 2 provides an upper bound achievable when the RLPE selects algorithms with maximum entropy (i.e., uniformly). In practice, the RLPE policy will converge to favouring specific algorithms for specific threat states—for example, selecting AES-256-GCM in 70% of normal-operation time steps and ChaCha20-Poly1305 in 25%, with Kyber-related modes only in 5% of high-threat scenarios. Under such a skewed distribution p = (0.70, 0.25, 0.05), the actual algorithm selection entropy is

H(α) = −(0.70 log₂ 0.70 + 0.25 log₂ 0.25 + 0.05 log₂ 0.05) ≈ 1.08 bits

This is substantially below the theoretical maximum of log₂(3) ≈ 1.58 bits. We therefore restate the practical interpretation: the entropy advantage should be understood as H(α) bits, where 0 < H(α) ≤ log₂(|L_enc|), with the actual value determined by the learned policy distribution. The advantage approaches zero if the policy degenerates to always selecting the same algorithm and approaches the maximum only if threat conditions produce roughly uniform algorithm utilisation over time.

Furthermore, this entropy advantage quantifies increased attacker uncertainty about the encryption configuration, not a strengthening of any individual cipher. If the attacker can determine which algorithm was used for a given ciphertext (e.g., through traffic analysis, timing side-channels, or ciphertext length differences), the advantage reduces to zero for that ciphertext. The SCI must therefore ensure that the ciphertext format does not leak algorithm identity. We specify that the CEU pads all ciphertexts to the maximum block size across L_enc and applies constant-time output formatting to prevent timing-based algorithm identification.

Corollary 1.

For the AI-AED symmetric encryption pipeline with |L_enc| = 3, the upper bound on entropy advantage from algorithm selection uncertainty is log₂(3) ≈ 1.58 bits per encryption operation, achievable under uniform cipher selection. Under realistic RLPE operation, where cipher selection is skewed by threat conditions, the actual advantage H(α) will be lower (see Theorem 2 qualification below).

Theorem 3 (Key Entropy Maintenance Under Adaptive Rotation).

Let H(K_t) denote the entropy of the active key at time t, and let the threat-responsive rotation ensure key replacement whenever H(K_t) falls below threshold τ. Then,

H(K_t) ≥ τ for all t ≥ 0

Proof sketch.

The AKMS (Algorithm 2, lines 6–8) continuously monitors key entropy. When H(K_new) < τ (e.g., due to TRNG degradation), the hybrid generation falls back to pure TRNG output with verified entropy. The threat-responsive rotation frequency f_rot = f_base(1 + λs_threat) ensures that under elevated threat (s_threat → 1), rotation frequency increases by a factor of (1 + λ), reducing the window during which any single key is exposed. Combined with the entropy floor check, this ensures the bound holds. □

5.3. Operational Complexity Analysis

We emphasise that dynamic algorithm selection does not invalidate the theoretical foundations of cryptanalysis against any individual cipher in the library L. Each algorithm in L retains its known cryptanalytic properties regardless of whether it is used statically or as part of an adaptive rotation. The security of the AI-AED, therefore, rests on the security of the weakest algorithm in L, not on the rotation itself.

What adaptive rotation does provide is increased operational complexity for an attacker conducting a sustained campaign against the device. Specifically, an attacker targeting a static system can accumulate observations (chosen plaintexts, power traces, and timing measurements) indefinitely under consistent algorithm parameters. Against the AI-AED, the attacker’s observations are partitioned across multiple algorithm configurations, each potentially requiring different attack strategies and tooling.

Definition 12 (Observation Partitioning).

Let N be the total number of observations an attacker can collect over a campaign of duration T. Under adaptive rotation with average configuration lifetime τ_config, the observations are partitioned into approximately N/(N × τ_config/T) = T/τ_config segments. If the attacker requires a minimum of n_min observations under consistent parameters to mount a successful attack against algorithm α_i, then the attack succeeds only if τ_config ≥ n_min/r, where r is the observation collection rate.

This represents an operational constraint on the attacker, not a fundamental cryptographic strengthening. An attacker with sufficient resources could potentially target each algorithm segment independently. The practical value lies in increasing the time and resources required for a successful attack, not in providing information-theoretic guarantees beyond those of the individual ciphers.

5.4. Side-Channel and Physical Security

The ADE monitors power, timing, and electromagnetic signatures. Tri-modular separation constrains side-channel surfaces—compromise of a single module yields incomplete operational data. Each module supports independent tamper detection with key zeroisation.

5.5. Adversarial ML Resilience

Defences include: (i) inference-only ATAM with read-only weights in the secure element; (ii) bounded action space |A| = 216 constraining outputs to pre-validated configurations; (iii) hardware fallback on anomalous outputs; and (iv) multi-modal physical inputs across separate modules, making coherent adversarial crafting infeasible [32,33].

5.6. Post-Quantum Transition Strategy

Supporting CRYSTALS-Kyber and CRYSTALS-Dilithium in the cipher library is a necessary but insufficient condition for quantum resilience. We propose a three-phase migration strategy within the AI-AED framework.

• Phase 1 (Current): Classical-Primary with PQ Monitoring. The system operates primarily with classical algorithms (AES-256, ChaCha20) while the ATAM monitors external quantum threat intelligence feeds. CRYSTALS algorithms are available in L but not selected unless the quantum threat score exceeds a configurable threshold.
• Phase 2 (Transition): Hybrid Mode. When quantum threat indicators reach moderate levels, the CEU activates hybrid encryption mode. In hybrid mode, each plaintext block is encrypted under both a classical and a post-quantum algorithm, and the ciphertext becomes the following concatenation:

C_hybrid = Enc_classical(P, K₁) || Enc_PQ(P, K₂)

Decryption requires successful decryption under both schemes. This ensures that if either the classical or PQ algorithm is subsequently found to have a vulnerability, the other provides continued protection. The cost is approximately doubled ciphertext size and encryption latency (estimated 0.88 ms for AES-256 + Kyber hybrid), which remains within operational bounds.

• Phase 3 (Post-Transition): PQ-Primary. When classical algorithms are assessed as no longer providing adequate security margins, the ATAM transitions to PQ-primary operation, retaining classical algorithms only as a fallback.

Key Encapsulation Migration. For key exchange operations, the AKMS implements hybrid key encapsulation following the approach described in NIST SP 800-227 (draft) [34]: the shared secret is derived as KDF(K_classical || K_PQ || context), where K_classical is derived from ECDH and K_PQ from Kyber encapsulation. This prevents a quantum adversary from recovering the shared secret even if Kyber is later found vulnerable, provided ECDH remains secure (and vice versa).

Algorithm Agility Limitations. We acknowledge that algorithm agility introduces its own risks, including increased code complexity and potential for implementation errors across multiple cipher backends. The AI-AED mitigates this through a fixed, pre-validated cipher library with no runtime code loading; all supported algorithms are compiled into the secure element firmware and cannot be modified in the field. Adding new algorithms requires a firmware update with cryptographic signature verification.

5.7. Theoretical Performance Model

We estimate system latency using published benchmarks for comparable embedded AI and cryptographic hardware.

Table 3. Theoretical latency model for AI-AED pipeline stages. Note: values are derived from published benchmarks across different processor classes (ARM Cortex-A76 for neural inference, Cortex-M4 for post-quantum operations, AES-NI for symmetric encryption) and do not represent measurements from a unified testbed. See text for per-component source details.

Pipeline Stage	Normal (ms)	Threat (ms)	Source Basis
SIM input processing	0.05	0.05	GPIO latency
NNTC inference	0.45	0.45	MobileNetV3 INT8 [35]
ADE evaluation	0.12	0.12	VAE inference [35]
RLPE action selection	0.08	0.08	DQN forward pass
CEU encryption (AES-256)	0.03	—	AES-NI benchmark
CEU encryption (Kyber)	—	0.85	CRYSTALS benchmark [10]
Key rotation (if triggered)	—	1.20	TRNG + install
SOM output processing	0.10	0.10	Bus + render
TOTAL	0.83	2.85

presents the latency breakdown.

The latency estimates in Table 3 are derived from the following published sources. The NNTC inference time (0.45 ms) is based on MobileNetV3-Small INT8 inference on ARM Cortex-A76 class processors, as reported in the MLPerf Tiny benchmark suite [35], scaled for our 8-class classification task (versus ImageNet’s 1000 classes, reducing final layer computation). The ADE evaluation (0.12 ms) reflects a compact variational autoencoder with 3 hidden layers and a 64-dimensional latent space, consistent with edge anomaly detection benchmarks [35]. The RLPE action selection (0.08 ms) represents a single forward pass through a three-layer DQN with 256 hidden units over the 216-action output space. The AES-256-GCM encryption time (0.03 ms per 1 KB block) assumes hardware AES-NI acceleration, which is standard in modern embedded processors. The CRYSTALS-Kyber encapsulation time (0.85 ms) is sourced from NIST PQC Round 3 benchmarking on ARM Cortex-M4 [36]. We note that Table 3 aggregates benchmarks from different processor classes (Cortex-A76 for neural inference, Cortex-M4 for post-quantum operations, AES-NI for symmetric encryption). On a unified Cortex-A76 class SoC—the target platform for the AI-CPU—the Kyber encapsulation time would decrease substantially (estimated 0.15–0.25 ms based on clock frequency scaling), reducing the worst-case pipeline latency. The figures in Table 3 should therefore be interpreted as conservative upper bounds pending prototype benchmarking. The key rotation overhead (1.20 ms) includes TRNG generation, XOR conditioning, entropy validation, and secure key installation in the hardware key register.

The total pipeline latency of 0.83 ms under normal operation assumes sequential execution of all stages without parallelism. In practice, the NNTC and ADE can execute concurrently on the NPU, reducing the effective ATAM latency to approximately max(0.45, 0.12) = 0.45 ms and the total pipeline to approximately 0.71 ms. Under active threat with algorithm transition, the 2.85 ms figure represents the worst case, including both the post-quantum cipher switch and a key rotation event; steady-state operation under elevated threat without rotation events would be approximately 1.58 ms.

For throughput estimation, at 0.83 ms per 1 KB block, the theoretical throughput is 1205 blocks/s (approximately 1.18 MB/s). This is adequate for the device’s intended use cases (secure terminal operations, key management ceremonies, audit-logged transactions) but would not support high-bandwidth bulk encryption. Bulk data encryption would require offloading to a dedicated hardware crypto accelerator operating in pipeline mode, which is architecturally supported but not the primary design target.

Integration Overhead Considerations. The additive latency model above does not account for hardware integration overheads that arise in a unified SoC implementation, including inter-module bus arbitration (typically 0.01–0.05 ms per transaction on ARM AMBA AXI buses), context-switching between NPU and cryptographic accelerator execution contexts (estimated 0.02–0.08 ms depending on cache state), memory access contention when multiple pipeline stages compete for shared SRAM or DRAM bandwidth, and interrupt handling latency for sensor-triggered threat escalation events. Based on published embedded systems benchmarks for comparable multi-accelerator SoC designs, we estimate a cumulative integration overhead of 10–20% above the additive baseline. Applying this correction yields adjusted estimates of approximately 0.91–1.00 ms under normal operation and 3.14–3.42 ms under active threat with algorithm transition. These adjusted figures remain within operationally acceptable bounds for the device’s intended use cases. Cycle-accurate simulation using frameworks such as gem5 is identified as a priority future work to validate these estimates prior to prototype fabrication.

5.8. Worked Scenario: Multi-Stage Attack Response

We illustrate system behaviour through a simulated multi-stage attack escalation. Consider an AI-AED device deployed as a network encryption gateway.

• Stage 0 (Baseline, t = 0): System operates under normal conditions. State: s = (0.05, 0.30, 3, 0.92, 0.83). Action: a = (AES-256, 256, f₂, GCM, 1). The system uses AES-256-GCM with standard rotation and single-factor authentication. Throughput: ~1.18 MB/s.
• Stage 1 (DDoS Onset, t = 12 min): NNTC detects traffic anomaly consistent with volumetric DDoS. Threat vector T = (0.78, 0.05, 0.02, …, 0.10). State updates: s = (0.78, 0.55, 3, 0.92, 1.20). RLPE selects the following: a = (AES-256, 256, f₄, GCM, 2). Key rotation frequency increases from f₂ (every 4 h) to f₄ (every 30 min). Authentication escalates to two-factor (PIN + biometric). The biometric sensor requests fingerprint verification.
• Stage 2 (Side-Channel Probing Detected, t = 18 min): While DDoS continues, the ADE detects anomalous power consumption patterns (reconstruction error exceeds θ by 2.3σ), indicating potential differential power analysis. State: s = (0.91, 0.60, 3, 0.88, 1.45). RLPE selects the following: a = (ChaCha20-Poly1305, 256, f₅, stream, 2). The system switches from AES to ChaCha20 (constant-time implementation resistant to timing attacks) and increases rotation to f₅ (every 5 min). CEU activates dummy operation injection.
• Stage 3 (Quantum Threat Intelligence, t = 25 min): External threat feed reports an elevated quantum computing threat score. State: s = (0.95, 0.65, 3,0.88, 2.10). RLPE selects the following: a = (ChaCha20-Poly1305, 256, f₆, stream, 3). The system maintains ChaCha20-Poly1305 for symmetric encryption (retaining its timing-attack resistance from Stage 2), while the AKMS independently activates hybrid key encapsulation: session keys are now established via KDF(K_ECDH || K_Kyber-768 || context) following NIST SP 800-227 hybrid key derivation. Maximum rotation frequency and three-factor authentication are engaged. The SOM requests smart card token insertion. End-to-end latency increases to ~2.85 ms but remains within operational bounds.
• Stage 4 (Threat Subsides, t = 45 min): NNTC threat scores decline to baseline. State: s = (0.12, 0.40, 3, 0.95, 0.90). RLPE gradually de-escalates: a = (AES-256, 256, f₃, GCM, 1). The system returns to AES-256 with moderately elevated rotation (f₃: every 2 h, slightly above baseline as a precautionary measure) and single-factor authentication. This gradual de-escalation, rather than immediate return to baseline, is a learned behaviour from the RLPE reward structure that penalises rapid oscillation.

This scenario demonstrates the key advantage of the AI-AED: proportional, autonomous response across the full spectrum from benign operations to multi-vector attacks, with graceful transitions between security postures.

5.8.1. Simulation Validation

To validate the MDP formulation and demonstrate policy convergence, we implement a tabular Q-learning agent over the full 216-action space with safety constraint enforcement via action masking. The simulation discretises the continuous state space into 45 states (5 threat levels × 3 resource levels × 3 sensitivity levels) and trains for 1000 episodes of 50 time steps each, using the synthetic five-stage threat trajectory described in Section 5.8.

Reward parameterisation. The reward weights are set to w₁ = 0.5 (security), w₂ = 0.2 (latency), w₃ = 0.1 (resource), and w₄ = 0.2 (adaptation), with discount factor γ = 0.95 and learning rate α = 0.15. Exploration follows ε-greedy decay from ε = 1.0 to ε = 0.05 (decay factor is 0.995). The adaptation term uses the corrected formulation Adapt(s, a) = 1 − |threat_coverage(a) − s_threat|, rewarding proportional response. Under elevated threat, latency and resource penalties are scaled by (1 − 0.4 · s_threat), reflecting operational priorities where security takes precedence over efficiency during active attacks.

Action masking. At each step, the agent’s action selection is restricted to the safe action set A_safe satisfying all four constraints C₁–C₄. Under normal conditions (s_threat ≤ 0.5), 72 of 216 actions survive masking; under elevated threat (s_threat > 0.5), constraint C₃ further reduces this to 48 actions by requiring multi-factor authentication.

Results. 

Table 4. Learned policy configurations across threat stages (Q-learning, 1000 episodes, |A| = 216).

Stage	s_Threat	Cipher	Key (bits)	Rotation	Auth	σ(a)	Latency (ms)
0: Baseline	0.05	AES-256-GCM	256	f3 (2 h)	1	0.500	0.85
1: DDoS Onset	0.78	ChaCha20-Poly1305	256	f6 (cont.)	2	0.500	1.49
2: Side-Channel Probe	0.91	ChaCha20-Poly1305	256	f5 (5 min)	3	0.500	1.74
3: Peak Threat	0.95	ChaCha20-Poly1305	256	f5 (5 min)	3	0.500	1.74
4: Threat Subsides	0.12	AES-256-GCM	256	f3 (2 h)	1	0.500	0.85

Parameters: w₁ = 0.5, w₂ = 0.2, w₃ = 0.1, w₄ = 0.2, γ = 0.95. Safety constraints C₁–C₄ enforced via action masking.

presents the learned greedy policy at each threat stage. The agent converges to configurations that closely match the qualitative behaviour described in the worked scenario (Section 5.8):

The policy exhibits several noteworthy behaviours. First, at baseline, the agent selects AES-256-GCM with moderate rotation (every 2 h) and single-factor authentication—the minimum-cost configuration that satisfies all safety constraints. Second, upon DDoS onset, the agent switches to ChaCha20-Poly1305 with continuous key rotation and two-factor authentication, prioritising constant-time execution and rapid key turnover. Third, under side-channel probing and peak threat, the agent escalates to three-factor authentication while maintaining ChaCha20 (constant-time) and high rotation frequency (every 5 min). Fourth, when the threat subsides, the agent de-escalates to the baseline configuration, demonstrating learned proportional response.

AES-128-GCM is never selected, as it is strictly dominated by AES-256-GCM in the reward function (lower security strength with negligible latency advantage on hardware-accelerated platforms). The effective cipher library under the learned policy is |L_eff| = 2.

Convergence. Mean episode reward increases from 22.38 ± 0.41 (episodes 1–100) to 25.75 ± 0.79 (episodes 901–1000), representing a 15.1% improvement (Figure 8). Policy stability analysis over the final 200 episodes shows 100% agreement at Stages 0, 2, 3, and 4, with 76% dominant configuration at Stage 1 (the transition from baseline to elevated threat, where state noise causes boundary effects).

Safety verification. Throughout all 1000 episodes, the minimum security strength during escalation periods was σ(a) = 0.500, exceeding σ_min = 0.35 (C₁ satisfied). Authentication levels during high-threat periods (s_threat > 0.5) were always ≥ 2 (C₃ satisfied). No unsafe action was ever executed.

Entropy analysis. Under the learned policy, the cipher selection distribution across the threat trajectory is approximately 39.9% AES-256-GCM and 60.1% ChaCha20-Poly1305, yielding H(α) ≈ 0.97 bits. This is consistent with the bound established in Theorem 2: 0 < H(α) = 0.97 < log₂(3) ≈ 1.58 bits, and confirms that realistic policy distributions produce entropy advantages below the theoretical maximum.

Figure 9 illustrates the learned policy response over a single episode, showing threat level, cipher/rotation selection, and authentication escalation across the five stages.

Limitations. This simulation uses tabular Q-learning with a discretised state space as a proof-of-concept validation. The reward weights (w₀–w₄) were selected to produce operationally reasonable behaviour; systematic weight optimisation through sensitivity analysis is identified as future work.

5.8.2. DQN Validation over Continuous State Space

To evaluate the DQN architecture proposed in Section 4.3 and address the limitations of state-space discretisation, we implement a Deep Q-Network operating directly on the continuous four-dimensional state representation (threat level, network latency, resource utilisation, and current encryption strength) without manual binning. The DQN uses a feedforward network with two hidden layers of 64 units each, ReLU activations, and a 216-unit output layer corresponding to the full action space. Training uses experience replay (buffer size 10,000), a target network updated every 50 episodes, batch size 64, and the same ε-greedy exploration schedule as the tabular baseline (ε decaying from 1.0 to 0.05). CMDP safety constraints C₁–C₄ are enforced via action masking identically to the tabular agent. Both agents train for 1000 episodes of 100 timesteps each on the same stochastic environment with seed 42 for reproducibility. The implementation uses Python (v3.10), NumPy (v1.24), and matplotlib (v3.7) with manual backpropagation, requiring no deep learning framework dependencies.

Convergence. Figure 10 presents the convergence comparison. The tabular agent achieves a higher final average reward (14.63 vs. 10.64 over the last 100 episodes), but with substantially greater variance (standard deviation 5.48 vs. 3.95). The tabular agent’s higher reward is partially an artefact of discretisation: by collapsing continuous states into discrete bins, the tabular agent can exploit boundary regions more aggressively, selecting configurations that yield higher immediate reward at the cost of increased constraint violations. The DQN’s lower variance indicates more consistent policy execution across the continuous state space.

Safety constraint compliance. Figure 11 shows CMDP constraint violations during training. The DQN achieves 82% fewer total constraint violations than the tabular baseline (297 vs. 1627 over 1000 episodes). More critically, the tabular agent’s violation rate increases over time (rising after episode 600 as the agent exploits discretisation boundaries), while the DQN maintains near-zero violations throughout (0.06 violations per episode in the last 100 episodes vs. 2.92 for tabular). This result directly validates the DQN’s advantage for safety-critical CMDP enforcement: the continuous state representation avoids the boundary-crossing artefacts inherent in manual discretisation.

Threat response. Figure 12 compares policy response under four threat scenarios (low steady state, gradual escalation, spike attack, and oscillating threats). The DQN responds to threat escalation in 1.40 timesteps on average, compared to 8.20 for the tabular agent—a 6× improvement in response time. This speed advantage is attributable to the DQN’s ability to process continuous threat gradients without waiting for the state to cross a discrete bin boundary. Both agents achieve proportional threat response, but the DQN exhibits smoother transitions between security postures, consistent with its lower action-switching rate (0.645 vs. 0.694).

Table 5. Comparative simulation metrics: Tabular Q-learning vs. DQN (1000 episodes, |A| = 216, seed = 42).

Metric	Tabular Q-Learning	DQN
Final average reward (last 100 eps)	14.63	10.64
Standard of reward (last 100 eps)	5.48	3.95
Total constraint violations	1627	297 (82% fewer)
Average violations/ep (last 100)	2.92	0.06
Response time to threat escalation	8.20 steps	1.40 steps
Action-switch rate	0.694	0.645 (more stable)

summarises the comparative metrics. The key finding is that while the tabular agent achieves marginally higher raw reward (an artefact of discretisation-enabled boundary exploitation), the DQN is superior on every safety-relevant metric: 82% fewer constraint violations, 6× faster threat response, lower reward variance, and more stable policy switching. For a safety-critical CMDP where constraint satisfaction is paramount, the DQN’s continuous state handling provides clear advantages over manual discretisation.

Figure 13 visualises the DQN’s learned policy across the threat level × resource utilisation state space. Figure 13a shows the maximum Q-value surface: Q-values are highest in the high-threat, low-resource region (top-left), where the agent can deploy strong encryption without resource contention, and lowest in the low-threat, high-resource region (bottom-right), where minimal security suffices. Figure 13b shows the preferred algorithm at each state: above the CMDP safety threshold (dashed line at threat = 0.7), weak algorithms (AES-128-GCM, Kyber-512) are excluded by action masking, and the policy favours Kyber-768 and Kyber-1024 for post-quantum protection. Below the threshold, the policy selects a broader mix of algorithms, with AES-256-GCM and ChaCha20-Poly1305 dominating at lower resource utilisation.

Limitations. Both simulations operate in a synthetic environment with stochastic threat dynamics; real-world deployment would involve more complex, non-stationary threat distributions. The DQN architecture (two hidden layers, 64 units) was selected for tractability in a pure NumPy implementation; larger networks with framework-optimised training may yield further improvements. Systematic reward weight optimisation through sensitivity analysis and transfer learning from simulation to physical prototype are identified as future work.

5.9. Comparative Security Properties

The comparison in

Table 6. Comparative security properties.

Property	Static HSM	SW AI-Sec	Context-Aware	AI-AED (Ours)
Algorithm selection	Fixed	Limited	Partial	MDP-optimised
Threat response	None	~100 ms	None	<3 ms
Key rotation	Fixed	Software	Rule-based	RL-driven
Entropy advantage	0 bits	~1 bit	~1 bit	up to +1.58 bits
Biometrics	External	No	No	Integrated
PQ-ready	FW update	SW update	FW update	Autonomous
Module isolation	Monolithic	N/A	Monolithic	Tri-modular

reflects architectural capabilities rather than empirical measurements. The “~100 ms” threat response time for software AI security systems is based on typical inference latencies for deep learning IDS models deployed on general-purpose servers [13,16], which include operating system scheduling overhead absent in dedicated hardware. The “~1 bit” entropy advantage attributed to software AI security and context-aware systems reflects the limited algorithm selection typically available in these frameworks (usually a choice between two configurations, yielding at most log₂(2) = 1 bit). These comparison values are estimates intended to illustrate architectural differences and should not be interpreted as precise benchmarks. Rigorous empirical comparison would require prototype implementation of all four system types under controlled conditions, which we identify as essential future work.

We caution that Table 6 is intended as a qualitative architectural comparison, not a quantitative benchmark. The column values represent design-level capabilities, not measured performance. A rigorous empirical comparison is identified as priority future work (Section 7, item 1).

6. Discussion

6.1. Theoretical Advantages

The AI-AED offers three formally grounded advantages. First, Theorem 2 establishes a quantifiable entropy advantage of log₂(|L|) bits over static systems. Second, the MDP formulation provides a principled framework for balancing security, latency, and resource trade-offs—unlike heuristic rule-based systems, the RL policy converges to an optimal balance for each deployment context, as validated by the DQN simulation (Section 5.8.2), demonstrating 82% fewer constraint violations than tabular discretisation. Third, the tri-modular hardware architecture provides physical isolation, guaranteeing that module compromise does not propagate, a property unattainable through software isolation alone.

6.2. Limitations

Key limitations include: (i) the entropy analysis assumes algorithm selection independence from plaintext, which must be enforced by design; (ii) while the DQN validation (Section 5.8.2) demonstrates superior constraint compliance over continuous states compared to tabular discretisation, both simulations operate in a synthetic environment with stochastic threat dynamics; (iii) the performance model relies on published benchmarks with an estimated 10–20% integration overhead (Section 5.7), pending validation through cycle-accurate simulation; (iv) formal verification of the RL policy against safety constraints remains an open challenge; and (v) empirical validation through prototype implementation is essential to confirm theoretical predictions.

6.3. Regulatory Context

Deployment requires compliance with the EU AI Act for autonomous ATAM decisions, UK GDPR for biometric processing, Wassenaar Arrangement for encryption export controls, and potential Common Criteria/FIPS 140-3 certification for government use.

7. Future Work

Priorities: (1) FPGA prototype to validate the performance model predictions; (2) cycle-accurate latency simulation using gem5 or its equivalent to validate integration overhead estimates; (3) penetration testing per NIST SP 800-115; (4) formal safety verification of the MDP policy using constrained RL methods; (5) federated learning across deployed devices; and (6) extension of Theorem 2 to account for correlated algorithm selection under persistent threats.

8. Conclusions

This paper presented a formally grounded framework for an AI-Driven Adaptive Encryption Device integrating machine learning into a tri-modular hardware architecture. The key formal contributions include: an MDP formulation with 216-configuration action space for optimal encryption policy; an information-theoretic analysis establishing an upper bound of log₂(3) ≈ 1.58 bits of entropy advantage from adaptive algorithm selection over static systems, with realistic policy distributions yielding lower values; algorithmic specifications for the threat analysis, key rotation, and authentication escalation pipelines; a performance model estimating sub-3 ms response under active threat including integration overhead; and a worked scenario demonstrating proportional multi-stage attack response. Simulation validation over 1000 episodes comparing tabular Q-learning against the proposed DQN over the continuous state space demonstrates that the DQN achieves 82% fewer CMDP constraint violations, 6× faster threat response (1.40 vs. 8.20 timesteps), and more stable policy switching, confirming the advantage of continuous-state reinforcement learning for safety-critical adaptive encryption. Prototype implementation and cycle-accurate latency validation are identified as priority future work.

9. Patents

UK Registered Design No. 6488506 (Registered: 27 November 2025; Renewal: 27 November 2030), UK Intellectual Property Office.