Chainloop Trace: From Prompt to Production

This is part 1 of a deep-dive series on AI governance and Chainloop Trace. Today, most teams either keep no record of an AI coding session and the specs the agent worked from, or they keep one that is disconnected from everything that happens to the code afterwards. At Chainloop we set out to connect that record to the rest of the SDLC, end to end. This post follows one AI coding session from the prompt to production and shows how the Chainloop features connect along the way.

TL;DR: When an AI agent writes code, most teams can’t answer a simple question: what happened to that code afterwards? Chainloop now answers it. The new session lineage view takes you from the AI coding session to its pull requests, the release, what runs in production and the vulnerabilities found in it, with signed evidence at every step. You no longer have to chase people and tools to rebuild the story.

Coding session SDLC lineage

A coding agent spends forty minutes on a feature, a developer pushes the result, and two days later the code runs in production. Somewhere between those two points the change went through a pull request, a set of checks, a merge, a few scans, a build and a deployment. Each of those steps left a record in a different tool. In most companies, answering “what did that session lead to?” means asking different people and systems, then correlating their answers by hand to rebuild the lifecycle.

We built the session lineage view to answer questions like these:

• Which agent, model and spec produced this change, and which lines did the agent write?
• Did the session follow our policies, and how well does the result match its spec?
• Which pull requests did the session feed, and what did reviewers and scanners see on them?
• Which merge commits and artifacts came out of it, and where do those artifacts run today?
• Which findings affect those artifacts, and how did this session contribute to them?

Recording AI coding sessions

Everything starts with chainloop trace, which installs hooks into Claude Code, Codex, Cursor or opencode, with Pi support coming soon, and records the session while the developer works: models, tokens, cost, tool calls, the transcript and the exact lines the agent wrote. It can also record the spec the agent worked from, such as a ticket or a design doc.

On git push, the pre-push hook redacts secrets, signs the session and sends it to Chainloop as a CHAINLOOP_AI_CODING_SESSION attestation tied to the pushed commits.

This step gives you a signed answer to “what did the agent do, with which model, and which lines are AI-written”. The collector is open source under Apache 2.0, and we covered why in Open Sourcing the AI Session Collector. The evidence types themselves were introduced in Agentic Coding Support.

From session to pull request

Chainloop is notified of every pull request on a linked repository, and it can run automated scans on the code without any change to your CI.

A session knows its commits, and GitHub knows which commits belong to which PR, so Chainloop correlates sessions and PRs as soon as a PR opens or gets new commits. GitLab merge requests work the same way.

In the lineage, this is the first link to the right of the session. One session can feed several PRs, and each PR shows up with its state and its commits.

Reviewers see the session on the PR, where Chainloop posts one comment and publishes two checks, Chainloop AI Policies for the session policies and Chainloop PR Validation for the code scans that run on PRs.

The session summary in that comment shows attribution, files, lines and duration. The built-in policies check for approved agents, allowed MCP servers, dangerous commands and leaked secrets, and each one can be advisory or block the merge. The AI Session Score grades how the session implemented the feature. It matches the diff and the session transcript against the plan, which is made of the specs and inputs given to the agent, and it reads the rest of the session context too, including the skills the agent used. The result is a 0 to 100 score with findings and recommendations. The PR scans run SAST, secret, vulnerability, IaC and GitHub Actions checks on the changed files only.

The same comment carries the security context, which Chainloop builds from the repository’s history of security fixes. When a PR touches a file with that history, the comment lists the past fixes and the invariant each one established. A collapsed prompt below it lets you hand the same context to a coding agent for review. That note is advisory and never blocks a merge.

The score and the PR-level controls are the subject of AI Coding Governance: Same Thesis, Bigger Surface. The security context comes from the research in Predicting the next vulnerability from a codebase’s own fix history.

To set this up, you connect GitHub or GitLab once for your organization and link each repository to a Chainloop project. We introduced that onboarding in Changelog: Connect Your Repo, Secure on Day One.

After the merge: your CI/CD process

The PR merges, and Chainloop records the merge and attaches the sessions to the merge commit. Every other GitHub workflow run on that commit then has a path back to the session through the Chainloop trust graph.

From there, the managed scans run on the linked repository. Chainloop clones the repository into a sandbox and runs the built-in scanners at least once every 24 hours, with no CI changes. That covers opengrep for SAST, betterleaks for secrets, syft and grype for vulnerabilities and the SBOM, checkov for IaC, zizmor for GitHub Actions, and a check of the repository settings. Each run produces a signed attestation, and the same policies that check every other attestation evaluate it.

In the lineage, those scans attach to the merge commit, so you can see what the code looked like to the scanners once it reached main. GitLab gets the same scans, as covered in Changelog: Now on GitLab.

Artifacts and deployments

When you use Chainloop across the whole SDLC, your CI builds from main and attests the result with the Chainloop CLI, including the container image, the SBOM and any binaries. If you have not done that yet, Your First Attestation shows how to add those pieces of evidence to an attestation. Chainloop references every material by its SHA256 digest, and that digest links the rest of the chain. A build that produces an image and a scan of that same image point at the same digest, without either one knowing about the other.

Because the build attestation records the commit it built, the lineage can attach the artifacts to the merge commit. Container images and attested binaries both show as linked artifacts in the session’s path to production.

The last step is deployment tracking, where chainloop deployment record registers that an image digest runs in an environment such as production on a given cluster. Records are immutable. A new version marks the previous one as superseded, so you keep the full history of what ran where.

Security findings

The scanner reports attached to those artifacts and their SBOMs become findings. The vulnerabilities policy evaluates each report and deduplicates on CVE and package PURL, so the same CVE reported by two scanners across many builds is one finding. In the example from our docs, a report with 480 entries becomes 77 findings.

Each finding keeps a link to the signed scan attestation and the policy that produced it, plus the artifacts the vulnerable package lives in. Your team, or an AI agent, triages it and records a versioned risk assessment, which goes into a VEX feed and the control gates. Changelog: Control the Autopilot covers how much of that workflow Chainloop runs on its own per severity.

The whole picture

Put together, the lineage view answers the questions from the start of this post on one page. For one AI coding session, you see:

• The agent, model and spec behind the change, and the lines the agent wrote.
• The pull requests the session fed, with their policy checks, AI Session Score and security context.
• The merge commits, and the gates, scans, builds and release processes that ran on them.
• The artifacts built from those commits, and the environments where they run today.
• The open findings on those artifacts, and where each one is in triage.

Attestations connect the steps

Every step is an in-toto statement in a DSSE envelope, packaged as a Sigstore bundle with the certificate and timestamp needed to verify it later. The payloads go to your CAS backend under the digest the client computed and the server checked, so an edited transcript or SBOM no longer matches its reference. The links between steps are commit SHAs and content digests inside signed statements. The lineage is therefore a walk over evidence you can verify, and the same policy engine evaluates all of it.

The lineage view adds no new data, because it reads the graph that sessions, PR scans, managed scans, builds, deployments and findings already write to.

Next steps

Everything in the lineage is already in the Chainloop graph, and you can walk it yourself with chainloop discover. For example, chainloop discover -d <merge-sha> starts from a merge commit and finds the sessions that contributed to it. The lineage view is one practical visualization of that graph, centered on the AI session lifecycle from prompt to production. We plan to add other perspectives over the same graph, such as views that start from a security finding.

To try it, the AI Sessions quickstart takes you from installing the CLI to your first recorded session. To see the session lineage view on your own repositories, talk to us. The session collector, the evidence store and the policy engine are open source, and if you like what we are building, star the repository.

Follow the Chainloop blog for the next parts of this series on AI governance.