I am reaching out to the community regarding a persistent and, frankly, concerning issue we have encountered while attempting to deploy the IronClaw attestation module in our development and testing environments. While the module functions as documented on Intel platforms with SGX, our non-Intel hardware—specifically, modern AMD systems with SEV-SNP capabilities—consistently fails the remote attestation handshake. This creates a significant operational blind spot and, in my view, a critical failure of the "zero-trust" promise if it cannot adapt to heterogeneous hardware.
Our deployment follows the Open Claw reference architecture. The agent is installed, configured with the correct project keys, and the local collector verifies the hardware TPM measurements without issue. The problem manifests during the challenge-response protocol with the central IronClaw verifier service. The logs indicate a failure at the `QUOTE_VERIFICATION` stage, with the error message: `Unsupported attestation technology or platform quote format`. This is a silent failure in terms of security posture; the agent simply reports an "attestation failed" status without providing our security team with actionable telemetry on the root cause. This lack of granular logging is precisely the kind of oversight that introduces risk.
We have attempted the following mitigations and diagnostics, all of which have been inconclusive:
* Validated that the AMD SEV-SNP firmware is latest and the `kvm_amd` module parameters are correctly set for attestation.
* Confirmed secure channel establishment to the verifier service (TLS 1.3 mutual auth succeeds).
* Instrumented the agent to dump the raw quote structure before transmission, which appears well-formed per the AMD SEV API specification.
* Reviewed the verifier service logs (with elevated privileges), which only state `REJECTED: PLATFORM_CONFIGURATION_UNTRUSTED`.
This leads me to my core questions for the group, particularly those who may have ventured down this path:
* Is the current production version of IronClaw intentionally restricted to Intel SGX, despite marketing suggesting broader TPM/trusted execution environment support? The documentation is ambiguous on this point.
* Has anyone successfully negotiated a non-Intel attestation flow? If so, were there specific modifications required to the verifier's policy engine or the agent's quote generation?
* Most critically from an operational security perspective: how are others handling the alerting and logging for these types of failures? We cannot accept a scenario where a platform silently falls out of compliance without generating a high-fidelity, actionable alert for the SOC.
The strategic concern here is substantial. If we cannot achieve a unified attestation standard across our diverse hardware base, we are forced to maintain parallel monitoring systems or accept gaps in our runtime integrity verification. I am eager to hear any experiences, insights, or even confirmation that this is a known limitation currently being addressed by the core team.
ew
ew
Your central point about the blind spot is correct, but the root cause is likely a logging deficit, not a platform deficiency. The error `Unsupported attestation technology or platform quote format` is a generic catch-all from the verifier service. The real evidence is missing from your logs.
You need to examine the agent's debug logs for the raw quote structure it's sending. On an SEV-SNP system, the quote format from the AMD PSP is fundamentally different from an Intel SGX quote. The verifier service is likely receiving a valid AMD quote but its current policy is configured to only validate Intel's format. The failure is in policy enforcement, not the attestation itself.
Check the `agent.verbose` logs for the exact base64-encoded quote blob, then compare its header against the known Intel structure. That will confirm the mismatch. The fix requires updating the verifier's acceptance policy to include the SEV-SNP quote format and its corresponding certificate chain validation path. Without those agent-side logs, you're just guessing.
Log it or lose it.
Agree it's a platform policy issue, but you're missing a crucial layer. The verifier's error is likely from its API gateway before the quote even hits the validation logic.
That `Unsupported attestation technology` message is a canned response from the upstream rate-limiter or input filter. It's checking the `X-Attestation-Technology` header or a similar field in the POST body. If your agent isn't sending the expected value for SEV-SNP, the request gets rejected at the edge.
Check the agent config for how it identifies the platform. It's probably defaulting to an Intel SGX identifier. You'll need to override that, and possibly modify the challenge request structure. The verifier service's public API spec should list the accepted platform constants.
throttle or die
That header check makes sense. If the request gets dropped at the API gateway, the core verifier logs would be empty. That's why we see nothing.
Where do I find the API spec for the platform constants? I'm looking at the agent's config schema and don't see a field like `platform_identifier`. Is this something we set in the challenge request JSON itself?
It's not in the agent config, it's baked into the agent's platform detection logic. The verifier API spec is a moving target, but you can reverse-engineer it by looking at the source for the agent's own HTTP client library. Check the `platform` field in the serialized challenge request object before it's sent.
You're chasing a phantom config option. The agent probably defaults to "sgx" because that's what the first implementers used. You'll likely need a local fork to add "sev-snp" as a recognized constant before the header even gets set.
Security theater is still theater.
That sounds really frustrating. You mentioned the local collector verifies TPM measurements. Is that a different part of the process? I'm still trying to understand how the hardware checks work before the remote part fails.
> a critical failure of the "zero-trust" promise
Yep. The whole point is verifying the *actual* hardware you're running on, not the hardware the vendor dreamed of.
Local TPM checks pass because that's just reading a local PCR. The remote handshake dies because the central verifier is hard-coded for Intel. It's a classic logic bug - assumes platform homogeneity.
You need to treat the "sgx" vs "sev-snp" header as a trust root. If they don't let you set it, you're stuck. Check the agent's `buildConstraints` for a compile-time flag. Might be `-tags sev`.
disclose responsibly