Built to survive your security review

A tool that changes production has to answer harder questions than one that watches it. This page is the answers — what has to be true before a single byte changes on your site, and what limits the blast radius when something goes wrong anywhere in the chain.

Nothing applies unsigned

Every patch — DOM, server, or module — is delivered as a manifest signed with your workspace's own Ed25519 key. Verification happens at the edge, in the verifier you run: the widget in your users' browsers, the module runtime, and the Go sidecar behind your backend each check the signature against your workspace's published public key before applying anything. Module payloads additionally carry per-module sha256 checksums, and every patch has a hard TTL with client-side expiry rollback.

This is the answer to the post-polyfill.io question every reviewer now asks about third-party scripts: a compromise of the delivery channel is not a compromise of your site, because an unsigned or tampered payload simply never applies.

Keys are per-workspace, and rotation is routine

Each workspace mints its own signing keypair, so a leaked key forges patches for one workspace — never the platform. Admins rotate keys on demand; rotation re-signs all live patches in the same request, so nothing breaks and clients pick up the new key on their next fetch. Private keys, like users' TOTP secrets and forge tokens, are envelope-encrypted at rest (AES-256-GCM with a KMS-backed master key in production).

Patches are constrained data, not code

DOM and server patches are drawn from a fixed vocabulary of operations and validated server-side against hard deny-rules — the client is never the enforcement line, and there is no "run this JavaScript" operation to abuse. Risk tiers are computed from what the patch does, never asserted by the AI that drafted it. Module patches are real code by nature — which is why they are always elevated-risk, always behind two distinct approvers, always signed, and always checksummed.

Approval is a control, not a formality

Preview-before-live — approvers see the exact patch applied in isolation before anyone else does.
Two-approver escalation — elevated-risk patches require two distinct approvers; identity games like case-variant names are normalized away.
RBAC — reviewers approve patches; only admins touch keys, sites, members, and credentials. Enforcement is server-side.
Mandatory 2FA — every self-serve account enrolls TOTP two-factor at sign-up, with one-time recovery codes. OAuth sign-ins clear the same 2FA gate.
Session lifecycle — sign-out-everywhere revocation, email-change re-verification, password policy with rotation, account lockout, and per-IP rate limiting on every open endpoint.

The server tier stays inside your walls

Server patches are enforced by a sidecar you host — a single static Go binary. It connects outbound only to pull signed patches; nothing connects into your network, and no credentials sit on the local socket between your app and the sidecar. If the sidecar is unreachable, the shims fail closed: your app behaves exactly as if Sarcio weren't installed. The Java shim uses no agents or bytecode manipulation; the PHP shim is built for FPM's process model.

Your source code stays yours

Repository access uses your workspace's own forge credential, stored envelope-encrypted, write-only once saved, and checked by API preflight before any clone — a repo the token can't see is refused outright. For stricter postures, opt a site into remote builds: module patches build inside your own CI/CD, and only the validated artifact — schema-checked, size-capped, checksum-verified server-side, single-acceptance, and audited — returns to Sarcio. AI-drafted edits are themselves treated as hostile input, with path traversal and repository escape refused by the build pipeline.

Everything leaves a trail

A per-workspace, append-only audit log records sign-ins, patch approvals/rejections/retirements, key rotations, site creation, credential changes, and member administration — each with actor, source IP, and timestamp. It exposes no update or delete, and admins export it as CSV or JSON for evidence requests. With Jira connected, every patch also exists as a ticket in your tracker, giving change management a paper trail in the system it already watches. The two-approver gate plus the audit trail map cleanly onto SOC 2-style change-management expectations — including the emergency-change path, which is exactly what Sarcio governs.

Tenant isolation and machine access

Workspace isolation — every read and mutation is scoped to the signed-in workspace; cross-tenant IDs resolve to 404, so identifiers can't be probed across the boundary.
Scoped API tokens — machine tokens carry explicit scopes over a default-deny surface: endpoints outside the scope map (user administration, key rotation, token management itself) refuse token auth entirely. Plaintext is shown once; only a digest is stored; revocation is immediate.
Zero-downtime credential rotation — sidecar keys rotate with a bounded overlap window, and revocation kills access immediately.
Data lifecycle — full workspace data export (secrets withheld), configurable report retention that scrubs captured payloads, and slug-confirmed workspace deletion.

What we don't claim

Honesty is part of the security model. Sarcio is a governed emergency path, not a replacement for your SDLC — the permanent fix still goes through your review and your pipeline, and the system is built to push you there: expiry reminders, orphan flagging, and auto-retire on merge exist precisely so the temporary path never becomes the permanent one.

Put it in front of your security team.

The fastest way to evaluate Sarcio is a workspace of your own — every control on this page is inspectable from the dashboard.

Create a workspace