Every permission we ask for, and exactly why
Sarcio changes production, so it earns every permission it holds. This is the complete, honest list — what each integration requests, why the product needs it, what we deliberately leave on the table, and how every token and key is stored and revoked. Read it before you connect a thing.
Workspace connections, linked accounts and acting links
Sarcio keeps the identity it works as apart from the people who use it. A workspace connection does the work. A linked account only says who you are on a Git host or in Jira. An acting link, if your admins allow it, lets Sarcio do two named things as you. And the way you sign in to Sarcio grants none of them.
| At a glance | Workspace connection | Linked account | Acting link (opt-in) |
|---|---|---|---|
| What it is for | The identity Sarcio works as: clone the repo, push the fix branch, open the PR, post sarcio/approval, read CI, dispatch remote builds, and file and update Jira tickets. | Names you: @your-login on the fix PR and its sarcio/approval check, and an @mention in the Jira go-live comment. | Acts as you for two things only, on patches you approve with Also act as me ticked: approving the fix PR on the Git host, and posting the Jira go-live comment. |
| Who sets it up | Admins only, on the Integrations tab. QA members never see it, and API tokens cannot reach it. | Each member, admins and QA alike, for their own account only, on the Account tab. Admins can see who is linked on Members but cannot link anyone. | Each member, for their own link, on the Account tab, and only while an admin has turned on the Acting links policy on the Integrations tab. It is off by default. |
| Is a token stored? | Yes for a pasted token or an OAuth connection: envelope-encrypted and never shown again. The Sarcio GitHub App keeps no long-lived token; Sarcio mints a one-hour token when it needs one. | No. Sarcio reads your account id, handle and name once, then revokes or drops the token. | Yes: envelope-encrypted, refreshed when it lapses, and deleted when you stop acting, unlink, are removed, or an admin turns the policy off. |
| Does it count toward approval? | No. Approval happens only in Sarcio, by signed-in reviewers. | No. | No. The Git host approval it posts lands after Sarcio has decided, and the approval gate never reads it. |
| If it is missing or fails | The live patch keeps running. The fix PR fails and can be retried once an admin fixes the connection; ticketing is best-effort, so a missed ticket is simply missing. | You are named instead of @mentioned. | Sarcio carries on with the workspace connection. |
The vocabulary, and the badges you'll see
| Term | What it is | Badges | Who manages it |
|---|---|---|---|
Workspace connection | The identity Sarcio uses to do work: clone the repo, open the fix PR, post the sarcio/approval check, read CI, dispatch remote builds, and file Jira tickets. It belongs to the workspace, not to a person. | App Bot token Personal Owner unknown | Admins only, on the Integrations tab. QA members never see it. |
Linked account | A member's own GitHub, GitLab, Bitbucket or Jira account, linked so fix PRs and tickets can name or mention them. Identity only by default: no token is stored. If the workspace allows it, a member can let Sarcio act as them for two things only, approving the fix PR and posting the Jira go-live comment. It never opens PRs or files tickets, and never counts toward an approval. | Linked · identity only Acts as you | Each member, admins and QA alike, for their own account only, in Account → Linked accounts. Admins can see who is linked, and who lets Sarcio act as them, on the Members page. Acting needs the workspace policy an admin turns on. |
Sign-in method | How a member signs in to Sarcio: email and password, Google or GitHub. It never grants Sarcio access to code or tickets, even when it is the same provider as a workspace connection. | Sign-in only | Each member, for themselves. |
Bot token covers a bot account's token, a GitLab project or group access token, a Bitbucket repository, project or workspace access token, and an Atlassian service account. Personal is a person's OAuth grant or personal token: Sarcio's work then appears as that person and reaches everything they can, so the dashboard shows a warning. Owner unknown means Sarcio couldn't ask the provider who owns a pasted token. App is the Sarcio GitHub App, installed on the repositories an owner picks. Beyond the owner, Sarcio checks each token's scopes, role and expiry against your sites' repositories and Jira projects, shows anything missing as a warning, and reminds admins before a token expires.
Only admins add, replace or remove workspace connections, and API tokens can't reach them at all. Every member, admins and QA alike, links only their own accounts, and a linked account never becomes a workspace connection. Approval always happens in Sarcio, behind sign-in (and 2FA where enrolled); nothing on a Git host counts toward it.
Linked accounts
Any member can link their own GitHub, GitLab, Bitbucket or Jira account in the dashboard under Account → Linked accounts. Sarcio sends you through the provider's consent screen with the narrowest identity scope it offers (no scope on GitHub, read_user on GitLab, read:me on Atlassian), reads your account id, handle, name and avatar once, and then revokes the token (GitHub, GitLab) or drops it (Bitbucket and Atlassian offer no single-token revocation, so it lapses on its own within hours). No token is ever stored. Bitbucket is the exception on scope: its scopes are fixed on the OAuth client, and when a deployment links through the same client it uses for connecting repositories, the consent screen lists repository and pull request access even though Sarcio only reads your profile and discards the token straight away.
By default, linking uses the same OAuth app per provider as the workspace's Connect buttons, so if you already authorized that app, the provider may skip its consent screen and send you straight back.
A link only names you. When you approve a patch, the fix pull request and its sarcio/approval check say Approved in Sarcio by @your-login on the Git host you linked, and the Jira go-live comment mentions your Atlassian account. Commit trailers keep your name. A link can't open pull requests or file tickets, it acts as you only if you choose an acting link (below), and it never counts toward an approval. One provider account can be linked to only one member per workspace; admins can see who is linked on the Members page but can't link or unlink for you, and removing a member deletes their links. Linking and unlinking are recorded in the audit log.
Acting links (opt-in)
An admin can turn on Acting links on the Integrations tab. It is off by default. While it is on, any member can upgrade one of their own links so Sarcio acts as them for exactly two things, and only on patches they approve with Also act as me ticked: approving the fix pull request (a GitHub review, a GitLab merge request approval, or a Bitbucket approval) once it opens, and posting the Jira go-live comment. Nothing else: the workspace connection still opens the PR, posts sarcio/approval, and files and moves tickets.
The upgrade asks for the least each action needs. On GitHub the token comes from the Sarcio GitHub App, with no scopes and only on repositories the app is installed on; GitLab needs api (it has no narrower scope that can approve a merge request); Bitbucket uses Pull requests: Write; Jira asks for read:me write:jira-work offline_access. Sarcio keeps that token encrypted and refreshes it when it lapses. A Git host approval made this way never counts toward Sarcio's approvals, which stay the record. If the provider refuses, Sarcio carries on with the workspace connection.
Stopping is immediate. A member can stop acting at any time, which deletes the token; unlinking or being removed does too. Turning the workspace policy off deletes every stored acting token at once, so turning it back on restores none of them. Every use, success or failure, is in the audit log, and admins can see who has an acting link on the Members page.
What each one can do
| Action | Workspace connection | Linked account (identity) | Linked account (acts as you, opt-in) | Sign-in method |
|---|---|---|---|---|
| Clone the repo and push the fix branch | ||||
| Open the fix PR or MR | ||||
| Post sarcio/approval and read CI | ||||
| Dispatch remote builds | ||||
| File, comment on and transition Jira tickets | ||||
| Post the Jira go-live comment | otherwise, or if acting fails | as you, when you tick Also act as me | ||
| Name or mention you on PRs and tickets | ||||
| Request your review on the fix PR (coming later) | would target you | needed to target you | ||
| Submit a PR approval as you | when you tick Also act as me; never counts in Sarcio | |||
| Approve a live patch in Sarcio | plus 2FA where enrolled | |||
| Who manages it | Admins | You (admins can see who is linked) | You, if the workspace policy allows it | You |
Least privilege, by default
Every integration requests the smallest scope that does the job — and no more. Where a provider only offers a coarse scope, we say so and point you at the tighter alternative.
Revocable, encrypted, per-host
The Sarcio GitHub App keeps no long-lived token. A pasted bot token or an OAuth connection is envelope-encrypted at rest (AES-256-GCM), shown to nobody after you save it, and scoped per host. Remove it and it is deleted.
Your captured data stays put
Only the metadata you already see in the dashboard ever crosses into your Git host or tracker. Captured console, network, and screenshot payloads never cross into either.
Pick a surface to see the exact scopes
Sarcio asks for access in four independent places, each its own consent and its own credential. Nothing is bundled — connecting your repo tells us nothing about your identity provider, and signing in grants no access to your code.
None of this is gated behind a plan. Every connector — your Git host, your tracker, remote builds, and programmatic API tokens — and every patch kind is available on all tiers. Plans differ only by scale: the number of sites and seats, and the AI drafts and credits you get each month. What you can integrate never depends on what you pay.
How access is granted, and taken away
Every integration is config-gated: a provider only appears when this deployment has its OAuth app configured, so the surfaces you see are the surfaces that are live. OAuth consent always redirects back to Sarcio's own API origin, never to a third party.
Workspace connections are stored per host and per workspace, and only admins manage them, on the dashboard's Integrations tab. When an admin saves a token, Sarcio asks the provider who owns it (an identity-only call that needs no extra scope) and badges the connection Bot token, Personal or Owner unknown; a GitHub App installation is badged App. It also checks the token's scopes, role and expiry against your sites, shows gaps as warnings, offers Re-check, and emails admins 14 and 3 days before a token expires. Connecting a provider over OAuth clears any pasted token for that host, and vice-versa — the two never mix on one credential. A GitHub App installation sits alongside either, and Sarcio prefers it wherever it covers the repository. To revoke, remove the connection on the Integrations tab (which deletes the encrypted token) and revoke the token, or uninstall the app, at the provider to kill it at the source. Every add, remove and re-check lands in your append-only audit log.
Setting one of these up? The quick start covers the how; this section is the what and the why.
How your secrets are stored
Every token Sarcio keeps — OAuth access and refresh tokens, pasted access or API tokens, and the tokens behind members' acting links alike — is envelope-encrypted before it touches the database. Each secret is sealed under its own random 256-bit data key with AES-256-GCM, and that data key is itself wrapped under a master key that is kept outside the database. The database alone never yields a usable secret, and GCM's authentication tag means any tampered ciphertext fails closed rather than decrypting to garbage.
If a deployment has no master key configured, Sarcio refuses to store a Git host, ticketing or acting-link token rather than writing it in the clear — no key, no connection. And once a secret is saved it is never returned: the dashboard shows a connection's presence and metadata, never the token behind it. The same envelope also protects your workspace's signing private key and every user's TOTP secret.
This is all standard node:crypto — no bespoke cryptography — in one small, isolated module.
Every patch is signed before it ships
A patch is not trusted because it arrived from Sarcio — it is trusted because it verifies. Each workspace has its own signing key, and every patch is signed with it. The widget in the browser and the sidecar next to your app check that signature against your workspace's public key before applying anything. A patch that does not verify is rejected on the spot.
The private half is per-workspace and encrypted at rest; admins rotate it on demand, and rotation re-signs every live patch in the same request so nothing breaks.
Bring this to your security review.
Every scope on these pages is inspectable from a workspace of your own — and nothing engages until you connect it.
Create a workspace