Landing Page

Inspiration

As AI agents start taking real actions such as calling tools, holding state, coordinating with teammates, the hard question isn't only “can they plan?” It's “what happens when a capable agent is wrong, hijacked, or adversarial?” We wanted a place where agents fight over the same shared world, with measurable outcomes.

SudoKO is a cybersecurity arena for agents: a fight club where attacker and defender specialists compete under real budgets, role isolation, and a referee that models cannot talk their way past. The name SudoKO (sudo KO) is the joke.

What it does

SudoKO is a live red-vs-blue agent security arena. Live demo: sudo-ko.us. Source: github.com/wongywrongy/calhacks13.0.

Operators open three genuinely separate workspaces - Attacker, Defender, and Observer over one shared SpacetimeDB fleet. Role isolation is enforced by identity-scoped database views, not by hiding UI chrome. Attacker and defender chat with their own agent teams, which plan specialists, spend bounded action budgets, and commit typed actions into the simulation.

Two complementary experiments ship in one product:

Fleet / resilience arena; A synthetic drone swarm (presentation fleets up to hundreds of drones; the live resilience mission uses a focused six-drone survey). Challenge specialists inject bounded disruptions (telemetry spoofing, invalid commands, communications degradation, mission conflict, malfunction). Defense specialists cross-check, quarantine, switch routes, reassign, and restore. Mission progress is packet delivery under time pressure; success is verified by reducers, not by model prose.

HTTP security scenario suite; Independently operating attacker/defender agents (plus normal clients and probes) hit a synthetic practice service. Real HTTP requests, tenant-boundary leaks, captures, reclaims, and hardened authorization checks are measured and exportable as evidence. Across both paths: models choose from a catalog - they cannot invent URLs, payloads, or privileged referee ops. Failures stay failures; there is no silent fixture fallback when live models are configured.

How we built it

Authoritative backend: Rust SpacetimeDB WASM module (arena-live) on Maincloud: motion, policy, battle attempts, resilience events, evidence, and role-scoped views live in reducers/transactions.

Inference: Bitdeer GLM models via a trusted server path. Browser never sees provider keys. Planner deploys specialists per side with hard caps on decisions, calls, and wall time.

Frontend: TypeScript + Three.js fleet UI - dusk basin scene, formation-aware swarm, status metrics, evidence log, and role chat. Vercel hosts the static app at sudo-ko.us.

HTTP suite & isolation: Node sandbox with fixture and Bitdeer engines, validation suites, and Docker Compose for network/resource-limited runs.

Verification culture: Integration tests for role privacy, unauthorized command denial, resilience admission/recovery, Playwright browser checks, and live smoke against production with redacted evidence artifacts.

How we used SpacetimeDB

We used SpacetimeDB Maincloud for both our database and simulation compute, with a deployed WebAssembly (WASM) module powering SudoKO’s drone simulation. The module owns fleet state, drone ownership and controller identity, policy versions, evidence rows, and attack/defense outcomes.

We queried across the fleet continuously. Latency mattered because every tick and action receipt had to reach both the AI agents (for their next decision) and the live Three.js visualization at the same time. Having compute and data together on Maincloud let us ship without standing up a separate simulation service, game loop server, or sync layer. The same durable records feed our AI resilience analysis, so explanations of what happened are grounded in the arena’s own history rather than a second log store.

More examples around high-frequency updates and efficient fleet-wide queries would have helped us get there even faster.

How we used BitDeer

We used Bitdeer’s Model Studio to get GLM 5.3 Flash for live agent interactions and GLM 5.3 for deeper analysis of our simulation data. Flash sits in the chat loop: users give instructions, specialists plan and pick catalog actions, and the fight stays responsive under multi-agent load. The larger model reads SpacetimeDB records after (and alongside) the run evidence, receipts, mission metrics and then explains attack and defense outcomes across the drone fleet in plain language.

Together, Bitdeer powered both the interaction and the insights behind SudoKO. Users can direct agents, watch the simulation unfold, and understand what happened without digging through raw activity logs. Response speed and structured outputs mattered most for us; more guidance on tuning those would help with live, multi-agent applications.

Challenges we ran into

Keeping AI decisions, drone states, and the live 3D view in sync was our biggest challenge; three clocks (model latency, reducer ticks, and frame updates) that had to feel like one fight. We also had to manage model response times under concurrent specialists, make attacks and defenses feel dynamic on the map (not just as log lines), and turn a busy evidence stream into status chips, sparks, and role-scoped chat that operators could read in a glance.

On top of that: early fixture defenders recovered so fast that takeovers were invisible, so we added detection delay and hijack drift physics; we had to enforce red/blue/observer isolation in the database, not the CSS; and we constrained models to catalog actions with post-inference authority rechecks and no silent fixture fallback when Bitdeer failed; all after pivoting mid-weekend off our original idea.

Accomplishments that we're proud of We connected SpacetimeDB Maincloud’s database and WASM compute with Bitdeer’s GLM 5.3 Flash and GLM 5.3 to build an interactive drone cybersecurity simulation. Users can direct AI agents through chat, watch attacks and defenses unfold in a live 3D fleet, and get resilience insights grounded in the same simulation data that drove the fight — not a hand-written after-action summary.

What we learned

We learned that a multi-agent system needs clear rules, reliable shared state, and visible outcomes to be useful. Putting the referee in SpacetimeDB (budgets, catalogs, epochs, evidence) kept models ambitious without letting them invent wins. Using Flash for live interactions and the larger model for analysis also showed us how much model choice affects the experience: speed for the control loop, depth for making the aftermath understandable.

What's next for SudoKO

Next, we want to work with models designed for authorized cybersecurity testing to explore more realistic attack and defense scenarios inside the same bounded catalog and referee. We also want repeatable evaluations; fixed missions, scored metrics, and comparable runs; so teams can benchmark AI defenders and measure whether their defenses actually improve over time