Security

Prax applies defense-in-depth across all trust boundaries: webhook validation, path traversal protection, sandbox auth, and a multi-layer plugin security model.

Contents

• Plugin Trust & Isolation — Trust tiers, subprocess isolation, capabilities proxy, lifecycle audit
• Tool Risk Classification — Risk levels, governance layer, supply chain hardening
• Configuration — Environment variables, .env setup, all configuration options
• Network Exposure & Binding — Why Prax/TeamWork bind loopback by default, and how to serve on 0.0.0.0 safely behind an authenticating proxy (Tailscale, IAP, Cloudflare Access, oauth2-proxy)
• Deployment Topology — isolate, sandbox, guardrail — the endorsed production shape: Prax, the secrets-proxy, the sandbox (and optionally TeamWork) as separate containers on one shared network — they can talk but can’t read each other’s filesystem/env/keys. Covers the two proxy modes (reverse = model keys; forward MITM = ~all egress), how to wire forward mode, the 🔒 lock-the-proxy-down-hard checklist, and the keys-in-Prax opt-out (at your own risk).
• Credential Registry — the single source of truth (Prax ⇄ proxy, no drift) — every credential Prax supports, classified by whether/how the proxy can hold it (model / forward / local). Backed by prax/services/credential_registry.py + a CI drift-guard test so a new key can’t be added without classifying it. Start here to see what’s proxyable and what stays in Prax.
• The Secrets Proxy — running a KEYLESS Prax — Run Prax with no real API keys in its process: a small separate proxy holds the keys, injects them into model calls, and streams responses back — so a compromised/injected Prax has nothing to steal (the infra-level “make the secret unreachable” wall). Tier 1 (OpenAI + Anthropic) is built as a separate, isolated service (praxagent/prax-secrets-proxy) — real isolation is process/filesystem separation, not a second env file Prax can open(); it’s opt-in and default Prax is unchanged: allowlist by construction, streaming, an audit log that never logs the key/body. Honest limits (stops theft, not abuse; the proxy becomes the trusted component) + how to run it + Tier 2 (general egress) plans.
• Git repos attached to a space — Attaching repositories to a Library space: one ed25519 deploy key per repo (an account SSH key cannot be scoped — it reaches everything the account can), IdentitiesOnly=yes so ssh cannot silently widen that, write off until a human toggles it, per repository, and checkouts isolated under their own space with a name check plus a resolved-path check. Keys live outside the workspace and library/spaces/*/repos/ is gitignored, because the workspace commits everything not ignored.
• The Sandbox Execution Boundary — Where code-exec tools (run_python, data_query, sandbox_shell, lean_check) actually run and what they can reach: the container is the boundary, never the host (no host-subprocess fallback); only /workspace is mounted (host source/.env are not, except the gated self-improve /source mount). The default is now keyless — the coding-agent CLIs + model keys were removed from the sandbox image (prax-sandbox #4) and the multi-round coding-session tools were removed from Prax entirely (#142), closing the old container-ENV key-exfiltration path. Residual: egress is unrestricted; ranked mitigations (tracked). Why isolation, not command-filtering; the rules for adding a code-exec tool.