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:

Good: it ships	Bad: it is blocked, and the findings go back
An approved agent and model wrote the change	An unapproved model, or an agent nobody allowed
Tests pass and coverage holds	A secret in a prompt, a transcript, or a commit
Every release has an SBOM and a clean scan	A critical CVE, or a release with no SBOM
The pipeline ran every step the contract asks for	A skipped step, a force push, or a dangerous command

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.

Now code with Claude Code, OpenCode, 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

Team	What they use Chainloop for
Platform engineering	One place for the evidence from the tools every team already runs, on top of the existing CI/CD. New requirements go in progressively, from report-only to gated, without touching pipelines.
Security	One vulnerability threshold across every scanner, required secret scans, signed attestations and SLSA provenance, and control gates in CI/CD.
Compliance and risk	Evidence collected as a side effect of building. Policy results kept as signed records. SBOMs centralized and used. The lineage of a release from one digest at audit time. Fits regulated industries under the CRA, DORA, or FedRAMP.
Engineering leaders	Visibility and control over AI agents: which models write code in which repositories, what it costs, and policies on the sessions themselves.
Developers	One CLI step that says what the contract still expects, and AI coding sessions attested on git push. No in-toto, Sigstore, or SLSA to learn.

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

Component	What it does
AI session collector (chainloop trace)	Records Claude Code, OpenCode, and Cursor sessions, redacts secrets, attributes AI and human lines, and attests the session on git push. requireTrace in .chainloop.yml blocks a push that has no record.
CLI (chainloop)	One integration point for every major CI runner and 45 evidence types. It crafts, signs, and pushes attestations, and runs policies.
Trusted store	Content-addressable storage for evidence, backed by an OCI registry, S3, Azure Blob Storage, or inline. Your storage, your keys. Called the Artifact CAS in the code.
Signing	in-toto attestations, keyless by default, or your own cosign / KMS keys, or SignServer. Timestamped.
Provenance graph	The trusted graph from the intro. The control plane links sessions, commits, builds, and releases into one lineage, with organizations, projects, and workflows.
Governance as code	Workflow contracts declare what each job must produce. Rego and WASM policies run on every record. Write and test them locally with chainloop policy develop.
Integrations	Dependency-Track, GUAC, Slack, Discord, webhooks, SMTP, and a plugin SDK for your own.

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.

Repository layout

Path	What it is
app/controlplane	Control plane: API, contracts, policy evaluation, run index, integrations
app/artifact-cas	Content-addressable storage proxy for OCI, S3, and Azure Blob
app/cli	The chainloop CLI, including chainloop trace
pkg	Shared libraries: attestation crafter, evidence types, runners, signers, policy engine
deployment/chainloop	Helm chart
docs/examples	Example contracts, policies, and CI workflows
extras/dagger	Chainloop module for Dagger pipelines

Supported evidence (45 types)

During an attestation you can attach these evidence types. The CLI uploads files to the trusted store and references them in a signed in-toto attestation. Full reference: evidence types.

• AI: Chainloop AI Coding Session, Chainloop AI Agent Config
• SBOM: CycloneDX, SPDX
• VEX and advisories: OpenVEX, CSAF VEX, CSAF Informational Advisory, CSAF Security Advisory, CSAF Security Incident Report
• Scans: SARIF, GitLab Security report, ZAP DAST, BlackDuck SCA, Prisma Cloud Twistcli, Checkmarx One, Oversecured, OpenSSF Scorecard, CERT/CC dranzer, Sysinternals Sigcheck, Sysinternals AccessChk, radamsa metadata log and crashing inputs
• GitHub Advanced Security: code scanning, secret scanning, dependency scanning
• Secrets: Gitleaks, TruffleHog, detect-secrets
• Tests and coverage: JUnit, JaCoCo, Cobertura, PIT mutation testing
• Provenance and artifacts: SLSA provenance, container image, Helm chart, artifact, existing Chainloop attestations
• API specs: OpenAPI, AsyncAPI, GraphQL SDL
• Collected automatically: runner context, pull request info
• Generic: key-value metadata, custom evidence (any file, for example an approval report in JSON)

Use cases

Put guardrails on coding agents. Record every Claude Code, OpenCode, 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.

Agent	Status
Claude Code	Supported, with token usage and cost
OpenCode	Supported, with token usage and cost
Cursor	Experimental, no token usage or cost yet
Codex, GitHub Copilot, Gemini, Windsurf, Amp	Coming. Contributions welcome

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.

	Chainloop OSS	Chainloop Platform
What	Everything in What's in the box	Everything in OSS, plus the layers below
Define	Workflow contracts, your own Rego / WASM policies	Curated policy catalog, agentic (AI reviewer) policies
Collect	AI session collector on developer machines, CLI in any CI, every evidence type, trusted store in your bucket	Same collector and CLI, no fork, plus managed storage
Enforce	Report-only or gated on every record, the job fails on a gated violation, push gate (requireTrace)	PR merge check, AI Session Score, LLM-driven policies
Act	Integrations and webhooks	Managed agents (analysis, remediation, Ask AI), managed tools (scanners, MCP), bring your own agents and tools
See	CLI and API	Session replay, org-wide dashboards, risk scoring
Run	Self-hosted, Apache 2.0, complete on its own	SaaS or on-prem Enterprise, SSO

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

Run Chainloop on your own infrastructure

Kubernetes. Deploy the control plane and the trusted store with the Helm chart. The self-hosting guide walks through it step by step.

Local stack. Start the full stack (control plane, store, Postgres, Vault, Dex) with Docker Compose. The steps, including how to get the development token, are in devel/README.md.

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

Quick evaluation. Development mode bundles Vault and Dex, so you need nothing else:

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

Point the CLI at your instance:

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

Install options:

# 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

You can also download the CLI from the releases page or build it from source. To install the Chainloop Platform CLI instead, omit --oss.

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, or --opencode for the agents in use. The command writes .chainloop.yml and git hooks. Commit .chainloop.yml. 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.