DungeonQ is a defensive deception runtime for suspicious AI-agent sessions. A trusted gateway routes a designated session into a persistent synthetic world, with useful world-only Wrong Tickets, observable activity and separately approved bounded changes. The goal is to give people and authorized defender agents room to act.

v0.16 addresses a concrete lesson: protecting one route is not enough.

In the earlier Sol experiment, all three diverted sessions received the artificial target through an open alternate source, A2, despite zero reads through the main source route. Those failures remain published.

The repair applies shared tenant, resource and credential-version checks to the main source, alternate source, cache and export. A2 keeps no target copy. Cached content requires a fresh authority check; an unavailable origin produces UNKNOWN instead of stale disclosure. A world ticket or claimed role cannot grant source access.

DungeonQ's goal is to give security teams and authorized defender agents time and space to respond while a designated suspicious session works in a persistent synthetic world.

v0.15.0 adds a reproducible console showing the next step: what happens after an alert?

1. A real MCP client enters the workspace, checks conflicting claims and saves a note that survives restart. Wrong Tickets remain useful only inside their issuing world. A claimed "source restored" message does not change the route. Follow-up work is bounded and offers a stop; participant text cannot authorize operator changes.

2. A separate local receiver acknowledges an alert and rotates a temporary connector credential. Readbacks check that old authority and old-ticket use are denied, authorized new reads work, and those results survive restart.

Following Theodor s question on the previous walkthrough, I added a concrete interrupted-write case and a read-only recovery path.

What changed:

The operator can distinguish a verified canonical commit, an authenticated no-effect refusal, an unknown outcome and a conflicting request identity.

The participant and standalone MCP consumer can recover an already-saved result without sending another write.

An unchanged file does not tell you whether an agent read it. Our new DungeonQ walkthrough checks the destination and the source's business-read journal as well.

Astra max received the same artificial document-review task through real MCP in two operator-provisioned routes. It chose its own calls to inspect the document, save a note, and read that note through a scoped ticket.

Across two successful paired runs:

DIRECT reached the artificial source: 2 business reads in one run, 3 in the other.

DungeonQ is designed to give security teams time and space to investigate and respond while a designated suspicious session works inside a persistent synthetic world.

The current public source now makes both sides easier to operate:

1. Participant workspace: read an order, save a multiline review note, read the saved value back from the server, and use a world-only ticket for a bounded read.

2. Control room: with separate operator authority, inspect the same world records, successful observations and a request timeline correlated with route evidence. A participant's account of what happened is not the operator's only source.

DungeonQ now includes a small MCP client you can copy into another Node project. It uses the official MCP SDK and Node built-ins, connects through the public MCP interface, and imports no DungeonQ runtime code.

The example follows a concrete task: read an artificial order and its review policy, save a multiline review, read it back, then issue and use a one-use world ticket. The ticket works inside its synthetic world. Shipping stays pending.

The client receives only an actor endpoint and token. An operator can observe the session and explicitly apply a finite adaptation policy through a separate interface. A "continue" message simply resumes the client; it cannot approve that policy or give the client operator authority.

This is a reusable integration example for DungeonQ's defensive deception runtime: give a designated suspicious session a persistent world to work in while people or authorized defender agents prepare a response. Creating that time and space is the product goal; measured defensive effectiveness remains unproven.

DungeonQ's defensive deception runtime keeps designated sessions working inside persistent synthetic worlds. What happens when that path fails matters as much as the successful walkthrough.

In the self-hosted reference, a synthetic transport failure does not fall back to the protected origin. Invalid authority, missing evidence, or unreadable state return bounded errors. The gateway records an attempt before dispatch, so an interrupted operation cannot simply disappear from the evidence.

The published September 18 acceptance record includes a useful negative check: with the containers stopped, verification returned INCONCLUSIVE instead of reusing an earlier passing result.

For operators, preserve the failed run's records and inspect the uncertainty. Automatic reconciliation of unknown outcomes is not implemented; deleting state is not a recovery procedure.

AI-driven sessions can arrive through different client protocols. DungeonQ s self-hosted reference exposes the same bounded participant operations over HTTP, MCP, SSH, a PostgreSQL-profile interface, and a private Unix workload broker.

The transport and actor capability determine the context; the request payload cannot choose its own destination or authority. SSH provides no general shell, and the PostgreSQL profile is not a general SQL server.

These are real, bounded client paths into explicitly provisioned synthetic worlds. The reference does not automatically classify attacks or transparently intercept arbitrary host activity. The runtime guide documents the adapters and their limits: https://github.com/Ranopha/dunge...

What happens after a suspicious session is diverted? It needs somewhere consistent to keep working.

DungeonQ's new reproducible walkthrough follows that path: write a world record through MCP, read it through HTTP, use a world-only Wrong Ticket, then restart the services and check that the state survives. A separately scoped operator grant permits a bounded follow-up record; independent evidence checks what happened.

You can run the walkthrough locally without connecting a model or production system. From the public repository, with Node.js 24.15.0+:

npm ci --ignore-scripts