docs: correct air-gapped and MySQL-egress overclaims (backend#1186)

environment-setup/security.mdx

@@ -1,9 +1,9 @@
 ---
 title: "Security & data handling"
 description: "What stays on your infrastructure, what leaves, and how tracebloc enforces it — the page to share with your security team."
 ---
 
 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
 
@@ -17,8 +17,8 @@
 ## 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.** Training pods are denied data egress — they can't reach MySQL, other pods, or the Kubernetes API.
+- **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](/environment-setup/eks-client-deployment-guide).
 - **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.

tools-help/faqs.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Frequently Asked Questions"
 description: "Common questions about running tracebloc — privacy, infrastructure, training, and getting help."
 ---
 
 ## Privacy & security
@@ -8,19 +8,19 @@
 ### Can the data scientist see my raw data?
 No. Data scientists submit model code; the code runs on your client, against your data, in an isolated sandbox. They only ever see the metrics you decide to expose. Raw data, in-flight model state, and intermediate artifacts never leave your infrastructure.
 
 ### What gets shared with the data scientist or with tracebloc?
 Only the evaluation metrics you configure on the use case (accuracy, F1, latency, and so on). No raw data, no trained weights, no logs.
 
 ### Where do trained model weights end up?
 On your storage. Trained weights stay on the persistent volume claim attached to your client. Data scientists never receive them.
 
 ### Is the client's egress restricted?
 Yes — the chart applies a Kubernetes `NetworkPolicy` that only allows training pods to reach the tracebloc backend (for orchestration metadata) and the in-cluster proxy that handles result and FLOPs reporting. **The egress lockdown only takes effect on a CNI that enforces NetworkPolicy.** EKS's default VPC CNI does not, out of the box — see the [EKS deployment guide](/environment-setup/eks-client-deployment-guide) for what to install.
 
 ## Infrastructure
 
 ### Do I need a GPU?
 For most ML workloads, yes. The standalone installer detects NVIDIA and AMD GPUs and installs the right drivers automatically. CPU-only is fine for small tabular and text models, but expect long training times on anything image- or sequence-heavy.
 
 ### What Kubernetes versions do you support?
 Kubernetes 1.24 and above. See the [setup guide](/environment-setup/setup-guide) for the full prerequisites.
@@ -28,8 +28,8 @@
 ### Can I run on-premise only?
 Yes. The standalone installer provisions a local cluster on your machine, or you can deploy the unified Helm chart into your existing on-prem Kubernetes. The client never depends on cloud infrastructure for training.
 
-### Do you support air-gapped clusters?
-Yes — see the [packaged-chart install path in tracebloc/client INSTALL.md](https://github.com/tracebloc/client/blob/main/docs/INSTALL.md) for the offline flow.
+### Can I install offline or run behind an egress proxy?
+You can install from a packagedchart `.tgz` rather than the public chart repo, and platform traffic can route through your corporate proxy (set `HTTP_PROXY` / `HTTPS_PROXY` before installing). The environment is **outbound-only** — nothing needs to reach *in* — but it does need outbound HTTPS to the tracebloc platform to run experiments, so it is **not** fully air-gapped. What you get instead is defined, auditable ingress and egress: raw data never leaves your infrastructure, and only the results and weights you choose to share are sent out. See the [install guide](https://github.com/tracebloc/client/blob/main/docs/INSTALL.md).
 
 ## Training & models
 
@@ -37,13 +37,13 @@
 Through the [tracebloc dashboard](https://ai.tracebloc.io) — every experiment, every model, every metric. Or query the API if you prefer programmatic access.
 
 ### What if a training run fails?
 The client retries transient failures automatically. Persistent failures show up in the dashboard with logs and exit codes. For ingestion-time failures, check the Job logs in the namespace you deployed into.
 
 ### Can I bring my own model?
 Yes. Use the [tracebloc Python package](/tools-help/tracebloc) to upload a model file (PyTorch, TensorFlow, or a custom container). For ready-made starting points, see the [model zoo](https://github.com/tracebloc/model-zoo).
 
 ### Do you support fine-tuning?
 Yes — the same upload flow handles full training, fine-tuning with pretrained weights, and inference-only evaluation.
 
 ## Cost & support