TEE Observability Constraints — TEE

Hard Constraints (TEE Security Model Enforces)

Constraint	Why	Impact on Observability
No plaintext workflow payload data in logs	Workflow input/output is the protected computation — exfiltrating it defeats TEE purpose	Log messages must never include form field values, computation results, or user data
No full span attributes in traces	Span attributes may encode computation details (e.g., "amount = 1500000")	Only trace IDs (not spans) may cross boundary; span details stored in-TEE
No unreviewed egress channels	Every outbound connection from TEE must be explicitly approved in TEE policy	OTel Collector endpoint must be in the TEE's approved egress list
No ad-hoc debug access	SSH, debugger, live memory inspection are impossible by design	All debugging must use pre-defined observability channels

What Standard BizFirst Observe Features Are Not Available in TEE

# Standard BizFirst Observe features unavailable in TEE deployments:

1. Grafana Explore with ad-hoc log queries
   # Available in standard, NOT in TEE:
   {job="processengine"} |= "formData" | json | field.income > 0
   # This query would reveal protected computation data

2. Exception message logging with data values
   # Available in standard:
   _logger.LogError("Calculation failed for value {Value}", input.Value);
   # In TEE: FORBIDDEN — input.Value is protected data
   _logger.LogError("Calculation failed: error code E_OVERFLOW");

3. Full distributed trace spans crossing TEE boundary
   # Available in standard: full span with all attributes flows to Tempo
   # In TEE: only the TraceId crosses; span content stays inside TEE

4. Live log streaming in Grafana
   # Available in standard: live tail of log stream
   # In TEE: approved log batches only; no real-time stream egress

Network Egress Restrictions

# TEE network policy must explicitly allow the OTel Collector endpoint.
# In AWS Nitro Enclaves:
{
  "Version": "1.0",
  "NetworkPolicy": {
    "AllowedEgressEndpoints": [
      {
        "Host": "otel-collector.internal.bizfirstai.com",
        "Port": 4317,
        "Protocol": "GRPC",
        "Description": "OpenTelemetry Collector for approved telemetry"
      }
    ]
  }
}

# Any other egress is blocked by the TEE platform.
# The OTel Collector itself must be outside the TEE —
# it is the boundary control point that decides what reaches Loki/Prometheus/Tempo.

Design TEE Observability as an API Contract

Treat TEE telemetry as a formal API: define exactly which log fields, metric names, and trace context (IDs only) are permitted to cross the boundary. Document this contract alongside the TEE attestation policy. Changes to the observability contract require re-attestation — treat observability changes as code changes, not operational changes.

← TEE Observability Overview Next: Allowed Telemetry →