TEE Observability Overview
A Trusted Execution Environment (TEE) provides hardware-enforced isolation for sensitive computation — Intel TDX, AMD SEV-SNP, and AWS Nitro Enclaves are the main implementations. TEE deployments of BizFirstGO face a fundamental tension: observability requires data to leave the computation environment, but the TEE's security model restricts data egress.
What Is a TEE?
Hardware Isolation
The TEE's computation and memory are encrypted and isolated from the host OS, hypervisor, and even cloud provider. Code and data inside the TEE are not visible externally — including to the infrastructure team.
Attestation
Any party can verify the code running inside the TEE by requesting a cryptographically signed attestation report — proving that specific code (measured by hash) is running in a genuine TEE.
Egress Restriction
Data leaving the TEE must be explicitly authorized. The security model assumes that any data exiting the boundary may be observed by the host — so sensitive computation results must not leave in plaintext.
No Ad-Hoc Access
Traditional debugging (SSH, debugger attach, memory dump) is impossible inside a TEE. Observability must be designed into the system before deployment — reactive debugging tools are not available.
TEE Observability Risk Model
| Signal Type | Risk of Crossing Boundary | Allowed? |
|---|---|---|
| Aggregated metrics (count, sum, avg) | Low — no individual data points | Yes — with review |
| Sanitized structured logs (no payload data) | Low — operational context only | Yes — with sanitization policy |
| Raw workflow payload data in logs | High — may contain confidential computation input/output | No |
| Distributed trace spans with span attributes | Medium — attributes may reveal computation details | Trace IDs only (not spans) |
| Exception stack traces | High — may reveal internal state or data values | No — only error codes |
| Attestation report (TEE identity) | None — cryptographic proof only | Yes |
Unlike standard deployments where you can add logging after the fact, TEE observability must be part of the initial design. Once BizFirstGO is running in a TEE, you cannot add new telemetry emission points without modifying and re-attesting the code. Define your observability contract (what signals, what data) before the first TEE deployment.