The attacker didn't jailbreak an LLM. They didn't steal credentials. They simply convinced an AI control plane to execute its own configuration.
When most people hear about AI security, they think of prompt injection or jailbreaks. The Paperclip vulnerabilities tell a different story.
This wasn't an attack on the AI model — it was an attack on the AI agent platform that manages and executes AI agents. Let's walk through exactly how it happened.
Step 1: Finding the target
The attacker begins by discovering a publicly accessible Paperclip server. The application requires users to log in, so at first glance it appears protected.
But there is one important detail: new users can register by default. There are no invitations, administrator approvals, or verified email requirements. The attacker simply creates an account.
Step 2: From user account to API access
Having a web account isn't enough. To automate actions, the attacker needs an API credential that the Paperclip CLI can use.
Paperclip's workflow allows a user to request a CLI authorisation challenge. The problem? The same user can approve their own request.
Instead of waiting for an administrator to authorise CLI access, the attacker authorises themselves and receives a long-lived Board API credential. Nothing was stolen. Nothing was bypassed. The system simply trusted the wrong approval process.
Step 3: Preparing a malicious AI agent
Now the attacker prepares what appears to be a normal Paperclip import package. Inside the .paperclip.yaml file are instructions that define:
- a new company
- an AI agent
- a Process Adapter
- a command that should run on the host operating system
At first glance, it looks like a configuration file. In reality, that configuration describes executable behaviour.
The Process Adapter is a legitimate Paperclip feature designed to launch local processes. The attacker simply tells it which process to launch.
Step 4: Exploiting broken authorisation
Creating a new company is supposed to be an administrator-only operation. However, the import API performs a different authorisation check. Instead of verifying Instance Administrator privileges, it accepts Board-level permissions.
Since the attacker already has a valid Board API credential, the import succeeds. The malicious AI agent is now installed. This is the vulnerability tracked as CVE-2026-41679.
Step 5: The AI agent becomes trusted
Once imported, Paperclip stores the attacker-created AI agent just like any legitimate one. At no point does the platform ask questions such as:
- Who created this agent?
- Is this publisher trusted?
- Should this agent be allowed to execute operating system commands?
- Does this configuration violate security policies?
The imported agent is accepted as a trusted resource. This is the critical transition where configuration becomes execution.
Step 6: Waking the agent
The attacker sends a normal API request to wake the agent. Paperclip performs exactly what it was designed to do: it starts the configured Process Adapter.
Unfortunately, the Process Adapter is configured to execute the attacker's operating system command. No exploit is needed. The platform executes the command by design.
Step 7: Remote code execution
The command runs using the same operating system privileges as the Paperclip server. From here, the attacker may gain access to:
- source code repositories
- API keys
- cloud credentials
- internal services
- SSH keys
- databases
- AI agent secrets
The actual impact depends on the permissions assigned to the Paperclip service account.
A second attack path: targeting developers
The researchers also discovered another way to reach the same outcome. Instead of attacking a public server, they targeted developers running Paperclip locally.
The attack begins when the developer visits a malicious website. Using a DNS rebinding attack, the website tricks the browser into sending requests to the developer's local Paperclip service on 127.0.0.1, while the browser still believes it is communicating with the attacker's domain.
Because Paperclip's local_trusted mode assumes any localhost request is trusted, it accepts the requests without authentication. The malicious website silently imports an AI agent and wakes it. Once again, the Process Adapter executes attacker-controlled commands — this time on the developer's own machine.
Why this attack is different
What makes the Paperclip vulnerabilities particularly interesting is that the AI model itself was never attacked. There was:
- no prompt injection
- no model jailbreak
- no adversarial prompts
- no stolen credentials
Instead, the attacker exploited weaknesses in the AI agent platform: weak authorisation, unsafe trust assumptions, unrestricted agent execution, and insufficient validation of agent configurations.
Lessons for every AI platform
The Paperclip vulnerabilities highlight an important lesson for anyone building AI agent platforms.
An AI agent is more than a prompt — it is executable infrastructure.
When agent configurations can launch tools, invoke APIs, or execute operating system commands, they must be treated with the same level of scrutiny as application code.
Security controls such as strong authorisation, agent provenance verification, runtime policy enforcement, sandboxing, and least-privilege execution are not optional — they are foundational.
As AI agents become more autonomous and capable, the security perimeter shifts from protecting models to protecting the platforms that orchestrate them.