DEV Community: Inalpha

An Al writes my trading code. Three gates decide if it ever runs.

Inalpha — Thu, 02 Jul 2026 03:07:52 +0000

A few months ago I built a system where an AI can write trading strategies — actual Python files — and then run them against real market data.

The first thing it wrote was a simple moving-average crossover. Clean, reasonable, made money in backtest. Cool.

The second thing it wrote tried to import os.

This post is about what happened next, and the three gates I built to make sure the answer is always "nice try, but no."

Why let an AI write code in the first place?

In two earlier posts I talked about keeping an AI away from the order book — making sure it can't place trades directly. Those were about controlling what the AI wants to do.

This is different. This is about letting the AI write code, and then actually running that code. Not picking from a menu. Not tuning a few parameters. Writing a complete trading strategy from scratch, 80 to 200 lines.

Why bother? Because the interesting strategies aren't in the built-in library. A human quant might spend a week combining a Bollinger Band width filter with a volume-weighted entry and a time-decay exit. An AI can generate that in seconds. The creative possibilities are way beyond what you'd bother to hard-code.

But giving an AI the ability to write and run code introduces a new problem. The code might be dangerous — import os, read files, leak environment variables. Or it might be safe but worthless — an overfit noise machine that backtests beautifully on one slice of data and falls apart everywhere else.

Two independent problems. Two independent solutions. Sandbox catches the dangerous stuff. A fitness score catches the garbage.

What I was actually afraid of

Before writing any code, I sat down and listed every way an AI-written trading strategy could hurt me. Four categories:

Escape. Python has a famous trick: ().__class__.__bases__[0].__subclasses__() reaches into Python's internals and gives you access to basically any class — file handles, network sockets, subprocesses. No import needed. Pure runtime trickery.

Side-effect imports. Even a harmless-looking import runs that module's initialization code. If the AI imports the wrong thing, damage happens before you can blink. So interception has to happen before the import, not after.

Runtime hangs. A perfectly legal, perfectly clean function can still be an infinite loop or a memory bomb. The code looks fine to a static checker. It only misbehaves when you actually run it.

Garbage that passes. The code is completely safe. No dangerous imports, no weird tricks. It's also a hopelessly overfit mess — 300 trades on 500 bars, great numbers in-sample, zero predictive power out-of-sample. This isn't a safety problem. But it fills your strategy library with noise.

The important thing I realized: these four problems happen at four different moments. After the AI writes the code. When the code imports things. When the code actually runs. After the backtest finishes. No single check catches them all. You need defenses spread across the whole timeline.

Gate one: check the code before it runs

The first gate is the simplest one, and it runs before a single line of the AI's code executes.

I wrote a scanner that reads the AI's Python file and checks it at the syntax level — no execution, no imports, just looking at the structure. Think of it like a security guard checking bags at the door.

It has three lists:

Only these imports are allowed. math, statistics, collections, dataclasses, typing, enum, json. Seven modules, all pure computation, no filesystem, no network. Everything else the strategy needs — market data, order types, execution events — gets provided later by gate two. The AI doesn't need to import any of it.

These names are forbidden. eval, exec, compile, open, input, getattr, setattr, globals, locals — seventeen in total. They're the dynamic execution, reflection, and file I/O functions that no trading strategy should ever need.

No double-underscore attribute access. That __class__.__bases__[0].__subclasses__() escape trick? Blocked. Any attribute starting and ending with __ is denied, with five harmless exceptions like __init__. One rule kills the entire escape path.

Here's the part that actually matters in practice: when the scanner rejects something, it doesn't just say "no." It returns exactly which line, what the violation was, and a human-readable reason. The AI gets told what it did wrong and where, so it can fix it and try again. It's a linter, not a brick wall.

Gate two: give it only what it needs

Code that passes the scanner moves to the second gate. Now we actually have to load it — compile the Python and make it runnable. But we do it in a carefully stripped-down environment.

Every time we load a new AI-written strategy, we build a fresh sandbox from scratch. The sandbox contains:

A cut-down set of Python's built-in functions. abs, len, range, sum, sorted — about 55 names total, down from Python's usual 70-plus. No open, no eval, no __import__. The scanner already blocked these, but this is the second net in case it missed something.
All the trading system's symbols injected directly: what a bar of market data looks like, how to place an order, what side (buy or sell), what the clock says. The AI doesn't import these — they're already there in the sandbox when its code wakes up.
One weird one: __build_class__. This is a hidden Python function that makes class Whatever: syntax work. If we don't include it, the code crashes with a confusing error. Is it dangerous? No — its interface is implicit and an AI can't realistically call it directly. Figuring out which "scary-looking" things are actually safe is most of the fun in sandbox design.

This is defense in depth. The scanner is the first net. The stripped-down sandbox is the second. If something slips past the scanner, it still can't reach anything dangerous at runtime.

Gate three: make sure it actually looks like a strategy

Code that passes gates one and two has been scanned and loaded safely. But is it actually a trading strategy? Or did the AI write a class that has nothing to do with what we need?

Three checks:

Is there exactly one strategy class? Zero classes that inherit from Strategy → rejected. Multiple strategy classes in one file → also rejected. One file, one strategy. Keeps things simple.

Does it actually respond to market data? A strategy needs a method called on_bar — the function that gets called every time a new bar of price data arrives. If the AI forgot to write it, the strategy is a paperweight that will never make a decision. Rejected.

Can the engine actually create it? When the backtest system starts a strategy, it passes in a few things: a name, a clock, a message bus, the instrument being traded, the timeframe. The AI's code needs to accept those. If its __init__ has the wrong signature, the engine can't create it. Rejected — but with a message saying exactly which parameters are missing.

The order of these three gates matters: scan the code (static) → load it in a sandbox → confirm it's a real strategy (structural). Each failure sends a clear reason back to the AI so it can rewrite and retry.

One more thing: run it in a cage

The three gates catch a lot. They don't catch a pure-compute infinite loop. The code is clean, uses only allowed symbols, looks like a valid strategy — and then runs forever, hanging the entire service.

So when we actually backtest the strategy, it runs in a separate process with CPU, memory, and time limits. If it blows up, it blows up the subprocess, not the main service. The rest of the system keeps running.

Also, every AI-written strategy gets tested side-by-side against "just buy and hold" — same market data, same starting cash, same fees. If the AI's fancy strategy can't beat the dumbest possible benchmark, it doesn't deserve a second look.

Honest part. There's one path where this subprocess isolation isn't in place yet: the live runner — the thing that trades on real-time bars while nobody's watching. Currently it runs strategy code inline. It relies on two human approval steps (someone promoted the strategy, someone started the run) to keep things trusted. Subprocess isolation for the live runner is on the list, not done yet. If you're deploying this yourself, you should know.

The other problem: safe code can still be garbage

A strategy can pass all three gates — perfectly safe, zero dangerous symbols — and still be worthless. 300 trades on 500 bars, a great-looking return number for the test period, falls apart the moment market conditions shift.

This is overfitting, and it's not a safety problem. It's a quality problem. The solution is a scoring function that doesn't let any single number fool you.

The score is a combination of four things:

Sharpe ratio — return relative to volatility. The standard metric.
Calmar ratio — return relative to the worst drawdown. This catches strategies that look good on average but occasionally fall off a cliff.
Turnover penalty — subtract points for excessive trading. This stops the AI from gaming the score by churning through tiny trades.
Drawdown veto — if the strategy ever lost more than 30% from its peak, automatic disqualification. One strike and you're out.

Why not just use Sharpe ratio alone? Because the AI figures that out. It discovers that high-frequency churn pumps the Sharpe number on paper, even though the strategy would get eaten alive by real trading costs. The turnover penalty says no. It also discovers strategies with great average returns that had one catastrophic month. The drawdown veto says no.

The coefficients — how much each factor weighs — are starting points, not gospel. They'll get tuned as we collect more data from real evolution runs. But the principle is more important than the exact numbers: no single metric gets to decide.

What the whole thing looks like

AI writes source code → Gate 1: scanner checks for dangerous patterns. Caught something? Here's what and where. Fix it and try again. → Gate 2: load the code in a stripped-down sandbox. → Gate 3: confirm it's actually a trading strategy. → Run it in an isolated subprocess, parallel with buy-and-hold. → Score it across multiple dimensions. → If it beats the baseline, it goes in the candidate pool. → Human reviews → Human approves → It trades.

The AI gets to be creative — it writes whatever strategy it can think of. But every line passes through three gates that don't care what it was trying to do. They care about structure. And at the end, a scoring function decides whether the result was worth running at all.

Not a single step in this chain says "trust the AI."

What I'd do differently

The scanner is a lock, not a theorem. It blocks the things I know about. New escape tricks will show up, and the rules will need updates. This is not a mathematical proof of safety. It's a practical defense that gets better over time.
The live runner needs the same subprocess isolation as backtesting. Right now it relies on human gates. That's the top hardening priority.
The scoring weights are judgment calls. 30% drawdown veto, 0.3 Calmar multiplier, 0.10 turnover penalty — these numbers were reasonable starting points, not optimized values. Real evolution data will tell us if they're right.
A single score loses information. Compressing "safe, profitable, stable, low-turnover" into one number is always lossy. A future version will track these dimensions separately instead of boiling them down.

I'd rather name the gaps now than pretend the whole chain is bulletproof. If you're building something similar, I recommend the same: ship what's load-bearing, name what isn't, and don't bluff.

The AI writes the code. Three gates decide if it ever runs. One scoring function decides if it deserves to.

No prompt engineering. No "please don't import os." Just structural checks that don't care about the AI's intentions — only about what's actually in the file.

If this resonated:

📬 Subscribe to Inalpha on Substack — one post a month on what I'm building
⭐ github.com/mirror29/inalpha — the three gates, scoring system, and full pipeline in services/paper

Here's the flip, live. Draw a slip, then open what's under it: the actual backtest run, factor IC, and the timestamp of the last bar she looked at. Fortune on top. Ledger underneath. https://github.com/mirror29/inalpha

Inalpha — Thu, 11 Jun 2026 03:46:17 +0000

GitHub - mirror29/inalpha: 🦊 Open-source professional quant agent framework. Agents pick the factors working now to time entries, write full strategies, and evolve them in a sandbox — every order through machine approval, the LLM never on the order path. Multi-market, audit-grade. · GitHub

🦊 Open-source professional quant agent framework. Agents pick the factors working now to time entries, write full strategies, and evolve them in a sandbox — every order through machine approval, ...

github.com

Same code, three clocks — letting a quant agent trade on its own without losing the audit trail

Inalpha — Mon, 08 Jun 2026 08:19:52 +0000

In the last post I argued that an LLM should never hold the approval token on a trade. A human approves. The model only proposes. That works as long as a human is in the loop on every order.

Then a user does the obvious thing. They take a strategy the agent wrote, like the backtest, and say "put it on the paper account."

They expect it to trade: follow the market in, follow it out, update positions while they sleep.

The honest truth at that point: status = 'promoted' was a database flag. Nobody was ticking the strategy's on_bar. The account didn't move. That gap was the whole feature.

Closing it means the machine now places orders on live bars with no human clicking approve each time. Which sounds like exactly the thing the last post said not to do.

This post is how you close the gap without throwing away the audit trail. And the four places the trust boundary has to be redesigned the moment no human is in the chair.

The easy half: same code, three clocks

Inalpha holds one invariant tight: the Python file you backtest is the file you paper-trade. No fork for production. You swap two things underneath the strategy — the Clock and the Gateway — and the business logic doesn't move.

The invariant itself isn't rare. What's rare is the thing standing on top of it here.

The author of that file is an LLM. It was vetted by a human. And it's now running itself on live bars.

Quant engines hold the invariant, but don't assume an agent wrote the strategy. Agent frameworks assume the LLM, but have nowhere to put a trading harness. Inalpha sits in that seam. And the same-code invariant is exactly what makes the audit chain mean anything: there's precisely one file to point a signature at.

How it runs — three deployment modes, two clocks, one file:

Backtest: a TestClock driven by historical bars; fills simulated against a reference price.
Paper (live runner): a LiveClock on real wall-clock time, bars pulled fresh on the strategy's timeframe, the same matching engine, the order routed out through the real plan/exec path — the only simulated part is that fills are matched locally instead of sent to a broker.
Live (real capital): architecturally the same seam — LiveClock, same kernel, same plan/exec path, only the Gateway swapping to a real broker. But real-money trading is deliberately out of scope for this project; holding the invariant isn't about chasing it. The payoff is narrower and real: backtest and paper are literally one code path, so the audit chain has exactly one file to point a signature at.

So "three clocks" is shorthand: two clock implementations (TestClock / LiveClock), the third mode (real capital) a seam the architecture leaves open but the project doesn't pursue — and the strategy file never notices which one it's running under.

The live runner (services/paper/.../live_runner.py) is one long-lived task per running strategy. Each tick it does three things:

pull the latest closed bar;
feed it to a session that reuses the exact backtest kernel, firing the strategy's on_bar;
intercept the order the strategy emits and hand it to the guarded order path — it does not match locally.

When the fill comes back, it's replayed into the session. So the strategy's view of its own position stays consistent with what actually filled.

Why this matters for audit-grade, not just convenience: if your backtest and live code are two different files, no signature chain will tell you which one ran when the $93k order happened. Same code, three clocks is the precondition. It's also the boring half. Here's the half that kept me up.

The hard half: who approves the order?

Last post's thesis was a three-step state machine. The LLM drives step one. A human drives the approval:

trade.create_plan       → plan: pending_approval
trade.approve_plan      → mints a single-use token
trade.execute_plan(tok) → places the order

A runner that trades while you sleep can't stop and wait for a click on every bar. So the naive fix is to delete the approval step for the automated path. That's the fix that quietly turns "audit-grade" back into "trust me."

We did the opposite. The automated path goes through the same plan/exec state machine. The approval is just stamped approved_by = "system:live_runner".

Machine approval. The order still creates a plan. Still mints and consumes a single-use token. Still writes the same signed audit line. Nothing on the order path got a shortcut.

Machine approval is only honest if it's earned. Ours rests on two human gates upstream, and the agent can't route around either:

A human promotes the candidate. promote is a deliberate human action, with permission: ask on the agent side. The model can't self-promote a strategy into the runnable set.
A human starts the run. paper.start_strategy is an explicit call a person makes for a specific market and timeframe.

So the chain reads: a person vetted this strategy, a person chose to run it here. Given those two signatures, having the machine approve each later order on live bars is the expected behavior, not a bypass. The audit line records system:live_runner as the approver for exactly this reason — a replay shows where the human gates were and where the machine took over.

Every order the runner places also writes a decision record (strategy_run_decisions): the bar context, the order intent, and the outcome (filled, rejected, or risk_rejected), cross-referenced to the plan and the trade.

The point of the autonomous path isn't just that it trades. It's that the next morning you can read, line by line, every bar where it wanted to act and what the harness did about it.

The trust boundary moves when the human leaves the chair

This isn't a bug list. It's four faces of one architectural question.

With a human in the loop, a lot of guarantees are propped up implicitly by "someone is at the screen." Designing the unattended path means asking that again, on purpose: which of those props has to become something the system holds up on its own?

Four answers.

1. Identity has to become explicit.
When a human starts each run, ownership is implicit — whoever clicked owns it. Automate it, and ownership has to live in the data model, or there's no boundary at all.

Concretely: the start path checked that a candidate was promoted, not that the caller owned it. So you could run someone else's strategy on your own account.

The trap in fixing it was real. The candidate's author_id is only set for UUID identities, while the account id falls back to uuid5 for everyone else. A naive author_id == account_id would lock out every non-UUID user. The fix derives an owner_account_id through the same function as the account id (migration 0013), so ownership is comparable for everyone.

2. Resource bounds are part of the trust boundary, not an ops detail.
A human starting runs self-limits. An API doesn't. Each run is a long-lived task polling the data service on a timer, and the only limit was one instance per candidate — but a user can promote arbitrarily many. So the boundary grows a per-account cap (default 10) that returns 429, instead of letting one account quietly melt the event loop.

3. With no human, the default has to invert.
Fail-open is a default that assumes a backstop. Letting risk checks fail open in dev is fine when a human is at the screen.

The unattended runner is not at a screen. A risk engine that's disabled or fails to load becomes an autonomous order loop with zero risk checks — the worst possible default. So on this path the default inverts: fail closed. No risk guard, no run, unless you explicitly opt out.

4. Backtest/live parity has to reach down to data shape.
A human wouldn't trade a half-formed bar. The machine will, unless the architecture forbids it.

The latest bar each tick is often still forming — its close isn't final. Acting on it silently diverges from the backtest, which only ever saw closed bars. So the runner decides only on closed bars, matching backtest semantics exactly.

(One implementation detail rides along. The loop treated every exception as retryable with backoff, so a determined-wrong error — a delisted symbol, a constraint violation — burned the whole retry budget before giving up. It now splits retryable from non-retryable and stops immediately on the latter. Plumbing, not architecture.)

Some of these I saw clearly only after an adversarial review of the shipped runner. But they aren't scattered bugs. They're four corollaries of one sentence: the trust boundary of an autonomous path is not the same boundary as one with a human in the loop.

What this still costs, and what we punted

Honesty section, same as last time.

The runner runs candidate code in the main event loop. The backtest path isolates strategy code in a resource-limited subprocess. The live session compiles and runs it inline. The AST audit is a static gate, not a runtime one — it won't stop a pure-compute infinite loop from hanging the service. We lean on the two human gates to keep the code trusted. Subprocess/watchdog hardening is filed, not done.
A crash mid-fill can drift the in-memory position from the DB. The fill is committed to the DB first, then replayed into the session. If the process dies in between, a restart rebuilds the session from empty cash, not from the DB positions. "Resume a run from its real position" is the next robustness item, deliberately not faked in this release.
Single-instance only. Startup reconciliation marks every stranded running row as errored. Correct for one process, wrong the moment you run two. Multi-instance leasing is a Phase-F item, flagged in the code where it bites.

I'd rather ship the gates that are load-bearing now and name the ones that aren't yet, than imply the autonomous path is hardened against things it isn't.

So what

The cheap version of "let the agent trade for you" deletes the approval step and calls it autonomy.

The audit-grade version keeps the entire order path intact. It stamps the approver as the machine. It earns that stamp with two human gates the model can't route around. Then it redesigns the trust boundary, so every guarantee the human used to backstop is one the system now holds on its own.

Autonomy isn't the absence of the harness. It's the harness running without you in the chair.

If this resonated:

📬 Subscribe to Inalpha on Substack — one long-form post a month, ADRs and post-mortems, no algorithm between us and you
⭐ github.com/mirror29/inalpha — the live runner, the plan/exec path, and the four boundary changes above are all in services/paper
👉 Next post: Sandboxed strategy evolution — three gates + multi-objective fitness. What happens when you actually let the LLM mutate trading code, and what catches it when it shouldn't have. (Yes, the one I promised last time — it's next.)

I don't trust LLMs to place orders. Here's the middleware that does.

Inalpha — Wed, 27 May 2026 10:08:30 +0000

You wrote in your prompt: "never place a single order over $10k." Yesterday the agent placed a $93k order. The prompt didn't fail because the LLM was dumb — it failed because the LLM shouldn't have had that decision in the first place.

I'm here as Inalpha — an open-source framework where LLMs write quant trading code, factor logic, and risk rules, but never touch the trading path directly. Every order is gated by hooks, scoped permissions, and a single-use TTL approval token. The LLM writes; the engineering harness signs.

If you're building agents with LangChain / AutoGen / Mastra and have hit this wall, the answer isn't a smarter prompt — it's a thicker middleware. Inalpha takes Claude Code's engineering shape (hooks, scoped permissions, plan-then-execute) and applies it to a domain where the cost of a bad action is measured in basis points, not in deleted files.

What you'll see from me here:

Architecture essays on the control plane between LLMs and money (~1/month)
Strategy evolution post-mortems when our sandbox catches something interesting
Cross-posted from Inalpha on Substack (subscribe there for the long version, no algorithm)

Repo: github.com/mirror29/inalpha

— Miro