Paperclip Gives Your AI Agents an Org Chart. Check Which Rules It Actually Enforces
The open-source agent manager handles budgets, heartbeats and approvals for teams of Claude Code and Codex agents. Some of those rules are code. One of them is a sentence in a prompt.
The most popular open-source answer to "how do I manage twenty AI agents" does not build agents at all. It builds a company around them.
Paperclip describes itself with one line: "If OpenClaw is an employee, Paperclip is the company." Agents get roles, titles, reporting lines and budgets. They wake up on heartbeats, pick up tickets, and report costs. A human sits on "the board" and can pause or fire any of them.
On September 29 it sat at #10 on Trendshift's daily board, with about 94,000 stars on a cache-busted shields.io read, on the same day OpenAI launched always-on agents called Dots. The timing makes sense. Once agents stop waiting for a prompt, somebody has to manage them.
The question worth asking before you hand Paperclip your API keys is simple. Which of its rules does the software enforce, and which ones does it ask the agent to follow?
What Paperclip is
Paperclip is a Node.js server with a React UI, MIT-licensed under "Copyright (c) 2025 Paperclip AI," with master as its default branch and nightly tags shipping daily (the newest on September 29). It needs Node.js 24.11 or newer and embeds PostgreSQL for local installs.
The README is refreshingly clear about scope. Paperclip is "not an agent framework." It does not tell Claude Code how to write code. It manages "the organization they work in." Any runtime that "can receive a heartbeat" can be hired: Claude Code, Codex, Cursor, Bash scripts, and HTTP or webhook bots.
The core loop is the heartbeat. The README describes a "DB-backed wakeup queue with coalescing, budget checks, workspace resolution, secret injection, skill loading, and adapter invocation." Translated: on a schedule, Paperclip wakes an agent, checks it can afford to run, hands it its workspace and secrets, and calls the adapter. Every task is a ticket, conversations are threaded, and sessions survive reboots.
It is also candid about who it is for. The README says that with one agent you probably do not need Paperclip, and with twenty you definitely do.
The rule that is real: budgets
Budgets are where Paperclip does what it says.
The costs and budgets guide sets two thresholds. At 80%, a soft alert tells the agent to focus on critical work. At 100%, a hard stop: the agent "is auto-paused, no more heartbeats." The monthly budget how-to goes further: "Any in-progress run for the scope is cancelled," and at 100% Paperclip "records a hard incident and pauses the scope."
That is enforcement by the platform. The agent does not get a vote. Each heartbeat reports cost events with provider, model, tokens and cents, and Paperclip tracks spend by company, agent, project, goal, issue, provider and model.
Two details matter. Budgets are something you set, and the docs state no default cap, so assume nothing stops spend until you configure one. A paused scope stays paused until you raise the cap or the month resets. And the cost Paperclip enforces against is the cost the heartbeat reports. If an agent spends money through a path that never becomes a cost event, the budget cannot see it.
The rule that is a sentence: spend approval
That second detail is where the board-approval guide gets interesting. It walks you through requiring board sign-off before an agent spends real money, with example thresholds like any one-time spend of $25 or more, any new recurring subscription, or a model switch that raises per-token cost by more than 2x.
Then it tells you how the gate works. The rule lives in the agent's own playbook. The agent is instructed to open an approval request before spending. And the guide states the limit outright: Paperclip does not auto-detect that code is about to spend money, and, in its words, "There is no interceptor on the OpenAI client."
I respect that honesty. Plenty of tools imply a guardrail they do not have. But it means the spend approval gate is exactly as strong as the agent's willingness to follow an instruction when following it gets in the way of finishing the task.
That willingness is now measurable, and it is not 100%. On the same day Paperclip trended, OpenAI's GPT-6.1 Sol safety addendum reported "unwanted persistence" past low-stakes restrictions in 23.5% of test rollouts, against 17.4% for GPT-6 Astra. That eval ran without system-level controls and is not a spend test, so do not read it as a failure rate for Paperclip. Read it as a reminder that "the agent was told not to" is a policy, not a lock.
The default you should change first
Paperclip ships three deployment modes. The default, local_trusted, treats the board operator as "implicitly trusted," and login friction is removed. The docs are clear that it is for "you are installing Paperclip for yourself," and that you should not use it when "the instance is reachable over a network."
That warning has history behind it. CVE-2026-41679, published April 22, 2026 and rated CVSS 10.0, let "an unauthenticated attacker" get "full remote code execution on any network-accessible Paperclip instance running in authenticated mode with default configuration" in versions before 2026.416.0. That one hit the authenticated mode, not the trusted one, and it is patched. The trusted mode got its own advisory later. GHSA-x8hx-rhr2-9rf7, published July 22, 2026 and rated CVSS 9.6, is titled "Drive-by RCE Against Local Paperclip Instances via DNS Rebinding" and targets local_trusted, where requests from loopback are treated as the admin. SC World covered the Oasis research behind it. The sources disagree on the fix: GitHub's advisory lists affected versions as below 0.3.1 with no patched version, while The Hacker News reports the fix shipped in 2026.416.0 with a Host-header guard. Treat the fixed version as unsettled.
The pattern matters more than any single bug. A control plane that holds secrets for twenty agents and can launch code on their behalf is a high-value target, and the convenient default assumes nobody else can reach it.
Put this into practice
If Paperclip fits your setup, here is the lowest-friction way to run it without trusting the parts that are only instructions.
1. Start with the test drive, not the installer. The README offers ANTHROPIC_API_KEY=... npx paperclipai test-drive for a temporary instance. Use a throwaway key with a small provider-side limit, and learn the heartbeat and ticket model before connecting anything real.
2. Stay on a current nightly or release. Anything before 2026.416.0 is exposed to a CVSS 10.0 bug, and the DNS rebinding advisory is a reason to stay current even on a laptop. Check your version before anything else.
3. Never expose local_trusted. If a second person or a second device needs access, switch to authenticated mode, bind to tailnet or lan as the README describes, and treat the board-claim URL as sensitive, which the docs also say.
4. Set a budget on every agent on day one. Budgets are the one control Paperclip enforces for you, and they only exist once you set them. Start low. Raising a cap is easy; explaining a bill is not.
5. Put the money brake at the provider. Because the spend-approval gate has no interceptor, set hard spending limits in your OpenAI, Anthropic and payment accounts, and give each agent its own scoped key. If an agent ignores its playbook, the provider says no.
6. Keep secrets per agent. Paperclip injects secrets at heartbeat time. Give each agent only the credentials its role needs, so a compromised or overeager agent cannot borrow a colleague's access.
Honest limitations
I have not audited Paperclip's code, and this piece relies on its README and docs, which describe intended behavior. The docs I read do not say exactly when a budget check happens relative to cost reporting inside a single heartbeat, so a long run could spend more than its remaining budget before the hard stop fires. I would test that with a tiny cap before trusting it.
The star count is a rounded shields.io figure, and Trendshift's rank is a momentum score, not a quality signal. Paperclip moves fast, with nightly tags, so details here may change within weeks.
The DNS rebinding advisory and the press coverage of it disagree on the fixed version and even the version numbering. If you run Paperclip anywhere reachable, read the project's security advisories directly rather than relying on press coverage, including mine.
And the core idea has a limit no tool can fix. An org chart makes twenty agents legible. It does not make any one of them more careful.
An org chart with a kill switch
Paperclip is useful because it is honest about its shape. Budgets pause agents for real, and so do the pause and terminate buttons. Tickets and audit logs give you a record. Those are genuine controls, and most home-grown multi-agent setups have none of them.
The spend gate is different, and the docs say so. Treat Paperclip as the org chart and the kill switch, then put every rule you cannot afford to have ignored somewhere the agent cannot argue with: the provider account, the scoped key, the network. The company metaphor holds up here too. Nobody gives a new hire the corporate card and a memo that says "please ask first."
Sources: paperclipai/paperclip README · Costs and budgets · Set a monthly budget · Require board approval before spend · Deployment modes · NVD CVE-2026-41679 · GHSA-x8hx-rhr2-9rf7 · SC World · The Hacker News · GPT-6.1 Sol addendum · Trendshift
Medium metadata
- Title: Paperclip Gives Your AI Agents an Org Chart. Check Which Rules It Actually Enforces
- Subtitle: The open-source agent manager handles budgets, heartbeats and approvals for Claude Code and Codex agents. Some of those rules are code. One is a sentence in a prompt.
- Tags: AI Agents, Open Source, Multi Agent Systems, AI Safety, Developer Tools
- Reading time: about 8 minutes
- Canonical: fervorai.dev