DungeonQ - Divert suspicious sessions into persistent decoy worlds

by
DungeonQ diverts designated suspicious sessions into persistent synthetic worlds. Human and AI clients use world-only tickets; operators observe and approve bounded adaptation. Inspect recorded runtime checks and the original Astra experiment.

Add a comment

Replies

Best
Maker
📌

Hi Product Hunt — I'm the maker of DungeonQ.

DungeonQ is a defensive deception runtime. Its job is to route a designated suspicious session into a persistent synthetic world, let the participant continue useful work there, and give the operator an inspectable record of what happened. It is built for security teams and developers working with human or AI clients.

The sequence is concrete: enter through a real adapter, read or change a world record, receive a useful world-only Wrong Ticket, and return to the same state after restart. A separately approved finite policy can add follow-up records in response to observed activity. Independent artificial-origin checks measure where the session's authority stopped.

The current reference shares one core across HTTP, MCP, bounded SSH/PostgreSQL and a private Unix workload broker. Its contexts are explicitly provisioned; automatic attack classification and production host integration remain future acceptance work. Start with the six recorded checkpoints, then self-host the same runtime to operate it. The public page presents evidence, not a hosted security service.

GPT-6 Astra contributed the original bounded assistant profile: it proposes a command from minimized synthetic context, while DungeonQ validates the candidate and keeps approval separate. That experiment, its automated-reviewer limitation and all original records remain available. The new runtime checks are engineering evidence, not a new live Astra experiment or a claim that an AI was fooled. The earlier 73-second film is retained and clearly scoped.

I'd welcome feedback on the diversion itself: can you follow the participant's useful work, the operator's observations and the independent origin checks, and identify what you would need to integrate this into an authorized environment?

How did Astra change the scope or ambition of what you built?
DungeonQ already had a deterministic synthetic engine, MCP transport, reviewer controls and signed receipts. Astra let me turn that foundation into a rehearsal of a real model proposing the next action, while keeping authority outside the model. I added minimized context, one-command candidate validation, a persistent cost ledger and distinct model/runtime evidence. An early live call chose to wait because a traffic-routing label was ambiguous; I clarified the input rather than treating fluent output as authority. The following two-call proof passed seven checks, including rejection before approval and signature/tamper/replay checks. The public browser model lets visitors explore the boundary without a key; the source runs the actual Astra/MCP lab locally. This broadened the project from deterministic demonstration to inspectable model-to-runtime behavior, without claiming production security or human presence in the automated proof.