Hardening Paperclip and Keeping the Fixes From Regressing
A security pass over Paperclip's agent-orchestration server that closed critical, high, and medium findings and added enforcement so they stay closed.
Paperclip is open-source orchestration for running a business with a team of AI agents. It is a Node.js server and a React UI where you define goals, assign work to agents from any provider, and track their output and costs from one dashboard. Under the task-manager surface it carries org charts, budgets, governance, and agent coordination. This work was the security hardening pass: fixing the critical, high, and medium vulnerabilities and, more importantly, adding permanent enforcement so they do not come back.
Why an Orchestrator Is a Sharp Attack Surface
A system that coordinates many agents toward a goal is exactly the kind of thing you have to secure carefully. It holds credentials for multiple providers, it runs agents autonomously around the clock, and it moves real money through budgets. Anything that can receive a heartbeat can be hired into it. That is a large and porous surface, and a weakness in the coordination layer is not one broken feature, it is leverage over every agent the platform is driving.
So the fixes spanned the severity range rather than cherry-picking the scariest bug. Critical and high findings are the ones that make headlines, but medium issues are where real incidents usually assemble themselves, one modest weakness chained to another. Clearing the whole set was the point.
Fixing Is Only Half of It
The part I care about most is the permanent enforcement. Fixing a vulnerability is a moment in time. Keeping it fixed is a property of the system, and those are not the same achievement. It is easy to patch a hole and watch a later refactor quietly reopen it, because nothing in the codebase remembers the fix mattered.
Enforcement turns each fix into something the project checks and holds itself to going forward, so a regression is caught as a failure instead of shipping as a surprise. Writing that layer in TypeScript helped, because types let you make some classes of mistake unrepresentable rather than merely discouraged. The closer the guarantee sits to the compiler, the less it depends on anyone remembering.
The takeaway is that a security pass without enforcement has a short shelf life. The durable win is not the list of closed findings, it is the machinery that makes reopening them hard.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →