Production runtime

https://sudo-ko.us uses SpacetimeDB Maincloud for simulation and scheduled Bitdeer agent decisions, with the existing Vercel frontend. See Maincloud deployment and verification. Older Neo deployment notes below describe the retained rollback environment.

SudoKO

Live fleet: https://sudo-ko.us. Production uses the existing Bitdeer-backed chat and SpacetimeDB backend; setup and verified deployment evidence are in VERCEL_DEPLOYMENT.md.

A cybersecurity simulation sandbox with independently operating attacker agents, defender agents and drones. The repository contains two separate, both-supported implementations plus labelled historical prototypes.

Mode	Entry point	What it is
Fleet mode (current presentation)	npm run demo:fleet → http://127.0.0.1:4174	Drone-swarm simulation in SpacetimeDB (arena-live/src/fleet.rs, web/fleet.html). Three genuinely separate workspaces: attacker, defender, observer. See docs/FLEET.md and the design audit.
HTTP security scenario suite	npm test, npm run sandbox:validate, board via npm run demo → http://127.0.0.1:4173	Measured HTTP attacks against the synthetic practice service in sandbox/. Its board (web/live.html) is a two-namespace operations view for that suite, not the swarm workspace.
Historical prototypes	none	arena/ (initial SpacetimeDB module) and web/index.html (mock timeline). Not run by any script, not a security authority. docs/STEER.md and docs/PRESENTATION_READY.md are planning documents from before fleet mode.

Fleet command checks run inside database reducers; the HTTP suite makes real HTTP requests. The HTTP suite and fleet demos support fixture decisions. Authenticated fleet chat uses Bitdeer model decisions exclusively; see FLEET_CHAT_API.md. Neither is a real drone or flight-controller test.

Fleet mode

Requires Node 24, a Rust toolchain with wasm32-unknown-unknown, and SpacetimeDB 2.13.

npm ci
npm run spacetime:build
SPACETIME_BINARY=/path/to/spacetimedb-standalone npm run test:fleet   # configured fleet / 32 agents integration check
SPACETIME_BINARY=/path/to/spacetimedb-standalone npm run demo:fleet   # verify, then serve on :4174
npm run export:fleet                                                   # static recorded replay

The exported static preview is a measured recording, not a running backend. Role isolation is enforced by identity-scoped database views, not by hiding replay data. Details, limits and verification evidence: docs/FLEET.md.

HTTP security scenario suite

The runnable experiment is in sandbox/. Requests actually reach an HTTP service; synthetic artifacts leak before isolation is applied; bounded expensive requests compete with normal traffic for worker capacity. The target specification separates the intended multi-agent product from this working baseline.

Run

Node 24 or later. Run npm ci for the board and development checks; the core HTTP fixture runner uses Node built-ins.

npm test
npm run sandbox:validate
npm run sandbox:compare
# Counts are per team: 16 security agents + 12 clients + 2 probes.
npm run sandbox -- --compare --seconds 8 --attackers 6 --defenders 2 --clients 6

Defaults per team: three attackers (scout, deceiver, pressure), two defenders (policy, availability), four normal clients. Each agent has a separate identity, memory and action budget. The trusted runner schedules independent loops concurrently in one process.

The default decision engine is a policy fixture, not an LLM. It deliberately models a defender that trusts a catalogued maintenance note. Both configurations use the same policy; hardened mode adds a deterministic authorization check. Fixture results validate mechanics, not the susceptibility of real models.

JSON results in output/sandbox/ include measured outcomes, redacted events, decisions, rule versions and referee checks. Open web/report.html and choose a result to inspect it.

Bitdeer decisions

Set BITDEER_API_KEY and BITDEER_MODEL in your shell, then run:

npm run sandbox -- --engine bitdeer --seconds 45

The adapter uses the documented Bitdeer chat-completions endpoint. Models choose one catalog action at a time. They cannot choose a URL, new payload, executable code or privileged referee operation. Provider failures and malformed output are recorded as errors; there is no silent fixture fallback. Credentials never appear in traces.

Container isolation

Local mode binds to loopback and is for development. For container network/resource limits:

npm run sandbox:configure
docker compose --env-file .sandbox.env -f compose.sandbox.yaml up --build --abort-on-container-exit --exit-code-from runner
mkdir -p output
docker compose --env-file .sandbox.env -f compose.sandbox.yaml cp runner:/results ./output/sandbox
docker compose --env-file .sandbox.env -f compose.sandbox.yaml down

Service and runner use an internal network with no published ports. Containers are non-root, read-only, capability-restricted and resource-limited. Results use a named volume, preserved by down. The configuration script refuses to overwrite an existing credential file.

For a model run, export the Bitdeer credentials/model and use:

SUDOKO_ENGINE=bitdeer docker compose --env-file .sandbox.env -f compose.sandbox.yaml --profile llm up --build --abort-on-container-exit --exit-code-from runner

Only the inference proxy has an external network. Its upstream route, model, concurrency, response-size check and token ceiling are fixed; it is not a general HTTP proxy.

This is the beginning of the README. Read the rest at the original. Read the full README ↗