This is a cross-post. Original on our site: stellarbytecapital.com/blog
Every week another demo shows an AI agent writing code. Impressive — and, increasingly, commoditized. A large model turning a natural-language request into a working Python script is no longer the frontier. It's table stakes.
The frontier is what happens after the model hits "generate."
Because the moment you let an autonomous agent execute the code it just wrote — against real market data, real funds, real infrastructure — you've handed an unpredictable author write access to your production environment. That's not a prompt-engineering problem. It's a systems-security problem. And it's the one that actually decides whether an AI application ships or stays a demo.
This is the problem we build for.
The real barrier isn't generation — it's autonomous execution
Consider a concrete case from our domain: an AI quant agent. A user says, "backtest a mean-reversion strategy on A-shares, filter out ST stocks, and show me the drawdown." The agent writes the code. Fine. Now it has to run that code — code no human reviewed, line by line, before execution.
What could that code do?
- Read or exfiltrate other users' data on the same machine
- Leave behind daemon threads, open file descriptors, or mutated environment state that leaks into the next run
- Make outbound network calls you never intended
- Exhaust CPU or memory and take down the shared service
- Simply crash in a way that corrupts a long-lived worker process
None of these are hypothetical. They're the default failure modes of running untrusted code in a shared process. And "the LLM probably won't write malicious code" is not a security model — it's a hope.
Our answer: disposable, one-shot containers
The architecture we settled on is deliberately unglamorous, because in security, boring is a feature.
Every code execution runs in its own fresh Docker container. After the run, the container is destroyed — never reused.
That single policy — no reuse — eliminates an entire class of bugs and attacks at the root:
- No state-leak between runs. A container that executed user A's code is gone before user B's code runs. There is no shared mutable surface to leak through.
- No lingering side effects. Mutated env vars, leftover temp files, zombie threads — all die with the container.
- A clean, provable boundary. Each execution starts from a known-good image. Reproducibility and isolation come for free.
We maintain a warm pool of ready containers so this disposability doesn't cost latency: spawn → idle → acquire → busy → recycle → destroy, with a new warm one spawned to replace each one consumed. The user feels an instant sandbox; under the hood, nothing is ever reused.
Defense in depth around the boundary
One-shot containers are the spine. Around them we layer the controls that make autonomous execution safe to operate at scale:
- Per-user quotas — execution counts capped per user per day, so no single actor (or runaway agent loop) can exhaust the pool.
- Read-only mounts — user uploads are mounted read-only, so generated code can read the data it needs but cannot tamper with source material.
- Network isolation — outbound access is constrained by default; the agent gets network only where the task genuinely requires it.
- Event auditing — every pool event (spawn, acquire, release, destroy) emits to subscribers: trace writers, metrics exporters, audit logs. When something goes wrong, you can reconstruct exactly what ran.
Individually, none of these is exotic. Together, they turn "an AI wrote and ran some code" from a liability into a system you can put in front of real users and real money.
Why this matters beyond quant
We built this inside a quantitative-trading agent, because trading is an unforgiving place to run untrusted code — real capital, real exchanges, zero tolerance for state leakage between accounts. But the pattern generalizes to any serious AI-agent product:
- A data-analysis agent running generated pandas over a customer's private dataset
- A DevOps agent executing generated shell against infrastructure
- A research agent that writes and runs its own tooling mid-task
The instant your agent stops suggesting code and starts running it, you inherit this exact problem. The teams who solve it are the ones whose AI products make it to production. The teams who don't ship impressive demos that never leave the sandbox — or worse, leave it and shouldn't have.
We're Xingyao Byte — a team with 14 years of engineering experience, building secure AI-execution layers, quant trading systems, and payment platforms. Remote, async-first.
If you're building an AI agent that has to run what it generates, that's exactly the conversation we like to have → stellarbytecapital.com
Top comments (0)