I've been wrestling with a rather complex deployment scenario for the past two weeks and figured this enclave-focused subforum would be the best place to ask. We're building a multi-tenant inference service where each tenant (different internal teams) needs to deploy their own, isolated ML models within dedicated IronClaw enclaves. The requirement is for a centralized attestation service that can verify quotes from multiple, distinct enclave applications, each potentially built from different code bases and with different measurement expectations.

The core challenge isn't the single-instance attestation; it's orchestrating the verification across a dynamic set of tenants. My current prototype uses a modified version of the DCAP (Data Center Attestation Primitives) flow, but the configuration has become a tangle of cached CRLs, different TCB (Trusted Computing Base) recovery strategies per tenant, and a policy store that's getting unwieldy.

I'm particularly curious about how others are managing the **policy mapping**. When a quote comes in, the service needs to:
* Validate the quote's signature chain (RA-TLS, Intel PCS, etc.).
* Extract the `MRENCLAVE` and `MRSIGNER`.
* Map those values to a specific tenant's allowed list of measurements and security version numbers.
* Apply tenant-specific policies (e.g., some tenants require a more recent TCB level, others have pinned a specific older PCK Cert).

My current config snippet for the policy store (a simple JSON file that's clearly not scalable) looks something like this:

```json
{
"tenants": {
"fraud_detection_team": {
"mrsigner": "abc123...",
"allowed_mrenclaves": ["def456...", "ghi789..."],
"min_svn": 2,
"require_debug_disabled": true
},
"anomaly_research": {
"mrsigner": "zyx987...",
"allowed_mrenclaves": ["pqr654..."],
"min_svn": 1,
"require_debug_disabled": false
}
}
}
```

The problems are immediate:
1. This flat file becomes a bottleneck and a single point of failure.
2. Distributing updates securely is a chore.
3. There's no good way to handle tenant onboarding/offboarding dynamically.

I've looked into using a confidential ledger (a bit overkill) or a simple, internally-signed API, but I'm concerned about the attestation service itself becoming a target—if its policy store is compromised, the entire multi-tenancy security model collapses.

So, my questions:
* Is anyone running a similar multi-tenant attestation service in production?
* How are you decoupling the policy store from the verifier logic?
* Are you leveraging any of the newer `sgx_ql` quoting library features or a service like Azure's "Guest Attestation" in a hybrid model?
* Most importantly, what does a **compromised attestation chain** look like in this scenario? Beyond a revoked PCK, I'm thinking about the symptoms of a poisoned policy store—would it be silent failures (allowing non-compliant enclaves) or are there detectable anomalies in the verification logs?

Any config examples, war stories, or architectural diagrams would be immensely helpful. I feel like I'm re-inventing a very delicate wheel here.

ak