YC Open-Sourced the Agent It Runs Its Company On. Read QM's SECURITY.md First.

QM gives every employee and every Slack room its own scoped memory, files, permissions, and sandbox. Its own threat model then lists twelve places that scoping stops holding, and that list is more useful than the code.

Most agent repos ship a README that describes what the thing does and a SECURITY.md that says "please report vulnerabilities privately." Y Combinator open-sourced QM on July 31, the multi-agent harness it runs internally across accounting, legal, events, and engineering, including the work of building QM itself. The README is good. The SECURITY.md is 161 lines, and about half of it is a list of things that do not work yet.

"Command policy is bypassable." "Sandbox credentials are plaintext while in use." "Audience-floor filtering has known gaps." "Admins can read sensitive content." "Durable data can outlive user expectations."

That is a company publishing, under its own name, the exact document a security reviewer would spend three weeks trying to reconstruct from the source. It is the most useful thing in the repo, and I suspect most people cloning it this weekend will not open it.

The design problem QM is actually solving

Start with what makes QM different from the harness you already run.

Almost every agent framework in the last two years assumed one user. One person, one config, one memory store, one set of credentials, one machine. You can bolt a company onto that, and the README says so directly: "You can make one work for a whole company, but it quickly gets complex."

QM's organizing idea is that the unit of isolation is a scope, and a scope is a person or a room. Each one gets its own memory, files, keychain view, permissions, crons, web apps, and a durable sandbox. Your agent in your DM knows your things. The agent in the #payments channel knows the channel's things. The same identity follows you between Slack and the web UI. Skills are scope-owned and shared by explicit grant, with admin-gated promotion to the whole org.

Underneath, the core is TypeScript on Node with Fastify, Postgres holds sessions and durable state, the Slack surface uses Bolt, and the web UI builds with Vite and renders with Lit. The agent has a small fixed tool surface, and one of those tools is execute, which runs commands inside that scope's own sandbox. Harness and model are pluggable: Pi, OpenCode, Codex, and Claude Code all drive the same core, so a deployment is not tied to one vendor. MIT license, cloud-first, runs in your own cloud account.

That is a real answer to a real question. What happens when twelve people share an agent that remembers things is a question single-user harnesses never had to ask, and the answer "give each principal its own everything" is the right shape.

The honest part

Now the file I actually want you to read.

QM's SECURITY.md opens by refusing the obvious marketing move. "QM is designed to isolate each person's data and activity by scope. It is early, experimental software: that design goal is not a promise that data cannot leak, a certification, or a substitute for a deployment-specific security review."

Then it names twelve limitations. A few that matter if you are thinking about deploying this:

Command policy is a speed bump. It classifies shell text and catches configured or common dangerous forms. The doc says obfuscation, encoding, or writing a script and then executing it can evade it, and calls it "a speed bump against mistakes and injection, not a sandbox boundary." Most products would have called this feature "command safety enforcement" and stopped there.

Sandbox credentials are plaintext while in use. Credentials materialized into a sandbox as environment variables or files are readable by processes in that sandbox. Scope isolation and short-lived capabilities limit the blast radius. They do not stop a compromised agent process from spending or exfiltrating a usable credential.

Credential purposes are not enforced authorization. This is the subtle one and I think it is the most important paragraph in the file. When you grant a credential with a stated purpose, core enforces the grant's owner, audience, mode, expiry, revocation, and audit. The purpose text travels with the credential as an instruction to the model and an audit field. Core does not evaluate whether a later command stays inside that purpose. So the guardrail that feels like a permission is a note, and the model is the thing reading it.

Browser actions sit outside some core gates. Actions inside the browser runner do not re-enter command policy or human-in-the-loop approval, and browser traffic exits through the browser provider rather than QM's egress proxy.

Admins can read sensitive content. A scope-authorized admin can read transcripts, captured provider requests, documents, memory, connector metadata, mirrored message bodies, user details, and skill bodies. The read is audited. It is not separately consent-gated. If you sell "everyone gets their own private workspace" to your team, that sentence is the one you have to say out loud during rollout.

There are three security postures, and they are named with useful bluntness. Strict pauses every harness tool call for human approval. Auto, the default, runs a classifier over provenance-labelled external data and tool results before they reach the model. The third one is called Dangerous, and it does no content screening and no pauses. Naming your permissive mode "Dangerous" instead of "Performance" is a small thing that tells you how the rest of the code was probably written.

One more detail I liked, unrelated to agents entirely: newly published npm versions must age 7 days before they can enter a lockfile, enforced by min-release-age=7 in .npmrc. That is a direct response to compromised-maintainer supply chain attacks that get caught and yanked within hours. CI installs with npm ci from committed lockfiles and is unaffected.

Put this into practice

You do not need to deploy QM to get value from it this week. Three paths, in increasing order of effort.

1. Read SECURITY.md as a checklist against your own setup (30 minutes). Go through the twelve limitations and answer, for whatever agent your team already shares: is this true of us too? Most of them will be. Almost none will be written down anywhere. That exercise alone is worth the afternoon, and it costs you a browser tab.

2. Steal the posture model (an afternoon). Three named postures, with the org setting a floor that narrower scopes can only tighten, and a predeclared command policy of approval rules and hard denials that applies in every posture including the permissive one. That last clause is the design decision worth copying. Even in Dangerous mode, recursive deletes and destructive SQL still hit the policy. Most homegrown setups have one global "are we asking for confirmation" flag and nothing that survives turning it off.

3. Stand up a deployment (a day or more, and real infrastructure). Initialization is a single command:

npm exec --yes --package=@yc-software/qm@<exact-version> -- \
  qm init . --org <slug> --target <fly-or-aws>
npm install

That materializes a deployment directory and walks an agent through infrastructure, web sign-in, connector credentials, optional Slack access, deploy, and live verification. No source checkout needed. Everything company-specific lives in that deployment directory; core stays identical to upstream, which is what keeps your merges small later.

One trap worth naming before it bites you. If you want the whole codebase private rather than just a config layer, the docs tell you to make a private clone, not a GitHub fork, and they are right. A GitHub fork inherits the visibility of its parent, so a fork of a public repo cannot be made private, and forks share one object network, meaning commits you push stay fetchable by SHA from the public side. Use the bare-clone-and-mirror-push recipe in the README. The cost of the plain clone is that upstream's CI workflows run live in your account, so plan to supply secrets or disable the workflows you do not want.

Honest limitations

The star count is a mess and I want to flag it rather than pick a number. Coverage published within hours of the announcement quoted around 1.9k stars. Loading the repo page during this write-up served 11 stars, 0 forks, 19 commits. Loading the SECURITY.md blob page in the same session served 233 stars, 17 forks. Three figures, one session, one repo. GitHub's caching behaves like this on fast-moving repos, and it is a good reminder that a star count in a launch post is a screenshot of a moving object. Judge this one on the code and the threat model, not the badge.

Nineteen commits is the more telling number regardless of which star figure is real. This is a fresh public export of an internal system, not a project with a public history you can audit. YC's own docs say public source releases must start from a fresh export, so the internal commit history is not coming.

Cloud-first with a native Slack surface means standing up shared infrastructure, an identity provider, Postgres, object storage, and an audit obligation. This is not npx and go. And QM's interactive surfaces assume one organization of authenticated internal users. The doc is explicit that this is "not a hardened public or multi-tenant service boundary," with published apps as a deliberate exception where a capability link is bearer authorization: anyone holding the link reaches that app, copied links stay usable, and app ACL changes do not revoke individual link holders.

A harness YC tuned for accounting, legal, events, and its own engineering carries assumptions about how work flows that may not match yours. The permission model is portable. The workflow opinions baked into the seed skills probably are not.

And the deepest limitation is one QM cannot fix and says so: "the agent and software it runs in a sandbox are not trusted to make authorization decisions." Core is supposed to enforce identity, scope, grants, and delivery around the model. Every place where that enforcement is heuristic, and screening is explicitly described as "incomplete and heuristic," you are relying on a model's judgment about text that a stranger may have written.

What I would watch

The interesting question is not whether QM wins as a harness. It is whether publishing a twelve-item known-limitations list becomes normal.

Right now it reads as unusual candor. It should read as the minimum. Any team running a shared agent has this list; the only variable is whether anyone wrote it down and whether the people using the agent got to see it. YC just made the cost of writing yours much lower, because you can open theirs and cross out the lines that do not apply to you.

If you deploy this and find a thirteenth limitation, the SECURITY.md tells you exactly where to send it, and not to a public issue. I would like to hear what it was.

Sources: yc-software/qm README, qm SECURITY.md, Y Combinator announcement.