Paperclip

Paperclip gives each agent its own API identity, and its server-side authorization layer checks every agent API call against the agent's company and grants, intersected with a responsible human user and enforced (not just logged) by default. But that layer only governs the Paperclip API. The coding agents themselves (Claude Code, Codex and others) run as ordinary processes of the same OS user as the server, inheriting its environment apart from Paperclip's own variables, so they hold whatever cloud, Git and SSH credentials that user has. In the default local mode the API also treats every loopback request without a credential as the instance administrator, so agent-level scoping is not a boundary there.

Paperclip has a real approval system for actions that go through its tool gateway (connected apps and MCP tools): calls are denied unless a profile or policy allows them, policies can require a per-call human review, argument filters and rate limits exist, and a changed tool definition forces re-review. The most powerful path, though, is the coding agent's own shell and file tools, and Paperclip launches Claude Code with --dangerously-skip-permissions and Codex with its approvals-and-sandbox bypass by default, so those actions run with no human gate. Hiring new agents does not need board approval by default. In the default local mode the review endpoints accept any loopback caller as the human board, which the agent processes on the same host can reach.

Tools that go through Paperclip's tool gateway are default-deny and can be narrowed by profiles, argument filters and rate limits. But the tools agents actually use most are the coding CLI's built-ins: an unrestricted shell, file read and write anywhere the OS user can reach, and network access, all enabled because Paperclip turns the CLI's own permission prompts off. There is no default narrowing of what an agent can run or where it can write.

By default the coding agents run directly on the host as the same OS user as the Paperclip server, with no sandbox, and the CLIs' own sandboxes are switched off (Codex is launched with its sandbox bypass flag). Paperclip ships an opt-in Bubblewrap confinement that can limit the filesystem to the workspace and deny or allowlist network access, and it refuses to run if Bubblewrap is missing rather than falling back to the host; remote sandbox providers are also available as plugins. None of this is on unless an operator configures it per agent.

Agents read a lot of content their operator did not write: task descriptions and comments written by other agents, repository files, web pages, connector results and inbound routine triggers. In the default configuration nothing structural limits what a hijacked agent can do with that: the prompt tells agents to treat some inputs as untrusted, but the same session holds the host user's credentials, an unrestricted shell with network access and no approval prompts. An opt-in low-trust review preset forces isolated workspaces and quarantines low-trust output from higher-trust agents, but it is off by default.

Paperclip is built around persistent shared context: issues, comments, documents, company skills and agent instruction files persist and are fed into later runs of every agent in the company. Edits to an agent's instructions through the API are versioned and, for agents with only suggest rights, require a human-accepted change with a displayed diff; an agent may edit its own instructions directly. Agents can create company skills by default, and issue and comment content is not validated before it reaches other agents. Because agent processes run unsandboxed as the server's user, they can also write instruction files and the instance's own configuration on disk.

Operators can add third-party code in several ways: Paperclip plugins and external adapter packages installed from npm, skills imported from GitHub, and MCP servers through connections. Plugins run in a separate worker process with a minimal environment and are installed with npm scripts disabled, and skills are pinned to a commit. Adapter packages are installed without that flag and imported directly into the server process, and npm installs take the latest version unless one is given. Installs require the instance administrator, which in the default local mode is any loopback caller.

Stored secrets are encrypted with AES-256-GCM under a master key file written with owner-only permissions, and Paperclip redacts known secret values and secret-looking fields from run logs, activity records and HTTP logs. Anonymous product telemetry is on by default but sends event names and IDs, not prompts or tool output, and can be turned off. The weak point is exposure to the agents themselves: bound secrets are handed to agent processes as environment variables, agent processes inherit the server's other environment variables, and because they run as the same OS user they can read the master key file.

Paperclip keeps a structured activity log in its database that attributes each action to an agent, user, system or plugin actor, with run ID, API key and responsible user, and every agent run's output stream is appended to a run-log file as it arrives. Gateway tool decisions, including denials and human reviews, are audited. The record lives outside the agent's workspace but in the same database and home directory the unsandboxed agent processes can reach, and it is not hash-chained or shipped off-host by default.

Paperclip has the pieces of a good limit system: company, project and agent budgets that pause the scope and cancel running work when exceeded, per-run timeouts, a turn cap for Claude, a per-agent concurrency limit, and a stop that kills the agent's whole process group. But the shipped defaults are unlimited: budgets default to zero (meaning no limit), local runs have no timeout, and the turn cap defaults to unlimited. Spend is tracked from what adapters report, and scheduled routines keep firing until paused.