Workcell uses a single-maintainer release process. The maintainer applies security fixes to main. The repository has no long-lived release branches. Only the latest release gets security fixes. Workcell does not backport fixes to old tags. The maintainer ships a fix in the next release. Install the latest verified release to get the fix.

Always verify a release before installation. scripts/install-release.sh verifies the signed checksum file and the asset digest. It fails closed before any bundle code starts. See docs/install-lifecycle.md.

Release tags and commits are GPG-signed by the maintainer. Confirm any key you import against this fingerprint before trusting a signature:

Omkhar Arasaratnam <omkhar@gmail.com>
ed25519  9055 4248 C4F7 CC08 6BB7  45D0 DA5A 8E9F 536C 42FD

When you obtain the installer from a checkout of a release tag (the verified install path in docs/getting-started.md), verify that tag's signature against this key before running any code from it:

# import the maintainer key (e.g. from a keyserver) and confirm the fingerprint above, then:
git tag -v vX.Y.Z

This authenticates the installer source; the release artifacts are independently verified with keyless cosign signatures (no long-lived signing key), documented in docs/provenance.md.

Do not disclose new sandbox escapes, credential leaks, signing bypasses, or boundary-preservation bugs in a public issue.

Use GitHub Private Vulnerability Reporting to open a security advisory for this repository. If that channel is unavailable, contact the repository owner privately through GitHub first.

We aim to acknowledge reports within 5 business days and to provide an initial assessment within 10 business days. Critical issues (sandbox escapes, secret exposure) will be prioritised. You will be credited in the advisory unless you request otherwise.

High-priority reports include:

• reads of host secrets outside the documented boundary
• writes outside the intended workspace without explicit breakglass
• unmanaged host socket or credential passthrough
• silent trust widening through repo content or workflow changes
• release signing, SBOM, or provenance regressions

The following are not in scope for this policy:

• social engineering attacks
• physical access attacks
• bugs in third-party providers (Codex, Claude, Gemini) that do not involve a Workcell boundary violation
• issues reproducible only in unsupported configurations (non-macOS host, breakglass mode used as intended)

The set of git-config keys that the in-container git wrapper and the in-container LD_PRELOAD exec guard refuse to honor (e.g. core.askpass, core.hookspath, credential.*.helper, includeif.*.path, pager.*) is the canonical control-plane denylist for git-mediated bypasses. The single source of truth is policy/git-config-blocklist.toml; scripts/verify-invariants.sh enforces parity between the TOML and the three enforcement points (scripts/workcell, runtime/container/bin/git, runtime/container/rust/src/lib.rs). Adding a key requires editing the TOML and updating each enforcer in the same PR.

If you are an operator responding to a suspected runtime boundary breach — an agent escaping the session, host credential exposure, or workspace tampering — follow the operator boundary-incident response runbook to contain, preserve evidence, collect a redacted support bundle, and escalate through the reporting channel above.

The CI/CD threat model covers the build and release pipeline: runner trust tiers, secrets handling and rotation, attestation verification assumptions, and the signing-compromise incident response runbook.

We follow a coordinated disclosure model. Please allow a reasonable fix window before public disclosure. We will notify you when a fix is ready and work with you on timing.

Closed-finding evidence and assurance artifacts from past reviews live under docs/security/:

• 2026-04-24 validation summary
• 2026-04-24 PoC matrix
• 2026-04-24 mutation results
• 2026-04-24 verification CSV