What Happened
Oasis Security disclosed critical vulnerabilities in Paperclip, an AI agent platform, allowing unauthorized remote code execution and data exposure. The most severe flaw, CVE-2026-41679, let attackers gain board-level permissions simply by creating an account. No exploitation was required beyond signing up. The vulnerabilities were patched in versions 2026.416.0 and 0.3.1.
This wasn't a sophisticated attack chain; it was a failure of identity boundaries in a system where AI agents operate with delegated authority.
Timeline
The public disclosure timeline isn't fully documented, but the sequence of events follows a familiar pattern:
- Oasis Security identified the vulnerabilities during research into AI agent control planes.
- Researchers found that default configurations granted excessive permissions to new users.
- The vendor released patches across two affected versions.
- Public disclosure followed remediation.
The key issue is that the vulnerability existed in default settings, meaning every deployment was exposed until teams actively patched.
Which Controls Failed or Were Missing
Default-deny access control: The platform shipped with permissive defaults. New accounts received board-level permissions without explicit grants, violating the principle of least privilege.
Identity boundary enforcement: AI agents in Paperclip operated with trust assumptions that didn't match actual user permissions. When configuring an AI agent, you're writing executable instructions. The platform treated these configurations as data, not code, and failed to validate that the user issuing commands had authority to execute them.
Input validation for agent configurations: AI agent configurations are executable input. They tell the system what to do, who to impersonate, and what resources to access. Paperclip didn't treat these configurations with the same scrutiny you'd apply to API calls or database queries.
Privilege separation: Board-level permissions shouldn't be a default state for any user, especially one who just signed up. The failure here is architectural; the system didn't separate administrative functions from user operations.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 7.2.2 states: "Access to system components and data is assigned to users based on job classification and function, and is set to least privilege." Board-level access for new accounts fails this requirement completely.
OWASP ASVS v4.0.3 Requirement 4.1.1 requires that access control decisions "fail securely" and default to deny. Granting elevated permissions by default is the opposite of failing securely.
ISO/IEC 27001:2022 Control 5.15 (identity management) requires establishing and maintaining processes for granting, reviewing, and revoking access rights. Default board access means you're granting rights without review.
NIST 800-53 Rev 5 AC-6 (least privilege) states: "Employ the principle of least privilege, allowing only authorized accesses for users which are necessary to accomplish assigned organizational tasks." New users don't have assigned tasks yet, they shouldn't have board access.
For AI agent systems specifically, you need to extend these controls:
Treat agent configurations as executable code: OWASP ASVS v4.0.3 Requirement 5.2.1 requires validating all input. AI agent configurations are input that becomes execution. Apply the same validation you'd use for uploaded scripts or API parameters.
Enforce identity boundaries in delegation: When an AI agent acts on behalf of a user, it must inherit that user's permissions, not escalate them. This is AC-6(2) in NIST 800-53: "Require that users of system accounts... are authorized to access the system."
Lessons and Action Items for Your Team
Audit your AI agent permissions today: If you're running AI agents, LLM integrations, or automation platforms, check what permissions they have by default. Don't assume the vendor got this right. Create a test account and see what it can access.
Map agent configurations to your input validation policy: Your organization already has rules about validating API calls, form submissions, and file uploads. AI agent configurations belong in the same category. They're executable input. Treat them that way.
Add to your validation checklist:
- Does the user have permission to create an agent with these capabilities?
- Does the agent's requested scope exceed the user's own permissions?
- Are the agent's actions logged with the user's identity, not the agent's?
Implement privilege boundaries for AI systems: You can't apply least privilege if you don't have privilege levels. Define roles for AI agent operations:
- Agent creator (can define configurations)
- Agent operator (can run existing agents)
- Agent administrator (can modify permissions)
- Board/system administrator (can change platform settings)
Don't let these collapse into a single permission level.
Review default settings across your stack: CVE-2026-41679 happened because someone shipped permissive defaults. You probably have similar issues. Check:
- What can a new service account do before you configure it?
- What permissions does your CI/CD system grant to new pipelines?
- What can a newly provisioned API key access?
Build identity awareness into agent architectures: When you design systems that use AI agents, make the user's identity a first-class concept. The agent should know who it's acting for, and the system should enforce that user's permissions at every decision point.
This isn't about AI-specific security controls. It's about applying the access control principles you already know to a new type of executable system. AI agents are automation with natural language interfaces. Secure them like you'd secure any automation that runs with delegated authority.
The Paperclip vulnerabilities are fixed. The pattern they exposed, treating AI configurations as benign data instead of executable instructions, is still widespread. Your team's job is to find it before someone else does.
