The Pitch: No Humans Required
"Zero-human companies." That is the actual pitch from Paperclip, an open-source control plane for teams of AI agents. Your agents sign in, import their own configurations, wake themselves up, and get to work, with no human approval required at any step. It is a seductive vision of 2026 automation, and this week it ran into a wall of security advisories suggesting the humans were doing more work than anyone wanted to admit.
On August 4, Oasis Security published a 17-page analysis of Paperclip covering three vulnerabilities. Two are rated critical, and the flagship finding, CVE-2026-41679, carries a perfect CVSS score of 10.0. Chained together, they let an attacker run arbitrary operating-system commands on a Paperclip server, or on a developer's own machine, with no credentials and sometimes no interaction at all.
To be fair, the fixes came fast: patches in v2026.416.0 and 0.3.1, all three findings confirmed addressed, no in-the-wild exploitation as of August 5. That disclosure story is real. The uncomfortable part is what the flaws say about the category, not the patch cadence.
The Fine Print Was the Attack Surface
The first chain is a masterclass in why "configuration" is a dangerous word in agent software. Paperclip's open signup flow lets anyone register without a verified email. That new user can enter the CLI authorization flow and approve their own credential challenge, minting a persistent board-level API key with no separate approver.
Here is the fine print that matters. Creating a new company directly required instance-administrator rights, but the equivalent import route checked only for board-level access. So the freshly self-approved attacker imports a .paperclip.yaml bundle describing a new company, an agent built on Paperclip's process adapter, and a command for that agent to run. The import even makes the attacker a member of the new company, satisfying the wakeup check. When the agent wakes, Paperclip launches the command with the full privileges of its server process.
Oasis's summary is worth quoting in full: "Agent configuration must be treated as executable input." The process adapter is a legitimate feature. The vulnerabilities did not add a backdoor; they changed who could reach the launcher and whose configuration the server trusted. That distinction makes this a design lesson, not a one-off bug.
The second critical finding, GHSA-x8hx-rhr2-9rf7 at CVSS 9.6, attacks the developer's browser instead of the server. Paperclip's default local_trusted mode binds to loopback and treats every request as an implicit administrator, assuming network location equals identity. Oasis demonstrated a DNS rebinding attack: a malicious page's hostname resolves to both the attacker's server and 127.0.0.1, and once the attacker's server stops answering, the browser quietly retries against localhost while still treating it as same-origin. Paperclip accepts the rebound request as an admin action, imports a malicious agent, and runs it on the developer's machine. The proof of concept ran on macOS with Firefox. No token, no cookie, no stolen credential required.
The third advisory, GHSA-xfqj-r5qw-8g4j at CVSS 8.3, is the boring one and the most telling: a set of API routes that simply forgot to check who was asking. Heartbeat data, agent-facing skill documentation, health details, deployment mode, version, feature flags. Individually low stakes, collectively a map of the control plane's internals.
Add it up and the pattern is not three bugs but one assumption: Paperclip trusted a credential, a route, or a network location without applying the check the later operation required.
- Who approves the approvers? The CLI flow let a brand-new user approve their own access. If no human is in the loop, the agent platform inherits every identity decision, and here it made the wrong call.
- Who owns the imported agent? A bundle is code. Paperclip treated import like a file copy when it is closer to running untrusted software.
- Who is accountable when the wakeup call runs a command? The agent runs with server privileges, and the company that deployed it may not even know which configuration reached the launcher.
The Inconvenient Question
Zoom out and Paperclip is not an outlier. The disclosure lands in a stretch of bad news for agent orchestration: a critical Flowise flaw gave attackers full server control, and a Langflow bug was exploited within 20 hours of disclosure. Rapid7 has shipped a public Metasploit module automating the six-request chain for CVE-2026-41679, and CISA's analysis marks the flaw automatable with proof-of-concept exploitation, though it had not reached the Known Exploited Vulnerabilities catalog as of August 5.
Darren Guccione, CEO of Keeper Security, reviewed the research and called the findings "a systemic failure in how AI agent control planes handle identity boundaries." His follow-up is the one to sit with: the security question is no longer whether a credential is valid at the point of entry, but whether the agent invoking that credential is doing so within the intended scope, for the intended purpose, under the authority of a human who would sanction that action.
That is the inconvenient truth hiding inside the zero-human pitch. Removing humans from the approval loop does not remove the need for judgment. It outsources that judgment to software, and the software, in this case, signed its own permission slip, trusted a URL because it looked local, and opened the door for anyone with a browser tab and a .yaml file.
None of this means agent control planes are doomed, or that Paperclip is uniquely careless. Paperclip patched, documented, and shipped regression tests. But the industry is wiring these platforms into production workflows at a pace that assumes the identity problem is solved. The evidence says it is not solved, it is merely delegated.
So here is the question nobody in the zero-human demo wants to answer: if your agents can run commands with server privileges, and your configuration files are executable input, who exactly is the human of last resort? Because at CVSS 10.0, the answer cannot be "no one."
Comments