Independent effect observer

The observer is a second, read-only trust domain. It does not trust a verdict, an annotation, or an executor response. It receives an ExecutionProof and its signed receipt, replays the complete authorization derivation at the proof's issuance time, reads the Kubernetes object at the current time, and signs the facts it actually observed.

Security boundary

The executable service is src/observer-service.ts. It requires:

• TLS 1.3 mutual authentication and one exact client SPIFFE URI;
• a distinct observer SPIFFE URI and Ed25519 signing key;
• a pinned active public control-plane key bundle;
• one explicit kubeconfig, context, cluster alias and namespace allowlist;
• a Kubernetes identity limited to get/list on pods and NetworkPolicies.

It exposes only authenticated GET /health, POST /v1/attest/execution and POST /v1/attest/restoration. There is no mutation route. Request bodies are limited to 256 KiB and must contain exactly proof and receipt.

The client in src/remote-observer.ts independently checks the server SPIFFE URI and verifies every returned attestation against a separately distributed public-key bundle. A successful attestation binds:

• the proof hash and execution-receipt hash;
• the exact cluster, namespace and pod;
• the pod UID and resourceVersion;
• the quarantine label and exact deny-all NetworkPolicy, including its UID;
• the observation time, observer SPIFFE identity, outcome and short lifetime.

For restoration, the short mutation grant is expected to be expired. The observer therefore replays authorization at the signed proof issuance time; the current Kubernetes observation still has an independent freshness limit. That historical verification can authenticate a completed action but cannot authorize another mutation.

Qualification

npm run sota:webhook:qualify launches the observer as a process distinct from the integration driver, with its own key, TLS server identity and read-only kubeconfig. The driver has only the observer public key and a client certificate. The campaign proves both quarantine and restoration observations, then kills the admission webhook and confirms that Kubernetes mutation fails closed before restoring the webhook.

The final 2026-08-29 run produced execution attestation hash 51f7069015b67d5c89e200ecc5483975da15359321446d9909a6d0a3ba596024 and restoration attestation hash fce130d0536b1c590a6d3a63b3d0babb0716925e8c97f762629504b5c5a3a590. Its machine-readable result is retained under .aegis-lab/reports/.

Production requirements not claimed

The lab separates identities, keys, process and Kubernetes RBAC, but shares one host and cluster. Production requires separate scheduling and administrative domains, replicated availability, independent alerting, protected key custody, external attestation retention, network-policy verification and an operator who does not report to the executor owner. The current result proves the protocol and one deployment pattern, not organizational independence.