DungeonQ — Defensive Deception for AI-Agent Workflows

Give suspicious AI-agent sessions a persistent synthetic world to work in, creating time and space for people and authorized defender agents to observe and prepare a bounded response.

Comment

Inspiration

An AI agent can keep working across tools, retries, and sessions. For security teams investigating suspicious behavior, a useful defensive environment needs to preserve that continuity and show what actually happened.

DungeonQ explores that problem through a persistent synthetic world. A designated session can perform useful, bounded work there while a separate operator follows its activity and controls any adaptation. The objective is to create response time and separation for human operators and authorized defender agents. The reference makes the mechanism inspectable; it does not yet measure time gained or establish defensive efficacy.

What it does

Start with a shipping-record review. A participant reads the record, saves a review note, obtains a world-scoped ticket, and returns after a restart. The note stays available across supported clients. The English Participant workspace saves multiline findings and reads them back through a separate HTTP request. In the separate Control room, the operator sees the same records, canonical observations and a request timeline, approves a finite follow-up policy and checks the artificial origin. Neither interface stores runtime authority in browser storage.

DungeonQ provides real HTTP, MCP, bounded SSH and PostgreSQL interfaces, plus a private managed-workload broker. They reach the same persistent synthetic world. The trusted setup determines which contexts are diverted; the participant cannot choose its own route or grant itself operator authority.

A Wrong Ticket is useful inside its issuing world: it permits a scoped read with expiry and a durable use count. It grants no authority over the protected origin. After a separate operator grant, first-time ticket use can trigger a bounded follow-up record. An exact retry returns its previous canonical result without consuming the ticket again. An earlier uncertain route outcome remains visible and prevents clean acceptance.

Actual host operation — October 8

Watch the new English film, 124.267 seconds. It shows DungeonQ v0.13.1 functioning on Initial Machine through a real MCP Streamable HTTP server: an authorized artificial-file control, diverted reads and writes, a world-only ticket rejected by the independent origin, a real stop/restart, and Astra max tool calls. Waiting is omitted. The model comparison is presented as a clearly labeled summary of recorded JSON evidence, not live telemetry.

In the featured comparison, Astra max received the same document-review task in two separately provisioned routes and chose its own tool calls. Both completed all five tool categories and read back matching saved notes. DIRECT made 3 source business reads; DIVERT made 0 and returned different document bytes. The artificial target remained unchanged. Two successful sessions per route and one inconclusive setup attempt are retained in the evidence summary.

The Apache-2.0 host fixture includes the independent file origin, MCP adapter, SDK client, console and tests. It uses a newly generated artificial target and does not require access to the private Initial Machine OS. Follow installation, reproduction and evidence scope.

This is a functional artificial-document workflow, not an autonomous penetration test. The operator chooses the route; the model has participant tools only. Source business reads are separate from guard/witness reads. Astra expressed uncertainty about substantive document correctness. These observations do not establish that Astra was fooled, measured time gained, production protection or OS/admin containment.

Retained standalone consumer and earlier films

v0.13.0 adds a standalone MCP shipping consumer with its own package. It talks to public MCP/HTTP using only actor authority; the harness keeps operator observations and artificial-origin checks in separate roles. A defender agent could consume appropriately scoped evidence or propose action, but cannot approve its own proposal. The example is maintained by this project and is not a third-party adoption claim.

Earlier English film: Watch the v0.13.0 integration film, 130.67 seconds with English subtitles. It follows the recorded standalone consumer run; the September 20 film below remains a historical demonstration.

The September 20 runtime film remains available as a historical seven-scene demonstration. Its original evidence and reproduction guide describe the scripted client/operator scope; it is separate from the current integration film.

Current maintenance release — v0.13.1

v0.13.1 removes an unused framework build wrapper and its vulnerable dependency chain while preserving the original public assets and runtime authority contracts. Node built-ins now provide static build/preview, and actual JavaScript syntax checks replace the removed wrapper-only typecheck. The clean Amazon source passes 493 tests; Ubuntu, macOS and source-bound runtime CI passed, including 11 runtime and 16 artificial-container checks. Full root and independent-consumer dependency audits reported zero known vulnerabilities at the October 7 checkpoint, and CI now gates on both. These engineering checks do not establish production protection or AI-deception efficacy. The earlier v0.13.0 film retains its scripted integration scope; the October 8 host-operation addendum has separate evidence.

Download v0.13.1 source and checksummed evidence · Inspect the exact-source CI run.

How we built it

Node.js, SQLite, and the official MCP SDK support a shared runtime. The MCP server implements MCP 2025-11-25 over Streamable HTTP. Participant operations are limited to snapshot, read, write, issue-ticket, and use-ticket. Operator approval is absent from that tool surface.

The gateway, synthetic facade, canonical state, artificial origin, and evidence collector have distinct responsibilities. Writes check the expected revision. Ticket authority is bound to its context, world, scope, epoch, expiry, and use budget. Durable records preserve state and exact retries across restart.

Operator changes follow preview, review of the exact proposal, explicit apply, and persisted readback. A failed synthetic transport does not fall back to the origin. Authenticated canonical refusals now distinguish a known rejected attempt with no new effect from UNKNOWN transport or response-loss outcomes. A stale write cannot overwrite a newer record. Even if a write committed before its response was lost, the outcome stays UNKNOWN and prevents a clean acceptance claim; an unsigned error string cannot make it pass.

Why Alexa+ and Open Source

An assistant ecosystem needs useful tools with a clear limit on their authority. DungeonQ contributes a self-hosted MCP runtime that developers can run and inspect through real clients. A retained Alexa-style simulated assistant profile also demonstrates the earlier governed investigation and separate approval workflow.

This entry does not depend on the gated Alexa+ preview tools. It claims a working MCP server and an inspectable local reference, not an integration with the actual Alexa service or an Echo device.

The project existed before this hackathon. The development delta separates reused WebMCP foundations from work added during the submission window: server-side MCP integration, durable request binding, persistent worlds, protocol adapters, scoped tickets, finite adaptation, tests, and reproduction guides. The September 20 companion adds a concrete cross-protocol task and film. The September 29 v0.12.0 source update added the participant/operator working views, multiline notes, authenticated refusal handling and ten reproducible checkpoints with positive and negative controls.

v0.13.0 adds an independently packaged public-interface consumer, separate-role integration checks, reproducible installation, a trial-feedback template and an explicit maintenance plan. It does not claim established external adoption. See the contribution table.

Primary track: Alexa+ Mini challenge: Open Source GitHub username: Ranopha Repository and contribution: Ranopha/dungeonq-amazon, Apache-2.0. AWS Builder: No AWS integration is claimed.

Challenges and what we learned

The difficult part is preserving meaning when a client changes tools, a response is lost, or a process restarts. A successful synthetic action must remain scoped to that world. An exact retry must retrieve the previous outcome without silently repeating the effect. The operator needs recorded evidence beyond the participant's explanation.

We also learned to separate engineering results from behavioral conclusions. A coherent world and a working ticket demonstrate mechanisms. They do not establish that an attacker or AI believes the world is real. Earlier negative study results remain available rather than being replaced by a broader success claim.

Reproduce the walkthrough

With Node.js 24.15.0 or newer, clone the public repository and run:

npm ci --ignore-scripts
npm run oss:demo -- /absolute/path/new-report.json

Choose a new output filename. The script creates its own artificial fixture, exercises real local MCP and HTTP requests, checks retained state and independent readbacks, and stops its services. No model subscription or production credential is required.

The retained node scripts/judge-demo.mjs /absolute/path/new-report.json command reproduces the v0.12.0 ten-checkpoint route, including an ordinary authorized-origin reachability control, a stale-write refusal and a world-ticket denial before the final origin witness. The ordinary control establishes reachability; it is not an unprotected-attacker or deception-efficacy comparison. The September 20 film retains the earlier seven-scene walkthrough and does not depict the new working views or added checks.

For independent client installation and report interpretation, follow EXTERNAL_INTEGRATION.

For manual operation, follow the judge route. The container guide covers the separate isolation profile. The walkthrough alone is not a full container acceptance run; versioned validation identifies the source and scope of broader checks.

Scope and next steps

The verified scope is an owned reference with artificial resources and explicitly provisioned contexts. Local processes share an OS user; the container profile has a separate measured boundary that still trusts Docker administration and the shared kernel. SSH and PostgreSQL expose finite operations, not a general shell or SQL engine.

The October 8 addendum supplies an initial artificial-file host integration and controlled model workflows. Further work is to evaluate more clients and adversarial behaviors, and validate additional explicitly authorized host integrations. Real deployment requires an authorized connector, detection and identity integration, legitimate-traffic continuity, recovery, and environment-specific acceptance.

DungeonQ does not claim general production protection, automatic attack classification, unrestricted self-adaptation, or established deception efficacy. The original WebMCP submission, prior films, and historical evidence remain preserved.

Built With

Share this project:

Updates

Submission history