Skip to content

Back to the catalog

QM
github.comrepo

QM

QM is an MIT-licensed, self-hosted "multiplayer" agent harness that lets a company deploy a shared coding/ops agent across Slack and a web app, with per-person and per-room isolated sandboxes, memory, keychains, permissions, and crons. Its security model centers on an org-wide posture (Strict pauses every tool call for approval; Auto blocks private-network access and applies optional content screening; Dangerous disables both) layered under a predeclared command policy that hard-denies things like recursive deletes, plus an explicit Isolated/Open sharing posture that governs cross-scope memory and file access with provenance labeling and audit trails. It supports pluggable harnesses (Pi, OpenCode, Codex, Claude Code) behind a common core and documents its threat model and operator assumptions in SECURITY.md.

TL;DR Open-source multi-tenant agent harness (Slack + web) with tiered tool-approval postures, sandbox isolation, and scoped cross-context memory/file sharing controls.
Open original ↗
Document

What it is

QM (github.com/yc-software/qm) is a self-hosted multiplayer AI agent harness. Beyond the summary, the page documents two things a security reviewer needs before deploying: the actual default behavior of the "Auto" posture, and a separate sharing posture axis with specific cross-scope data-exposure rules the summary omits entirely.

How it works

Two orthogonal org-level ceilings, which narrower scopes can only tighten:

Security posture — Strict (every harness tool call pauses for approval, except two no-effect turn-enders); Auto (default); Dangerous (no screening, no pauses). The predeclared command policy (hard denials for recursive deletes, destructive SQL) applies in every posture including Dangerous.

Sharing posture (independent) — Isolated (default) vs Open.

flowchart TB
  ORG["Org posture (ceiling)"] --> SEC["Security axis"]
  ORG --> SHARE["Sharing axis"]
  SEC --> A["Auto: blocks private-network;\nmodel screening OFF by default"]
  SHARE --> O["Open: cross-scope reads\non live human turn"]

What to do — read before trusting "Auto" as injection defense

The summary implies Auto screens external content by default. The page contradicts this: Auto blocks private-network access and uses a content screener only when the deployment configures one. Model screening is OFF by default — deployments must use an external proxy or explicitly opt into the built-in classifier. Do not assume prompt-injection screening is active out of the box.

Open sharing posture widens data flow across scopes on a live authenticated human turn. Concrete limits to note:

  • Speaker's opted-in personal files/artifacts/skills/memory readable in opted-in shared rooms.
  • In DMs: files and skills from up to 25 recent shared contexts where they remain a member.
  • Included memories are loaded into the prompt in full with source-scope labels, with no relevance ranking.
  • Candidate window: 100 recent sessions; file discovery: 200 files.
  • Binary files still require explicit sharing before entering another conversation's sandbox.

Durability: set DATABASE_URL and SESSION_STORE=postgres. Without it, sessions live in process memory and vanish on restart.

Caveats

  • The page text is truncated mid-sentence ("personal and room scopes can…"), so the full scope-override rules are not shown.
  • "Isolated" is the default sharing posture, so Open's exposures apply only where an org opts in — but they are the reason to audit the sharing axis separately from the security posture.

Technologies named here

Techniques named here

  • Strict security posture
  • Auto security posture
  • Dangerous security posture
  • securityScreen.allPostures
  • Predeclared command policy
  • Isolated sharing posture
  • Open sharing posture
  • Agent acting as the credentialed user with auditing

Related in AI Security