Skip to main content
tracebloc is built so your data never has to leave your network. This page is the summary to hand to your security or compliance team.

​
What’s shared, what isn’t

​
How it’s enforced

  • Data locality. Training runs against your data on your hardware. Raw data never crosses the boundary.
  • Isolation. Each training job runs in its own container with restricted system access; Kubernetes namespaces separate workloads.
  • Network policy. The chart applies a Kubernetes NetworkPolicy that denies all inbound to training pods and restricts their outbound traffic — arbitrary pod-to-pod connections and the Kubernetes API are blocked, while the in-cluster MySQL that serves the training data and the in-cluster proxy that reports results and FLOPs stay reachable. Direct outbound HTTPS is still allowed by default today; a stricter lockdown that instead routes it through an in-cluster egress gateway ships with the chart and can be enabled per cluster, and enforcement requires a CNI that honors NetworkPolicy.
  • Model scanning. Submitted models are scanned for vulnerabilities (Bandit) before anything executes.
  • Encryption in transit. All workspace ↔ platform traffic is TLS, on an outbound-only connection.
  • Access control. Only contributors you whitelist by email can join a use case.
  • Minimal footprint. The installer touches only Docker and ~/.tracebloc — no system-wide changes.

​
You control what leaves

Trained weights are shared only when you choose to share them. Whom you collaborate with, and whether weights are downloadable, is set in the admin panel — per use case.

​
Support bundles are redacted

If support asks for diagnostics, --diagnose produces a bundle with credentials removed (passwords, tokens, and proxy secrets stripped before the archive is written). See Troubleshooting.

​
Outbound access

Your workspace needs outbound HTTPS to: *.docker.io, ghcr.io, raw.githubusercontent.com, *.github.io, *.tracebloc.io, and pypi.org. Nothing needs to reach in.