Hardware Enclave Policy Governance requires that organisations define and enforce a policy specifying which AI agent workloads must execute within approved trusted hardware environments or hardware-enforced isolation boundaries, based on the risk tier, data sensitivity, and regulatory requirements of each workload. Trusted execution environments, confidential computing enclaves, and hardware-enforced memory isolation provide protections that software-only isolation cannot guarantee — including defence against privileged insiders, compromised hypervisors, and co-tenant side-channel attacks. This dimension mandates that enclave requirements are governed as policy artefacts, that enclave attestation is verified before workloads process sensitive data, and that the organisation maintains continuous assurance that hardware isolation is operational throughout the workload lifecycle — not merely at deployment time.
Scenario A — Model Weights Extracted via Hypervisor Compromise: A financial-value agent deployed in a multi-tenant cloud environment uses a proprietary risk-scoring model trained on 7 years of institutional trading data. The model weights represent approximately EUR 12 million in development investment and contain embedded patterns that, if extracted, would reveal proprietary trading strategies. The agent runs on standard virtual machines without hardware-enforced isolation. A sophisticated attacker compromises the cloud provider's hypervisor layer through a supply-chain vulnerability in a management component. The attacker extracts memory snapshots from 340 virtual machines on the affected host, including the financial agent's VM. The memory snapshot contains the full model weights in plaintext. The attacker sells the extracted model weights to a competing institution. The theft is discovered 8 months later when the competing institution's trading patterns begin to statistically mirror the victim's strategies.
What went wrong: The proprietary model weights were processed in standard virtual machine memory without hardware-enforced encryption or isolation. The hypervisor — a privileged software layer outside the organisation's control in a multi-tenant cloud — had full access to the VM's memory contents. No hardware enclave or confidential computing technology was used to encrypt memory contents against the hypervisor. The organisation's risk assessment classified the model as "highly sensitive" but the infrastructure team deployed it on standard compute because no hardware enclave policy existed to translate risk classifications into infrastructure requirements. Consequence: EUR 12 million in model development value compromised, competitive advantage lost, 14-month forensic investigation costing EUR 1.3 million, litigation against the cloud provider ongoing with uncertain outcome.
Scenario B — Patient Data Exposed Through Co-Tenant Side-Channel Attack: A healthcare AI agent processes diagnostic imaging data for 23 hospitals, running inference on shared GPU infrastructure in a cloud environment. The agent processes approximately 4,500 diagnostic images per day, each associated with patient identity, medical history, and diagnostic results. A research team at a university sharing the same GPU cluster publishes a paper demonstrating a practical side-channel attack against GPU shared memory that can reconstruct portions of data processed by co-tenant workloads. The research team did not target the healthcare agent specifically — they demonstrated the attack on their own test workloads — but the published technique is directly applicable. The healthcare organisation's security team assesses the exposure and determines that patient data processed on shared GPU infrastructure over the preceding 14 months may have been accessible to co-tenant workloads through the demonstrated side-channel. The organisation must notify 23 hospital partners and their respective data protection authorities.
What went wrong: The healthcare AI agent processed highly sensitive patient data on shared GPU infrastructure without hardware-enforced isolation between tenants. The organisation relied on software-level isolation (container boundaries, process-level memory protection) that does not defend against hardware-level side-channel attacks. No hardware enclave policy required that workloads processing special-category personal data use hardware-enforced isolation. The shared GPU infrastructure was selected for cost efficiency without a governance assessment of isolation requirements. Consequence: Data protection notifications to 23 hospitals and their supervisory authorities, estimated 180,000 potentially affected patient records, regulatory investigation under GDPR Article 32 (appropriate technical measures), remediation costs estimated at EUR 4.7 million including infrastructure migration to isolated GPU infrastructure, patient notification, and regulatory engagement.
Scenario C — Crypto Wallet Signing Keys Exposed in Unprotected Memory: A crypto/web3 agent manages a portfolio of digital assets worth approximately USD 34 million, executing automated trading, staking, and rebalancing operations. The agent holds private signing keys in application memory during transaction signing operations. The agent runs on a standard cloud instance without hardware security module integration or trusted execution environment isolation. A memory-scraping malware infection — introduced through a compromised dependency in the agent's monitoring stack — scans process memory for cryptographic key patterns. The malware identifies and exfiltrates 4 private signing keys. Within 6 hours of exfiltration, the attacker drains USD 8.2 million from the associated wallets across three blockchain networks.
What went wrong: Private signing keys were held in unprotected application memory without hardware-enforced isolation. No hardware enclave policy required that cryptographic key operations for high-value digital assets occur within a trusted execution environment or hardware security module. The agent's risk tier (managing USD 34 million in assets) should have mandated hardware-level key protection, but no policy translated the risk tier into hardware isolation requirements. The compromised dependency had access to the same memory space as the signing operations because no hardware boundary separated them. Consequence: USD 8.2 million in direct asset loss (irrecoverable on-chain), USD 2.1 million in incident response and forensics, client remediation and compensation costs of USD 5.4 million, regulatory enforcement action for inadequate custody controls.
Scope: This dimension applies to every AI agent deployment where workloads process data or perform operations that, if exposed to co-tenants, privileged infrastructure operators, or attackers with hypervisor-level access, would create material risk to the organisation, its clients, or affected individuals. This includes but is not limited to: processing of personal data classified as special categories under GDPR, processing of financial transaction data or credentials, handling of cryptographic keys or signing operations, inference using proprietary models whose weights constitute trade secrets, and safety-critical decision-making where integrity of the compute environment must be assured. The scope encompasses the full compute lifecycle: model loading, inference execution, result generation, and any transient state held in memory during processing. Organisations must assess their agent portfolio against this scope and classify each workload's hardware enclave requirements based on risk tier — the policy governs which workloads require hardware isolation, not whether any particular hardware technology is used. The test is: if an attacker with hypervisor-level access could observe the workload's memory during operation, would the exposure create material regulatory, financial, or safety risk? If yes, this dimension applies in full.
4.1. A conforming system MUST maintain a hardware enclave policy that classifies each AI agent workload into hardware isolation tiers based on data sensitivity, risk classification, and regulatory requirements, specifying which workloads require hardware-enforced isolation (such as trusted execution environments, confidential computing, or hardware security modules) and which may operate on standard compute infrastructure with documented risk acceptance.
4.2. A conforming system MUST verify hardware enclave attestation before any workload classified as requiring hardware isolation is permitted to process sensitive data, confirming that the enclave is genuine, has not been tampered with, is running approved firmware and software, and meets the isolation guarantees specified in the hardware enclave policy.
4.3. A conforming system MUST implement continuous attestation or periodic re-attestation of hardware enclaves during workload operation — not solely at deployment time — with a re-attestation interval not exceeding 24 hours for high-risk workloads and 72 hours for other enclave-protected workloads.
4.4. A conforming system MUST ensure that cryptographic keys, signing operations, and credential material used by AI agents classified in the highest risk tier are processed exclusively within hardware-enforced isolation boundaries, and that key material never exists in plaintext outside those boundaries during any phase of operation.
4.5. A conforming system MUST log all enclave lifecycle events — including attestation successes, attestation failures, enclave provisioning, enclave teardown, firmware updates, and policy violations — with timestamps, workload identifiers, enclave identifiers, and attestation results.
4.6. A conforming system MUST subject hardware enclave policy changes to formal change control requiring approval by both the security function and the governance or compliance function, with documented risk assessment for any change that reduces isolation requirements for a workload.
4.7. A conforming system MUST conduct hardware enclave integrity testing at least annually, verifying that enclave attestation mechanisms detect tampered or non-genuine enclaves and that workloads are correctly prevented from processing sensitive data when attestation fails.
4.8. A conforming system SHOULD implement enclave-aware workload scheduling that automatically routes workloads to enclave-capable infrastructure based on the hardware enclave policy, preventing human error in workload placement.
4.9. A conforming system SHOULD maintain a hardware enclave technology registry documenting the approved enclave technologies, their security properties, known vulnerabilities, firmware versions, and the risk tiers they are approved for, updated at least quarterly or upon disclosure of a relevant vulnerability.
4.10. A conforming system SHOULD implement defence-in-depth isolation combining hardware enclaves with network isolation (per AG-399), software-level container isolation, and memory encryption to provide layered protection even if any single isolation mechanism is compromised.
4.11. A conforming system MAY implement remote attestation verification services that allow external auditors or regulators to independently verify that a workload is executing within a genuine, uncompromised hardware enclave without requiring physical access to the infrastructure.
Software-only isolation mechanisms — virtual machines, containers, process boundaries, and access control lists — share a fundamental limitation: they are enforced by software running at a higher privilege level. A compromised hypervisor can read any virtual machine's memory. A compromised container runtime can access any container's filesystem. A compromised operating system kernel can inspect any process's address space. For AI agent workloads processing highly sensitive data, the question is not whether software isolation is "good enough" in normal operation — it is whether the organisation can accept the risk that a single compromise of a privileged software layer exposes every workload on that host.
Hardware-enforced isolation addresses this by creating trust boundaries that are enforced by the hardware itself, independent of software privilege levels. A hardware enclave encrypts memory contents with keys that are inaccessible to the hypervisor, the operating system, and even physical memory access. A hardware security module performs cryptographic operations in a tamper-resistant boundary that does not expose key material to the host system. These hardware guarantees are not absolute — hardware vulnerabilities exist and are periodically discovered — but they represent a fundamentally different trust model than software-only isolation.
Three factors make hardware enclave governance essential for AI agent deployments. First, AI agents process sensitive data at inference time. Unlike traditional applications where sensitive data may be encrypted at rest and only briefly decrypted for processing, AI agents hold large volumes of data in active memory during inference — model weights, input data, intermediate activations, and output results are all simultaneously present in memory. This creates a large and persistent attack surface for memory-based attacks. Scenario A illustrates this: the model weights were fully present in VM memory, accessible to any hypervisor-level attacker.
Second, AI agents in multi-tenant environments share hardware with unknown co-tenants. Cloud GPU infrastructure, in particular, has demonstrated side-channel vulnerabilities that cross tenant boundaries (Scenario B). The shared nature of cloud infrastructure means that the organisation's threat model must include co-tenant attacks, not just external attacks. Hardware enclaves with memory encryption defend against co-tenant side-channels because the shared hardware operates on encrypted data that the co-tenant cannot decrypt.
Third, AI agents managing digital assets or executing financial transactions hold cryptographic key material that has immediate, irreversible financial value. A private key extracted from memory can drain a wallet in minutes (Scenario C: USD 8.2 million in 6 hours). There is no recall, no chargeback, and no reversal. The only defence is ensuring that key material never exists in plaintext outside a hardware-enforced boundary. Hardware security modules and trusted execution environments provide this guarantee; software-only isolation does not.
The regulatory environment reinforces hardware isolation requirements. GDPR Article 32 requires "appropriate technical and organisational measures" to ensure data security — regulators have increasingly interpreted this as requiring hardware-level protections for special-category data in multi-tenant environments. DORA Article 9 requires financial entities to implement ICT risk management measures proportionate to the risk — processing financial data alongside unknown co-tenants without hardware isolation is disproportionate to the risk. The EU AI Act Article 15 requires robustness against attacks — hardware enclaves provide robustness against a class of attacks (privileged insider, hypervisor compromise, side-channel) that software-only controls cannot address.
Hardware Enclave Policy Governance requires that organisations systematically assess which workloads need hardware-enforced isolation, deploy those workloads on appropriately isolated infrastructure, verify isolation through attestation, and maintain continuous assurance throughout the workload lifecycle. The core principle is that the risk tier of the data and operations determines the isolation tier of the infrastructure — and this determination is a governed policy decision, not an infrastructure team default.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Financial-value agents and crypto/web3 agents handle the highest-value data in terms of immediate financial consequence. Signing keys for digital asset custody (Scenario C) must be protected in hardware security modules or equivalent — this is a regulatory expectation in most financial jurisdictions. Proprietary trading models (Scenario A) represent significant intellectual property that can be monetised immediately if stolen. Financial services firms should classify most AI agent workloads at Tier 1 or Tier 2 in the hardware isolation matrix.
Healthcare. Patient data classified as special-category personal data under GDPR requires the highest level of technical protection. Shared GPU infrastructure processing diagnostic images (Scenario B) is a high-risk pattern. Healthcare organisations should require hardware-enforced isolation for all workloads processing identifiable patient data, with particular attention to GPU workloads where side-channel research is active and evolving.
Crypto and Web3. Digital asset custody is the domain where hardware enclave failures have the most immediate and irreversible consequences. Private key compromise leads to permanent asset loss with no recourse. Crypto/web3 agents must be classified at the highest hardware isolation tier with mandatory hardware security module integration for all signing operations. The agent's entire key lifecycle — generation, storage, usage, and destruction — must occur within hardware-enforced boundaries.
Safety-Critical and Embodied Agents. Safety-critical agents must assure the integrity of their compute environment — the safety guarantees depend on the agent running the correct, untampered code. Hardware attestation provides this assurance by cryptographically verifying the code running in the enclave before the agent is permitted to make safety-critical decisions. Embodied agents deployed in edge environments face additional challenges: edge hardware may have more limited enclave capabilities than cloud infrastructure, and physical access to edge devices creates additional attack vectors.
Basic Implementation — The organisation has documented a hardware enclave policy classifying each AI agent workload into hardware isolation tiers. Workloads classified as requiring hardware isolation are deployed on enclave-capable infrastructure. Attestation is verified at workload deployment. Cryptographic key operations for the highest risk tier occur within hardware-enforced boundaries. Enclave lifecycle events are logged. The policy is change-controlled.
Intermediate Implementation — All basic capabilities plus: continuous attestation with re-attestation at least every 24 hours for high-risk workloads. Attestation-gated workload initialisation prevents sensitive data access before attestation succeeds. Enclave-aware secret injection seals credentials to enclave measurements. A hardware enclave technology registry documents approved technologies, their properties, and known vulnerabilities. Annual enclave integrity testing verifies that attestation mechanisms detect tampered enclaves.
Advanced Implementation — All intermediate capabilities plus: hardware vulnerability monitoring with 48-hour impact assessment and 30-day remediation timelines. Remote attestation verification enables independent audit. Defence-in-depth combines hardware enclaves with network isolation, container isolation, and memory encryption. Enclave-aware workload scheduling automates placement based on policy. The organisation can demonstrate through independent testing that sensitive data is inaccessible to hypervisor-level attackers, co-tenant side-channels, and memory-scraping malware for all enclave-protected workloads.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Enclave Policy Classification Enforcement
Test 8.2: Attestation-Gated Data Access
Test 8.3: Tampered Enclave Detection
Test 8.4: Continuous Re-Attestation Compliance
Test 8.5: Cryptographic Key Isolation Verification
Test 8.6: Enclave Policy Change Control
Test 8.7: Enclave Lifecycle Event Logging
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| GDPR | Article 32 (Security of Processing) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Supports compliance |
| NIST AI RMF | MANAGE 2.2, MANAGE 4.1, MAP 3.4 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Annex B | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework) | Direct requirement |
Article 15 requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities. A hypervisor compromise that extracts model weights (Scenario A) or a side-channel attack that exposes patient data (Scenario B) are precisely the types of attacks that Article 15 requires resilience against. Hardware enclaves provide a concrete technical mechanism for this resilience by encrypting data in use and isolating workloads from privileged software layers. Organisations deploying high-risk AI systems in multi-tenant environments without hardware-enforced isolation will find it difficult to demonstrate Article 15 compliance when the known threat of hypervisor-level attacks is not addressed.
Article 32 requires controllers and processors to implement "appropriate technical and organisational measures" including "as appropriate... encryption" and the "ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems." Supervisory authorities have increasingly interpreted "appropriate" in the context of multi-tenant cloud environments as requiring hardware-level protections for special-category personal data. Processing diagnostic imaging data on shared GPU infrastructure without hardware isolation (Scenario B) is unlikely to satisfy the "appropriate technical measures" standard when the known risk of GPU side-channel attacks exists and hardware-enforced mitigation is commercially available.
DORA requires financial entities to identify, classify, and adequately manage ICT risks, including risks arising from multi-tenant infrastructure. The extraction of proprietary model weights (Scenario A) and the theft of signing keys (Scenario C) represent ICT risks that hardware enclaves directly mitigate. DORA's proportionality principle requires measures that are proportionate to the risk — for financial agents managing significant assets or processing sensitive financial data, hardware-enforced isolation is a proportionate measure given the severity and irreversibility of potential losses.
Financial processing models whose integrity cannot be assured represent a material weakness in internal controls. If an attacker can modify model weights in memory (because no hardware isolation protects them), the model's outputs — which may feed into financial reporting — cannot be trusted. SOX auditors will assess whether the organisation has adequate controls over the integrity of AI models used in financial processing. Hardware attestation provides a verifiable control that the model running in production is the approved, untampered model.
The FCA expects firms to establish and maintain adequate systems and controls to manage risks. For AI agents processing financial data or executing transactions, the FCA expects controls proportionate to the risk. Hardware enclaves provide a control over data-in-use security that software-only controls cannot match. Firms using AI agents for regulated activities on multi-tenant infrastructure should expect FCA scrutiny of their hardware isolation controls.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Workload-level for data exposure, but potentially organisation-wide for model weight theft or signing key compromise — a single key extraction can compromise an entire asset portfolio |
Consequence chain: A workload processes sensitive data or performs cryptographic operations without adequate hardware-enforced isolation. The immediate technical exposure is that data in use — model weights, inference inputs, inference outputs, cryptographic keys, or intermediate computations — is accessible to entities with hypervisor-level privilege, co-tenants sharing physical hardware, or malware with elevated host-level access. The attack surface is large because AI inference holds data in memory for extended periods and across large memory regions. The data exposure consequences vary by workload type but are uniformly severe: proprietary model weight extraction (Scenario A: EUR 12 million development value, competitive advantage destroyed), patient data exposure through side-channel (Scenario B: EUR 4.7 million remediation, 180,000 potentially affected patients), or cryptographic key theft (Scenario C: USD 8.2 million irrecoverable asset loss in 6 hours). The regulatory consequences compound the direct losses: GDPR Article 32 enforcement for inadequate technical measures, DORA enforcement for inadequate ICT risk management, potential EU AI Act enforcement for insufficient robustness against known attacks. The temporal dimension is critical — model weight theft and key theft are often detected months after the event (Scenario A: 8 months), during which the attacker continues to derive value from the stolen assets. The reputational damage is amplified by the nature of the failure: the organisation chose to process sensitive data on inadequately isolated infrastructure, and the risk was known and commercially mitigable. The failure is not a zero-day exploit of unknown hardware — it is a governance failure to require known, available protections for known, documented risks.
Cross-references: AG-399 (Region Pinning Governance), AG-012 (Credential & Secret Lifecycle Governance), AG-401, AG-405, AG-407, AG-006, AG-370, AG-372.