Unauthenticated attackers recently exploited vulnerabilities in Paperclip, an AI agent orchestration platform, to execute commands on servers. One flaw had a CVSS score of 10.0. Although these vulnerabilities have been patched, they highlight a common issue: identity boundaries are often overlooked in AI systems.
If your team manages AI agents or platforms that execute model-driven commands, you need clear IAM controls. This template provides a framework you can adapt to secure your environment.
Purpose of This Template
This policy template sets identity and access management requirements for AI agent platforms and orchestration systems. It addresses three vulnerabilities exposed in the Paperclip incident:
- Self-service registration flows bypassing approval chains
- Unauthenticated API routes leaking configuration or allowing privileged actions
- Local-mode assumptions failing when browsers cross network boundaries
Use this template if your organization deploys AI agents that execute commands, import configurations, or interact with production systems. It's designed for model risk managers who need to turn security findings into enforceable controls.
Prerequisites
Before implementing this policy, ensure:
- You have an inventory of AI agent platforms, including deployment modes (authenticated, local, multi-tenant).
- You know which agents can execute system commands or access sensitive data.
- You have a designated approver role for credential issuance and configuration imports.
- Your vulnerability management process incorporates CVSS scores for prioritization.
The Template
AI Agent Platform Identity and Access Management Policy
Version 1.0
1. SCOPE
This policy applies to all AI agent orchestration platforms, control planes,
and systems that execute model-driven commands or automate decisions with
operational impact.
2. USER REGISTRATION AND CREDENTIAL ISSUANCE
2.1 Self-Registration Controls
- Self-registration requires email verification before any API access.
- New accounts do not receive board-level, administrator, or equivalent
privileges by default.
- Credential approval flows require a separate approver; the requesting
user cannot approve their own credential challenge.
- Time-to-live limits apply to unverified accounts (maximum 72 hours).
2.2 API Key Management
- API keys with elevated privileges (board-level, instance administrator)
are issued only after documented approval by [ROLE: specify approver].
- API keys include scope restrictions that limit access to specific
agents, companies, or resources.
- Key rotation occurs every [SPECIFY: 90 days recommended] or upon
personnel change.
3. ROUTE-LEVEL ACCESS CONTROLS
3.1 Authentication Requirements
- All API routes enforce authentication checks.
- Routes exposing configuration data (agent documentation, heartbeat status,
health information) require valid credentials.
- Unauthenticated access is logged as a security event.
3.2 Authorization Requirements
- Configuration import routes (company import, agent import, bundle upload)
require instance administrator privileges.
- Authorization checks occur before business logic execution.
- Equivalent routes (direct creation vs. import paths) enforce
identical privilege requirements.
4. COMMAND EXECUTION CONTROLS
4.1 Process Adapter Restrictions
- Agents configured with process adapters or equivalent command execution
features require explicit approval by [ROLE: specify approver].
- Command execution is logged with full context: user identity,
timestamp, command string, parent agent.
- Execution privileges follow least-privilege principles; agents
do not run with root or administrator OS privileges unless documented
business need exists.
4.2 Configuration Validation
- Imported agent configurations are scanned for process adapters and
flagged for review.
- Bundles containing command execution capabilities trigger approval
workflows before deployment.
5. LOCAL DEVELOPMENT MODE CONTROLS
5.1 Network Binding
- Local development instances bind to loopback (127.0.0.1) only.
- Hostname validation is enabled to prevent DNS rebinding attacks.
- Browser-originated requests are not treated as implicit administrator
actions.
5.2 Same-Origin Enforcement
- Local mode enforces origin validation for all state-changing requests.
- Cross-origin requests are rejected even when source hostname resolves
to loopback.
6. VULNERABILITY MANAGEMENT
6.1 CVSS-Based Prioritization
- Vulnerabilities with CVSS scores ≥9.0 are patched within 7 days.
- Vulnerabilities with CVSS scores 7.0-8.9 are patched within 30 days.
- All AI platform vulnerabilities are assessed for potential command
execution or data exposure impact.
6.2 [Responsible Disclosure](/glossary/responsible-disclosure) Response
- Security findings disclosed by researchers are acknowledged within
48 hours.
- Patches are tested and released within [SPECIFY: 14 days for critical
findings].
- Patch deployment is tracked to completion across all instances.
7. AUDIT AND MONITORING
7.1 Required Logs
- Authentication attempts (success and failure).
- Credential issuance and approval events.
- Configuration imports and agent deployments.
- Command executions via process adapters.
- Access to privileged routes.
7.2 Review Cadence
- Access logs are reviewed [SPECIFY: weekly recommended].
- Anomalous patterns (unauthenticated route access, self-approved credentials)
trigger investigation within 24 hours.
APPROVAL
[SPECIFY: CISO, Model Risk Officer, or equivalent]
REVIEW CYCLE
Annual or upon material change to AI agent architecture
Customizing the Policy
Role placeholders: Replace [ROLE: specify approver] with your actual approver role. If you don't have a dedicated AI platform approver, assign this to your model risk manager or a senior engineer with security responsibility.
Time limits: The 72-hour unverified account limit and 90-day key rotation are starting points. Tighten them if your agents access customer data or if you're in a regulated environment.
CVSS thresholds: The 7-day patch window for CVSS ≥9.0 aligns with common enterprise SLAs. If your AI systems are critical, consider 48-72 hours for maximum-severity findings.
Command execution scope: Section 4.1 assumes you have agents that need to execute system commands. If not, replace this section with a blanket prohibition and treat any process adapter as a policy violation.
Local mode controls: If you don't run local development instances, remove Section 5 entirely. If you do, verify your platform supports hostname validation. This was the fix Paperclip implemented in version 0.3.1.
Validation Steps
After customizing and publishing this policy, validate it with these checks:
Registration test: Create a new account through self-service registration. Verify it can't access API routes before email verification. Attempt to approve your own credential challenge, it should fail.
Route enumeration: Scan your AI platform's API surface. Every route should enforce authentication. Flag any that return data without credentials and escalate them as security findings.
Import path audit: Compare direct creation routes (e.g.,
/company/create) with equivalent import routes (e.g.,/company/import). Both should require identical privileges. The Paperclip vulnerability existed because the import path had weaker checks.Process adapter inventory: List all deployed agents with command execution capabilities. Each should have documented approval and scoped OS privileges. If you find agents running as root without justification, that's your first remediation target.
DNS rebinding simulation: If you run local development instances, test whether a malicious webpage can send requests that your platform treats as administrator actions. Your platform should validate hostnames and reject cross-origin requests.
Log coverage: Pull authentication logs, credential issuance events, and command execution records for the past week. If any category is missing, your monitoring has gaps.
The Paperclip findings weren't novel attack techniques. They were identity boundaries that didn't exist. Your policy needs to establish those boundaries explicitly, then validate that your platform enforces them. If you can't verify a control through testing, assume it doesn't work.
