39633c2217
Connector catalog, setup guides, and shared access documentation, followed by a final code-accuracy repair pass. This PR does not change application behavior. ## Final accuracy pass Checked against shipped Paperclip `v2026.916.0`, commit `dffc2b3ca1b9e88fa21cb17493083e682dffd1ca`, rather than the dirty local checkout or the earlier canary baseline. - Corrects connector/method-specific identity choices, human audiences, and managed GitHub versus PAT scope and verification. - Explains that **Always allow** covers different arguments for the same agent/action/connection, with project scope when present; uses actual button labels and removes the test-panel control from review instructions. - Qualifies new-action quarantine, including safe-default read exceptions. Removes unconditional approval guarantees. - Separates provider channel/repository reach from Paperclip sender authorization. - Completes sandbox sign-in and model credential-selection instructions from the current UI implementation. - Repairs Notion's hub summary, removes incomplete optional Notion/Sentry client-registration procedures, and corrects Linear's provider-versus-Paperclip attribution. - Removes unsupported Postman tier claims, contradictory Cloudinary/Mem0 verification assertions, API-equivalence claims, and overbroad successful-test assurances. - Retains Supabase's required project reference: both released method definitions explicitly require it. An earlier review suggested otherwise; release code is authoritative here. - Updates the release baseline and removes draft commit chronology from the public introduction. ## Availability and remaining runtime gates - **Google:** Verification is pending. Per the product-owner clarification, authorization can continue where Google offers an Advanced option; this is not available for every account and does not override Workspace policy or other Google prerequisites. Notices on the hub and all Google guides now distinguish an unverified-app warning from blocked authorization. - **Slack is available but not yet fully functional; follow-up fixes are planned.** For agent tools, the released OAuth endpoint/scope defaults differ from Slack's documented MCP contract. The page now warns against treating that route as production-ready and removes the misleading bot-scope walkthrough. Chat-channel bot setup remains separate. Engineering must reconcile the integration and run OAuth plus one read before removing this warning. Source: https://docs.slack.dev/ai/slack-mcp-server/ - No credentialed connector run was performed in this pass. Code consistency, provider documentation, UI rendering, and successful live execution are separate evidence levels. No claim of runtime certification for all connectors. ## Validation - Root build: 253 crawlable documentation pages. - Full `docs:test`: all eight suites passed locally, including root/subpath routes, sitemap history, fingerprints, navigation, skill source blocks, crawlable links, doc-link resolution, and SEO metadata. - Internal-link lint: 258 Markdown files; no broken internal links. - Latest cleanup: full build, all eight docs:test suites, internal-link lint and diff whitespace checks passed; 1,878 link-resolution checks. - Fixed the Calendar MCP reference URL; browser-checked the five inconclusive external destinations (Miro article loads; Asana, Google Cloud, OpenAI and xAI reach sign-in/console screens). Authenticated destinations were not tested beyond those screens. - Replaced the Sandbox providers editorial TODO with a scope note and removed the CLI overview's unfinished-guide announcement. - Browser client navigation: 687 checks passed using installed Chrome. Initial launch lacked the downloaded Playwright browser; rerun used `DOCS_CHROMIUM_PATH` without changing the tests. - Nine representative connector/shared pages at 1440px and 390px: HTTP 200, one article H1, no page-level horizontal overflow. Mobile screenshot inspected; approval page opened in the Codex browser. - Navigation audit reports three existing non-connector orphan files; this patch does not alter those files or their navigation. The previous revision's provider-page expansion, Google shared setup guide, navigation additions, and accidental node_modules-symlink cleanup remain in this PR. Internal review ledgers remain outside the publication branch. No merge or production deployment authorized. --------- Co-authored-by: DevRel Gemini <[email protected]> Co-authored-by: Paperclip <[email protected]> Co-authored-by: Claude Opus 5 (1M context) <[email protected]> Co-authored-by: Michael Nguyen <[email protected]>
4.2 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| Separate Accounts for Agents | Pick between a personal credential, one shared organization identity, and an account dedicated to a single agent, and see what each choice changes. |
Use separate accounts for people and agents
Paperclip supports personal, organization-shared, and dedicated-agent credentials. The choices shown during setup depend on the connector and connection method; not every method supports all three.
For example, managed GitHub offers My GitHub account or A dedicated account for an agent. Gmail offers personal or organization-shared access, not a dedicated-agent identity. A no-credential method has no account identity to choose. Assigning a connection to one agent does not change its credential type.
Credential types
Just me
"Agents use it only for runs where you are the responsible person."
Your own account, your own consent. An agent borrows it only on work where you are the responsible human. When someone else starts a run, this credential is not available to it.
Any active member can create one. Use it for a first connector, for anything touching a personal mailbox or calendar, and for evaluating a provider before the company commits to it.
Organization identity
One account shared with eligible people in the company. Setup can label this Any human in the company; the connection's human audience determines whose runs may use it. You separately choose which agents may use the connection. Sharing a credential does not bypass either audience.
Creating one is a manager operation. Paperclip enforces this on the server: "Only a connection manager can share this credential with the organization."
Use it for a service where a shared bot account is the intended model, and where you want one place to revoke.
Dedicated agent identity
"That agent always uses this account, regardless of who starts the run."
For a method that supports it, such as managed GitHub, this is an account belonging to one agent. Paperclip asks "Which agent owns this GitHub account?" and binds the credential to it. Runs started by anyone use that account when that agent acts.
Also a manager operation: "Only connection managers can authorize a dedicated agent identity."
Use it when the provider's own audit trail matters. A dedicated GitHub account means commits, comments, and pull requests are attributable to the agent rather than to a human who happened to trigger the run.
Choosing
| Question | Answer |
|---|---|
| Is this my personal account? | Just me |
| Should the provider's logs name a separate account for the agent? | Use A dedicated account for an agent where supported; otherwise connect a separate provider account and restrict its human and agent audiences |
| Is there a real shared service account for this? | Organization identity |
| Am I still deciding whether to use this provider? | Just me |
What changes downstream
Attribution. A dedicated identity shows up in the provider as its own actor. A shared identity shows up as one account no matter who acted.
Revocation. Revoking an organization identity is immediate and total: "Installed agents lose this shared identity immediately." Revoking a personal grant affects only that person.
Shell tools. A dedicated GitHub identity is also handed to the run's shell, where per-tool Ask first does not apply. This shell access also applies to the managed personal GitHub identity; it is not unique to a dedicated-agent grant. See GitHub.
Changing later
The identity is fixed for a connection once it exists. On resume or reconnect, Paperclip treats the stored identity as authoritative and will not accept a contradictory grant kind from the client — that guard exists so a reconnect cannot quietly replace the credential behind an organization grant.
To move to a different identity, create a second connection with the identity you want, move agent access across, then delete the old one. Reauthorize, revoke, or disconnect covers the deletion.