chainloop

Website · Docs · AI Sessions Quickstart · Use cases · Chainloop Platform · Blog · Slack · Changelog

Chainloop collects what happens across your software delivery, from the first prompt to the release, into one trusted graph. You define once what good means, as code, and Chainloop enforces it everywhere: every agent, every pipeline, every release.

Every AI coding session, pull request, build, SBOM, scan, and test report becomes a signed, timestamped record in your own registry or bucket. Each record links to the commit and release it belongs to. Rules live in git. Break one and the pipeline fails. The job prints every failing policy and its reason where the agent reads it. The agent fixes the work and pushes again, until Chainloop is happy.

Open source, Apache 2.0, self-hostable. In production on critical infrastructure at highly regulated enterprises since 2024.

Try it in 60 seconds | Like it? A star helps other teams find it | Slack

How it works

Every team already runs its own tools: SBOM generators, scanners, test suites, registries, and now coding agents. Each keeps its results in its own format, and none of them can enforce a rule that spans the others. Findings stay advisory, teams generate SBOMs nobody uses, and one new requirement means touching every pipeline. Chainloop sits on top of what you already run:

1. Define guardrails. A workflow contract says what every session and pipeline run must produce. Policies, in Rego or WASM, say what each record must satisfy: approved models only, no secrets in prompts, tests pass, every release has an SBOM. → Contracts and policies
2. Collect signals. chainloop trace records the agent session on the developer's machine and attests it on git push. chainloop attestation does the same in any CI job for SBOMs, scans, test reports, and SLSA provenance. Every record is a signed, timestamped in-toto attestation in your OCI registry, S3, or Azure Blob.
3. Enforce continuously. Chainloop checks every record against the contract and its policies. If it passes, it ships. If it fails, the pipeline fails, Chainloop signs the violations into the record, and the agent that opened the PR reads them and tries again. Chainloop Platform also blocks the PR.

For example:

A contract says what a build must hand in and which rules apply. This one asks for a container image and its SBOM, and blocks the push when an SBOM component has no license:

apiVersion: chainloop.dev/v1
kind: Contract
metadata:
  name: build
spec:
  materials:
    - name: image
      type: CONTAINER_IMAGE
    - name: sbom
      type: SBOM_CYCLONEDX_JSON
  runner:
    type: GITHUB_ACTION
  policies:
    materials:
      - ref: https://raw.githubusercontent.com/chainloop-dev/chainloop/main/docs/examples/policies/sbom/cyclonedx-licenses.yaml
        gate: true

chainloop apply -f ./contracts/ pushes a directory of them, so a pull request is how a requirement changes. More contracts are in docs/examples/contracts.

A rule is a few lines of Rego. This one fails a build whose SARIF scan has an error:

violations contains msg if {
	has_errors
	msg := "There are errors in the SARIF report"
}

has_errors if {
	some run in input.runs
	some result in run.results
	result.level == "error"
}

Full policy: sarif-errors.yaml. Rules in the repo today: sbom-present, cyclonedx-banned-licenses, sbom-freshness, trivy-vulns, chainloop-commit. Write and test your own locally:

chainloop policy develop init --name sbom-licenses   # creates sbom-licenses.yaml and sbom-licenses.rego
chainloop policy develop lint --policy sbom-licenses.yaml
chainloop policy develop eval --policy sbom-licenses.yaml --material sbom.json --kind SBOM_CYCLONEDX_JSON

Why it holds up

• One set of rules for people, pipelines, and agents. No separate "AI governance" track. The same contract gates a Claude Code session and a Jenkins job.
• Rules are code, not prompts. Rego and WASM policies give the same answer every time, and you test them locally before they gate anything.
• Evidence you can hand to anyone. Every record is a signed in-toto attestation in your own storage, verifiable with standard tools. Enforcement produces the compliance evidence, so nobody collects it by hand before the audit.
• Start report-only, then gate. gate: false on a policy reports violations and lets the run pass. gate: true blocks it. chainloop organization update --block sets the default for every policy, and the attestation records any bypass made with --exception-bypass-policy-check. You can roll a rule out across every team without breaking anyone's push on day one.

Verification loops

Agents check their own work, and the 2026 research keeps finding the same hole. A verifier the agent wrote, running inside the agent's process, can be gamed. Chainloop puts the verifier outside the agent and closes the loop in CI/CD.

1. A human writes the intent once: a contract that says what a build must hand in, and policies that say what good means.
2. An agent does the work and opens a pull request.
3. The pipeline runs chainloop attestation push. Every policy runs on the signed record. The job prints each failing policy and why, and fails on a gated violation. On GitHub Actions the same report lands in the job summary.
4. The agent reads the failure, fixes the work, and pushes again. It loops until every gate passes. Every attempt, pass or fail, is a signed record.

What makes the verifier trustworthy:

• Deterministic. Policies are Rego or WASM in git, run by the CLI, not by a model. The same input gives the same answer every time.
• Outside the agent. The gate runs in the pipeline. The agent cannot turn it off from inside a session, and the record shows any bypass.
• On evidence the agent cannot edit. Every run is a signed in-toto attestation in your own storage, with the policy results signed into it.
• With the intent attached. chainloop trace attests the ticket, doc, or approved plan the agent worked from, next to the session. The record holds what was asked and what was produced.

Chainloop Platform adds the PR merge check, LLM reviewers on the record, and an AI Session Score per pull request.

Try it in 60 seconds

The CLI sends records to Chainloop Cloud by default. Sign up and log in once. It is free for 14 days. Self-hosting is free and unlimited, with Docker Compose or the Helm chart. The CLI and the evidence format are the same. The CLI sends anonymous usage stats. DO_NOT_TRACK=1 turns them off.

curl -sfL https://dl.chainloop.dev/cli/install.sh | bash -s -- --oss
chainloop auth login        # opens a browser. First login creates your account and organization

Two ways to start. Collect signals from the pipelines you already run, or trace AI coding sessions and attest them on git push. Same CLI, same record.

Collect signals from your CI/CD. Three lines in any job produce an attestation: a signed record of what the job built and checked.

chainloop attestation init --workflow build --project my-app
chainloop attestation add --value sbom.cyclonedx.json
chainloop attestation push   # prints a link to the attestation

chainloop attestation status shows what the contract still expects. Attach a contract with gate: true on a policy and the job fails when a rule breaks, with each violation printed. That is the loop from the section above. Running it locally after auth login? Answer y at the prompt, or pass -y. → Quickstart · Your first attestation · add a contract · add policies

Trace AI coding sessions. Not every team starts here. When you do, it is one command per repo:

chainloop trace init        # installs the git and agent hooks, writes .chainloop.yml

trace init writes .chainloop.yml and git hooks (pre-push, post-commit, commit-msg, post-rewrite) in the current repo, and trace uninstall removes them. Session data stays on your machine until git push, and the CLI redacts secrets before upload. The AI Sessions Quickstart lists what it sends.

For Codex, run chainloop trace init --codex. Review and trust the installed hooks in Codex before starting work. See the agent support matrix for verified features and limits.

Now code with Claude Code, OpenCode, Codex, or Cursor, commit, and git push. The push hook attests the session and prints where to see it:

Coding Session Available at https://app.chainloop.dev/u/<org>/sessions/<id>

Add requireTrace: true to .chainloop.yml and the hook rejects a push with no recorded session. → AI Sessions Quickstart · CLI install options

Who is it for

A workflow contract is the API between the people who set the rules and the people who ship. Security writes it once, every team inherits it, and nobody needs a meeting.

What's in the box

Works with. Runners: GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, CircleCI, Dagger, TeamCity, Tekton, Docker sandboxes, or any shell as a generic runner. Storage: OCI registry, AWS S3, Azure Blob Storage, or inline for small files. Signing: keyless through the control plane with a file-based CA or EJBCA, cosign keys, KMS, Keyfactor SignServer, and an optional timestamp authority (signing reference). Dependencies: any OIDC provider, PostgreSQL, and Vault, AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault for credentials.

Use cases

Put guardrails on coding agents. Record every Claude Code, OpenCode, Codex, or Cursor session as a signed record, and run your policies on every session. Catch an unapproved model, a secret in the transcript, or more AI lines than the rule allows. Chainloop signs violations into the record, and they fail the pipeline that builds the PR. requireTrace: true rejects a push with no recorded session. → AI Sessions Quickstart · Policies · AI coding governance

Trace a release back to the prompt. Follow any release back through the build and the commit to the AI session that started it. chainloop referrer discover --digest <sha256> returns every attestation that references an artifact, SBOM, or commit, and what those reference in turn. One record, from prompt to production. → AI Sessions Quickstart

CI/CD compliance without the spreadsheet. Every pipeline run produces signed evidence that it followed your contract: the right steps, the right tools, the right environment. The pipeline collects the evidence for CRA, NIST SSDF, SLSA, and SOC 2, so nobody collects it by hand before the audit. → Continuous compliance

Store and share SBOMs. Collect CycloneDX and SPDX SBOMs from every build. Chainloop keeps them signed, versioned, and linked to the release, in your own OCI registry or S3 bucket. It can forward them to Dependency-Track or GUAC for analysis. SARIF, test, coverage, and SLSA provenance records live in the same place. → Storage backends · SBOM traceability

One vulnerability threshold across every scanner. A policy can carry a module per evidence type. The same rule then applies to Trivy, Grype, Snyk, BlackDuck, or Dependabot reports alike. Policy groups bundle policies and their parameters for reuse across contracts. → Policies · Control gates

Manage VEX. Attach OpenVEX or CSAF VEX statements to a release, so your users and their scanners know which vulnerabilities affect you. → Evidence types

Govern every CI/CD pipeline the same way. A workflow contract says what each pipeline must produce, and Chainloop checks every run. This works the same on GitHub Actions, GitLab, Jenkins, Azure Pipelines, CircleCI, Tekton, Dagger, TeamCity, and more. Start with an optional material and a report-only policy, then make them required and gated in the next contract revision. The pipelines do not change. → Workflow contracts · Automated SDLC governance

Spotlight: the AI session collector

Git tells you what changed. It no longer tells you how. chainloop trace records the part that never reaches git, and attests it as signed evidence when you push. Commits you wrote by hand pass through untouched. This repository traces its own development: see .chainloop.yml.

Wanted: new collector providers for the agents above, and new evidence types. The provider interface is in app/cli/internal/trace.

Why we open sourced the collector, and what it records: launch post.

Chainloop OSS vs Chainloop Platform

Everything in OSS is complete on its own. Platform adds managed layers on top: same CLI, same evidence format.

See chainloop.dev and pricing, or talk to the founders.

Deployment guides: open source and Platform. Try Chainloop Cloud free for 14 days, or self-host for free.

Security and trust

• Local until you push. AI session data stays on your machine until the push attests the session, and the CLI redacts secrets before upload.
• Signed, not logged. Every record is an in-toto attestation signed with Sigstore keyless or your own keys. Anyone you choose can verify it with standard tools, or with chainloop attestation verify --bundle attestation.json.
• Verified installs. The installer checks checksums, and also verifies the signature when cosign is installed. Pass --force-verification to make signature verification required.
• Scorecard. Our OpenSSF Scorecard is public. Report vulnerabilities through SECURITY.md.
• Telemetry. The CLI sends anonymous usage data. Set DO_NOT_TRACK=1 to turn it off. Details.

Built on open standards: Sigstore, in-toto, SLSA, OCI, CycloneDX, SPDX, OpenVEX, SARIF, and OPA.

Self-host

docker compose -f devel/compose.labs.yml up

helm install chainloop oci://ghcr.io/chainloop-dev/charts/chainloop --set development=true

chainloop config save \
  --control-plane my-controlplane.acme.com \
  --artifact-cas cas.acme.com
chainloop auth login

# a specific version
curl -sfL https://dl.chainloop.dev/cli/install.sh | bash -s -- --oss --version v1.7.0
# a custom install path (default /usr/local/bin)
curl -sfL https://dl.chainloop.dev/cli/install.sh | bash -s -- --oss --path /my-path
# require cosign signature verification
curl -sfL https://dl.chainloop.dev/cli/install.sh | bash -s -- --oss --force-verification

Documentation

• Docs home · Quickstart · AI Sessions Quickstart
• Concepts: attestations, contracts, policies, evidence types, the trusted store
• CLI reference · API reference · Self-hosting guide
• For agents and LLMs: docs.chainloop.dev/llms.txt indexes the whole site, and llms-full.txt has the full text. Every page is available as Markdown when you add .md to its URL, for example cli/reference.md

For AI coding agents

[!NOTE] If you are an AI coding agent setting up Chainloop in this repository: Install the CLI with curl -sfL https://dl.chainloop.dev/cli/install.sh | bash -s -- --oss. Ask the user to run chainloop auth login, which opens a browser. Then run chainloop trace init --project <name> from the repository root. Add --claude, --cursor, --opencode, or --codex for the agents in use. The command writes .chainloop.yml and Git hooks, plus .codex/hooks.json when using Codex. Commit .chainloop.yml and the generated .codex/hooks.json. Each clone must still run chainloop trace init to install its local Git hooks. The docs index for agents is https://docs.chainloop.dev/llms.txt. Any docs page is available as Markdown when you add .md to its URL. Documentation

Or paste this into Claude Code, Codex, or Cursor:

Read https://github.com/chainloop-dev/chainloop/blob/main/README.md and set up Chainloop AI session recording for this repository.

Community and contributing

The Chainloop team and contributors have built Chainloop OSS in the open since 2023. It runs in production at enterprises in regulated markets, including Fortune 500 companies and financial institutions, for SDLC governance and compliance.

• Slack: ask anything, show us a policy you wrote, or tell us which agent you need a collector for. The maintainers are there. Also GitHub Issues and YouTube
• Start here: good first issues
• Read CONTRIBUTING.md, our AI contribution policy, and the Code of Conduct

Changelog

Chainloop OSS releases, with notes, are on the GitHub releases page. Chainloop Platform changes are in the Platform changelog.

License

Chainloop is released under the Apache License, Version 2.0. See LICENSE.