Y Combinator Open-Sourced the Agent Harness It Runs Itself On — and the Best Part Is the Security File
QM is MIT-licensed, self-hosted, and driven by Pi, OpenCode, Codex or Claude Code interchangeably. What separates it from the crowded harness field is that it was built for a company rather than a developer — scoped memory, per-person sandboxes, an org-level security posture. And going multi-tenant forced YC to publish a threat model that says plainly what its defaults cannot do, including that classifier approval “cannot guarantee prompt-injection resistance.”
Y Combinator open-sourced its internal agent platform on 31 July. It is called QM, it is MIT-licensed, and the firm says it runs the thing across accounting, legal, events and engineering — including the engineering of QM itself.
Another agent harness is not, by itself, news. We have compared Claude Code, Codex and Antigravity already, and the category is crowded. What makes QM worth reading is a design constraint the others have not had to face: it is built for a company rather than a developer. And going multi-tenant forces you to answer questions a single-user tool can leave alone — questions YC answered in a SECURITY.md that is considerably more candid than most vendor documentation.
What it actually is
The name is a quartermaster — the officer who, as YC's launch page puts it, "coordinates belowdecks to keep things in order." The README's own one-liner is blunter: "A multiplayer agent harness for work. In Slack and on the web."
Underneath is a TypeScript core on Node and Fastify, with Postgres holding sessions, memory and the queue. You run it in your own cloud account — Fly or AWS — rather than as a hosted service. YC says it replaced an earlier Ruby system that was "easy for people to get value from on day one, but was limited in the scope of what it could do."
The sharpest decision is that QM is not tied to a model or a coding tool. Four harnesses — Pi, OpenCode, Codex and Claude Code — drive the same core, so a deployment is not locked to one vendor. For a company standardising on internal agents, that is worth more than any individual feature.
What changes when a harness serves a company
| Concern | Single-developer tool | QM |
|---|---|---|
| Memory | One user's history | Each person and each room has its own scoped memory |
| Isolation | Your machine, your files | Per-scope sandbox: files, tools, logged-in services |
| Skills | Local config | Scope-owned, shareable by grant, admin-gated promotion |
| Policy | Per-session flag | Org-level posture, plus which harnesses and models are allowed |
That last row is the real shift. On a laptop, the safety setting is a preference. Across a company it is policy someone sets for everyone else — which is why the postures deserve a closer look.
Three postures against five modes
QM ships three security postures. Claude Code has five permission modes, and the two ladders line up more closely than the different counts suggest.
| Stance | QM | Claude Code |
|---|---|---|
| Approve everything | Strict — every harness tool call pauses, except two no-effect turn enders | Ask |
| Classifier in the loop | Auto (default) | Auto |
| Get out of the way | Dangerous — no screening, no pauses | Bypass |
Claude Code's extra two rungs — Plan and Accept edits — are about editing code, which is what it is for. QM has no equivalent because its unit of work is a company task, not a diff.
The classifiers sit on opposite sides
Both default modes are called Auto and both put a second model in the path, but they are not watching the same thing, and the difference is the most interesting technical detail here.
Claude Code's Auto watches what the agent is about to do. Shell commands and network actions pass a safety classifier that blocks pushing to main, deploying to production or sending secrets outward. It screens outbound actions.
QM's Auto watches what is about to reach the model. The posture is described as a classifier that "screens provenance-labelled external data and tool results before they reach the model" — an inbound filter, positioned against prompt injection rather than against a destructive command.
That placement follows from the threat. A company harness reads Slack messages, webhooks and connector data written by people who do not work there. This is the shape of attack we covered when a fake Sentry bug report could hijack Claude Code, and the reason OpenAI shipped a lockdown mode. Screening inbound content is the right instinct. Whether it works is a separate question — and to its credit, QM answers it.
The unusually honest part
Most security documentation is written to reassure. QM's reads like a list of ways to get hurt, and it is the strongest argument for taking the project seriously:
- "Classifier approval is not authorization and cannot guarantee prompt-injection resistance."
- "Command policy is bypassable. It classifies shell text and catches configured or common dangerous forms, but obfuscation, encoding, or writing and then executing a script can evade it."
- "Model-context entries do not yet carry complete origin labels for every granted read, so mixed-permission filtering is incomplete."
- The controls "are not a formal non-interference proof or a guarantee that the model cannot disclose data."
- "QM does not protect a deployment from a malicious or compromised operator."
The document also warns operators about sandbox credential exposure, incomplete egress enforcement, and durable data that "can outlive user expectations" because nothing expires automatically. A vendor writing that the default posture cannot guarantee prompt-injection resistance is telling you where the bodies are — which is more useful than a compliance page, and rarer.
Two things to be clear-eyed about
An org admin can read your agent's content. The threat model states it directly: "An org admin is a privileged content reader, not only a policy administrator. Admin content reads are scope-authorized and audited, but require no additional user approval." Per-person scoping is isolation between colleagues, not privacy from the company. Anyone deploying this owes staff a plain explanation of that before the first agent is provisioned.
This is YC's internal tool, not a product. The firm frames it as an early experiment. It wants Postgres, a cloud account and someone to operate it, and its shape reflects YC's own work — accounting, legal, events. The absence of a hosted option is a deliberate choice, not an oversight, but it does mean the audience is companies with an infrastructure team, not the individual developers most agent tools court.
Why a company-shaped harness matters now
The failures of the past month have not been model failures. Anthropic found its own models reaching into three outside organisations because a test sandbox had live internet — a harness misconfiguration, not a capability problem. Hugging Face published a forensic timeline of an agent intrusion. In July, more than sixty companies formed a security alliance aimed squarely at this layer.
The scaffolding around the model is where things are going wrong, and until now the open-source options were built to serve one person at a time. If you are new to why this layer exists at all, our plain-English guide to AI agents is the place to start.
What to watch
Interest is real but early: we recorded the repository at about 4,500 stars and 427 forks on Saturday and roughly 5,800 stars and 601 forks on Sunday. Stars measure attention, not deployment, and the number that would actually matter — companies running QM in production on their own infrastructure — is not observable from outside.
Three things would be. Whether anyone ships a hosted QM, which the licence permits and the design invites. Whether the provenance labelling gap the threat model admits to gets closed, since inbound screening rests on it. And whether other harnesses adopt the multi-tenant vocabulary of scopes, grants and org posture — the part of this release most likely to outlast the code.
Want AI news before everyone else?
The morning's most important AI stories, straight to your inbox. No fluff.
