SECURITY MODEL

User-submitted code (strategies and skill scripts) executes under multiple layers of isolation. The orchestrator never trusts code output and never exposes platform secrets to the sandbox.

Execution Sandbox

Strategy code runs in an Azure Dynamic Session — an isolated, ephemeral Python runtime. The session executes signal() against a serialized context and returns target weights. It has no access to the platform database, credentials, or network internals.

Skill Script Hardening

Skill scripts (see Skill Bundles) run under an additional hardened executor:

AST scan first. Source is parsed and rejected before execution if it imports dangerous modules (os, subprocess, socket, sys, ctypes, importlib, pickle, marshal, threading/processing modules) or uses __import__, eval, exec, open, or dunder traversal.
Subprocess by default. Scripts run via python -I with JSON over stdin/stdout, a minimal environment, cwd confined to the skill's scripts/ directory, and a real wall-clock timeout. The orchestrator never inherits the script's process state.
Path confinement. Scripts cannot read or write outside their scripts/ directory.

Environment Variable Restrictions

Sensitive variables are never forwarded to sandboxed code: AZURE_*, DATABASE_URL, *_SECRET, *_API_KEY, and similar. Only Python-runtime variables (PATH, PYTHONPATH, PYTHONIOENCODING, PYTHONHASHSEED, PYTHONDONTWRITEBYTECODE) are passed through.

Output Is Untrusted

Everything returned from the sandbox is re-validated on the host. Target weights pass through guardrails, governance is logged on the host, and script output is never eval()-ed.