I’ve been reviewing IronClaw’s latest technical documentation and architecture whitepapers in the context of our own compliance prep (we’re gearing up for a SOC 2 Type II), and a recurring thought keeps nagging at me. The promise of hardware enclaves for isolating agent execution is compelling from a logical access and data-in-use perspective, but I think we might be over-indexing on that boundary as a complete security solution.

Specifically, when we scope our agent runtime into the audit, the auditors are inevitably going to ask about threats beyond software isolation. In our case, we’re using a major cloud provider’s confidential computing offering for our most sensitive agent workloads, which is conceptually similar to IronClaw’s approach. During our pre-assessment meetings, the lead auditor immediately zoomed in on shared hardware threats. Their line of questioning wasn't about the enclave’s cryptographic attestation, but about what happens beneath it:

* **Resource contention channels:** If a malicious tenant’s workload is co-located on the same physical CPU as our enclave, can they infer something about our agent’s behavior or data through patterns in cache usage, memory bandwidth, or power draw? Even basic timing attacks on function execution could leak prompts or decision logic.
* **Management console exposure:** The hypervisor and host management layer are still outside the enclave. Our evidence for the "Logical Access" controls (CC6.1, etc.) relies on the cloud provider’s own SOC 3 report, but that doesn’t eliminate the threat of a compromised host OS being used to mount a side-channel attack.
* **Supply chain for the hardware itself:** This veers into ISO 27001 A.8.31 (Security of development, test and production environments) and A.8.33 (Protection of information systems during audit testing). How do we, or IronClaw, account for the trust in the CPU manufacturer’s microcode and the integrity of the hardware root of trust? It’s a subservice dependency that’s almost impossible for us to assess.

In practice, this creates a tangible control gap in our security matrix. We can document administrative controls (like "we use enclaves") and cryptographic controls (attestation on startup), but the operational detective controls are virtually nonexistent. We aren’t monitoring for anomalous hardware-level behavior because we have no visibility into it. An auditor could rightly flag that our "Protection of Information Systems" control set is incomplete because we’ve accepted a residual risk we aren't actively watching.

I’m curious how others are handling this in their compliance frameworks. Are you:
* Accepting this risk with a note in your risk register, given the high barrier to execution for such attacks?
* Implementing any form of runtime shuffling or noise injection to mitigate timing channels?
* Pushing your cloud providers for more telemetry from the confidential computing host layer?
* Or, pragmatically, arguing that the threat model for most agentic workloads (outside of maybe highly sensitive financial or health agents) doesn’t yet justify the extreme cost and complexity of trying to mitigate hardware-level side-channels?