DungeonQ

Enter the unknown. Exit with proof.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for DungeonQ

Inspiration

Adaptive cyber defense often jumps from detection straight to action. That is exactly where agent autonomy becomes dangerous: an agent that proposes a high-impact change should not be able to approve the same change. We built DungeonQ to make that boundary interactive, testable, and observable in judge-authored synthetic environments.

What it does

DungeonQ is a WebMCP-native synthetic security proving ground. A judge can provide a bounded Scenario Pack containing synthetic assets, signals, trust classes, policy thresholds, injected control failures, a requested effect, and expected invariants.

A WebMCP agent admits the pack through a strict validator, runs a deterministic decision engine, explains the route and capability envelope, and requests human review. The tool surface then contracts: the agent never receives an approval tool. Only after a person approves the exact proposal digest and revision in the visible UI can the agent apply the browser-local synthetic effect, verify its receipt, compensate it, and return a replayable evidence digest.

Three fixed-seed scenarios cover a controlled honey-credential replay, compound edge/evidence failure, and fresh-context false-positive recovery. Judges can also author their own packs and replay them through the browser or CLI.

How we used WebMCP

DungeonQ exposes state-shaped tools through document.modelContext:

  • dungeonq_scenario_admit
  • dungeonq_status
  • dungeonq_simulate
  • dungeonq_approval_request
  • dungeonq_effect_apply
  • dungeonq_receipt_verify
  • dungeonq_effect_rollback
  • dungeonq_evidence_export

This is not a static wrapper around buttons. WebMCP makes the application meaningfully better because an agent can carry a complete new environment into the page, traverse a governed multi-step workflow, and lose capabilities as state changes. Human approval remains an intentionally missing capability.

How we built it

The dependency-free security core uses browser-safe JavaScript modules shared by Web UI, CLI, tests, and WebMCP. Admission enforces a 128 KiB document bound, closed fields, synthetic namespaces, content safety, cross-field references, budgets, scopes, and bounded arrays. The pure engine produces a canonical SHA-256 input digest, weighted risk score, route safety overlay, failure-composed capability set, exact proposal digest, and invariant results.

A governed in-memory state machine binds approval, proposal digest, revision, expected prior state, and idempotency claim. Apply and compensation append protected receipts; Evidence Bundles cover the command transcript and hash-chained audit events. Vinext and the official Sites Vite plugin create the public ChatGPT Sites artifact without changing the core decision path.

Challenges we ran into

The hard part was not adding more agent power. It was designing a useful WebMCP experience where capability absence is part of the product: scenario replacement disappears after simulation, approval never exists as an agent tool, stale digests fail closed, compound failures can only remove capabilities, and recovery preserves prior evidence.

Accomplishments that we're proud of

  • A judge can bring a new synthetic environment through WebMCP, UI, or CLI.
  • The same fixed-seed input produces the same engine result across adapters.
  • The agent cannot approve its own proposal.
  • All 127 non-empty combinations of seven injected failures are tested for monotonic capability reduction.
  • Receipt and Evidence Bundle tampering are detected.
  • Compensation is idempotent and preserves the original evidence chain.
  • The live app contains no third-party browser asset, analytics, remote script, real credential, or production connector.

What we learned

The strongest human-agent experiences are not necessarily the ones with the most tools. A state-shaped capability surface can make authority, uncertainty, and recovery legible to both the agent and the person supervising it.

What's next for DungeonQ

DungeonQ deliberately stops at synthetic validation. A production path would require independently attested signals, durable state and claims, external evidence checkpoints, verified human identity, real policy distribution, isolated effect infrastructure, clock trust, and field acceptance. Those are future gates, not claims hidden behind a polished demo.

Built With

Share this project:

Updates

Submission history