Keeping Quant Research On-Prem: A Self-Hosted Agent Sandbox for Banks

An LLM agent that can iterate on a backtest — write the strategy, run it, look at the result, adjust, run it again — is genuinely useful to a quant research desk. It is also, by definition, a system that reads proprietary position and trading data and executes arbitrary code against it. For a bank's platform team, that second fact decides the whole architecture before the first one gets to matter.

Why compliance won't allow this near a third party

A hosted code-execution sandbox — however well-run — is still somebody else's infrastructure, reachable over somebody else's network, subject to somebody else's incident response. For proprietary trading strategies and position data, that's not a question a compliance team is likely to entertain regardless of how good the vendor's security posture is. The requirement isn't "a trustworthy vendor, " it's "this data does not leave our network," and no amount of vendor diligence substitutes for that being structurally true.

Self-hosting: the sandbox lives inside your own boundary

boxkite is open source and self-hostable on the bank's own Kubernetes cluster, which means the question "where does the agent's code actually run" has a concrete, inspectable answer: inside the firm's own network, on infrastructure the platform team already operates, not inside a vendor's cloud account. That's the difference between trusting a security questionnaire and being able to point at the cluster.

The persistent python_interpreter: iterating without starting over

A single backtest run is rarely the point — a researcher wants to load the data once, run a strategy variant, look at the drawdown, adjust a parameter, and run it again, keeping everything already in memory. boxkite's python_interpreter is a kept-alive interpreter rather than a fresh process per call, so that iteration loop happens inside one session instead of re-loading the dataset and re-establishing state on every turn.

A working data-science stack with nothing to install

The sandbox image ships pandas, numpy, polars, and scikit-learn pre-installed. That matters here for a reason beyond convenience: with network access denied by default, a runtime pip install would fail anyway. Shipping the stack in the image rather than installing it per session is what makes network-dark-by-default compatible with actually being able to do the work.

One pod per researcher session

Multiple desks running unrelated analyses concurrently is the normal case, not an edge case, and each session's pod is isolated from every other one — one desk's in-progress strategy can't be read by, or interfere with, another desk's session. That separation is enforced by the Kubernetes pod boundary itself, the same primitive already used to isolate any two unrelated workloads on the cluster.

Network-dark by default as the auditable answer

When a bank's security team asks "can this agent send our data anywhere," the answer here isn't a policy document — it's that the pod has no network egress unless the platform team has explicitly configured an exception for a specific session. That's a structural property the team itself controls and can audit on its own cluster, not a claim they have to take on trust from an external provider.