Machine access & the keys we mint
These are the credentials Sarcio issues, rather than the ones you grant it: the machine token your CI uses, the key your sidecar pulls with, and the cryptographic key that signs every patch. Each is default-deny, scoped to one job, and revocable the moment you need it gone.
Programmatic API tokens (pat_)
A pat_ token lets an integration or CI job call the API without a browser session. It carries only the scopes you grant, over a default-deny surface: any endpoint without an explicit rule refuses token auth entirely. Pick from these scopes when you mint one:
| Scope requested | What it grants, and why | Access |
|---|---|---|
reports:read | List and read bug reports. | Read |
patches:read | Read a patch, and list live and orphaned patches. | Read |
patches:write | Draft module patches, regenerate a draft, reject or retire patches, retry a fix pull request, and request module builds or dispatch remote builds — but never approve them. | Write |
sites:read | List and read sites. | Read |
sites:write | Create sites. | Write |
builds:write | Fetch a remote-build request, upload the built artifact, or report a build failure — the exact surface your CI step needs. | Write |
audit:read | Read and export the audit log. | Read |
What a token can never do
Approval is the human gate the whole model rests on, so it is session-only and refused to tokens twice over: absent from the scope map, and rejected by the service even if it were reached.
Keys & secrets Sarcio issues
Workspace signing key (Ed25519)
Every patch is delivered as a manifest signed with your workspace’s own Ed25519 key, so the widget, module runtime, and sidecar can verify it at the edge before applying anything.
Stored: Keys are per-workspace. The private key is envelope-encrypted at rest (AES-256-GCM, under a master key kept outside the database).
Revoked: Admins rotate on demand; rotation re-signs all live patches in the same request and clients pick up the new key on their next fetch. The public half is published at GET /api/sites/:key/signing-key for verifiers.
Sidecar key (sk_)
The secret your self-hosted sidecar uses to pull signed fixes from Sarcio over outbound HTTPS.
Stored: Shown once, when issued. Only a hash is stored; the plaintext lives only with your sidecar. Issue one before production: from then on every pull requires a valid key, even if all keys later expire or are revoked.
Revoked: Rotation issues a new key and expires the old one after a bounded overlap window (7 days by default), so replacing it never needs a lockstep redeploy. Revocation kills access immediately.
Site key (pk_)
The public key the widget uses, shipped in its script tag. With it, anyone can send that site a report or receive its live patches, but it grants no access to your workspace, code or data.
Stored: Public by design — not a secret.
Revoked: Safe to ship to browsers. Browser origins can be restricted per site as defence in depth.
App token (SARCIO_SHIM_TOKEN)
An optional value you choose, shared between your app and its local sidecar. Set it: with it, only processes that present it can talk to the sidecar over the local socket; without it, any local process can.
Stored: Chosen and held by you; never stored by Sarcio.
Revoked: Rotate it by changing the value in both places. It never leaves your infrastructure.
Programmatic API token (pat_)
A tenant-scoped bearer token for integrations and CI, carrying only the scopes you grant it over a default-deny surface.
Stored: Only a sha256 digest is stored; the plaintext is shown exactly once, at creation.
Revoked: Revocation takes effect immediately; an optional expiry refuses the token like a revocation once passed.
See it from the inside.
Spin up a workspace and every one of these connections is a click away — with the exact scopes shown before you approve them.
Create a workspace