Verify it offline in under a second. CI/lock records and signs the work your agents already perform, bound to the exact commit. Checking that record needs the policy and the evidence, not a service call.
$ cilock run --step unit-tests -- go test ./...
✓ command-run exit_code=0
✓ git commit=7b3c9e1…
✓ evidence signed + timestamped
Get CI/lock
Install the current release.
The installer resolves a release from the published manifest, and direct links appear here only when that manifest is available.
curl -fsSL https://cilock.dev/install.sh | sh
The installer detects your OS and architecture, resolves the latest version from the manifest, and checks the archive's SHA-256 against the manifest before it installs anything. Set CILOCK_VERSION to pin a specific release.
Each release ships build and source provenance attestations, and the release pipeline publishes an artifact only after cilock verify passes it against the signed release policy.
What it does
From a real command to a policy-checkable record.
CI/lock signs Git objects, records command evidence, and verifies artifacts while keeping workload and human roles separate.
01 · GIT
Sign Git objects.
cilock git configure sets Git's X.509 signing protocol and names CI/lock as gpg.x509.program. Commits and annotated tags then sign through CI/lock with a short-lived Fulcio certificate and a mandatory RFC 3161 timestamp.
Git reuses the same program for a push certificate when you run git push --signed, and Pushgate parses and verifies that certificate at the gate. The configure command does not turn push signing on. Use --global to cover every repository.
cilock run --step <name> -- <command> wraps a real command and records signed in-toto evidence about the execution. It is keyless by default against the hosted TestifySec platform: Fulcio signing, RFC 3161 timestamps, and Archivista storage all derive from --platform-url.
Set --platform-url "" to run fully offline with no platform and no TSA.
cilock run --step tests -- go test ./...
DSSE + in-toto + RFC 3161
03 · VERIFY
Verify against policy.
cilock verify ./artifact computes the artifact's SHA-256 subject. With a platform session, trust and the product's bound policy resolve automatically. Verification rechecks cryptography, subjects, policy, and evidence—not a status string.
Gate on the exit code, never grepped output. Piping to grep replaces CI/lock's exit code with the pipe's and can mask a failure.
Measured, offline. A passing cilock verify --offline of a two-step policy with a rego rule, over 17 KB of signed evidence, ran at a 0.21 s median wall time across 25 runs on an Apple M4 Max on 2026-09-22; about 30 ms of that was CPU. Tripling the evidence did not move the median, because the wall time is process start rather than the checking. Resolving trust from a platform session instead adds a trust-root lookup and an evidence query, and that network time dominates the total.
cilock verify ./artifact04 · IDENTITY
Keep humans in the loop.
cilock login resolves identity in order: an explicit token, ambient CI OIDC, then an interactive browser login. GitHub Actions is auto-detected, with no browser and no stored secret.
cilock trust github <owner>/<repo> registers a federated OIDC identity for upload. It creates an OIDC credential only; cilock never mints a long-lived API-token secret. The workload that signs, the human who activates a policy, and the human who signs a commit stay distinct.
Replaces / works with
Fewer signing tools. More evidence from the tools already in use.
CI/lock consolidates the signing path while preserving compatibility and stating the difference between direct attestors and recognized tools.
Takes the place of
A separate Git-signing helper
CI/lock occupies Git's standard gpg.x509.program slot (cilock git configure), so commits, annotated tags, and push certificates sign through it — no second signing program.
A separate cosign / Sigstore CLI setup
For these flows, keyless signing, the timestamp, and attestation storage come from one --platform-url. They use the platform's Fulcio and TSA, not public Sigstore.
A long-lived CI API token
cilock trust registers federated OIDC instead.
A second witness install
Rookery continues the in-tree work of in-toto/witness. It is witness-compatible: a chain produced by witness verifies under CI/lock, and a CI/lock chain verifies the other way.
An attestor-backed entry has a first-party attestor that produces signed evidence. A catalog-only entry is a tool CI/lock recognizes and can wrap, with its output captured as evidence.
31 further entries match none of these four groups, including core attestors like command-run and environment.
Use it where work runs
One evidence model, from the agent loop to governed CI.
Start locally, carry the same signed evidence shape into GitHub workflows, and connect it to organization-wide policy, compliance, and governance when the team is ready.
01 · AGENT
Run beside the code
Let an agent inspect the catalog, select the real tests and scanners, and run them through CI/lock. CI/lock defaults to the TestifySec platform; registered workload OIDC keeps reusable credentials out of the workspace.
Use the open-source action in GitHub workflows to capture runner and workflow context, sign keylessly with workload OIDC, and emit the same policy-checkable evidence model.
Use the TestifySec platform to retain and verify signed attestations, connect them to policy, and make the resulting evidence available to compliance and governance workflows.
Cryptographic evidence is valuable when every layer states its boundary precisely.
Verified: envelope, credential, timestamp, and bound subject
A verifier can reject changed bytes, an untrusted signer, a bad timestamp, or evidence for another commit.
Observed: the command and process result CI/lock captured
For the basic command policy, “passed” means a commit-bound command exited zero. It does not invent richer test semantics.
Not implied: that the test suite was sufficient
A policy must name the evidence and trust it requires. Independent CI spot checks remain useful where the agent environment is not enough.
Identity is bound to the credential path
Evidence authenticates the subject in the signing credential. Observed agent metadata is useful context, but it is not an authenticated principal. Workload signing, artifact signing, and the human who activates a repository policy remain distinct roles.
Agent signing boundary
Let agents invoke CI/lock. Verify the boundary.
The agent keeps its normal workflow and calls CI/lock directly. The ALPS 0.1 profile defines levels that progress from repository guidance to keyless identity, enforced tool isolation, and isolated signing; verifiers derive the supported level from signed observations.
01 · CONTAIN
Start with a clean sandbox
Launch with a clean environment, a workspace-only filesystem view, and an explicit network allowlist. Deny home directories, SSH files, keychains, browser launch, Apple Events, Docker or service sockets, and every human agent socket.
no key file · no SSH_AUTH_SOCK · no session token02 · WITNESS
Pin the CI/lock tool
Install a signed, version-pinned CI/lock release outside the workspace. At the constrained level, the agent invokes that exact non-writable binary through a command policy that records the applied boundary.
coding agent → tool policy → CI/lock03 · SEPARATE
Keep human acts human
A registered workload signs under its own identity. The agent can prepare a policy artifact and direct a signed-in human to review and activate it. Human Git attribution and policy activation stay outside the agent process.
artifact signer ≠ activation actor ≠ human commit signer
Do not confuse inheritance with isolation. A sandbox cannot protect a secret that the launcher places in its environment, mounts into its filesystem, or forwards through an open agent socket. Start clean, add only the minimum capabilities, and test both denial paths and an allowed non-human signing path.
Use the deployment guide for copy-paste native macOS and Linux configurations, launch commands, and boundary checks.
Pushgate verifies the evidence contract—DSSE-signed in-toto predicates, exact commit subjects, signer trust, and timestamps—not a product label. New predicate types remain explicit so policy authors and verifiers agree on the claim schema before activation.