Harden the Jupyter sandbox runner against env-secret exposure

Run each kernel under a scrubbed environment so untrusted code can never read
the host's secrets. A custom 'docsgpt-python' kernelspec launches ipykernel
through a wrapper that keeps only what the kernel needs (PATH, HOME, LANG, and
the Jupyter runtime/data dirs), dropping API keys, tokens, the database URL, and
the gateway token. The app selects this kernel by name via SANDBOX_KERNEL_NAME,
so the distinct name is never shadowed by the stock python3 spec. Per-session
workspaces are created mode 0700 (defense in depth under the shared uid). The
README documents the runner as a single trust domain and points to the Daytona
backend for per-tenant isolation.

deployment/sandbox/kernel-launch.sh

@@ -0,0 +1,20 @@
+#!/bin/sh
+# Env-scrubbing launcher for the docsgpt-sandbox ipykernel.
+#
+# The gateway process inherits the operator's full environment, which can carry
+# secrets (*_API_KEY, *_TOKEN, POSTGRES_URI, the gateway auth token, ...). Stock
+# kernels inherit that env verbatim, so LLM-authored code could read it via
+# os.environ. This wrapper re-execs ipykernel under a MINIMAL allowlisted env so
+# NO secret reaches kernel code, regardless of how the gateway was launched.
+#
+# Only what ipykernel needs is kept: PATH (find python), HOME (~/.ipython etc),
+# LANG (encoding), and the Jupyter runtime/data dirs (writable tmpfs paths). The
+# {connection_file} the gateway passes is forwarded via "$@" so loopback ZMQ
+# reachability is preserved -- do NOT drop or rewrite those args.
+exec env -i \
+    PATH="${PATH}" \
+    HOME="${HOME}" \
+    LANG="${LANG}" \
+    JUPYTER_RUNTIME_DIR="${JUPYTER_RUNTIME_DIR}" \
+    JUPYTER_DATA_DIR="${JUPYTER_DATA_DIR}" \
+    python -m ipykernel_launcher "$@"