Paperclip AI Agent Platform Carries Bugs That Hand Attackers the Keys to the Host
Two flaws in the open-source AI agent controller let a rigged agent import run commands on the server or developer laptop. A third leaks control-plane data through unprotected API routes.
Key points
- Paperclip, an open-source control plane for coordinating teams of AI agents, contains two flaws that let attackers run commands on the machine hosting it.
- Both command-execution paths need the victim to import a malicious agent file and start it, either on a server or a developer's own laptop.
- A third flaw exposes sensitive data and internal control-plane details through unprotected API routes.
- The vulnerabilities affect anyone running Paperclip to manage AI agent workflows, including developers testing agents locally.
- Users should treat imported agent definitions as untrusted code and review Paperclip's advisories before running unfamiliar agents.
Researchers have disclosed three security flaws in Paperclip, an open-source tool that acts as a control panel for orchestrating groups of AI agents. Two of them let an attacker run commands on the computer where Paperclip is installed. The third quietly hands over sensitive information through the product's own web interfaces.
The common thread across the two worst bugs: someone has to import an agent file that a criminal has tampered with, then start it. That agent could arrive by any of the usual routes, a shared template, a public repository, a colleague passing along a config.
What is Paperclip and why does this matter?
Paperclip is open-source software that helps teams manage swarms of AI agents, the automated helpers that plan tasks, call other tools and hand work between each other. Think of it as air traffic control for bots. If the controller is hijacked, everything it manages is at risk too.
That matters because Paperclip runs in two very different places. Companies host it on servers to run production agent workflows. Individual developers also run it on their laptops to build and test agents. A single malicious agent import can therefore land on a corporate server or on an engineer's personal machine, with the same result: the attacker gets to run commands as the logged-in user.
How does the attack actually work?
An attacker prepares an agent definition, the file that tells Paperclip what an agent should do, and seeds it somewhere a victim will pick it up. The victim imports the agent into Paperclip and hits start. That start action is enough to trigger code execution on the host.
On a developer's laptop, that means access to source code, SSH keys and browser sessions. On a server, it means a foothold inside the network, which is usually where the real damage begins. The Hacker News, which first reported the disclosures, noted both flaws follow the same import-and-run pattern.
What about the third bug?
The third issue sits in Paperclip's API routes, the web addresses its own components use to talk to each other. Some of those routes return sensitive data and internal control-plane details without proper checks. An attacker who can reach the API, whether from inside the network or from an exposed instance on the internet, can read information they should not see.
That kind of leak is often the first step in a larger attack: learn how the system is wired, then aim precisely.
The flaws at a glance
| Flaw | What it does | What the attacker needs |
|---|---|---|
| Command execution #1 | Runs commands on the Paperclip host | Victim imports and starts a malicious agent |
| Command execution #2 | Runs commands on a developer machine | Local import and start of the rigged agent |
| API exposure | Leaks sensitive data and control-plane details | Network reach to the Paperclip API |
What should Paperclip users do now?
Treat every imported agent as untrusted code, because that is what it is. Do not import agent definitions from strangers, public gists or unvetted marketplaces onto a machine you care about. Check Paperclip's project repository for the latest release and patch notes before running new agents, and restrict who can reach the Paperclip API, ideally keeping it off the public internet entirely.
Developers testing agents locally should use a throwaway virtual machine or container rather than their main laptop. Server operators should assume any Paperclip instance exposed to the wider network needs authentication in front of it, not just network-level trust.
