Skip to main content

Paperclip: AI agent fleet

You want an AI to own tasks end to end (fixing a bug, preparing a merge request, answering a support ticket, watching a pipeline), without rewriting an in-house orchestrator or trusting a closed SaaS to execute code against your repositories. Bunker hosts Paperclip, the open-source control plane that runs a fleet of autonomous AI agents.

Access: your dedicated instance, for example at https://paperclip.getbunker.net, deployed from the Bunker console.

Why Paperclip?​

A Paperclip agent receives a task (a ticket, a request, a scheduled routine), executes it (code, commands, API calls), then reports on its work through a merge request, a ticket comment or an email. An organization's whole fleet runs on an instance of its own, with its own database and its own workspace, never shared with another organization.

Every agent output (merge request, email, ticket action) passes back through the guardrail before it leaves the instance.

Isolation and guardrails​

Trusting autonomous agents to execute code shifts the trust question. Ordinary hosting asks "where does my data go"; here, you also have to ask "what is an agent allowed to do". Two levels, not to be confused:

  • Between organizations: real isolation, guaranteed at the infrastructure level. Each client organization has its own instance and its own database; two organizations never share the same container or the same storage.
  • Between your own agents: no technical isolation. All agents on a single instance run in the same container and can execute arbitrary code. That is a deliberate design choice, never presented as multi-tenant isolation. Protecting your agents from each other is not what the product is for.

The guarantee rests on an execution guardrail, rather than on a technical sandbox. It intercepts and validates every action before it goes out:

  • no CI pipeline bypass (a red job stays red, no forced merge);
  • read-only access to sensitive APIs (banking, customer support);
  • no direct push to a protected branch;
  • emails always drafted, never sent directly;
  • one merge request per task, never a branch stacked on another.

On the network side, outbound traffic to your private networks is filtered by a network policy (NetworkPolicy). Outbound traffic to the public internet, though, is not filtered per agent. The execution guardrail governs what agents are allowed to do.

Backups and data​

Your instance's database (CNPG/Postgres) is backed up daily to S3 storage. The agents' application workspace (git clones, working files) is deliberately excluded from that backup, because it is reconstructible at any time by re-cloning your repositories; backing it up would add nothing. See externalized backups for complete protection.

Edition and license​

Bunker hosts and operates the open-source Paperclip software for you and is not affiliated with its authors. "Paperclip" refers here to the software being operated, named for descriptive purposes only. The code stays auditable and the instance re-internalizable on your own infrastructure whenever you decide; the exact license terms are the ones published on the project's official repository (see References).

Portability​

If you leave, you take with you:

  • a database export (standard PostgreSQL dump);
  • the history of tasks, merge requests and tickets, already sitting in your own systems (GitLab, Jira, your forge);
  • the Paperclip software itself, open source, reinstallable on your own infrastructure.

Bunker vs self-hosting​

You could deploy Paperclip yourself. But:

AspectSelf-hostingBunker
High availabilityUp to youGuaranteed
Database backupsTo configureAutomatic (CNPG → S3, daily)
Execution guardrailTo design and maintainProvided, kept current across the fleet
Security updatesTo monitorApplied
HA databaseDBMS to manageManaged replicated PostgreSQL (CloudNativePG)
AuthenticationLocal accounts to manageOrganization SSO (FerrisKey, OpenID Connect)
24/7 monitoringTo set upIncluded

Quick start​

1. Deploy from the console​

  1. Go to console.getbunker.net
  2. Create your Bunker account or sign in
  3. Activate the Paperclip service from the console
  4. Access your instance via the provided URL, then sign in with your organization's SSO

2. Create your first agent​

  1. In the Paperclip administration, open Agents → Create agent
  2. Give it a role (support, code, operations) and the matching access
  3. Attach it to a task source (ticket queue, inbox, scheduled routine)
  4. Activate the agent once its guardrail has been checked

3. Follow the agents' work​

  1. Every task picked up shows up on the dashboard with its status
  2. Outputs (merge requests, draft emails, ticket comments) stay pending your review before external delivery where the channel allows it
  3. An agent's full action history stays available for audit

Channels​

A Paperclip agent receives its tasks and reports on its work through the channels already in place in your organization, like your Git forge (tickets, merge requests), your customer-support tool or a team messaging app. Nothing new for your teams to learn. An agent's outputs look like those of a colleague using the same tools.

Best practices​

  • Give each agent the narrowest possible scope for its task, rather than broad access "just in case"
  • Review a new agent's first outputs before letting it run unsupervised
  • Keep the execution guardrail current: it is what bounds what an agent can do, rather than a technical isolation between agents
  • Keep instances separate per organization, never one agent shared between two distinct organizations
  • Archive the processed task history regularly, beyond what the daily database backup covers

References​