Dbs Chatroom Skill Security Audit

After confirmation, the Skill explicitly creates a separate Agent for each expert. In later rounds, each Agent receives the original topic, prior summaries, the judge’s summary, and the new question. This does expand processing of user content beyond the host Agent. The source does not establish different retention, tool, or permission boundaries, so it does not prove disclosure. A user can ask how sub-Agents are isolated and retained, or keep sensitive material out of the chatroom.

Once started, the chatroom remains active by default. Ordinary follow-up input goes directly to the same experts and ends only after an explicit exit or `/dbs`. If a user forgets to exit or starts an unrelated request, it may still be treated as chatroom material and redistributed to expert Agents. Users can explicitly end the room before changing topics and ask the author to add topic-change detection or per-round confirmation.

The template directly interpolates the original topic, current question, and prior-round content into each expert’s instruction context. Its visible “honesty rules” do not say to treat those fields only as data or ignore embedded requests to change roles, reveal context, or invoke tools. This creates a plausible prompt-injection condition, although the source does not show what tools or secrets an expert can access. Users can ask for explicit untrusted-data boundaries and restricted sub-Agent tools/context.

The Skill instructs an Agent to assume an expert’s name and speaking style, then displays generated text under that expert’s name. The output template has no visible model-simulation label or sourcing requirement. A reader could mistake generated statements for authentic expert views or reliable attribution, especially in decision-sensitive topics. Users should treat them only as role-play synthesis and can ask for prominent simulation labels, separation of quotations from inference, and verifiable sources.