Provenance, signing, and where jobs run

What Canon records for each run

Each run records how work moved through the flow: the compiled stage graph, the candidate commit each stage worked on, the outputs handed from stage to stage, and every human gate decision. The run issue in your repository is the readable record of stage status, outputs, retries, loop-backs, and failures.

Where the build runs

On hosted CI, not on a developer's laptop. Canon compiles the workflows, and GitHub Actions runs them in your repository. Provider credentials stay in GitHub Actions secrets. Canon does not write them into generated files or run output.

Who can publish or sign a release

No agent can. Agents never receive the credential that merges, tags, or publishes.

• An agent job returns its source changes as patches. It cannot push.
• A separate trusted publisher checks the paths, the patch, and its provenance, then applies it with a short-lived, operation-scoped token brokered through the Canon GitHub App.
• Release tags (v*) are protected by a ruleset that names the Canon GitHub App as the only actor allowed to create them.

The authority an agent does have is set on the flow. See Connections, tools, and agent authority.

SLSA

Canon does not produce a certified SLSA attestation today, and claims no SLSA level.

• Builds run on a hosted CI platform. That is the shape SLSA describes at Build L2. It is not an L2 certification.
• Publication credentials are isolated from the agents doing the work. That is the idea behind L3. It is not an L3 certification.
• Signed provenance documents are planned for the release path. They are not available today.