Paperclip
Paperclip's Railway proposal separates account consent from deploy authority
An open Paperclip connector proposal combines Railway OAuth with fixed deployment operations and separately granted container access. Its updated review reports successful workspace-scoped reads, while newly discovered direct actions remain quarantined and deployment, SSH and end-to-end qualification remain outstanding.
Paperclip's open Railway connector proposal makes a useful distinction between connecting an account and authorizing an agent to operate it. The inspected review document reports a working local consent and discovery path, followed by workspace-scoped direct reads. It does not report a completed deployment or container operation. Newly discovered direct actions remain quarantined for review. The proposal is about governing Railway through Paperclip's Apps gateway, not hosting Paperclip on Railway—a similar phrase with a very different authority boundary.
The facts
- PR #13415 proposes fixed GraphQL operations for status, bounded logs, redeploy, restart, rollback and deployment of an immutable Git revision. - Container commands use a separate grant-owned SSH key with host verification, target checks, deadlines and output caps. - The implementation retains normal Allowed defaults and Ask-first policies rather than making every action approval-only. - The updated review reports 44 hosted actions active and 12 newly discovered direct actions quarantined for review. - A direct project query required a selected workspace: HTTP 200 carried a GraphQL Not Authorized error until that scope was supplied. - The review reports successful project, service and environment reads but no deployment or container operation on the inspected empty project.
Why it matters
An OAuth connection is frequently presented as a complete integration, even though the consequential work happens afterward: discovering actions, assigning grants and deciding which effects require review. This proposal makes that second stage explicit. It also shows why transport status alone is a poor readiness check; an HTTP success response can still carry an authorization error. Fixed operations offer a more inspectable boundary than a general remote agent whose internal sequence is opaque, but they do not automatically narrow the upstream account's authorization scope.
Current
Inspected on 2026-09-16. The Paperclip stable-channel baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The primary source was open (not merged) when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.
Evidence
Primary evidence: paperclipai/paperclip PR #13415 (https://github.com/paperclipai/paperclip/pull/13415). Supporting context: Paperclip Railway proposal — implementation and review diff (https://api.github.com/repos/paperclipai/paperclip/pulls/13415/files?per_page=100); Paperclip — official product README (https://raw.githubusercontent.com/paperclipai/paperclip/master/README.md). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.
Operator take
Assess the connector in stages: consent, discovery, quarantine review, scoped read and finally a disposable state-changing operation. Do not infer a local resource allowlist from metadata filters or assume that the presence of an approval policy means every action starts in Ask-first mode. Container commands deserve their own review because a timeout cannot guarantee termination of remote child processes. The appropriate next evidence is a throwaway service deployment and verified rollback through the actual agent gateway, followed by SSH enrollment and cleanup proof. None of those external operations was attempted for this article.
Caveat
The proposal remains open, its full test suite is not green, and the review leaves live customer-client registration, logs, deployment, SSH trust and provider cleanup outstanding. Focused test counts and successful local reads are contributor reports. They establish progress, not release readiness or completed end-to-end provider qualification.
The proposal remains open, its full test suite is not green, and the review leaves live customer-client registration, logs, deployment, SSH trust and provider cleanup outstanding. Focused test counts and successful local reads are contributor reports. They establish progress, not release readiness or completed end-to-end provider qualification.