Understand the Feedback Loop

Enterprise problem: Filtering an individual input is insufficient when untrusted work can observe results, retry, and carry information into another execution.

Whole-course context: We use the qualified Day 01 evidence ledger to model defensive control points without asserting unreported exploit details.

Today’s slice: Implement an evaluation boundary that treats dataset configuration, execution, telemetry, and egress as separate capabilities.

End-of-day evidence: A traceable denied run plus an unaffected benign evaluation run.

Still unsolved: The next day removes the credentials that turn a local evaluator compromise into wider authority.

The platform operator needs to run useful evaluations without turning every run into a reconnaissance channel. The design is simple: an intake service assigns an immutable run ID, an isolated worker executes with a read-only input mount, and a policy gateway decides whether telemetry or egress may leave the sandbox.

Without a component boundary, “sandboxed” is an adjective with no enforcement point. The worker has ephemeral compute; the run record and audit stream are durable; no cache contains credentials or source secrets.

A reusable worker or inherited service account lets information and authority leak between jobs. Use a per-run Kubernetes Job with token mounting disabled and an explicit network policy; the cluster scheduler interprets this desired state.

apiVersion: batch/v1
kind: Job
metadata:
  name: evaluation-run-7f2c
spec:
  template:
    spec:
      automountServiceAccountToken: false
      restartPolicy: Never
      containers:
        - name: evaluator
          image: registry.example/evaluator@sha256:replace-with-immutable-digest
          resources:
            limits: { cpu: "1", memory: 1Gi }

Declared intent: one bounded, credential-free process. Interpreter: the Kubernetes API server, Job controller, scheduler, and container runtime. Software effect: a Job creates one pod and records completion state. Hardware effect: the scheduler reserves one CPU and 1 GiB RAM on a node; its ephemeral filesystem dies with the pod. Evidence: kubectl get job evaluation-run-7f2c -o jsonpath='{.status.conditions}' plus the matching trace archive object.

An egress denial is useful only when it is attributable and does not stop unrelated work. Send a single labelled test request from the named disposable Job, expect a proxy denial, then prove a known offline evaluation still reaches Complete.

kubectl logs job/evaluation-run-7f2c # Correlate the run ID with the proxy decision.
kubectl get job benign-fixture -o jsonpath='{.status.succeeded}' # Positive control must remain 1.

Decision rule: permit outbound connectivity only through an owner-approved destination and only when the task needs it; otherwise make the absence of egress a testable default.

One long-lived evaluator mixes execution, observation, and authority, so a retry can carry information forward. Per-run isolation separates those capabilities and records each denied boundary crossing.

• A sandbox needs separate execution, network, and observation controls.
• A denied request and an unaffected benign run are stronger evidence than a successful deployment.

• [ ] Each run has an immutable ID, manifest hash, and trace.
• [ ] Worker tokens are disabled and egress is policy-controlled.