CDEB isolation is proven against the local evaluator, never against a real container runtime

[MongLong0214]

What is unverified

CDEB's isolation guarantees have never been exercised against a real container runtime. #532 wired the composed pipeline end to end and its own Warn: says so: no container daemon was reachable, so network isolation, host secret and mount isolation, and resource limits were proven only against the local sealed evaluator.

The local evaluator does refuse the tamper, network and secret fixtures — that is real and worth having. It is not evidence that the OCI enforcement path does the same thing, and those are the guarantees the study's threat model rests on.

Why this cannot ship as "tested"

The study exists to produce a number other people are asked to believe. If its isolation was verified only by the component that would also be bypassed, the number carries the strength of the weakest unverified link. Stating it as a limitation is honest; treating it as tested would not be.

What closes it

A dedicated Linux CI runner with Docker or Podman, running the adversarial matrix against the real runtime:

• egress attempts from inside the container
• /proc, host paths, and the Docker socket
• environment secret exfiltration
• fork bomb, memory exhaustion, CPU timeout
• evaluator image tampering
• candidate and evaluator colluding — the case Run the whole chain against itself before trusting any of it #532's own Limit: names as unattempted
• attacks on the freeze artifacts before a run starts
• provider retry and partial billing
• daemon crash recovery mid-run

The last four are not in the current suite at all, and the collusion case is the one an adversary who reads the design would try first.

Sequencing

This blocks sealing CDEB, not the product release. It should be closed before any CDEB result is published, and the freeze must not describe these paths as tested until it is.